s the number of fieldbus projects continue to increase around the world, it seems that for every one of these new or retrofit installations, digital communications technology has either been deployed, or at the very least, seriously considered as a viable option. The sad part of it is, is that in the wake of these projects, many have yet to take advantage of this technology and reap the benefits of their investment. Similarly, while many a project has initially been successful, plenty of companies are having difficulties with their installations and are blaming it on the technology.
Many automation professionals and practioners believe that because the developers of the fieldbus standards did such a good job of minimizing the impact of the technology on the actual sensors (front end) and Human Machine Interface (HMI)(back end) of fieldbus installations, they are no different than conventional or normal.' We should know better than that. Especially since there are often difficulties in converting from one model of a device to another.
The most common real' problem is the lack of knowledge about the technology at all stages of the project: design, installation, and most importantly operations. How does this lack of knowledge or understanding impact each of these parts of a project?
Many engineers and designers believe that the various fieldbus devices are not much different than what they were to working with in the past, and they are right about the sensor or controller anyway. What has changed significantly is the way in which a fieldbus device connects to the remainder of the control system and communicates with the host and other devices on the network.
Notice the word "network" in the last sentence. This is significant since it represents the largest change in thinking required for the design process. Each device be it a transmitter (analog in), valve or VFD (analog out) or contact (discrete in) or relay (discrete out) is now part of a system, which implies that it is no longer an island onto itself but rather that a change at the device level must and will be propagated to the remainder of the network which in many cases includes the other devices and the central controller.
Depending on the type of fieldbus installed, and the configuration of the network (token ring, star, bus, or combination, etc.) the impact of the addition of deletion of a device will be different. Take for example a Foundation fieldbus chicken-foot, or tree configuration in which multiple individual field devices terminate in a field junction box where they connect to the "home run" cable to the host computer. This configuration is very similar to what the industry has used for many years. Multiple devices connect to a "central" field terminal box from which a multi-conductor cable runs to a host computer and where the individual signals are terminated on the appropriate I/O card. Figure 1 shows conventional I/O termination and Foundation fieldbus termination and both illustrate how this installation actually differs.
Figure 1: Fieldbus vs. Conventional Configurations
Note that not shown in the drawing, but important nonetheless is the fact that because the fieldbus is a network, it will also require terminators at each end of the network to balance the impedance and avoid "reflections" and associated signal degradation. Termination details for each individual fieldbus network is different and therefore must be given careful consideration as part of the design. Similarly, calculations on network loading, voltage, and current at each device, as well as communication cycle time, jitter and cable layout must also be considered within the context of the network's design.
If the design engineer only takes into account the networking differences between conventional and analogue systems, he or she is missing a great opportunity to significantly trim costs over the life the installation. Since fieldbus sensors support digital communications, it is possible for those devices to transmit multiple process variables from a single field device (Figure 2).
Figure 2: Multiple Process Variables
For example, a differential pressure transmitter can not only send the differential pressure or (if desired) flow reading, it can also transmit the upstream pressure reading as well, without the requirement of additional wire pairs or sensors. For a Coriolis meter, the opportunities are even greater with mass flow, temperature, and viscosity as possible outputs. Of course, fewer sensors mean fewer process connections and, consequently, fewer potential leak points requiring EPA monitoring and enforcement.
If the engineering and design process has been properly done and documented, then field construction should not be significantly different than that of a conventional system. The main difference is likely to be the type of terminations required for the device. The good practice of separating different signal voltage types remains apprpriate, as does implementing the various other electrical code requirements.
Special tools are required to monitor the ability of the infrastructure to support digital communications, though conventional analogue devices continue to be used to monitor voltages, currents, and continuity. In some cases, these tools are only available on a laptop computer, though most fieldbuses have simpler hand held troubleshooting tools that can be used to conduct preliminary analyses of systems.
Because fieldbuses expand the network to the device and these devices communicate digitally with the host, a much richer data environment exists (Figure 3). Almost all fieldbus systems have some form of diagnostic, or quality of measurement signal associated with each device on the network. Operations and maintenance people must make a conscious decision on how to handle and process this extra data. In addition, these people, as well as engineers, must have a clear understanding of how the various alarms will be handled by the control system.
Figure 3: Expanded System and Data View
In the early days of Foundation fieldbus, one control system supplier was unable to differentiate between an alarm due to a device failure on the network, and an alarm due to the failure of a system controller. Both were treated as system-level alarms, which they were, since both occurred on the network, and hence, at system level. However because of the severity of the alarm, it was not possible to disable the device from alarming, and as a result, if any other alarms at the system level had occurred it would have been masked by the alarm because a flow transmitter had failed.
Unfortunately, of the people impacted by this alarm many did not realize that first, the devices were capable of initiating a failure alarm and that second, the level at which this alarm was assigned. The end result was that the operators were under the impression that Fieldbus doesn't work because they always get this alarm, when in fact, it was working as it was supposed to by annunciating that the device had failed.
Ironically, when the original analogue device was replaced and removed from service, it was found that the impulse lines were so plugged they could not be cleaned and new taps had to be used for the Fieldbus installation. Fortunately, in the abovementioned incident, the maintenance technician who installed the Fieldbus transmitter recognized the transmitter number and correctly inferred that the impulse lines were plugging. The technician then cleaned the impulse lines and the alarm also cleared.
Since fieldbus systems are networks, and must communicate with the network to be operational, the most significant practical change that maintenance personnel must cope with is that they have to work on the device and network while it is "live." If the device is not live, it will not be powered and communicating, nor will it provide the technician with the information required to diagnose and resolve the problem.
Not only does this have implications on the types of tools required but also, to some extent, on the engineering design because the design in question must take into account that the field devices must be live and hot with covers and enclosures open.
The other major shift in work procedure is that if a change is made to a device in the field, it is now "automatically" propagated to the host and a "mismatch" will be identified and flagged. Or, depending on the configuration, the change disallowed. It may be that in some instances, the range changes etc., will now be executed by the applications engineer and transmitted from the control system to the device to insure data consistency.
Fortunately, fieldbus systems will offset their increased operational complexity by providing a variety (depending on the fieldbus level) of different diagnostic capabilities. If properly utilized, such diagnostic capabilities can support a predictive maintenance-based system, rather than a schedule-based system, or worse yet, a reactive, fix-it-when-it-breaks non-system! Regardless, the net benefit of a predictive maintenance system is usually significant overall operational savings.
What can be done to minimize the abovementioned opportunities from being lost, or more importantly preventing such errors from ever being made? We all know what "experience" means, it means "I've made that mistake before." The key, therefore, becomes collecting such experience second hand. This can be done in several ways. One easy way is by reading periodicals and other articles (like this one) and studying the hard-won lessons learned by the many colleagues who have proceeded you into battle. In other words, learn from what they have learned. Unfortunately, other folks often require a larger investment in time and money to learn the same thing.
Each of the fieldbus-supporting organizations either offer training courses themselves that provide, at minimum, an introduction to the technology, along with online mini-tutorials delivered via their website as either slide presentations or downloadable manuals. In addition, there are also a number of institutions offering training in fieldbus technologies, some of them certified by the supporting fieldbus organization.
An alternative is to attend the training offered by the host system supplier, especially if you are at a facility that has a long-term training agreement with the vendor. The problem with relying on manufacturer-specific training courses is that they may present a view biased toward their system's technical attributes and offer trainees a narrow, or limiting perspective, rather than a balanced view of the entire open fieldbus technology option.
Consultants, though often expensive, can be extremely valuable if their experience and expertise are applied at critical points along the project's timeline. Generally, it is not normally the most economical choice (with the exception of perhaps really large, big-budget projects) to hire a consultant full time. What is more prudent and cost-effective is to have this person's skill and knowledge applied only at points were their advice can have the largest impact. In the case of engineers, this is likely during the project's initial scoping, then again at significant engineering review milestones. For maintenance projects, it may be at the start of outage planning activity.
In effect, you are outsourcing knowledge work. As Peter Drucker noted in the January 12, 2004 issue of Fortune magazine: ",because knowledge work by definition is highly specialized...the utilization of the knowledge worker tends to be very low. What outsourcing does is greatly improve the quality of the people who still work for you. When you outsource to a specialist, he is busy 48 weeks a year, working for you and a number of other clients on something he sees as challenging. Whereas, the same person employed by the company is busy six weeks a year and the rest of the time is writing memoranda looking for projects. That's why when you outsource you may actually increase costs, but you also get better effectiveness."
The risk of hiring consultants, of course, is that they do not effectively transfer the core knowledge required for your staff to proceed on their own, but that is another issue entirely and one thoroughly covered elsewhere.
As the incident with the flow transmitter described above indicates, the most important measure that can be taken to prevent difficulties with a given fieldbus project is communication. Items to be communicated include:
Fieldbus and digital networking is fast becoming an integral part of the automation infrastructure of many of today's facilities--both as greenfield installations and as part of a retrofit or upgrade process. It is therefore important that automation professionals obtain a high-level understanding of how these systems work, the importance of communicating the operational changes they bring to others in the organization, and recognizing when it is time to bring expert help on board to obtain the best results.
Remember the definition of "experience" is that you have made that mistake before, while the definition of an "expert" is someone who realizes what they don't yet know, but does understand how to get that knowledge.
Ian Verhappen is Director at ICE-Pros, Inc. an independent Instrument and Control Engineering consulting firm specializing in fieldbus, process analyzer sample systems and oil sands automation. Verhappen can be reached at Ian.Verhappen@ICE-Pros.com or through his web site at www.ICE-Pros.com.