Every dream house needs a solid foundation. In the case of the Open Process Automation Forum's (OPAF) quest for interoperable, plug-and-play networking and process controls, this means defining common requirements, securing participating members, gaining consensus, and testing to achieve compliance with its Open-Process Automation Standard (O-PAS).
Beyond expanding to 133 members during the past year, including end users, system integrators, suppliers and supporting organizations, OPAF and the Open Group also took the major step of publishing their preliminary O-PAS, Version 1.0, on Feb. 5 at ARC Advisory Group's Industry Forum in Orlando. This five-part document addresses emerging technologies, and though it's likely to incorporate some changes before it's published as a full Open Group standard, OPAF reports it's focused on meeting minimum standard and specification requirements for process automation systems, and provides an open, vendor-neutral reference architecture for building scalable, reliable, interoperable and secure systems.
Preliminary in five parts
Because O-PAS is intended to be a "standard of standards," a primary goal of O-PAS 1.0 is adopting existing, "fit-for-purpose" industry standards. Consequently, it will integrate parts already developed by other organizations, such as security from ANSI/ISA 62443 (IEC 62443), connectivity from OPC UA, and systems management with Redfish from the Distributed Management Task Force. The five main sections of O-PAS 1.0 include:
- Part 1—Technical architecture overview of the current release and how it fits the overall, targeted standard. It's based on "OPAF Technical Reference Model (TRM), Part 1—Technical Architecture," provides an overall perspective of the vision to be attained by the standard, and basically show what pieces go where.
- Part 2—Security that employs IEC 62443 as the basis for compliance with the security requirements of the OPA ecosystem. It provides direction and consistency about security for developing other parts of O-PAS, especially parts 4 and 5.
- Part 3—Profiles that specify primary sets of functions for devices that comply with O-PAS and how they contribute to the interoperability required for component connectivity and systems management. These profiles will define which tests are needed to demonstrate conformance with O-PAS.
- Part 4—Open connectivity framework (OCF) that specifies interfaces necessary for base connectivity for client-server and publish-subscribe environments. It will primarily use a subset of OPC UA for process applications, though other communications strategies, such as MQTT and time-sensitive networking (TSN), could be added later.
- Part 5—System management of a process automation system, which covers managing hardware, operating systems and platform software, applications and networks. Its scope addresses hardware management only, and it will employ Redfish API, which is designed for servers, and uses a plug-in coprocessor to find, discover and manage hundreds or thousands of components. Future versions will address other system management functions.
"The primary goal of these five preliminary parts of O-PAS 1.0's interoperability is to get the underlying pieces in place for the next step—configuration portability in O-PAS, Version 2.0, which is planned to be released late in 2019 or early in 2020," says Dennis Brandl, principal consultant at BR&L Consulting Inc., co-chair of OPAF's standards working group, and chair of its technical architecture subcommittee. "O-PAS 2.0 will make control strategies portable to devices, and allow users to configure different strategies to run in distributed control nodes (DCN) from multiple vendors."
Next, application portability is planned for O-PAS, Version 3.0. It will allow portable applications to be downloaded to devices, and allow developers to create smartphone-style apps for process control and automation processes and a marketplace for those apps. It's planned for release in late 2020 or early 2021, while it's hoped the full O-PAS will be released in the second half of 2021.
Brandl reports that O-PAS 1.0, Part 2, will require conformance checks, which will be jointly carried out by ISA Secure and OPC-member test labs. Suppliers will pass by proving their product is secure to Security Level 2 of IEC 62443-3-3. "Security is the end user's responsibility, but they must have the tools to achieve it, and that's what we're providing," he explains. "Using common strategies like IEC 62443 for security, OPC UA for real-time communication, and Redfish for managing devices on networks is essential because users have thousands of devices and will have more in the future, and they need to be managed in the same way. O-PAS 2.0 will let any conformant configuration run on any O-PAS-conformant hardware, and O-PAS 3.0 will let any conformant software run on any O-PAS-conformant hardware. O-PAS 1.0 is providing the strong foundation for these future versions."
If it seems like OPAF's push towards O-PAS is moving faster than similar standards efforts in the past that's because it is. Prior standards initiatives could take seven to 10 years or more, with sometimes inconclusive results, while O-PAS is on schedule to produce its full standard in just five years.
This speed is mainly fueled by OPAF's end users, who are unhappy that they can't emulate mainstream, IT-based, enterprise users, and take advantage of lower-cost, more capable microprocessors running increasingly powerful software, and connect via easily accessible Ethernet and wireless networks to the Internet, cloud-computing services and other digitalized technologies to enable their plant floors and remote operations. Process end users just desire the same tools in their operations that consumers have on their smart phones, tablet PCs and other interfaces.
"OPAF is trying to define standards for an open, secure, interoperable process automation architecture that will enable industrial manufacturers to increase their productivity by: increasing operational benefits from improved control and digital capabilities; improving cybersecurity compared to currently available systems; and reducing the capital and lifecycle costs of systems," says Don Bartusiak, process control chief engineer at ExxonMobil Research and Engineering, which is one of OPAF's founding members. "OPAF is considering both the technical and business aspects of the open process automation (OPA) approach. The envisioned end state is a vibrant business ecosystem with increased earnings opportunities for those buyers and sellers who participate in the business transformation."
O-PAS 1.0 was developed in conjunction with TRM developed by OPAF's technical working group and "OPA Business Guide" developed by OPAF's business working group. TRM defines interfaces between process control devices, but doesn't dictate what's in those products or interfere with their intellectual property (IP). The 36-page business guide includes a value proposition and business cases for O-PAS.
"The business guide outlines the business ecosystem of end users, system integrators, hardware and software suppliers, and service providers," adds Bartusiak. "It defines how current stakeholders will be impacted by open interoperability, and it answers questions about the value propositions for buyers and sellers, accountability for system performance, timeline for the transformation to an OPA business ecosystem, etc."
PoC and prototype
In their parallel effort to OPAF, founding members Exxon Mobil and system integrator Lockheed Martin (www.lockheedmartin.com) continue to press ahead with their effort to design and build an OPA proof-of-concept (PoC) that will be used to control a pilot plant. They also enlisted global, vendor-independent system integrator Wood to help with the project. Plans are also underway for an OPA test bed and field trials.
"I recently worked on a migration project that was six and a half months of 12-hour days because a lot of the refining/chemical DCS fleet equipment installed in the 1980s that was supposed to last 30 years is now obsolete. This is why we wish to replace it with more interoperable, scalable, intrinsically secure technology that we can use to innovate, generate value, and reduce lifecycle costs," says Dave DeBari, process control engineer in ExxonMobil Research and Engineering's Measurement & Automation Projects section, and lead prototype engineer in its OPA program, who also presented at the ARC Industry Forum. "We're proposing a step change by participating in OPAF and seeking O-PAS, which will unlock a lot of benefits. And so, another 30 years in the future, we don't have the young engineers coming in now asking 'Why didn't they solve these problems back then?' as they're getting ready to retire."
DeBari reiterates the plug-and-play solution is the OPA architecture vision, which networks production-level distributed control nodes (DCN) via a real-time bus/open connectivity framework (OCF), such as OPC UA or the Data Distribution Service (DDS) open middleware standard from the Object Management Group. The OCF links the DCNs and other devices to manufacturing OT data centers using a real-time, advanced computing platform (RTAC), enterprise IT data centers using business platorms, and external data centers using cloud-computing services (Figure 1).
"The OPA architecture democratizes data and distributes control back to its users by giving them the results they need using a flatter model," adds DeBari.
To put their interpretation of the OPA architecture vision into practice, ExxonMobil and Lockheed developed a proof of concept (PoC) for a fired-heater application "to determine the technical feasibility of integrating hardware and software from multiple suppliers using industry standards and system integration expertise into a minimal, functional control system." The PoC consists of a lab system with dynamic simulation of process and emulated instruments in Owego, N.Y., and includes 50 devices from 10 suppliers, including ABB, Ansys, AspenTech, Inductive Automation, Intel, nxtControl, R.Stahl, RTI, Schneider Electric and Wind River.
The PoC was completed in March 2018, and successfully demonstrated interoperability, interchangeability, and configuration/application portability. For example, its network throughput measured as the maximum number of messages that could be sent at a 10 Hz sampling rate was 18,300 for OPC UA, 44,600 for TCP, and 49,900 for DDS. In addition, model predictive control (MPC) for combustion constraint control by the PoC's OPA setup achieved a 1-second execution period, compared to 15 seconds as the fastest feasible period for a typical DCS.
Based on these results, ExxonMobil, Lockheed and Wood have been building an OPA prototype to control temperature, pressure and other parameters in a hydrocarbon-containing pilot plant process in Clinton, N.J. It consists of 130 I/O points and 30 loops. The prototype's front-end engineering and procurement are complete, and it's presently in system integration in Owego.
The prototype is scheduled to be commissioned in mid-2019, and begin operating in the second half of this year. It also includes devices and software from nxtControls, Inductive Automation, OSIsoft, Phoenix Contact, Intel, Yokogawa and Moxa (Figure 2). Also, changes in the prototype from the PoC include:
- Replacing Raspberry Pi with customized commercial products;
- Replacing Profinet with Modbus TCP/IP;
- Using software-defined keys (SDK) for Modbus TCP/IP and OPC UA;
- Replacing simple data recording with OSIsoft's PI system;
- Testing IT security capabilities not typically available in a DCS; and
- Replacing Wind River's Titanium Control with Dell's EMC VxRail/VMware.
Test bed and pilot
At the same time, ExxonMobil reports it's also scaling up its PoC to create a test bed lab system, which will be used to test hardware and software components, as well as the O-PAS standard itself. It will be designed in 2019-20 and built in 2021 by ExxonMobil and a system integrator to be named later. The test bed will be used by ExxonMobil and its operating-company collaboration partners as the basis for additional O-PAS prototypes and multiple, parallel and subsequent field trials by the partners and other system integrators, beginning in 2020 and continuing into 2023. These partners presently include Aramco Services, BASF, Conoco Phillips, Dow Chemical, Georgia Pacific and Praxair. Non-competitive findings will be shared among them.
"The PoC showed that OPA ideas could work, and gave us the confidence to move forward," adds DeBari. "The prototype is doing the same, but the test bed will show whether OPA can fulfill the DCS role."
Ultimately, a field trial will use the OPA system to control an actual manufacturing process. ExxonMobil plans to engineer this application in 2020, and expects it to achieve a technology readiness level (TRL) 7 on the nine-level NASA/DoD Technical Readiness Scale. The collaboration partners are expected to conduct similar field trials.
"The test bed will support field trials with help from system integrators, suppliers and users partners, and this will help in developing system-heterogeneous components," explains DeBari. "The collaboration partners will then perform separate industrial field trials to get device ready, and give users the choice of interoperable devices they're seeking.
"We could try and wait for the world to change, but we need interoperability now. Thankfully, our R&D is showing that OPA is possible, and we're proving its benefits to ourselves. OPAF's mission is to create a standard of standards, but to succeed, it needs to prove it to other participants and suppliers, too. These efforts need an assist from everyone."
Plug-and-play for other processes
Beyond it's potential advantages for oil and gas applications, O-PAS will no doubt benefit users in the other process industries, which is the reason OPAF's membership continues to grow steadily.
"We also have a lot of HMIs and PLCs that were custom coded in the 1990s, but these tightly coupled devices in our processes that can drive us crazy when we're just trying to adjust or add a few data points," says Gene Tung, IT division lead for Merck & Co.'s vaccine manufacturing plants. "That's why we want to move ahead quickly on O-PAS 1.0. Eventually, our lifecycle management group for process control will integrate it with Merck's standards, and we'll ask our vendors if they'll to adopt O-PAS, and if not, why not?"
Plug-and-play components and networking will also become increasingly essential for DuPont as it begins the process of spitting into separate companies. "Our specialty products division runs high-value batch applications that are challenging to begin with," says Julie Smith, global automation and process control leader in DuPont's process control consulting division. "However, because the division had so many mergers and acquisitions in the past, our plants use a wide variety of control systems. As a result, we can't directly share useful control strategies with each other, so we must reengineer for each vendor’s system."
Smith adds DuPont's new corporate entities will still run its five primary businesses, which plan to retain much of their traditional autonomy. "There's no central support network; everything is decentralized," explains Smith. "As a result, upcoming migrations will be easier if we have more interchangeability. Interoperability and process portability with O-PAS will be key for us, and help our skid integrations save time and money. Several of our business are looking to expand, and they want to pick different, standardized, interoperable parts from different vendors as needed, and just slide them in. This is what could be the real game changer."
The application portability issue is particularly acute for DuPont’s electronics business segment, which supplies fine chemicals to the semiconductor industry. Migration projects often trigger product requalification cycles, which take a minimum of six months. “I have to segregate the product, notify customers, and await their testing approval before I can sell it,” notes Smith. “With O-PAS portability, I'd only need to do this once, versus at each site like I do today. That's a huge cost savings.”
To give vendors a heads-up and maybe more time to achieve interoperability, OPAF plans to hold an informal, week-long event this coming June at ISA headquarters in Research Triangle Park, N.C., where its 20-30 member suppliers will be able to bring their products to a test lab to see if they can interoperate according to the preliminary O-PAS specification, and help evaluate whether the standard's own specifications can function as planned.
"No reports will be written," says Brandl. "Events like this are common in the communications world because labs need objects to test. We're also going to test some prototypes."
For the present, basic O-PAS conformance relies on employing OPC UA, Redfish and IEC 62443. However, as with any consensus standard, compliance typically requires testing and certification by a third-party, according to Paul Hunkar, president of DSInteroperability in Cleveland, and the OPC Foundation's certification director and OPAF representative.
"Because malfunctioning controls can potentially cause fires, explosions, injuries, fatalities and property damage, suppliers have long understood that independent, third-party certifications must be required, and OPAF recognizes this, too," says Hunkar. "This will also show that O-PAS is real, and not just a paper standard."
Hunkar adds participants at the interoperability testing event in June will run through several hundred test cases to make sure their components can interoperate, this includes both client/server, pub/sub and Redfish/DMTF interfaces. "The target is to test only 20-30 devices, which allows each of them to achieve interoperability with all of the others," explains Hunkar. "We think most suppliers will do just fine because O-PAS combines existing standards, including some that have already been in use for years. For example, many suppliers are already very familiar with OPC UA and how to interface with it, but these suppliers might face more of a learning curve in the system management space where they don't usually play. End users are very important for the O-PAS standard important because they can tell us their experiences are and in what direction the standard of standards needs to go."
Adopt interoperability attitude
While it's crucial that end users, suppliers and everyone else rally around O-PAS and implement its common process control methods, players on all side must also integrate some new and different ways of thinking for these interoperability efforts to succeed.
"We all need to get comfy with some new competitive relationships," says Steve Bitar, R&D program advisor and former program lead for ExxonMobil Research and Engineering's open architecture initiative. "DCS suppliers will have to listen to users that need help with equipment that doesn't some from their shop, and end users will have to change the way they think, too. Instead of just picking from among a few one-size-fits-all devices, they'll have to better define their needs, determine which of many pieces fits their application best, and decide how to deploy them to improve their bottom line."
Dave Emerson, vice president of Yokogawa Corp. of America's U.S. Technology Center, and co-chair of OPAF's enterprise architecture working group, added it's participating in OPAF and contributing to O-PAS for several reasons, though it also had to reassess its mindset, too. "We've talked to many customers, and over the last few years, we've seen a bigger and faster shift towards IT entering the OT space, including in the process industries. Yokogawa sees this move as a natural and inevitable progression. Originally, DCSs and their operating systems and networking were proprietary, and they had to be because DCS suppliers were at the forefront of computing technology at that time. Since then, IT has progressed faster than OT. As a result, we've seen networking move to Ethernet from proprietary versions, including more open OPC UA, and seen HMIs progress from proprietary to more open Windows and HTML technologies. The last bastions of proprietary technology to be impacted by IT are DCS controllers.
"Yokogawa has seen these disruptions coming, and we'd rather be part of the solution and ride that wave, instead of trying to fight the inevitable or just sit on the sidelines waiting to be bowled over. Every supplier has to make their own decisions, but this disruption really is inevitable, so if you want to understand why and what it is, then it's best to get involved. We're not getting rid of competition or innovation. We're just learning to create a new ecosystem to operate in."
Like this article? Sign up for the twice weekly Control Update newsletter and get articles like this delivered right to your inbox.