Defining process automation’s next generation systems

“OPAF has a vision this will lead to an open and dynamic market with the benefits of competition and innovation for all end users, vendors, integrators and maintainers.” Consultant and OPAF member Dennis Brandl delivered an update on the Open Process Automation Forum's efforts to develop an open, interoperable process control and automation system at this week’s Foxboro User Group conference in San Antonio.

If you're going to dive headfirst into the digital transformation of process automation, one of the rocks you may hit is a lack of interconnectivity and interoperability. That's why it's crucial to examine all swimming venues, and check out the efforts of the Open Group's Open Process Automation Forum.

Its approximately 80 members, including end users, system integrators and suppliers like ExxonMobil, Lockheed, Schneider Electric and others, are seeking to develop a truly open and interoperable process control system—and they could use your help, too.

"It's not uncommon for industrial users to say to industrial suppliers something like, 'We don’t like what you're selling us, and we want better, but not just incrementally better—a whole lot better," said Dennis Brandl, chief consultant, BR&L Consulting Inc., and OPAF committee member.

Brandl updated attendees of the 2018 Foxboro User Group conference on OPAF activities this week in San Antonio.

Closed controls persist

Brandl reported that achieving this long-sought, much-desired, plug-and-play process control nirvana has been difficult for several important reasons.

"Current automation and operations architectures haven't changed significantly since the 1980s," reported Brandl. "They're still based on the concepts of one or more computers in a hardened box, which are connected to tens to thousands of I/O points and dumb devices, which are monolithic, vendor-specific, and closed. There have been incremental advances in functionality, and decreases in size and cost, but the basic architecture has remained the same. As a result, advances shaking up the world with connected smart devices in homes, stores, health care, transportation and energy haven't penetrated the barrier of obsolete industrial system architectures."

Brandl explained that many end users remain devoted to traditional, single-vendor controls because they boast better than 99.999% system availability. "They also have simple, deterministic system functionality, such as proprietary function blocks and custom programming," he said. "Physical coupling of a field I/O sub-network to one and only one controller creates a self-contained, closed regulatory control appliance. They also have one system designer and integrator, issue a standard product release that ensures compatibility, and provide a single point of contact for all system performance issues, so there's no opportunity to point fingers at other suppliers. Unfortunately, they have historically relied on 'security through obscurity' as well. ”

Redefine broke—then fix  

Despite their traditional advantages, closed controls retain many characteristics that hold back users and constrain their growth.

"I/O on a closed network are normally, physically connected to only one controller, so any new application using that I/O must fit into the connected controller," said Brandl. "If the controller becomes loaded, however, I/O and associated applications may have to move to another controller. If the I/O network becomes loaded, adding I/O requires a new controller, even if the existing controller has spare capacity. So, you're limited to whatever control programming language and built-in capabilities are provided by the vendor. This means no best-of-breed solutions allowed or they're very expensive."

In this constrained environment, controllers can't be upgraded to exploit new, more sophisticated functions due to the cost and risk associated with replacement, according to Brandl. "Stagnant controller capability doesn't allow facilities to exploit the competitive advantage of new technologies," he added. "Migrating hierarchical systems usually require concurrent controllers and I/O replacement, which drives up project cost, complexity, duration and risk.

“The result is few replacements are done and systems are decades old," Brandl said.

Wish list produces open vision

To break free of these constraints, Brandl reported that process control users have developed a wish list of capabilities:  

• Federated, modular, scalable and extendable system architecture that's conformant with existing field device standards and communication protocols; can assign any I/O to any networked device; and simple, online addition/replacement of any networked device as a maintenance activity.

• Distributed, portable, interoperable automation. This includes the ability to execute an application on all compliant platforms (portability); deployment of interactive applications on different platforms with no modification (interoperability); and standard exchange of both structure and unstructured data between adjacent system levels.

• Security by design, which includes embedded security layers that can evolve with emerging threats; verification of message authenticity and integrity with a simple key management system; authentication of new network devices; authentication of all new executable code; and automated intrusion detection and prevention.

• Productivity improvements, such plug-and-play field devices, intrinsic system notification tools such as alarms, alerts, advisories, etc., and reduced costs associated with patch management, software updates, etc.

"OPAF is seeking a federated, secure, open, interoperable, highly modular, vendor-independent manufacturing operations and automation control system that's upgradeable without production loss," said Brandl. "That's a big mountain to climb. However, OPAF has a vision this will lead to an open and dynamic market with the benefits of competition and innovation for all end users, vendors, integrators and maintainers. This will also let participants improve their systems over time, like upgrading smart phones."

Reference model to O-PAS

By following their vision, Brandl reported that ExxonMobil, Lockheed and OPAF's committees and members have developed a new, open-market network and control architecture with three main parts:

• Distributed control nodes (DCN) with I/O that support real-time application processing and interfaces with other network protocols. Resulting systems will be collections of DCNs with or without I/O, or a DCN-cloud that provides execution environment of potentially hundreds of thousands of control nodes and intelligent devices.

• Standardized interfaces from high-end data-center host servers to redundant embedded computers hardened for harsh field environments to simple devices.

• High-speed, Internet protocol (IP)-based, wired or wireless Ethernet switch fabric that supports Layer 3 switching, VLANs, TSN, and QoS to allow the most network flexibility and segmentation. This network will also have interoperable protocols for distributed control, and execute multiple levels of control strategies, distributed to the DCNs.

"The Open Group and OPAF want to develop a marketplace of open, dynamic, interoperable components, where DCNs can talk to any I/O," added Brandl. "This is much better than trying to build a distributed control system (DCS) from scratch, which could cost billions of dollars."

Brandl added the complete structure of the Open Process Automation Technical Reference Model (TRM), Technical Architecture Reference S184, is freely downloadable at https://publications.opengroup.org/s184. It provides a snapshot of what's intended to become a finished Open Process Automation TRM: Technical Architecture.

"It's important to remember that the TRM lays out the architecture of interfaces, but not components or what's inside them," added Brandl. "This architecture model shows how interchangeable components implementing the interfaces can fit together into a system. Interfaces define how components expose functionality, and developers expose interfaces, but their content remains confidential and protected."

In addition, the O-PAS architecture and specification is driven by 10 quality attributes:

• Interoperability—ability of two or more systems or components to exchange information and use the information exchanged.

• Modularity—degree to which a system or computer program is composed of discrete components, so that a change to one component has minimal impact on others.

• Standard conformance—process of developing and certifying systems or components to meet 100% of the OPA specified technical standards.

• Scalability—degree to which a system can have its capacities adjusted to meet system requirements.

• Securability—ability of a system or component to protect against unauthorized access or modification throughout its lifecycle.

• Reliability—ability of a system or component to perform its required functions under stated conditions for a specified period of time.

• Affordability—characteristic of design, expressed as a solution that meets a customer's requirements at an acceptable price for recurring and non-recurring costs.

• Portability--ease with which a system or component can be transferred from one hardware or software environment to another.

• Availability—degree to which a system or component is operational and accessible when required for use.

• Discoverability—ability of a configuration item or its information to be found, and ability to find an item and understand its information exchanges and capabilities.

Once the TRM and its architecture are complete, Brandl reported, the plan is to create an eight-part OPAF-Process Automation Standard (O-PAS) specification and standard. Its parts will include its technical architecture, security aspects, profiles, OPAF communication framework (OCF), system management interface, application portability and physical platform. As a "standard of standards" it will borrow from established standards, such as:

• IEC 61131-3—PLC Open;

• IEC 61499—distributed function blocks;

• IEC 62541—OPC UA, as well as OPC UA companion specifications;

• IEC 62714—AutomationML;

• ZVEI-MTP—module type package;

• DMTF/Redfish from the IT side;

• IEC 62769—FDI;

• IEC 62682/ISA 18.2—alarm  management; and

• ISA/IEC 62443—ISA 99 for security.