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

Control Systems, We Know What You Need

We Know What It Is You Want, So Step Aside While We Give It to You

09/15/2009

Simplifying Fieldbus Device Calibration

Creative End Users Have Been Exploring the Use of 802.11 Wireless to Display their DCS Interface on a Wireless Laptop or Notebook PC

08/12/2009

Finally, Registered Hosts

"Compliant Host" Came to Be Because Users Were Seeking Objective Ways to Evaluate Different Hosts's Capabilities

07/13/2009

Certainty of Outcome with Fieldbus

What Are Some of the Key Areas Where Effort and/or Investment Are Needed to Obtain Sufficient Certainty of Outcome for Even the Smallest Project?

06/24/2009

DCS Disasters

This Month We Join an End User Who’d Like Her Off-Hours to Be Less Subject to Distress Messages from Her Place of Employment. Dang! Cletus Been in My DCS!

05/11/2009

Save Money. Calibrate Less?

Have Our Calibration Skills and Practices Quietly Migrated to Being Largely "Plug-N-Play.”"Or Are They "Plug-N-Pray?"

04/03/2009

Finding Freebies in Fieldbus

Can We Use the Standard Deviation Method to Flag a Suspicious Measurement?

03/02/2009

Training Wheels for Fieldbus

Even in Lean Times, There Are Ways to Get a Fieldbus Testbed If You Think Creatively

02/06/2009

Fieldbus on a Shoestring

Use the Wire You Have. Unless You’re Really Challenging the Limits of the Physical Layer, Ordinary Twisted/Shielded Pair Will Work Reliably

01/12/2009

Bubba and the Bus

The Rule of 20: If You Select a Tech at Random from a Group of 20, Can He or She Fix the Problem in 20 Minutes?

12/12/2008

Patches the Bad Dog

Why Can’t Patches the Dog Sit at the Firewall and Bite the Hand Off the Bad Guys Whenever He Spots One?

10/28/2008

Using Fieldbus in your HMI

Digitally Integrated Field Device Information Is Useful to Your Operator

10/06/2008

Will Wireless Replace Fieldbus?

Hardwired Instruments Are Going to Be Around Until a Generation of Plant Operators Retires

09/05/2008

Bus = Remote I/O?

Consider “Bussing” a Network of 8- to 12-Point Analog and Discrete I/O and Locating It Strategically Close to the Field Sensors

08/07/2008

Ready for Control in the Field?

When The Loop’s Valve Positioner Loses Power, the Loop Will Experience an Upset No Matter Where the PID Is Solved

07/01/2008

Fieldbus for Safety Instrumented Functions

FF-SIF Transcends the Limitations of Conventional Safety System Design by Introducing New and Innovative Ways of Thinking About Safety

06/12/2008

Playing the Field

If Most of Loops Are Distributed to Field-Solved PID, What Are the Chances You Could “Hot Swap” Your Host Just Like a Field Device?

05/04/2008

And the Cheapest Bus Is . . .

Bus ‘XYP’ Uses Cheaper Devices. Users Will Find It Cheaper Than Foundation Fieldbus

04/01/2008

Instrinsic Safety Obsolete Yet?

Like Most End Users, I Truly Value the Credibility and Security That Organizations Such as Factory Mutual, the Canadian Standards Association, CENELEC and Their Ilk Bring to the Devices We Use in Hazardous Environments. But Perhaps One Practice is Ready to Be Relegated to the ISA Museum of How We Used to Do Things. Here’s Why.

03/07/2008

Paving the Way for Bus Technology

I’ve Had Great Success on Projects, Especially Upgrades and Retrofits, Where I Was Able to Get an Experienced Board Person and/or Front-Line Supervisor Assigned to the Job

02/04/2008