OPAF/O-PAS rubber meets road

Figure 1: Open Process Automation Standard (O-PAS), Version 2.1 Preliminary (V2.1) covers distributed control nodes (DCN) that connect to the O-PAS connectivity framework (OCF) and O-PAS communication interface (OCI) in the overall O-PAS technical architecture. The Open Process Automation Forum (OPAF) is quickly developing functional profiles for DCMs, OCF, OCIs and other functions, which it can use to create conformance tests for products, so they can be certified as O-PAS compliant. Preliminary interoperability workshops are allowing suppliers to check their devices before testing likely begins in the second half of 2022. Source: OPAF

The recent publication of Part 3 and introduction of Part 6.5 followed the March 2021 general release of V2.1, which covers many of the DCNs that connect to the OCF in the overall O-PAS technical architecture (Figure 1). V2.1 consists of:

• Part 1 on technical architecture is based on IEC 62264 (ISA-95) as a reference standard, and provides an overview of the other parts.
• Part 2 for built-in security is based on IEC 62443 (ISA-99). OPAF's subcommittees created checklists about which parts of IEC 62443 apply to which parts of O-PAS.
• Part 3 on profiles for conformance and certification. It groups together features and functions, and breaks products down to functional levels that can be conformance tested and certified.
• Part 4 on connectivity framework is based on IEC 62541 (OPC UA).
• Part 5 on interoperable system management uses DMTF's (dmtf.org) Redfish standard and the REST protocol to specify information reporting by software and hardware platforms such as DCNs. This allows different profiles and software to be certified, and requires each supplier to report their information in a consistent way.
• Part 6 with Part 6.1 on information and exchange models using OPC UA; Part 6.2 on basic configuration using OPC UA's information model; Part 6.3 on alarms based on IEC 62682 (ISA-18.2), Part 6.4 on reference function blocks; Part 6.5 on IEC 61499 event-based programming, and Part 6.6 on IEC 61131-3, which both determine how function blocks should be opened. Part 6 also relies on IEC 62714 (AutomationML).
• Part 7 on physical platform with a reference standard to be determined.

"Because Part 5 on system management requires consistent reporting, it provides the overall 'systemness' that O-PAS is seeking, and allows users to count on the information that's displayed," says Emerson. "Likewise, for cybersecurity in Part 2, if all components comply with IEC 62443, then when a system is put together, it's also easier for the system integrator to be responsible for system-level testing and certification."

In the same way, Emerson reports that O-PAS, V2.1, Part 6.2 on configuration adds vocabulary that tightly defines and controls system data, while Part 6.3 on alarms requires uniform reporting, so each supplier has to provide a common way to do it. "Each supplier used to publish alarms and event conditions in different formats, so users had to waste time with different types of messages," explains Emerson. "Consistent reporting means they can save time. In addition, Part 6.4 is trying to give users a set of reference function blocks, so they can have consistent tests, and be able to compare apples to apples."

Finally, Emerson adds that Part 6 and O-PAS also strive for consistent functions, which can be scaled down to the smallest control systems or scaled up to the largest systems, and be applied in all types of process industries, instead being restricted to one industry or a small group of end users. "We're not solving one industry's problems anymore. We trying to solve the problems of many applications and industries at the same time," adds Emerson. "For instance, scalable O-PAS can go into each windmill at a wind farm, and bring them all together. In the future, we believe Version 3 (V3) will allow application portability between different systems, which will allow more workloads, smoother performance, and greater reliability and resilience. Users will also be able to pull and replace standard, O-PAS hardware without impacting the larger system."

Testing takes off

To deliver the consistent functions it requires to achieve its ultimate goal of interoperability between devices, O-PAS requires thorough conformance testing and certification. The first wave of submitting and testing products for compliance with O-PAS is expected to begin at authorized labs and facilities in the second half of this year.

"It's usually believed that conformance happens on the backend, but it really begins when the technical working group (TWG) looks at testability and its purposes, such as what do they want to achieve, how to set up testing, and what behaviors are needed," says Ed Agis, co-chair of OPAF's certification working group (CWG) and senior director of compliance and certification at Intel. "There are many components that will be tested and certified based on O-PAS profiles set by OPAF's technical and business working groups. Once they develop conformance tests for profiles like OPC UA, suppliers will work with third-party verification labs to get their products tested. Test results will be validated and verified, and OPAF will get the results."

Just as they already contributed to O-PAS, organizations responsible for particular standards within it are also likely to facilitate the testing process. These include the OPC Foundation, ISA Security Compliance Institute (ISCI), DMTF and others. They and OPAF have already held interoperability events or "plug fests" to examine products and gauge their readiness for eventual testing. The latest was the January workshop attended by a dozen suppliers, and another will be held in July or August if enough products and suppliers are available.

"The beauty of these events is they allow participants to run test scenarios for their devices using functions based on O-PAS specifications, and see how well they work together," says Agis. "We tested software function blocks, execution engines and other capabilities in January, and now we're distilling the results. For example, O-PAS standard developers can see if its specification are working, while suppliers can gain insight into whether they understand O-PAS and can work with other suppliers, and both developers and suppliers can show end users where O-PAS is at and how well it's working. After a workshop, suppliers also get time to adjust their products in preparation for eventual testing. Most of what's needed for the first wave of testing is in place. Future O-PAS profiles will be introduced and tested for in subsequent waves."

Bartusiak adds that OPAF's recent interoperability workshops are similar to events that the OPC Foundation and other organizations used to stage to advance their network protocols. "We're just testing aspects of O-PAS and its interoperability," says Bartusiak. "So, we'll focus on data bundling into signals, and whether devices can do it. In the latest session, we tested O-PAS global discovery service (GDS). Suppliers got hardware and software to do the 'blocking and tacking' needed for system management, and many succeeded in making progress. However, we need to continue clarifying about function block layouts and the lines between them that signify data exchanges, and keep on raising everyone's collective understanding about collecting and communicating data."

Open for business

To get out all the news about O-PAS and attract new end users and suppliers, OPAF's Business Working Group (BWG) engages with potential participants and drafts publications like its O-PAS Business Guide (publications.opengroup.org/g182) and upcoming reference implementation guide to help users adopt O-PAS. 

"The business working group represents everything on the paying side of the OPAF ecosystem. Users are sticking their necks out to try O-PAS, and they deserve our help to evaluate and adopt it," says Jacco Opmeer, co-chair of the BWG and DCS subject matter expert at Shell. "OPAF and O-PAS are about infrastructure, standards and certification. However, they're also about guiding systems and commercializing solutions, so we need to make it clear to the overall marketplace what OPAF is doing, and return its feedback to the forum. This is how we'll drive acceptance of O-PAS among process industry sectors and verticals."

Luis Duran, co-chair of the BWG and global product manager for safety systems and cybersecurity at ABB, adds that OPAF already includes diverse users, system integrators, and hardware, software and service suppliers. However, OPAF needs to engage with more users and suppliers, alleviate their concerns, and explain the benefits of integrating O-PAS into their products and structures. "Beyond publishing books, we're collecting user stories at the interoperability workshop," explains Duran. "This can show how they'd benefit from OPAF membership, and how they might test and adopt the standard."

Opmeer reports BWG works internally with OPAF's 110 member organizations, but also communicates externally with many non-member organization and individuals, who often work for medium and small companies, and are eager to learn about how O-PAS could help their efforts. "We share what OPAF is doing," adds Opmeer. "We can say that O-PAS is alive in the end user communities. They want to know how to get started, so we give them the reference implementation guide, and they begin to think about what O-PAS can do for them."

Figure 2: The Open Process Automation (OPA) Test Lab operated by ExxonMobil with support from Yokogawa operates four process environments controlled by an open-process system architecture with DCNs communicating via an OCF network. After running for about two years, it's apparently generated enough positive results that ExxonMobil is investing in a related O-PAS field trial with more than 2,000 I/O that's scheduled for commissioning in 2023. Source: ExxonMobil

Going to (field) trials

As usual, the most extensive implementation of O-PAS-related devices, software and networking is the OPA Test Lab operated by ExxonMobil with support from Yokogawa at its Woodlands facility near Houston. The lab's testbed consists of four process environments responsible for development, testing and validation, acceptance testing of user applications, and production with continuous operation and demonstration functions. It's controlled by an open-process system architecture with DCNs communicating via an OCF network that also works with an advanced computing platform's (ACP) devices and software (Figure 2).

After running for about two years and generating a trove of interoperability know-how, the testbed has apparently generated enough positive results that ExxonMobil is investing in a O-PAS field trial at a brownfield manufacturing facility on the U.S. Gulf Coast. Presently at the front-end engineering and design (FEED) stage, the field trial is expected to have more than 2,000 I/O and 90-100 control loops. It will be enabled by components from a host of as-yet unspecified suppliers, and Yokogawa will act as system integrator and contractor. The field trial is scheduled to be commissioned in 2023.

"The OPA Test Lab showed we could take existing products and implement a cohesive, successful system that's consistent with O-PAS," says Ryan Smeltzer, OPA program manager at ExxonMobil Research and Engineering. "We used the testbed to derisk open process automation, and convince ourselves that it could add value and generate a successful return on investment (ROI). The test bed was also our way to qualify products against ExxonMobil's requirements and match O-PAS, too."

Smeltzer reports the testbed also let ExxonMobil assess that it met the functional requirements, which would allow its O-PAS deployment to meet most of the performance needs it would have to deliver in the field. Its developers also devised paths to closure for the remaining functions, so they could be achieved later. This enabled ExxonMobil's management to approve investing in the new field trial project last October.

"The manufacturing facility is a single-console operation, and the field trial will implement O-PAS, V2.1, employ OPC UA communications, and use the IEC 61499 control run-time standard, which is a reference architecture for executing regulatory and supervisory control," explains Smeltzer. "These interoperable controls will provide the industrial control functionality typically provided by a DCS and PLCs. We expect the ROI from the field trial will come from applying advanced applications enabled by O-PAS, and interoperability will deliver the improved capabilities and benefits that process users have been seeking for a long time. O-PAS will allow end users to employ best-in-class components from the full range of products that fulfill its requirements. The standard is still at the 'wet paint' stage, but many suppliers are recognizing that O-PAS is what users want, so they're developing or adjusting products to meet it."

Beyond O-PAS-enabled I/O, DCNs and OCF networking, Smeltzer adds that ExxonMobil is also exploring how ACP could perform control tasks in a hyper-converged architecture, which could also be part of the field trial.

"For some process functions, there are limited products that meet our needs, so we're also investigating how ACP can help us do low-latency, high-availability control that would be decoupled from and independent of the usual control hardware," adds Scmeltzer. "We're excited that ExxonMobil can be a catalyst for the O-PAS ecosystem in the process industry, and that we can use our field trial to hopefully encourage other users to develop and implement their own field trials. These are especially critical for O-PAS to succeed industry-wide, so we're also sharing what we're learning in our testbed and field trial, so others can use O-PAS for control and automation, too."