Integrating the bus
A control system is only as good as its infrastructure
By Ian Verhappen
Digital communications are becoming all pervasive and certainly in non-industrial settings are now almost being taken for granted with wireless Ethernet hot spots everywhere, PDAs/cell phones in practically every pocket or purse, and digital communications/microprocessors incorporated in a plethora of other everyday products. Despite this, the adoption of similar technologies in the automation sphere has been slower than expected based on the otherwise widespread adoption of digital communications. Part of the reason may be the lack of a “killer application” in the industrial setting, or perhaps it is simply the culture of “the existing system provides me the information I need to run my plant, so why change to something new and unproven such as fieldbus?” The reason to make the change is the “opportunity lost.” A digital system provides the foundation on which significant incremental opportunities to improve facility operations can be made. Of course “opportunity lost” is difficult to quantify—sort of like buying insurance; more of a risk management item than real dollars that I lost because something happened. So why is the fact that you are not taking advantage of the digital communications in your plant a lost revenue opportunity? The reason is no different than what these systems enable, so let’s see why.
Digital systems include the hardware and associated software, and the benefits of one are not possible without the other. In fact, there are some similarities between the network communications used at the various levels of the enterprise with the complexity of the network and the associated types of applications being implemented at each of the ISA95 levels to maximize the efficiency of plant operations.
As we rise “higher” in the hierarchy of control, the amount of data, number of variables, data processing requirements, and complexity of the associated software to optimize the return on capital increases almost exponentially. However, what remains true in the hardware and software realm is like all control algorithms, or any assembly for that matter, the result is only as good as its foundation. For control algorithms, this is the base regulatory controllers and associated loop tuning, and in the case of the control system hardware that foundation is the field level/fieldbus sensor and signal network.
Since the lowest layers of the hardware pyramid are most critical, the balance of this article will focus on these lower two layers. Therefore, what are considerations that must be made to provide relay signals from these levels of the control system?
Field network layer
The most widely installed digital communications protocol in process automation is HART. There are millions of HART devices installed in the world, yet more than 80% of the time, the digital capabilities of the device are not being used. Why?
Despite being able to support multi-drop communications, practically all HART installations use a point-to-point connection. The HART protocol requires that devices must be polled for any digital information, therefore it is inherently slower than other “true” fieldbuses. However, because the process data is provided as an analog signal, does the polling frequency really matter for information other than control data? This is a question that each site/operator must answer and then design their system accordingly.
The majority of today’s control systems support HART communications on their analog I/O cards, however many “legacy systems” require installation of signal “strippers” so only the pure analog signal is received and processed by the I/O card. These stripper systems use an associated parallel data gathering system, typically a combination of RS-485 and Ethernet, to a dedicated server where the information is processed as part of an asset management system.
All HART devices can also be communicated with on a one-to-one basis using handheld communicators/laptops and foregoing the asset management system—though doing so circumvents the ability to effectively mine the device diagnostic information for trends occurring across a similar range of products, or in a specific application to help you find the root cause of failures, or as a minimum, frequent “bad actors” to minimize your maintenance budget impact.
One possible reason organizations are not using the HART data they have installed in an organized manner is doing so requires a change in culture. Some technicians are afraid that by connecting their handheld units for synchronization with a server, the data collected will be used to see how much work is being completed by each of them with associated feeling of Big Brother watching. The result is all the data is on a local laptop but not being analyzed to provide the benefits of a complete asset management system, including integration with the plant work order/planning system.
Though not as common—at least not yet—full digital fieldbus systems provide the benefits of supporting multi-drop capabilities and hence multiple devices on a single network. In the wet process industries, the two most commonly used fieldbus networks are Foundation Fieldbus (www.fieldbus.org) and Profibus PA (www.profibus.com), both using the same physical layer of individually shielded twisted pair cables wired in parallel and a Manchester encoded 31.25 kbps signal.
Both of these standards included as part of their design basis reuse of existing infrastructure and full backwards compatibility with previous versions of the protocol from revision one to infinity (whenever we might get there.) The choice of twisted pair had an impact on the noise immunity of the network and of course distance (as well as environment) in which the cable that is run affects the maximum distance the cable can be installed while still insuring a measurable signal.
Experience has also shown the biggest factor in reliability of a fieldbus system is the installation practices, simple things like making sure the connections have the proper torque, proper grounding practices, spacing between high voltage AC conductors and signal cables, and of course remembering fieldbus signals are wired in parallel so a short in one device can potentially short the entire segment unless short circuit protection is included in the field device coupler.
Culture is often less of an issue with these installations since most facilities deploying Fieldbus either migrated from pneumatic or “dumb” analog devices so the change to this new technology also brings with it the expectation of other changes to the way work is done.
By definition, field level networks include the communications between the field devices and their associated I/O card. Therefore, though it is still evolving, wireless networks such as ISA100, WirelessHART, and related industrial “personal area networks” with typical ranges of <100 meters should also be considered part of this level of the enterprise infrastructure foundation.
Though proprietary networks still exist at this layer, they are predominantly now being based on Ethernet as the associated physical layer. Practically all buses have an Ethernet version where the protocol is bundled in an Ethernet package/packet. This is because the lower levels of the OSI model provide the physical and data link layers in which the data (application and/or user layer) is then carried. The information in the data packet/user message is packaged inside the complete Ethernet packet as it passes from the user layer, where the message is created, down to the physical layer, where it becomes either a voltage (cable) or frequency (wireless) so the 1s and 0s can be transferred from one location to another. When the message is received at the other end, the process is reversed, and the voltage/frequency is converted back to the message at the user layer of the recipient. The whole process is similar to sending and receiving a letter; the message does not care if it goes by foot, truck, ship, or plane as long as it eventually arrives and can be read by the intended person.
It is also because of this functionality that the control system supplier proprietary protocol as well as the various fieldbus protocols can run on an Ethernet backbone.
It is likely a matter of time before Ethernet-based field devices become more common, especially as Power Over Ethernet can provide signal and power via a single cable. However, the limitations for Ethernet continue to be distance (max. 100 meters) and a killer application where the high bandwidth (data) available with Ethernet is required.
At the Historian+ levels, and certainly at the interfaces between each layer with Ethernet, we need to be aware of security requirements and associated separation of systems. ISA99 standards propose several best industry practices, the key of which is the concept of defense in depth (lots of speed bumps) and segregation of systems into cells, so should one cell become infected, it is not propagated to other parts of the system. A definite Demilitarized Zone (DMZ) between the business and control environment is also a must. In fact, one company insured quick separation between the DMZ and control system with a red colored patch cable to the related switches, so if necessary, they could quickly unplug this single connection and get physical separation of the system. Electrons have a hard time jumping an air gap. Remember process historians are designed to fill in missing data when they are reconnected to the control system that has its own short-term (typically 1 week) history buffer so a lost connection is not as onerous as it may first appear.
Field level networks are often taken for granted, however, as just shown, they should not simply be taken for granted because they are not as glamorous as other parts of the control system—if they do not work properly, the entire control system is susceptible to failure or as least wobbly results and that could easily lead to larger problems.
ABOUT THE AUTHOR
Ian Verhappen, P.E. (email@example.com) is an ISA Fellow, ISA Certified Automation Professional, and recognized authority on Foundation Fieldbus and industrial communications technologies. Verhappen operates a global consultancy Industrial Automation Networks Inc., specializing in field level industrial communications, process analytics, and heavy oil/oil sands automation.
Wireless field level networks
Wireless is the new field level network that has the potential to open a range of process monitoring functions and a potential abundance of new applications once this data become available. We need only look at what we now do with our mobile phones to get an inkling of the possibilities.
However, like most industrial products, the challenge will be one of being able to take advantage of economies of scale. There are two impediments to making the economies of scale a reality in the wireless space. One is beyond our control, and that is it is unlikely a single wireless standard will be correct for all the different vertical segments/industries in which automation and control is used. Most notable of these is the high speed/low data packet size (discrete status bits) requirements of factory automation versus the lower speed/high data packet (analog information) needs for process automation. The second challenge is partially a result of the first, and that is the need for standards and like the fieldbus standard the resultant multiple versions of wireless networks standards to meet each niche.
Unfortunately, it looks like the process automation industry is compounding the problem with a potential three-way offering for a wireless standard being considered for submission to the IEC. The three standards include: ISA100, WirelessHART, and a “made in China” standard, all of which will likely be put forward for consideration, and as indicated above, the precedent has been set, so do not be surprised if the result is at least two process automation standards. Consequently, neither manufacturers nor end users will get the benefits of the economies of scale that might have been possible with a single standard, and everyone loses in the end.
DD language continues to evolve
The Field Device Integration (FDI) project represents the next evolutionary step in Device Description language on which the three predominant field device protocols—HART, Foundation Fieldbus, and Profibus PA—are based. Consequently, FDI will have a significant impact on the future look and feel of digital field sensors, especially after the recent announcement that host suppliers ABB, Emerson, Endress+Hauser, Honeywell, Invensys, Siemens, and Yokogawa have joined the FDT Group, Fieldbus Foundation, HART Communications Foundation, OPC Foundation, and PROFIBUS Nutzerorganisation in pushing not only the development of this new standard but also incorporating it in their product offerings.
So what is FDI? When complete, FDI will be the replacement for all EDDL (IEC 61804 -3) based languages—HART, Foundation Fieldbus, and Profibus PA.
While EDDL is a common, text based description of a device, the text description is normally converted to a “binary DD” though a tokenizer before being shipped with the device. The above manufacturing company members of FDI have made it a high priority to harmonize the binary DD through secondary standards and tools, so the result will be a single binary format file regardless of the protocol of the device.
The EDDL file for each protocol will be processed through a tokenizer much like today—this also ensures backwards compatibility. Because each protocol is not exactly the same, but rather closer to 90% the same, it will be necessary to develop an FDI Developer environment for each of the three EDDL based protocols to assist them in defining how to map the various parameters of each protocol to the appropriate FDI parameters.
The resulting binary file from the tokenizer is then passed to a “packager” where it will be converted to an FDI file.
What is important to end users will be the interoperability of these devices, and that will be insured through the appropriately colored green “test tool” box, which will provide the necessary check mark from the appropriate organization that the devices are not only compliant with FDI but also backwards compatible with existing equipment.
Lastly, when the device is connected and communicating on the network, the process needs to be reversed with the DCS/host converting the FDI information into a format useable by the internal system databases. This is not any different than is done today, where each system needs to interpret the information from the field to the appropriate database register within the host.
Return to Previous Page