OPAF/O-PAS world tour

Figure 1: The open process automation (OPA) testbed at ExxonMobil's OPA Test Lab realizes its vision for an open-process system architecture with distributed control nodes (DCNs) from many suppliers communicating via an O-PAS connectivity framework (OCF) network and protocols with advanced computing platform (ACP) devices and software. Using this design, the lab presently runs four environments that are responsible for development, testing and validation, acceptance testing of user applications, and production with continuous operation and demonstration functions. Source: ExxonMobil

Third stop: Texas, ExxonMobil and Yokogawa

The third tour revisited the oldest and most extensive of the O-PAS test labs, which is operated by ExxonMobil Research and Engineering in the Woodlands, Texas, near Houston. Based on its earlier proof of concept and prototype deployments, the 13,000-square-foot OPA Test Lab has been up and running for about one year. It receives system integration and administration support from Yokogawa, and incorporates a growing list of technologies, suppliers and other partners (Figure 1).

The lab's testbed consists of a simulated refinery separation tower, and carries out OPAF's basic vision of connecting DCNs via an open process automation system (OPAS) connectivity framework (OCF) network to advanced computing platforms (ACP) in onsite operations technology (OT) data centers, and to external OT data centers, information technology (IT) and enterprise data centers, and other business platforms. Participating DCNs include Phoenix Contact's PLCNext, Yokogawa's Network-I/O (N-IO), Siemens' 1515SP PC2 processor and Kunbus' Revolution Pi industrial PC (IPC), which is based on the Raspberry Pi processor. Other participating microprocessors and components include Schneider Electric’s M251d, ABB’s xDC and Opto 22's groov EPIC, while the testbed's ACPs include Wind River’s Titanium controller, Antsle, Supermicro and Dell VxRail systems. The testbed also recently added Cognite software, which contextualizes data that wasn't linked before to provide better insights, and it's looking at CPlane.ai orchestration software to automate software maintenance tasks.

"Many vendors such as ABB are offering devices that are half PLC to talk to I/O via OPC UA or another protocol, and half Linux OS to run a user's software and connect to the control network, Internet and cloud," says Dave DeBari, process control engineer in ExxonMobil Research and Engineering's Measurement & Automation Projects section, lead prototype engineer of its OPA program, and co-leader of the Application Portability subcommittee in OPAF's Technical Working Group (TWG). "To allow them to interoperate, these devices have to remove their proprietary barriers. However, unlike all the controllers we bought in the past, we're asking for the root passwords, and the vendors are beginning to share them."

The lab presently runs four environments, which are responsible for development, testing and validation, acceptance testing of user applications, and production with continuous operation and demonstration functions. The acceptance and productions areas each use a process simulator that works with many of their DCNs in their drive towards interoperability. "The test lab has two main purposes," says DeBari. "The first is to answer questions, understand designs, and build interoperable systems from heterogeneous parts, such as we did with the earlier pilot project in our research unit. The second purpose is to get to field trials on a production unit, so we can show that O-PAS can work efficiently, and deliver real benefits, reliability and revenue."

DeBari reports the separation tower application is supported by two teams. ExxonMobil maintains its basic systems, instruments, process applications, advanced control and IT-based functions, while Yokogawa handles its control logic programming, cybersecurity and other systems, including a hyper-converged system with Linux applications it wants to make more secure. "The teams work as a group and consult with others. There are usually five to eight people there, but just like everyone else in 2020, we're also working and collaborating remotely due to COVID-19, so our schedule and ability to get people together has slowed down," says DeBari. "The lab also supports two groups, ExxonMobil and OPAF, and the efforts of each to follow O-PAS. We tell OPAF what we've learned, so we can make the standard stronger for everyone."

Coming soon: field trials

In the near future, the OPA Test Lab's testing and acceptance results will let it develop the basis for field trials on a production unit. DeBari reports that more answers are needed before the teams can decide what process to run in their trials, though it's likely to be some kind of chemical or refining process. Independent field trials will be performed by ExxonMobil and its collaboration partners, including Aramco Services Co., BASF, ConocoPhillips, Dow, Georgia Pacific, Linde and Reliance Industries Ltd. They've already agreed on the need for OPA systems and they hope to speed up development by conducting several, parallel field trials, but they'll also choose their own system integrators, employ O-PAS as available, share non-competitive findings with each other and design further testbed experiments.

"We're hoping to start the engineering phase for the field trials later in 2021, after getting management approval, and start running a process with an OPA-based system in late 2022," says DeBari. "This will round out the basic science experiment in interoperability that we started eight years ago. But first we have to focus on what we still need to know, so we can select the right process application for the field trials. Standards are documents—it's said they're 'nets, not buckets'—so their principles must be tested because they're not the same as turning software and machinery into a working system. This is how the testbed will help us transition from scientific principles to the parts needed for field trials and operating process automation systems."

To encourage interoperability using physical means, ExxonMobil reports it's also been working with Georgia Tech Research Institute to develop a prototype and demonstration for a standardized pin-and-socket connector, backplane and communication protocol called Far Edge Open Compute Interface Standard, according to Steve Bitar, R&D program advisor and former program lead for ExxonMobil Research and Engineering's open architecture initiative. "The work is focused on the interchangeability of I/O and computing modules, and includes standardized connectors similar in concept to a USB port or a PCMCIA card, as well as a compatible backplane that provides a physical layer for communications," says Bitar. "This means users can plug devices from different suppliers into the same spaces, while their I/O and computing can be abstracted from each other. We're hoping OPAF will adopt it as part of the standard."

Next stops: Malaysia and Petronas

Following the first three tours at the ARC event, Sharul Rasid, custodian engineer for instrumentation and control at Petronas' east coast refinery and aromatics plant in Kertih, Terengganu, Malaysia, announced that his company will also establish an O-PAS testbed at its training plant in nearby Batu Rakit, test devices including DCSs and flow-computing platforms from multiple suppliers, and conduct field trials with help from Yokogawa.

Though they aren't on the tour itinerary yet, several other sites and organizations are actively pursuing O-PAS solutions. For example, BASF debuted its Open Process Automation demonstrator for the chemicals industry with four water tanks and managed control loops at the 2019 NAMUR conference in Germany. Based on  the NAMUR Open Architecture (NOA) that's similar to O-PAS, the  BASF reports that it's "an agile proof of concept with real components and an uncritical process, which makes the success of OPAF's initiative more and more likely."    

"In partnership with ABB, BASF, Codewrights, ExxonMobil, Phoenix Contact, Samson and University of Dresden, we showcased an OPAF-influenced proof of concept (PoC) that integrated Module Type Package (MTP) and NOA for interoperability and additional synergies," stated Amar Parmar, senior director for solution partners and product management at Wind River, in a Jan. 7 blog post. "It included Wind River’s virtualization technology, ABB’s process control applications, edge hardware and software from Phoenix Contact, and technology custodianship from the University of Dresden. BASF contributed it’s clear-water demonstration plant with components in an uncritical process, shared specific requirements of the chemical industry such as batch processing, and supported the integration of OPAF, NOA and MTP standards initiatives."

Similarly, Georgia Pacific got involved with OPAF a couple of years ago to learn about and participate in developing O-PAS, and investigate how it could improve data access and achieve savings at its 150 manufacturing sites. "We're also developing an O-PAS demonstration board," says Bruce Ainsworth, VP of automation innovation at Georgia-Pacific. "Many engineers are retiring, which means we have to develop more streamlined controls, and O-PAS can help us do it. Likewise, we can still buy some parts on eBay for old equipment, but when we can't get them, we won't be able to delay these migrations, and O-PAS can assist us with those, too."

Still hungry for further input, OPAF reported that even non-members can contribute stories about their needs for open process automation by participating in a new survey at www.cognitoforms.com/OPAS1/UserStories. The survey includes a brief form, and asks respondents for a "narrative that expresses one very specific need that a user has, normally expressed in a few sentences."

OPAF drives to control functions

Back at OPAF headquarters, O-PAS efforts are presently concentrated on three main fronts.

"The first is that we expect to release O-PAS Version 2.1 Preliminary (V2.1) in March 2021, so the public can comment on it before publication, and say what they want the standard to do," says Don Bartusiak, co-chair of OPAF and president of Collaborative Systems Integration. "V2.1 already represents thousands of man-hours of work on defining its specifications, and contains lots of details. In fact, there's enough for suppliers to begin making products, and they're doing it."

V2.1 covers many of the DCNs that connect to the OCF in the overall O-PAS technical architecture (Figure 2). It updates:

• Part 1 on technical architecture based on IEC 62264 (ISA-95) reference standard;
• Part 2 on security based on IEC 62443 (ISA-99);
• Part 4 on connectivity framework based on IEC 62541 (OPC UA);
• Part 5 on system management based on DMTF (Redfish); and
• Part 7 on physical platform with a reference standard to be determined.

Figure 2: Open Process Automation Standard (O-PAS), Version 2.1 Preliminary (V2.1), is being released in March 2021, so it can generate public comments and input that the Open Process Automation Forum's (OPAF) developers stress are crucial to making the standard stronger before further publication in 4Q21. V2.1 covers many of the distributed control nodes (DCNs) that connect to the open connectivity framework (OCF) in the overall O-PAS technical architecture. Source: OPAF

V2.1 also updates Part 6.1 on information and exchange models, Part 6.2 on basic configuration for OPC UA, and Part 6.4 on function blocks. It also introduces Part 6.3 on alarms complying with ISA/IEC 18.2/62682, and Part 6.6 on IEC 61131. Part 6 is based on several reference standards, including IEC 62541 (OPC UA), IEC 62714 (AutomationML), IEC 62682 (ISA-18.2), IEC 61131-3 and IEC 61499.

Later this year, V2.1 will update Part 3 on profiles and introduce Part 6.5 covering IEC 61499.

"Overall, Part 6 is the heart of O-PAS' control functions that allow portability and transfers of data," says Dave Emerson, vice president of the U.S. Technology Center at Yokogawa and co-chair of OPAF's Enterprise Architecture Working Group (EAWG). "Part 6.1 lets users move engineering data and control strategies from one tool to another. Part 6.4 defines the inputs and outputs of function blocks to provide a set of reference functionality. This includes how to take data from devices and get it to the function blocks, but it isn't meant to replace other blocks or controls. It's just a reference model that allows interoperability between different systems. Part 6.5 allows different control strategies between processors."

Emerson reports that V2.1's update of Part 2 continues O-PAS's requirement that all certified products provide a set of security capabilities, and that suppliers give system integrators consistent security tools. "V2.1 requires that security be applied to every interface for compliance testing, and that detailed mapping of security measures can go to other O-PAS sections," adds Emerson. "V2.1 enables software products to come to market, and OPAF is aiding this by performing 'paper' exercises that trace data through the system to ensure consensus in interpreting details, conducting interoperability workshops for supplier testing, ramping up compliance testing, and employing end user testbeds to establish product demand."

Emerson adds that Yokogawa views the overall migration to O-PAS as inevitable. "Existing proprietary DCSs have been running for decades, and in this time, we've seen the growth of commercial, off-the-shelf (COTS) products used in DCSs, HMIs and networks," adds Emerson. "O-PAS continues this evolution by making software and hardware interoperable, and decoupling them in a natural progression that adds capabilities in software. We're seeing the global acceptance of the O-PAS concept in the seriousness and desire of end users and suppliers to make the standard and its interoperability happen and get widely adopted."

Certification = credibility

Trevor Cusworth, co-chair of OPAF and Schneider Electric's global account manager for ExxonMobil, reports the forum's second big effort lately is that its Conformance Working Group (CWG) is revving up its Conformance Certification program, which will enable suppliers to bring in products for certification testing, and secure approvals that their products conform to the standard. OPAF states a strong certification program is critical because it: assures users that certified products meet the O-PAS standard; lets system Integrators be certain that certified products will work together; and lets suppliers gain acceptance in the market, and have a springboard for differentiation and innovation.

"Certification is vital to making sure O-PAS is credible for its industries and users, so it's developing test suites that will give users confidence that the products they deploy will meet minimum interoperability requirements," says Cusworth. "For example, the first wave of certification tests will include Part 4 on connectivity framework with IEC 62541 (OPC UA) as it reference architecture, so testing will be done by the OPC Foundation's certification labs. Meanwhile, Part 5 on system management is based on DMTF (Redfish), so the ERDi test lab in Australia will conduct testing for it.

"Certification means users won't have deal with the supplier self-declarations they've had to face because IEC, ISA and other don't have certification processes," adds Cusworth. "This will eliminate many of the integration nightmares of the past. Certification will give everyone rules, so we can plug-and-play like we do with RJ45 connectors, HDMI cables, USB ports and HTML on websites."

Desperately seeking participants

The third initiative is by OPAF's Business Working Group (BWG) that's holding seminars, webinars, virtual workshops and other events for end users and suppliers alike to let them all know about the status of O-PAS, assure them that compliant products will be available, and demonstrate how they'll be able to learn and use O-PAS technology. "These presentations are for everyone, especially individuals and companies that aren't OPAF members and aren't involved in standards development day-to-day," says Bartusiak. "We want this to be an inclusive activity, and cast a wider net to bring in non-members. This means they won't have to just read about standards and specifications being developed by someone else, but can say what they want the standard to do, and participate in the early stages of developing interoperable products that can help their operations and businesses."

Bartusiak adds this quest for inclusiveness on the road to interoperability is also where CSI and other system integrators hope to serve. "We're looking forward to the new O-PAS ecosystem, so we can engage with suppliers, and help users get started with their O-PAS systems," adds Bartusiak. "CSI wants to help other companies get started, so they use interoperable controls to manufacture products more easily."

Bite-sized, try-it-yourself system

One way for potential users to learn about O-PAS is to examine the prototypes and testbeds designed and implemented by earlier users, and this can certainly be instructive. However, Bartusiak adds that CSI and others are also developing an affordable, bite-sized, O-PAS system, which will give users a hands-on way to learn about how the standard provides interoperable, plug-and-play controls that can run their processes easier and cheaper. "This system will give a company's technical guys an opportunity to learn how O-PAS can work for them," says Bartusiak. "Plus, it will also provide a concrete example that users can show to their managers when they're seeking buy-in to take this step towards open automation."

To help users find non-proprietary, Ethernet-capable devices and software typically needed for interoperability, Bartusiak adds that CSI and likely other organizations will offer services to help potential users assess their individual readiness to employ O-PAS. "Our philosophy and management style will be 'when do you want to get started?' We'll gauge if users want to wait until O-PAS is mature and there's a portfolio of certified products, or if they want to be more proactive, take a box of available hardware, software, models and simulations, and see how O-PAS can help their businesses," he says.

Even though O-PAS has progressed quickly, Bartusiak reports no devices or software are officially approved and certified as complying with the standard because it isn't finished yet. However, because O-PAS is a "standard of standards," many components have been integrated in the prototypes and testbeds that already comply with other standards, and many of those are likely to be included in O-PAS, too. Consequently, many suppliers have been scrambling to tweak, revamp or redesign their devices, so they'll fulfill O-PAS's demands for interoperability.

"Components evaluated for the testbeds and applied in them have characteristics that are aligned with O-PAS principles, and come from suppliers that are willing to comply with the standard's requirements," says Bartusiak. "One of the best examples of this is Phoenix Contact's PLCNext product, which is an open, Linux-based PLC that can accept third-party software.

Jason Norris, group leader for process automation at  Phoenix Contact, reports that PLCNext grew out of its experience in the automotive industry that needed a more open, Linux-based controller with an easier runtime environment, which would let users build applications in ways that were more comfortable for them. "We tried to open a control domain that wasn't proprietary, so it wouldn't lock users into one solution," says Norris. "This allows users to employ PLCNext as the basis for bringing O-PAS applications to life because they can put whatever software they need onto their controllers."