The neighboring plant became an early adopter of fieldbus when they chose the technology for an upgrade from primarily older pneumatic controls to a modern microprocessor-based DCS. In the early years of this century, choosing fieldbus meant limiting the field of potential suppliers to a smaller subset, since a number of the major players had incomplete or nonexistent offerings. There was the chaos caused by mergers and acquisitions. And many of the players were concerned about their installed base—DCS solutions of the 1980s and ’90s that were still being sold to new projects in 2001. Somehow their fieldbus offering would have to be grafted onto the DCS solutions of yore. For nearly all suppliers, the new technology was more threats than opportunities.
Grafting fieldbus onto old DCSs turned out to be challenging. The very first demonstration took place at Chocolate Bayou, Texas, with an LCN-based Honeywell system. I think the message from that experience was: “Well, it worked eventually, but we’re not trying that again.” Many DCSs of the day were configured using a fill-in-the-blanks, text-based interface, which was not especially compatible with the new function-block (object)-based model incorporated in fieldbus. There were schedules and macrocycles to mind, and every segment introduced numerous additional intelligent devices, each with its own repertoire of parameter-laden function blocks. Messaging was according to the fieldbus standard, which was layered and highly evolved, but foreign to every vendor’s in-house solution. So hardware to provide a robust and hopefully “seamless” gateway for the new protocol had to be invented and tested. I remember a slide from a supplier’s roadmap presentation that depicted jet engines photoshopped onto a B-29 bomber from World War II—very succinct and accurate, in retrospect. I don’t think even the most jaded end user of that generation’s hardware fathomed how inherently constrained and limited their old DCS was. We were all still wearing pagers and connecting to the office with a phone modem, you might recall.
But if you were building a new plant in 2001, or updating old pneumatics, forward-thinking end users sharing a vision for the power of digitally integrated field devices didn’t want to install a legacy solution tied to 1980s-era tech for decades to come. Unfortunately for some—perhaps even a majority—they ended up with a grafted-on version of fieldbus. The troubles of these systems left them in a “trough of disillusionment” that persists to this day. The trough is especially long-lasting because the update required—a new DCS—is itself disruptive, near zero ROI, and far from inexpensive. So the “Smurfed” delivery of fieldbus goes on, and is even more egregious to their successors, who have inherited the system and been left to figure out how to deal with its foibles.
Over the 10 years since our neighbors installed their fieldbus system, end users finally persuaded system suppliers to undergo “host registration” testing, which aims to ensure at least rudimentary support for most fieldbus features at various levels of achievement.
It took 10 years. But it comes too late for some of the numerous sites that made an unfortunate choice in the early going.
There’s a useful lesson here that I think today’s seekers of digital integration (and more)—namely, the Open Process Automation (OPA) Forum led by Exxon-Mobil—have taken into account. No path to standardized digital integration can be defined from one side only—you can’t define a standard for field devices, simply dump it on the systems designers, and expect it to work seamlessly.
Standards create uncertainty and risk if they’re vague about how all the pieces are meant to interact, and the gateway to legacy platforms is especially important.
It’s “Smurfed”—that’s when fieldbus data turns blue on the DCS. The OPA initiative will offer a path for end users like my neighbors to migrate from kluged systems, segment by segment, and use their installed base of fieldbus devices. The days when the “bus is Smurfed” could become just a bad memory.
