Will an Ethernet-APL standard leave the door open to proprietary solutions?

Nov. 2, 2020

[sidebar id= 2]

Into a trove of complex and highly customized, proprietary DCS offerings—which included their own heritage Provox and RS3 systems—Emerson, then Fisher-Rosemount, introduced DeltaV a quarter-century ago.

With its name signaling a change in velocity, DeltaV was introduced, leveraging Microsoft Windows-based PCs, operator interfaces from Intellution, OSIsoft’s PI historian, National Instruments’ fieldbus interfaces, and a control language largely based around the very new FOUNDATION fieldbus function blocks. Compared to the systems they were aiming to replace, Fisher-Rosemount’s team was manufacturing next to zero hardware for their DCS, which was all connected by the “10BaseT” Ethernet of the day.

One thing they did construct was an engineering interface whose core promise was easy. EasyDeltaV was modeled around a graphical drag-and-drop interface that aimed to facilitate automatic discovery and easy commissioning and configuration of all system components, utilizing evolving Windows graphical-user-interface (GUI) conventions of the day, like right-click menus (such menus were for power users back then) and thoughtfully constructed and informative, context-sensitive help. It was a brave departure from the conventions of the 1990s on many fronts, including its early commitment to fieldbus.

Fieldbus was likewise embraced by several early adopters that included Shell, Saudi Aramco, and BP, among others, who all expressed enthusiasm, citing savings and successes. The ambitions of big oil and similar big-dollar end users compelled other DCS suppliers to develop some manner of fieldbus interface, often with mixed success—grafting FOUNDATION onto legacy systems for fear of alienating their installed base.

There arose challenges even for the built-for-fieldbus DCSs like DeltaV and Smar System 302: the consensus protocol wasn't always interpreted equally by all device suppliers, even though the Fieldbus Foundation was compliance testing and certifying all new devices. Test beds sprang up in nearly all of the major suppliers’ manufacturing centers, where they maintained their systems (sometimes more than one generation) with their devices as well as their competitors, all strung about on FOUNDATION segments to find issues before frustrated end users experienced them.

Pesky bugs were one thing—but an even greater source of dismay arose when a device needed maintenance. Device replacement was substantially more complex than 4-20 mA. Digitally integrated devices on a new and “autonomous” network behaved as if they were part of the DCS, and most times you couldn’t set one up with a handheld communicator on the bench and slap it in place of the old one. Engineers were being called out in the middle of the night because technicians couldn’t log into the engineering interface to complete commissioning replacement devices.

ExxonMobil was glaringly absent from the ranks of fieldbus adopters, despite a leading role in the development of the protocol. Why? There’s a story of football legend Vince Lombardi challenging his coaches to make sure every play was readily grasped by all players. ExxonMobil saw the world in a similar fashion: a midnight callout could randomly fall to any individual, potentially the fellow with the least training, the least experience, and the most limited understanding of digital systems. Let’s call him Bert. If it was too complicated for Bert to follow a procedure and get the process back to having a reliable measurement—on his own—it wasn’t going in the playbook. As more of the EPC and end-user community came to view FOUNDATION as “too complicated,” the protocol lost its luster and adoption slowed.

Ethernet’s present-day ubiquity might ease the anxiety over adopting any future bus like those that might exploit the Advanced Physical Layer (APL) currently nearing commercialization. But will suppliers use an open protocol or steer users to a proprietary solution that confines customers to their ecosystem? Next month, in Part 3 of this series we’ll inquire: can even an Ethernet-based, open protocol displace proprietary networks?

[sidebar id= 1]

About the Author

John Rezabek | Contributing Editor

John Rezabek is a contributing editor to Control