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!

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p>I personally think the article hits the nail right on its head. Package unit integration is a pain.</p> <p>Personally, I think the FF-ROM discussion has been too much centered around integrating DCS I/O cards to the DCS controller. However, this is not a problem. It works extremely well in systems today. I don’t hear users complain about this. Since there is no problem, there is no user pull for a solution, therefore, no excitement from manufacturers.</p> <p>However, package unit / skit integration is a huge problem. Users lament this all the time. Here’s a problem we can solve to help the industry. A solution better than Modbus mapping and OPC computers is required. Those are open protocols, but each with their limitations. Not only is it tedious to get the PV and outputs etc. – all the intelligence in the underlying fieldbus and 4-20 mA/HART devices is not coming through to intelligent device management (IDM) software part of the asset management system (AMS). We need “Smart package unit integration”. With focus on package unit integration I personally believe DCS manufacturers would be interested because they could save tons of engineering hours on integration. However, to make smart package unit integration happen, the manufacturers of package units, skids, and other “little disparate mini-systems” would need to use RTUs and PLCs supporting these new more capable protocols when building their solutions. This in turn means manufacturers of RTUs and PLCs have to incorporate such more capable protocols into their RTUs and PLCs. Manufacturers of RTUs and PLCs will only incorporate such protocols into their products once there is a user demand for such protocols – that is, when users write those protocols into their package unit automation specifications. Users will only write those protocols into their specifications if there are multiple vendors supporting it. That is, there is a potential chicken-and-egg problem. Guess the manufacturers of RTU and PLC have to get together with the manufacturers of DCS.</p> <p>The integration of package units will likely be over Ethernet. There are many Ethernet application protocols to choose from. If the underlying instrumentation is FF-H1, it makes most sense to use FF-HSE to integrate to the IDM software. If the underlying instrumentation is 4-20 mA/HART or WirelessHART, it makes most sense to use HART-IP to integrate to the IDM software. For PV and outputs the current practice is Modbus or OPC. However, Modbus is tedious in that you need to configure Modbus registers with data type and scaling etc. which is a pain to manage. A smart solution with human readable tag names in a logical hierarchy is required. OPC is smarter this way, but rums on a Windows machine which is not accepted by some users. Maybe OPC in some form embedded in a device or using FF-HSE is the solution for PVs and outputs. But whatever it is, the protocol must be embedded in the RTU/PLC because it doesn’t help to have Modbus in the RTU/PLC and then map Modbus to HSE or Modbus to embedded OPC in a gateway; the tedious and hard to manage mapping would still there. I guess what is needed is new RTUs/PLCs with HART-IP/FF-HSE/embedded OPC built-in. This would eliminate the need for intermediate gateways</p> <p>Standard engineering tools would meet resistance. Every PLC/RTU is programmed differently and therefore has its own engineering software just like every transmitter and valve had their own software in the past. Technically it is possible to build a PLC/RTU where the control strategy is built using standard FF function blocks and this would enable DCS to build control strategies in the PLC/RTU just like they can do it in a transmitter and positioner today. IEC 61131-3 is another set of standard configuration languages, but I don’t think there is any standard way of downloading a configuration. This would be a dramatic change to a PLC/RTU. Maybe the vendors of “little disparate mini-systems” might do it?</p>


RSS feed for comments on this page | RSS feed for all comments