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.
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.