By John Rezabek, Contributing Editor
The HART Communications protocol has been around for more then 20 years, and is perhaps the only one from its generation whose installed base continues to grow. With more than 20 million intelligent devices installed, you might wonder whether a new and expanded specification amounts to “fixing what ain’t broke.” Ed Ladd, of the HART Communication Foundation (HCF), says, “Our most recent report shows more than 70% of all process instruments shipped are HART-enabled.”
By short-circuiting the bogged-down ISA SP-100 path to a wireless standard, HART 7 allows suppliers and end users to begin manufacturing, selling and implementing wireless networks in a way that wasn’t previously possible. Along the way, the architects of the new standard seized the opportunity to plug some holes that increasingly were seen as fatal flaws relative to more modern standards like Foundation fieldbus (FF). With some major EPC firms in both hemispheres saying that up to 70% or more of projects adopting FF for large expansions, additions and greenfield sites, and with the successful demonstration of FF for SIL-rated process safety interlock applications, concern that HART was in danger of losing its dominant market position is not unreasonable. Will HART 7’s new enhancements bring it up to par in the eyes of the decision makers who wish to exploit state-of-the-art digital integration of field devices?
Like other fieldbus protocols, HART was poorly supported, if at all, in the large legacy DCS and PLC systems of the 1980s and 90s. But many plants are still running on this legacy installed base, and many of those may remain that way for years to come.
Safety-instrumented systems (SI”) can account for two-thirds of the I/O in some processes or production sites, and even today, few SIL-rated logic solvers support either native HART or any other fieldbus I/O. Users who try to exploit wireless or HART 7 diagnostics for safety applications may find themselves straying a bit far from the herd. A plant near me, for example, is implementing WirelessHART to provide secondary level indications on storage tanks. Its tanks contain substances much less benign than milk, and whether a wireless installation provides any ndependent protection layer” is worthy of some debate. Will HART 7 features rescue users who might be poised to “jump too soon?”
Since today’s wireless transmitters typically “go to sleep” for anywhere from 60 sec to 1 hour or more (primarily to optimize battery life—they are capable of sub-second measurement and transmission), they “wake up” to make a measurement and transmit it in a fundamentally asynchronous fashion. Consequently, the old HART model of master-slave polling had to be adjusted to one that accommodated considerably more field device autonomy. This same property will be part of new “wired” HART 7 devices, so they now can independently send time-critical, time-stamped alerts to a host that has the smarts to “hear” them. One will not have to wait on host or asset management system based “polling” to detect a condition that needs more urgent attention—the transmitter sends the message along with a time stamp immediately when the condition is detected.
Present-day HART 5 and later devices have a status bit that’s set when the device has an issue, and if the host is set up to read it, it can subsequently poll for more detailed information about the problem. How well this all happens, how fast it happens, or whether it happens at all, is worth some investigation on the part of end users who are aiming to exploit these features. If you’ve implemented any OPC, you have doubtless noticed that compliance to the standard is very much a matter of interpretation and has been the source of many headaches for end users. HART has always provided test tools for manufacturers to validate their devices conformance to the standard, but the degree to which a feature is implemented or exploited can vary widely, especially on the host end.
Eric Schnipke, process control specialist at the INEOS Acrylonitrile facility in Lima, Ohio, remarks, “We recently installed a new HART-capable control system with the hope of bringing in engineering units and secondary variables of all HART devices, but quickly realized that the older HART revisions were not supported by the system.”
It’s estimated that fewer than 20% of end users with existing HART-smart devices are using HART for more than initial configuration and re-ranging. If the end-user community consists of few pioneers blazing the trail, we are at the mercy of the supplier community to “do the right thing, and advanced users are on the wrong end of the Pareto charts.
“We have to do what the market demands” says an engineer at a major DCS supplier. “HART, Foundation fieldbus, Profibus—we support them all, and the specs keep changing. With finite resources, we continuously prioritize our investments in those areas where we anticipate the greatest value will be delivered to the clients.”
Schnipke hit a few speed bumps during hot cutover: “Once you have the system, there’s no guarantee you’ll be able to make use of all of your HART devices or that all devices of from the same vendor will behave consistently. Two different versions of valve positioners from the same vendor did not have the same engineering units. This was the source of much confusion when configuring the XD_Scale (transducer scale) of the associated analog output blocks.”
Users attempting to use some of the advanced features have been experiencing more frustration. For example, one end user is aiming to use the HART range-change bit to flag when a technician makes a range change using a field communicator that doesn’t match the host. “You’ll find that the function isn’t clearly specified. Each vendor has implemented the function differently—or ignored it. There is no definition of what a host should do with the bit or how a device should implement the functionality, and there is no ITK (never has been) to test functions such as this.”