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

Hungry for Open Network Protocol Standards

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

09/08/2014

Measurement, Control Specialists Might Neglect End Users

Our Customer Focus is not Just the Investor Who’s Financing a Project or the Project Manager Beating the Drum to Meet Cost and Schedule

08/05/2014

Tinker with Defaults to Get Value From Smart Devices

Empower Your Staff So They Can Show Thoughtful, Proactive Use of Intelligent Devices, says Writer John Rezabek

07/24/2014

Forays into Fieldbus Technology Pay Off

Plenty of Training Resources Available to Get Team On Board

06/26/2014

BYOE: Bring Your Own (Fieldbus) Expert

End Users' EPC Firms Lack In-House Expertise, But Also Oppose the Idea of Fieldbus .

05/02/2014

Wireless Smart Devices: Unhand Me, Handheld!

Handhelds: What's Not to Love?

04/08/2014

Can Operators Hear the Fieldbus Music?

Operators May Not Care Much About How Our "Machines" Deliver Information, What They Care About Is the Devices Work Properly and Deliver the Right Information

03/06/2014

Automation Project Priorities: This Isn't Disney

How Often Is It That Project Priorities Align Favorably With Those of the Operate-and-Maintain Organization That's Expected to Run the Plant Safely, Reliably and Profitably?

02/12/2014

Fieldbus: Do Fence Me In!

Just Because You Can Put 12 Devices on Each Fieldbus Segment, Doesn't Mean You Should

01/14/2014

You Want More Foolproof Fieldbus?

Should We Shut Off All the Diagnostic Messages and Risk Missing Some Valuable Intelligence During Start-Up, or Leave Them All Enabled and Deal with the Nuances of the Configuration Later?

12/17/2013

Foolproof Fieldbus II

Sometimes Our Well-Intentioned Attempts to Make a System "Foolproof" Create as Many Hazards as We Were Aiming to Prevent

11/07/2013

They'll Make a Better Software Fool

Because We're Working With Hazardous Processes, We Have to Think Through the Consequences of Every Errant Mouse Click

10/11/2013

No KISS for Digital Integration?

If KISS ("Keep It Simple, Stupid") Is the Tactic to Survive the Combat, What's the Strategy?

09/09/2013

Wireless Measurements

A Minute to Measure It: Hazardous-Area-Capable Multiplexers and I/O Bus Extenders and Modules Can Simplify Heat Exchanger Measurements, Providing a Quicker Method Than Routing a Cable for Process Monitoring and a More Reliable Method Than Portable Measurements

08/07/2013

Is Fieldbus a Three-Beanie Copter Problem?

There Is Work Going on to Simplify Selecting and Designing Useful Fieldbus Applications. It Remains to Be Seen if We'll Ever Get to Fieldbus for Dummies

07/11/2013

Fieldbus Savings the Same in Dollars or Yuan

There's Been Too Much Hype About the Cost Savings of Fieldbus. The Same Thing Can Be Done With Remote I/O

06/11/2013

Fieldbus is Dead! Long Live Fieldbus!

The Competing Communications Technology That Presumably Will Replace All These Buses, Including Process Fieldbuses, Is Ethernet

05/02/2013

Is Field-Based Control More Secure?

If We Hide Our Controls in Field Devices, Are We More Immune From the Infections of the Higher-Level Networks?

04/03/2013

Why Industrial Couplers Aren't Commodities?

Maybe We Should Ask If Couplers Can Be Procured on the Basis of Cost Only

02/26/2013

Contemplating Couplers, Part 1

What's the Purpose of a Coupler, Aside from Being a Handy Gadget for Landing the Segment's Trunk and Spurs?

01/31/2013