The Open Process Automation initiative presents predictable challenges in I/O systems

May 10, 2017
OPA is not a standards-developing body, which means they will either have to adopt existing standards or work with another standards-developing organization such as ISA, FM, or UL to create any required documents.

The Open Process Automation Forum (OPA) and the team led by end-user companies ExxonMobil, Chevron, Shell and BASF to develop the next generation control system have stated from the start that the solution will be based on open standards. Unfortunately, OPA is not a standards-developing body, which means they will either have to adopt existing standards or work with another standards-developing organization such as ISA, FM, or UL to create any required documents.

Normally, one of the first steps in the standards development process is to create use cases describing the problem to be solved. Though ExxonMobil has likely created this document or one like it, perhaps called something else, I could not find it on the OPA website. But I suspect that the pending patent discussed in “Pushing IIoT near the edge” summarizes what such a document would identify, and led to the Open Systems Architecture vision with its three new elements: the Real Time Advanced Computing (RTAC) operations platform, Real Time service bus, and Distributed Control Node (DCN), which are mapped to the ISA-95 four-layer model.

In addition to the four-layer model, the group also needs to create documents related to the seven layers of the OSI layer model. Many groups now think the OSI model should be eight layers, adding a “user layer” where the functionality of, for example, EDDL is defined. However, because almost all field-level networks are relatively simple (little or no transfer of data across multiple networks), the eight layers are compressed into four or five layers. This simplification of layers may not be possible in this architecture, in which case network management could become a significant challenge as existing DCS systems do not have a single solution, while Ethernet with TCP/UDP and IP only define the lower layers of the OSI model.

The part of the system that is potentially closest to having standards in place is the Device Control Node (DCN), for which I believe:

  • FDI will likely be selected for field device communications as more than 90% of process devices are already DD-based (HART, Foundation, Profibus PA), and FDI also includes OPC “hooks.”
  • The DCN will most likely not be intrinsically safe (IS) but probably will be non-arcing (nA)/non-incendive (NI), suitable for installation in Zone 2/Div. 2, since that covers the majority of hydrocarbon and oil & gas facilities driving the OPA effort. If IS is required, additional circuitry will be added to those signals, just as is done with fieldbus barrier power supplies.
  • One decision that will have to be made and which the DCS suppliers will be campaigning is whether the device will be based on software-configurable I/O (Schneider/Foxboro, Honeywell, Yokogawa) or a hardware snap-in module solution (Emerson, ABB, Wago).
  • Because existing I/O cards are based on multiples of four signals, the DCN will also be based on this multiplier.

Reliable power still remains an issue for any field-mounted device, though with the increasing use of distributed data gathering, several options for fully redundant UPS suitable for Zone 2/Div. 2 installation are commercially available. Unfortunately, these power supply systems do not have a standardized way with low overhead (other than a common trouble alarm contact) to communicate with the DCN to share their status with the balance of the control system. A contact normally indicates a failure, rather than a predictive message that can be used to initiate a maintenance activity. If we stay with the EDDL/FDI concept and fieldbus terminology, I would not be surprised to see development of a new transducer block to link to a digital input (DI) function block for this purpose.

A possible impediment to acceptance of FDI is the potential lack of input from industries such as pharmaceutical and others that may not use EDDL to the same extent as the process industry, but if the DCN contains enough intelligence or the specifications are well enough defined, it will have the flexibility to also serve as a protocol gateway.

I suspect several of the standards identified as being required will be better understood once the first prototype(s) are tested at year end. And I will not be surprised if OPA find these are the same areas that the ISA-112 SCADA standard development group, just getting underway, identifies as part of its work. Surprisingly, though personally invited, the end user companies listed above and chairing the various OPA working groups and subcommittees have not yet identified participants to this standard.

OPA has a vision for the future to migrate legacy systems to a more open, largely software-based future, however, because of this history, they will be constrained by needing to be able to move from today’s platform to the future with minimal disruption to existing field infrastructure and retraining of staff—a not insignificant challenge which, if not addressed, will be the biggest gap to success.