While I can count on one hand, thankfully, the number of unique, one-off configuration tools for which our controls people need to maintain software and stay proficient in, the spread of little specialized and proprietary boxes—RTUs and their cousins of every ilk—is marching on. With scores of small systems houses and shops producing such applications by the hundreds or thousands, how exactly will I&C professionals maintain them all?
Ponder this: There's a little, one-of-its-kind-on-your-site PLC that shipped on a package, say a deaerator or cooling water treatment skid, that stops functioning one day after 10 years of quietly doing its thing. Is the skid supplier still there? Is the person who configured the controls still around? Does the copy you have of the engineering interface from 10 years ago run on a Windows 7 laptop? Did the person you used to call at the vendor retire yet?
Aslo Read "Proprietary Protocols Hang Tough"
Lifecycle support for all these little disparate mini-systems threatens to be a challenge for most everyone. We're doing it to ourselves, or our enterprise is doing it to us, when we or they defer to expedient, proprietary solutions in the name of cost and schedule.
We need to get hungry for open standards. There's one standard whose purpose is to mitigate this towering Babel of random proprietary solutions. Called Foundation fieldbus for remote operations management (FF-ROM), it's a technology aimed at providing standardized, DCS-like tools and services for integrating data sources from remote sites. From conventional I/O to wired HART and FF to WirelessHART, ISA 100.11 and Modbus, the FF-ROM specification brings it all together. It does this by defined mappings of various signal types to FF transducer blocks, which in turn can be integrated with the entire repertoire of standard fieldbus function blocks, like analog input (AI) and discrete input (DI).
How does this help as opposed to adding complexity? Well, my current practice is to integrate these disparate signals with Modbus or OPC. It's already complex, as some data is contained in blocks of 32-bit, floating point registers, or some may be 16-bit integers. The sizes of the blocks of data, the scaling, linearization and so on is all done on a register-by-register basis. It's highly customized and a challenge to document and maintain.
Fieldbus function blocks, in contrast, are an open standard, all of which can be accessed and configured using the same tools and services from a variety of suppliers that we're already using. The AI block the systems guy configured in our system in 1999 can be configured and downloaded for a fieldbus device that was just delivered yesterday. For us, data quality is vitally important, and it's already prepackaged and delivered in the FF function block. FF-ROM would decipher the Tower of Babel—if we could buy it.
We can't buy it right now because suppliers aren't feeling any end-user pull. We aren't insisting on open solutions. But eventually, our suppliers will feel the bite of this mayhem of mini-systems, just like we do. In our scope of deliverables, you just can't be Apple to your customer and control every widget you sell.
There are many of our favorite suppliers with great products who can lead the way—as they have in the past—with open solutions. I'm pulling for them!
