If the word “interoperable” was in the dictionary prior to 1990, it certainly wasn’t in the vernacular of control professionals. In retrospect, we now realize that the pneumatic and single-loop electronic controls we were busily replacing with the second-generation DCS—a centralized, proprietary, microprocessor-based control system—already possessed this “new” property we were specifying for the advent of fieldbus. Today, a new world of Ethernet-based fieldbus beckons, and the explorers and nerdy early adopters are imagining their vessels and loading their tenders for the voyage over the horizon. Among those who were present for the last century’s foray into a single, interoperable, twisted-pair fieldbus, some are concerned that the rough seas that foundered that generation’s fieldbus are still stirring in the distance.
The red flags of troubled relationships and high seas were present three decades ago, but somehow we glossed over them and moved on. One of them appeared in the earliest beta (alpha?) test I can remember, where a trial FOUNDATION fieldbus H1 segment was connected to a then-modern, arguably industry-leading DCS at a chemical plant in Texas. It was considerably less than a smashing success, but again we were somehow happy that “it worked.” If the fieldbus folks acknowledged that red flag—that it required a customized, proprietary and sophisticated control system to interact flawlessly with an entirely foreign, autonomous and independent network—they did little to modify the specification. This issue would haunt and stifle the adoption of fieldbus, as suppliers needed to turn over a generation of battle-tested solutions before offering a system that was fieldbus-capable. Even after finally adopting a fieldbus host capabilities test for the centralized DCS, system support and integration remain a trouble spot for many.
Back in the 1990s, there were enough of us around that were bothered by the oxymoron of the centralized-yet-distributed control system, with its many eggs in one basket. Despite obsessive (and expensive) redundancy, issues would still emerge. The chip-ware of the day meant “fast” loops (as in executing once a second or better) were also configured at a premium. The fieldbus standard was called on to solve this, and the vision was lovable to those who remembered the virtues of single-loop integrity and determinism, abandoned when we installed the DCS. While it had a certain elegance and made sense in one’s imagination, it created not only a foreign, independent network for the host to integrate, but an entirely independent control system. The DCS supplier had to create and support engineering tools for configuring, interconnecting and scheduling the function blocks executing in any manner of field devices from other vendors. Some suppliers simply chose not to support control in field devices, and interacted with H1 in a SCADA-like polling fashion.
Supporting the elegant and complex function blocks and deterministic network of H1 created challenges for the device manufacturers as well, even those who had a DCS offering. Imagine a transducer block and an analog-input block coexisting in the same device that won’t play well together. It might seem absurd, but it was another red flag that we were straining the resources of the supplier community. Just last year, we struggled to get a measurement to appear from a well-engineered ultrasonic flow instrument, until we found the individual at some level of the company who remembered that its analog-input function was tied to a computational block, not a measurement channel.
Lack of backwards compatibility also manifested itself at the field-device level, as sites with a large inventory of HART-smart devices had no practical path for adopting fieldbus aside from rip-and-replace, and then only if or when their host supplier supported it. Presently, Ethernet-APL devices for multiplexing HART and conventional devices are being developed, but there’s no clear path for the not insignificant installed base of H1 devices.
Will the coming digital integration adventure benefit from these lessons, or do the same troubled seas await? The old salts from the last voyage are concerned, and we’re hoping for smoother sailing than the last time around.
Reader Feedback
I’d like to complement John Rezabek’s discussion of lessons learned from Foundation Fieldbus that we can apply to Ethernet-APL with one important dimension that wasn’t even part of the conversation in the early days of fieldbus: cybersecurity. It is likely that multiple communication protocols will use Ethernet-APL: HART-IP, EtherNet/IP, Profinet, etc. Since they will all use the same Physical Layer, the different protocols will be able to coexist on the same wire-pair. This has already been demonstrated at trade shows. The new dimension of cybersecurity will require some sort of join process to ensure the correct device is being added to the network. Whatever steps a user must take to add a device to the network, it is imperative that it be exactly the same for each and every protocol. Otherwise, the market for this new technology will fragment. The end user community does not have the staff to absorb multiple ways to add a device to a network. There are other considerations such as encryption and authentication technologies, but all of this must be transparent to the user. The market success of Ethernet-APL will depend not only upon those items John pointed out, but also on the way in which cybersecurity is implemented.
Marty Zielinski
Technology Director, Retired
Emerson
[email protected]
