It was 2017, and a small team at the recently-merged (HART + Fieldbus Foundation) FieldComm Group unpacked an old demo from the days when the Fieldbus Foundation’s marketing committee would host workshops around North America. It was a simple, level-cascaded-to-flow, “live” system assembled with donated instruments from the committee’s sponsors.
It included a small DeltaV DCS that had been returned when the demo was mothballed. Resurrected for an overseas conference, the small team was shocked and pleasantly surprised when the demo fired up and controlled level before the DCS showed up. No DCS—it had retained its configuration in the Pelican case for more than two years, including all the function blocks that had been downloaded to the instruments.
Once powered up, the backup Link Active Scheduler (LAS) took over and resumed controlling the little process. You can watch the drama at https://t.co/HGmpb1pZhY—a success that portends a lesson about Foundation fieldbus’ troubles and potential (inevitable?) sunset.
A brief dialog sprang up on the mostly-quiet ISA Controls list serve last month, framed by the question, “Is fieldbus dead?”
Is Foundation fieldbus (FF) dead? It’s a valid question. EPC firms that have some fieldbus expertise are seeing fewer end users who insist on FF for new projects, retrofits or upgrades. Even big oil companies that were vocal FF advocates five years ago are no longer requiring new projects to use it. Though their FF projects were nearly all great successes, rough edges like cumbersome device replacement took its toll on the thinning ranks of FF advocates. So, despite thoughtful standards, training, recruiting and so on, even big companies struggled to maintain a healthy nucleus of fieldbus practitioners. And as the ranks of I&C people have dwindled through headcount cuts, transfers, retirements and other attrition, any appetite for discretionary challenges like fieldbus has become proportionately less.
One fieldbus culture change was especially irritating: it fomented an awkward interplay between DCS (systems) people and instrument (field) people who previously lived in almost separate worlds. Because field devices now participated in control schemes, and had function blocks configured in the DCS and stored in its database, DCS engineers were intruding into the instrument department’s bailiwick. And because field device service often had systems-level impacts, the instrument person’s muddy footprints were appearing in the sacrosanct DCS room.
The remarkable resurrected demo dramatized a unique property of FF many of us didn’t comprehend: except for an operator interface, engineering interface or alarm system, FF was a fully functional distributed control system, operating on its own self-sufficient protocol, network and operating system. What this translates to is, any DCS supplier that sought to support FF was really constructing an interface to a foreign system—FF had its own network with its own rules, function blocks, baud rate, physical layer, etc.
[javascriptSnippet]
Out of respect for their installed base, most capable suppliers of DCS systems were reluctant to leave legacy systems in the dust to fully integrate this new protocol. Hence, many end users received products with clunky or incomplete support for FF. Early on, it was probably as important to be able to say, “We support FF” as it was to produce a system that seamlessly exploited all its features and capabilities.
Choosing fieldbus remains fundamentally a systems decision. It was envisioned to become an integral part or extension of the DCS, and it needs to be tended by systems-capable individuals, whether they wear steel-toe shoes or sneakers. Meanwhile, end users are just trying to find people who will show up for work.
Will future systems decisions ever turn on FF capability again? That will be a big factor in whether there’s a new dawn for the protocol. FF retains numerous strong selling points for the future—but will we find enough suppliers and end users who know how to sell it?
