OPA Forum expands open, interoperable standard for process control device interfaces - Part 2

Figure 1: In a typical process application with Open Process Automation (OPA) standard devices, OPA's Technical Reference Model
(TRM) includes On-Premise OT Data Center with real-time advanced computing (RTAC) platform and distributed control framework
(DCF); OPA Connectivity Framework (OCF), which is a real-time, universal service bus; and Distributed Control Nodes (DCN), which
are configurable I/O for input/output processing, regulatory control, logic solving and application hosting. Source: OPAF

Brandl adds that the TRM architecture also lets users choose what size of application and OPA solution they want to implement. "They can use single- and multi-point I/O for a small system like a boiler with just couple of DCNs; set up gateways to existing controllers and field networks; establish embedded DCF functions; or scale up to very large, advanced computing platform components," explains Brandl. "The TRM is also designed to support an application's entire lifecycle, such as installing, testing, maintaining and updating core components and configurations. The architecture supports multiple types of interoperable components. For example, the DCNs can support different protocols with their standard formats and definitions."

In a preview of TRM's interfaces, Brandl reported that portable format definition and companion specifications such as IEC 61131-3 will be used by configuration, application and system management tools, which will report through corresponding configuration, application and system management interfaces to the DCN and advanced computing platform (Figure 2). Likewise, other DCNs will report via an OCF interface, while the OCF network infrastructure will report to the DCNs via a DCP networking physical interface, and non-OPA sensors, actuators and other devices will be able to report to a DCN via a DCP I/O physical interface.

"The traditional DCS architecture hasn't really changed for 30 years, but this old way isn't going to get us where we need to go," adds Brandl. "Now, we can ride an exponentially advancing technology a wave that will let us apply new capabilities as they come out. This is a journey we have to take. If we don't drive it, it will be driven for us."

Dick Caro, consultant at CMC Associates and an OPA committee member, reports that OPC UA is presently being considered for inclusion in the OPA set of standards, but it will need Part 14, which is still in preliminary release. Part 14 incorporates the Internet Engineering Taskforce and IEEE's Time-Sensitive Networking (TSN), Publish/Subscribe messaging, and user datagram protocol/Internet protocol (UDP/IP) for the transport layer to provide a deterministic, guaranteed, end-to-end, data-delivery system.

"These three pieces will give OPC UA the real-time networking functions needed by the OPA standard," says Caro.

ExxonMobil's parallel project
Though much progress toward OPA is based on ExxonMobil Research and Engineering Co. and Lockheed Martin's initial efforts, and both remain active participants in OPAF, ExxonMobil is also forging ahead with its own PoC and field trials program to achieve practical performance gains. Beyond the recent scheduling announcements, it's useful to understand how its PoC program functions.

Figure 2: Interfaces in OPA's TRM architecture portable format definition and companion
specifications will be used by configuration, application and system management
tools that which will report through corresponding configuration, application and system
management interfaces to the DCN and advanced computing platform. Source: OPAF

"We're privileged to work with Lockheed Martin, and we're turning our efforts into a group of workable concepts," says Dave DeBari, process control engineer in ExxonMobil Research and Engineering's Measurement & Automation Projects section, and lead prototype engineer in its OPA program. "For example, all devices on the RT bus are peers, so the DCS doesn't need to broker all the data anymore because it's just another peer."

DeBari reports that ExxonMobil's PoC is based on a three-level concept with an RT advanced computing (RTAC) platform at the top, real-time communications bus via OPC UA in the middle, and DCNs, intelligent I/O and basic I/O on the bottom. The RTAC handles configuration management, historian, process simulation, performance monitoring, IT services and other tasks. The RT bus also links to enterprise systems through a firewall (Figure 3). "We're using this concept to control a simulated process unit, a natural draft, gas-fired heater that will let us test the PoC," he added. "We took the usual I/O points and controls and spread them over about three dozen DCNs, and slowed its communications to about 100 milliseconds, which is still far faster than the original DCS that runs at about 1 second."

This setup will let ExxonMobil test how well various components meet several primary objectives it has for its OPA solution, including:

• Interoperability that allows two components from different vendors to exchange meaningful data without the usual gateways or translators. This will enable integration of best-in-class components; foster competition and innovation in the marketplace; and permit customization and fit-for-purpose solutions.
• Interchangeability that allows a device from one vendor to be replaced by one from another vendor without modification. Employing the IEC 61499 standard for distributed function blocks, this capability will enable upgrades to leading-edge capability; reduce costs of future replacements; and decouple application lifecycles from platform lifecycles.
• Configuration Portability that allows a configuration from one application to be shared and used by another without modification, and Application Portability that lets an application program run on different systems and perform the same functions and services with the same configuration. Because neither requires changing control logic or making other modifications, portability between different vendors will preserve an asset owner’s custom configurations and intellectual property (IP); aid the use of leading-edge capability; and allow integration of best-in-class components.
• Application and Development Flexibility that let users buy or develop applications and integrate them into native control applications—similar to an App Store model. This flexibility also supports use of best-in-class algorithms; open the market to innovation; and preserves custom configurations and IP.

"We're proving these interoperability, interchangeability, configuration and application portability, and application and development flexibility can be done with an open, standards-based architecture like OPA," says DeBari. "We expect this technology to be ready by 2021, and that's why were encouraging other users to join OPAF, too."

Open, interoperability elsewhere
Because it wants OPA to be a standard of standards, and integrate and reuse others where it can, OPAF is examining many of the well-known, process control- and automation-related standards, as well as standards with conformance checks. Those under consideration include:

• IEC 61131-3—PLC Open
• IEC 61499—distributed function blocks
• IEC 62541—OPC UA
• OPC UA—companion specifications
• IEC 62714—Automation Markup Language (ML)
• ZVEI-Module Type Package (MTP)
• DMTF—system management
• IEC 62769—FDI
• IEC 62682—ISA 18.2 for alarm management
• ISA/IEC 62443—ISA99 for cybersecurity   

OPAF reports it will use the Open Group Architecture Framework (TOGAF) to combine existing standards, secure the elements it needs from each, and use them to help build its new standard. And, where OPAF finds functional gaps that aren't covered by existing standards, it will seek to design and implement new ones.

Two of most important openness/interoperability initiatives that OPAF is examining are NAMUR Open Architecture (NOA), which is reportedly scheduled to be released as an IEC standard in 2021-22, and ZVEI-Module Type Package (MTP), which is a standardized, non-proprietary description of modules for process automation.

"We need an open architecture to make digitalization happen, but the question is which approach to use?" asks Michael Krause, senior automation manager for DCS technology, engineering and maintenance at BASF. "Many ideas about openness and interoperability aren't exactly new, so the other question is why haven't they been achieved if they've been on the table for 20 years?

Figure 3: ExxonMobil is using an open-process proof of concept (PoC) on a simulated, natural draft, fired heater to test components it
may use in future field trials. This PoC system has three levels with a real-time (RT) advanced computing (RTAC) platform at the top,
RT communications bus via OPC UA in the middle, and distributed control nodes (DCNs) and intelligent and basic I/O on the bottom.
It will test hardware and software for interoperability, interchangeability, configuration and application portability, and application and
development flexibility. Source: ExxonMobil

Krause reports that NOA seeks to preserve the advantages of the traditional, accepted and available automation pyramid by layering NOA's monitoring and optimization (M+O) applications on top to the pyramid's field level, basic automation, MES and ERP levels. These apps cover plant-specific M+O functions like dispatching, alarm management, advanced process control (APC), and Industrie 4.0 device management, and central M+O functions like advanced analytics, historian, central HMI, production network simulation, reliability center and scheduling.  

"A lot of what we want to do with OPA is being done by ZVEI and MTP, so we've been looking at them because we don't want to recreate a standard," says Brandl. "We're also looking at PLC Open for its IEC 61131 capabilities, and at Automation ML to help share design data between design tools for building process systems. Defining tool interfaces is one of OPA's tasks."     

Don Bartusiak, process control chief engineer at ExxonMobil Research and Engineering, reports that OPAF agreed to collaborate with NAMUR last October because the functional requirements of NOA can be supported in the manufacturing data center of ExxonMobil's reference architecture, which is also known as the on-premise, OT data center in OPAF's TRM. "OPA, NOA and MTP are similar concepts," he explains. "These are not conflicting initiatives. Again, this about finding common ground on what users need, achieving a critical mass of user demand, and coalescing and marshalling it to force constructive change, but doing it with a spirit of compromise.

"The essence of OPA is based on distributing configurations for I/O modules and other devices, so they can do the same calculations for regulatory control, communicate over an open, RT network with security designed in, and collapse the RT control area that includes Level 1 to Level 3. We have a chance for Fieldbus 2.0 that's concentrated in the DCN, but suppliers will still be able to protect and license their IP even though this is an open connectivity effort.

"We're trying to run this like a project, but it has to be driven by users and their business needs. How it's done isn't what OPAF is about, and that's the difference between building a standard, which we're doing, and building a system, which we aren't doing. However, users must get involved and stay engaged, so we can avoid another fieldbus war. Openness and interoperability are about make knowledge more accessible, and we envision the end of massively expensive projects because we'll be able to upgrade when we need to and when it's quantitatively advantageous to do it."