Lessons learned from fieldbus users can help improve systems, performance and personnel. Part 1 of this three-part series discusses how wiring mistakes interfere with communication. Part 2 examines how configuration and addressing make all the difference.

Over years of visiting end user sites, talking to system integrators, and internal conversations with others within our own company, tribal knowledge begins to accumulate of what works, what doesn’t and what can be improved. When working in a Foundation fieldbus (FF) context, we find some user companies swear by the technology and won’t consider anything else, while others cannot claim such positive experiences.

When considering what differentiates enthusiastic users from those who gave up, many of the same top 10 points emerge.

Some of these points are specific to Foundation fieldbus and others are more universal, so even if you aren’t a Foundation fieldbus user you might find some familiar topics addressed. This article covers the final three points, and you can go to more comprehensive sources such as Fieldbus Foundation for more information. Here are the Top 10, plus one:

1. Wiring Practice Pitfalls
2. Terminators
3. Power Supplies
4. Stick with Tested and Registered Products
5. Incorrect DD/CFF Files
6. Using the Link Active Scheduler
7. Device Addressing
8. Choosing Between Publisher-Subscriber and Client-Server Communication
9. Traditional Project Management Techniques May Not Apply
10. Mismatch of Work Processes
11. Misunderstanding the Value Proposition

9. Traditional Project Management Techniques May Not Apply

More often than not, end users, system integrators and engineering contractors want to apply traditional project management techniques to a Foundation fieldbus project. This is not always the best course of action.

Foundation fieldbus is a device network with some general similarities to control or IT networks. A device has a network address and a unique physical address called a device ID. This is similar in concept to a PC which has a TCP/IP address and an MAC address. Multiple devices then communicate on the same pair of wires on the segment, just like multiple PCs on an IT network. Thus, analysis needs to be done to determine how many devices of each type should go on a particular segment. Many end users have their own guidelines for this analysis.

For example, loops that include a critical function must have only one valve positioner and must restrict the number of other devices on that segment in case a segment is lost. Category two segments may allow two valve positions and 4 to 8 devices. Another category description, however, may allow some measurement devices but no actuating devices.

This kind of analysis and up-front engineering effort rarely happens in traditional 4-20 mA or HART projects where devices are not shared on the wire in the same manner. When working with Foundation fieldbus, however, segment design and topology is a critical path in project management.

When going out for project bids, often there is no functional design specification that covers the design, installation, configuration, commissioning and maintenance for the Foundation fieldbus-based process control system and instrumentation. The vendor has little more than a count of various types of instruments and is left to estimate segment designs. Working in this information vacuum, the vendor may resort to imprecise rules of thumb to determine the number of segments needed.

This approach dictates the number of Foundation fieldbus H1 interface modules, which, in turn, determines the number of I/O nodes and, possibly, controllers. When the detailed design for the project is finally performed, the stakeholders may be dismayed to find that many more segments are needed. Discussions then may ensue over change orders to add modules, I/O racks and controllers, along with associated expense and finger-pointing.

Other related specification items include wiring schemes and the selection of Foundation fieldbus-related ancillary products such as junction boxes, power supplies and terminators, segment design for voltage and current consumption, selection of FF cables, shielding and grounding practices.

Another common complicating factor is failing to choose devices early enough in the project. Implementing control strategy depends on having correct function blocks in field devices. These need to be part of the instrument specification sheets so device vendors can provide transmitters with the proper functionality.

Once the project is under way, still more stumbling blocks may arise. FAT (factory acceptance test) and SAT (site acceptance test) practices for FF projects are different than for traditional device installations. In a Foundation fieldbus project, there is limited testing during FAT but all devices are tested during SAT. Sufficient consideration should be given to define FAT and SAT specifications to reduce risks during start up and commissioning phases.

10. Mismatch of Work Processes
In a Foundation fieldbus environment, work practices have to be different than in the case of traditional analog and HART installations. Foundation fieldbus is a network with its own tools for implementing, diagnosing and operating the system. Companies adopting Foundation fieldbus for the first time routinely underestimate the change in skill set and knowledge required at the technician level for the Foundation fieldbus network. On the other hand, most of the engineering personnel and technicians who have studied the technology and attended FF seminars and vendor presentations become comfortable and gain proficiency quickly.

In the real world, technicians often have Foundation fieldbus thrust upon them and are left to learn through trial and error. The result is a haphazard installation that performs poorly. Without adequate training, technicians can become frustrated with and even fearful of the technology.

Part of the training is simply getting the right tools. Instead of a multi-meter to troubleshoot conventional instruments, technicians need segment monitors, oscilloscopes or other diagnostic tools to perform similar functions with FF transmitters. Diagnostics and troubleshooting are done through computer terminals with FF-specific software and asset management systems, instead of by clipping lead wires to terminal on a field device.

A training program has to match knowledge and responsibility. Engineers who have been trained only to design segments will have a hard time training maintenance technicians to troubleshoot segments. The tasks require much different skill sets and should be considered separately.

11. Misunderstanding the Value Proposition
While this point isn’t a technical issue, it still can cause problems. Management simply may not understand the value of Foundation fieldbus, which can lead to poor investment decisions.

The right individuals might have been sufficiently convinced to launch a program, but remain unable to pinpoint where the savings are actually achieved. This outcome isn’t entirely their fault because mixed messages have been communicated over the years.

In the early days, Foundation fieldbus was touted as a way to reduce design and wiring as well as their documentation and associated costs. Those savings were real, but additional training and device costs for Foundation fieldbus transmitters compared to 4-20 mA or HART, and requirements for additional expertise, largely offsets the gains. Dollar for dollar, Foundation fieldbus is a wash if wiring and design savings only are considered.

So what has been the driving force that has kept Foundation fieldbus viable? Many have found its greatest value in the diagnostic communication from the device to the host. Instead of maintenance activities following a schedule or broad-brush directives (such as refitting all valves during a turnaround), Foundation fieldbus diagnostics can make maintenance predictive by using condition-based diagnostics to help schedule and determine which devices need attention and which are OK. Foundation fieldbus, thus, is an enabling technology for asset management that adds value at a completely different level.

Companies that deploy sophisticated asset management programs often find the biggest bang for the buck comes from more intelligent scheduling of valve maintenance. An FF valve positioner can gather and report extensive diagnostic information including, but not limited to, time near close, number of strokes and time open.

Self-diagnostic functions can detect deteriorating conditions and report problems before failure while there is still time to correct the situation. Field devices can issue messages through asset management systems to the control systems to alert (not alarm) users of impending conditions.

Who, then, is the main beneficiary of this new condition-based diagnostic approach? With many companies, it’s the maintenance department. But who specifies Foundation fieldbus for the unit? In many instances it is the engineering group. These two groups must come together to realize and properly account for all Foundation fieldbus benefits.

Maintenance is largely responsible for uptime, which should increase with Foundation fieldbus through higher plant availability and reliability. But this is true only if maintenance works with engineering and operations to monitor and determine device and segment health. All these people and departments are interrelated and must work together for the greater good of the plant. Much depends on designing and implementing new work processes to maximize the benefit offered by Foundation fieldbus technology.

Going Forward
Foundation fieldbus technology has come a long way by learning from practical implementations. End-user experiences contributed to overall knowledge, and these users provided input to vendors for improving products. Discoveries that added to users’ procedures and practices have been shared to gain benefits.

Looking over the Top 10 (11) list again, one can see many of these issues involve noise on the segment, how that causes communication problems and how to determine its origin. Other issues involve compatibility between devices and host software. And of course, people and processes always figure into the picture.

What’s on your Top 10 list of potential FF issues?

Authors: Amit Ajmeri is technical solutions consultant for Asset Management and Field Network Solutions at Yokogawa Corporation of America. Bruce Jensen is manager of Technical Marketing and Solutions Support, also at Yokogawa.