Voices: Rezabek

Hungry for Open Network Protocol Standards

You Just Can't Be Apple to Your Customer and Control Every Widget You Sell

By John Rezabek

A few years ago, our site upgraded the natural gas metering for custody transfer with a remote terminal unit (RTU), which now transmits our daily gas usage over a cellular connection to our supplier. The single-board device simply populates its data table by polling our DCS over a Modbus serial link, and then "phones home" using a cellular modem. We're hardly taxing its capabilities, which include interfaces for multiple positive-displacement or Coriolis flowmeters, temperature and pressure correction, and meter calibration checks. It's a powerful little box, customized for this sort of point-of-sale custody transfer application.

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!

More from this voice

Title

Right Message, Right Person, Right Time

Data Doesn’t Always Equal Information. Why Can’t We Get Alarm Information to Our Operators in a More Meaningful Way?

01/03/2008

Yikes! Look out for that Chasm!

The best practice by far is to choose a main instrument vendor who is accountable for the integration of all field devices.

12/03/2007

Load ’Em Up!

If we know the element will respond in a second at best, why compute a new output four times a second?

11/06/2007

Portable Diagnostic Tools – Who’s the Best?

So what do I grab when heading out the door to troubleshoot a suspect segment? More often than not, it’s the FBT-6.

09/27/2007

Lipstick on Modbus

There are people who would rather take a flogging than maintain an OPC installation.

08/31/2007

Justifying Fieldbus, Part I

Asset management and wiring saving cost were common justifications for installing Foundation fieldbus in refineries 10 years ago. Today, the cost to replace DCS with electronic field devices must be justified.

07/13/2007

One bus for all?

When it comes to applications that allow our basic controls to function, system lock-ups are intolerable, so it pays to examine the heritage of fieldbus and carefully analyze the market that shaped it.

05/06/2007

Tolerate less redundancy

Today, with Foundation fieldbus, the old redundancy paradigm no longer applies. Chances are, though, it isn’t free. So where should you apply it to achieve the fault tolerance you need?

12/05/2006