About the author
John Rezabek is a process control specialist for ISP Corp., Lima, Ohio. Email him at [email protected]A quarter century ago, trumpeting one’s “open” system capabilities was an essential marketing tagline. But in the early 1990s, I wouldn’t say we had a gnawing hunger for a fieldbus solution. Digital integration of field devices—now all the rage as we embark on the “new” Industrial Internet of Things (IIoT)—was an available option with our then-current Honeywell LCN-based hardware. “Things” had to be integrated using Modbus (e.g., gas chromatographs).
If you installed certain Honeywell smart pressure and temperature transmitters, it could happen using their proprietary “DE” technology. Of course, none of these “things” were autonomous or could interact with each other—they just dutifully responded to the requests emanating from the DCS. While Honeywell DE was closed and proprietary, it threatened to win enough projects through “bundling” (combining a massive transmitter order with a systems proposal) to inspire creation of the HART communication protocol.
As we started adding “smart” valve positioners—arguably one of the more interesting devices to have digitally integrated with the DCS—they not only wouldn’t talk to the host, the HART communication caused the I/O to go to an error state. You had to add a “HART filter” to keep the signal from disrupting the loop. Proprietary barriers and lack of interoperability added to the impetus to hasten the development of a single, interoperable process fieldbus.
[pullquote]But now, closed (proprietary) solutions have become so commonplace and successful (have an iPhone?) that we seem to have lost touch with the value of openness we pined for back in the 1990s. It seems like many of our pathways to interoperability, even today, involve complex or convoluted mapping like Modbus or OPC. So when projects are lightly manned, short on expertise and/or in a hurry, the appeal of a tidy proprietary solution is hard to resist. When the project is started up and producing saleable product, none of the investors likely care whether the process control system employed an open solution. The plight of the operate and maintain organization, who are forever strapped to a single solution provider, is precisely what we were hoping to avoid when fieldbus was conceived. In the mid-1990s, when the Fieldbus Foundation finally picked up the mission of providing a process fieldbus solution, their tagline read, “The Freedom to Choose, the Power to Integrate.”
The initial excitement about fieldbus had a simpler basis and appeal for the project builder. It promised to save you millions in copper, i.e. less wire, cable, conduit and labor for terminations. For most projects that covered more than, say, half a city block, the savings were significant and measureable. But the same projects found they were spending more on the cable, termination hardware (e.g., couplers with short circuit protection) and fieldbus devices.
Having found the shine of installation savings tarnished, projects considered the other deliverables of fieldbus—determinism, open communications, autonomous devices, function blocks and the user layer—not especially relevant or critical to project execution. These are part of the specification because of the issues their clients experienced with closed systems. But today, unless a committed end user insists on fieldbus, projects seem happy to defer to the expedient and/or the low bidder.
If this new era of digital integration is about to engulf us, it’s not unlikely that innovations for consumer and business networks will bleed over into process applications. End users and suppliers who understand the value of openness, interoperability and time-critical/synchronized, prioritized communications should have an interest in shaping its application and standardization. If we can revisit and grasp the values and priorities of 25 years ago, we might have a new opportunity to craft a single, interoperable process fieldbus.
