OPA Forum expands open, interoperable standard for process control device interfaces - Part 1
Getting up above your planet's atmosphere may seem tough enough, but that's where the real work begins because it's a long way to anywhere else. Likewise, the moonshot to open, interoperable, plug-and-play control in the process industries is reaching escape velocity, but its increasing participants still have many hurdles and potential snags to overcome, and a lengthy trip to their goals, too.
Long story short, the Open Process Automation Forum (OPAF) and its effort to develop and implement an open, interoperable process control "standard-of-standards" specification has expanded to 116 member firms and organizations, consisting of end users, system integrators, suppliers and support groups (see sidebar). During the past year, OPAF's business working group drafted its "OPA Business Guide," and published in January. This 36-page document details a value proposition and business cases for the OPA standard. (The business guide can be downloaded here.)
Meanwhile, OPAF's technical working group divided into seven subcommittees, including technical architecture, information model and standard configuration, application framework, connectivity framework, security architecture, physical platform, and systems and network management. Most notably, they also developed "OPAF Technical Reference Model (TRM), Part 1—Technical Architecture," which is scheduled to be released in May. They stress that TRM defines interfaces between process control devices, but doesn't dictate what's in those products or interfere with their intellectual property (IP). TRM Part 1 was previewed as part of several OPAF-related presentations at ARC Advisory Group's Industry Forum on Feb. 12-15 in Orlando, Fla., and more of it will be released later this year.
Partners make progress
At the same time, two of OPAF's founding members, ExxonMobil Research and Engineering Co. and system integrator contractor Lockheed Martin, have gained even more ground with their complementary initiative. After receiving 46 request for proposal (RFP) responses from more than 80 suppliers in February 2017 for the proof of concept (PoC) prototype of its open control system—just 10 were selected this past June for inclusion in the PoC project, which became fully operational in September, and is scheduled to be completed this month. The 10 RFPs picked were from ABB, Ansys, AspenTech, Inductive Automation, Intel, nxtControl, R.Stahl, RTI, Schneider Electric and Wind River.
To achieve its vision of reaching the next open-process stage and making OPA technically ready by 2021, ExxonMobil will:
- Urge other end users to join OPAF;
- Develop partnerships with other operating firms and system integrators during 2018-20;
- Conduct an on-process pilot during 2018-19;
- Use collaborative, front-end engineering and OPA standards as available to prepare for field trials;
- Complete prototype testing and detailed design for field trials during 2018-20;
- Perform parallel field trials in multiple industries during 2020-21, and share non-competitive learnings among collaboration partners; and
- Demonstrate its OPA technology in 2021.
"Our activity tracks include continuing to develop the PoC with Lockheed Martin and contribute to the OPA standard, but the third track we're introducing this year is collaborative development and upcoming field trials with other operating companies," says Kenny Warren, vice president of engineering at ExxonMobil Research and Engineering, who presented a keynote address at the ARC forum. "So far, we have letters of intent from Praxair, Georgia Pacific and Dow to participate in the trials, and we're in discussion with four other operating firms to do the same."
Warren reports that ExxonMobil operates 38 chemical plants and other facilities, and it wants simpler, more efficient fleet operations, maintenance and project management because each day its operations systems generate about 1.3 billion data records from 5 million device tags. To aid fleet management, he adds that ExxonMobil is seeking to improve “right data” acquisition and analytics; identify and monetize fleet opportunities; use a globally consistent above-site approach; employ consistency and transparency across time frames; and establish a common computing and visualization platform.
"We have to do control and analytics more easily by using cloud computing and other platforms, but ExxonMobil can't do it alone, which is why we need a critical mass of demand from many end users," explains Warren. "That's the benefit of OPA and having users, system integrators and suppliers develop its standard. This is a once-in-a-generation opportunity for a standards-based, secure, open automation architecture, but we need everyone's participation to help replace the closed, proprietary devices of the past with open, interoperable layers. The future will have more Internet of Things (IoT), cyber-physical systems, machine learning and artificial intelligence (AI). Digitalization will be required for survival, but other industries have made this digital transition, and so can we."
Harry Forbes, research director at ARC, adds he's more optimistic about OPA's eventual success than he was a year ago because both the automotive and telecommunications industries have recently virtualized many of their network functions, and virtualized and replaced many of their former central switches.
"The cloud computing stack is still improving, and that matters to the process industries because it allows these functions to scale to smaller systems," adds Forbes. "It also enabled software development of enterprise, cloud and embedded applications to converge and occur at open-source speed. However, the cloud isn't going to stay 'up there,' and will instead come down to where we work and live. Enterprise and cloud will first combine into cloud-native applications, which will then scale down into embedded systems using cloud-like runtimes. This will elevate user expectations for industrial automation software. Management at scale and over the lifecycle is a requirement shared by cloud, IIoT and OPA."
Open-source attitude adjustment
If this flurry of activity by OPAF, ExxonMobil, Lockheed and others seems faster than the genesis of typical process automation standards, it's mainly because its developers are tired of watching increasingly cheap and powerful microprocessors, software, Ethernet, wireless, Internet, cloud and other digital technologies enable mainstream, IT-based, enterprise applications, only to see them stop short of fully emerging on their plant floors and out in their field operations. Process end users want the same functions in their production systems that everyone has on their smart phones, tablet PCs and other interfaces, but more open, collaborative development is needed to make it happen.
"We're witnessing a mindshift from proprietary, vendor-driven control products to open-source-driven solutions with contributions from a community in which no one owns the software and code, and everyone in the open-source community is free to develop and add features " says Matthew Burton, corporate automation technology director at Hargrove Controls and Automation (C+A) in Mobile, Ala., an OPAF member and certified member of the Control System Integrators Association. "This is similar to how the proprietary Unix operating system (OS) that was so prevalent in the 1990s was challenged, and in many cases replaced in the 2000s by the Linux OS, which is now one of the most widespread, back-office solutions.
"In this case, the Open Group will manage the standard, so companies can develop products that work with OPA software. There must be guidelines for interfaces between the products, or the whole system will fail. Plug-and-play is the goal, and though there has been some success, there's still much improvement in the DCS world or even in the IT space to be done, even though we've been trying for 20 years. There's more interoperability in the open-source community because it brings in more developers, there's more freedom of ideas, and the marketplace decides which are best and which to hold for later."
Burton reports that Hargrove plans to help independently test I/O components and other hardware with OPA software, and report back to the forum and its applicable committees. Though few other system integrators have joined OPAF so far, he adds that CSIA is seeking to consolidate participation by its members, so both small and large integrators can contribute and gain its benefits.
"OPA can bring much lower-cost, distributed control technologies to smaller process industries, such as some food and beverage companies. Their pockets aren't as deep pockets and traditional DCS users, so they should be very interested in this," adds Burton. "Open, interoperable control will enable SIs and their clients to gain the ultimate performance capabilities they want and let asset owners target the value-added features they desire. Open-source vendors and SIs will be able to develop these features more directly. In the past, it's been very difficult to develop and add features that weren't in the original product package, and suppliers had little incentive to do it, and the market has limited ability to drive innovation. With open-source, users and the market drive the features. As an independent integrator, we look 10 years ahead, and we see OPA as a game changer, and we want to be on the forefront of that change."
Jose Rivera, CEO of the CSIA, adds that, "The OPA specification and its TRM architect will allow greater use of more standardized components, and we see this as an advance for system integrators because they'll be able to move from dealing with so many technical hurdles to solve more application-related issues."
Origins of OPA attributes
While it's tricky to plan for everything the OPA standard may need to do, it's even harder to design and draft the actual specifications developers will use to achieve functional openness and interoperability. "When we began working on OPAF in November 2016, Don Bartusiak was very smart in asking the founding members why they joined, and we've also polled other end users about what they need," says Gene Tung, IT division lead for Merck & Co.'s vaccine manufacturing plants, who also presented at the ARC forum. "This gave us user business cases that we turned into requirements, which the technical working group developed into the OPA specification, and we're still collecting business cases that will be added to improve the standard."
These cases are drawn from the oil and gas, mining and metals, pulp and paper, fine and bulk chemicals, biopharmaceuticals and other industries.
From its research and synthesis of user business cases, OPAF developed common technical and business themes for its OPA requirements. The common technical themes are:
- Interoperability,
- Reusable configuration,
- Standard interfaces,
- Integrate best-in-class technologies,
- Industrial Internet of Things (IIoT),
- Big data and analytics,
- Cybersecurity,
- Predictive maintenance,
- Advanced control and modeling, and
- Robotics.
The common business themes are:
- Zero or minimal downtime,
- Schedule flexibility,
- Improved safety during cutovers and migrations,
- Reduced engineering hours,
- Speed to market,
- Maximizing throughput,
- Deferred or reduced capital spending,
- Uniform product quality,
- Product traceability, and
- Reduced qualification costs
OPAF has also developed an "OPA Ecosystem" that shows how specifications and funding flow down to subsystem integrators and hardware and software suppliers, and how OPA's open, public standard enables them to have more "loosely coupled" relationships for delivering their products and services back up to system integrators and users by ensuring ahead of time that their deliverables are open and portable. Common themes identified for the OPA Ecosystem include:
- More flexible execution model;
- Lower barriers to entry and increased innovation;
- Use of best-in-class solutions;
- Emerging business models and opportunities;
- Reduced customization;
- Software and configuration leveraged across platforms;
- Faster introduction and adoption of new technologies; and
- Conformance and certification.
"The OPA Ecosystem helps all the players understand where they are now and in the future," adds Tung. "Those that can do it will prosper in the OPA environment, but conformance is understood as 100% adherence to OPA standard, and self-declaration won't be sufficient assurance for OPA Ecosystem participants. As a result, OPAF will set up a verification authority, and its results will have legal standing. In addition, conformance will be applicable to products, but not to a system. Also, conformance will not test for performance, safety and/or security. Finally, certification and registration of conformant products will available in the ecosystem and marketplace."
Certification of OPA conformance has several objectives:
- Improve buyer confidence due to reduced risk when purchasing products, and increased solution portability and interoperability;
- Create preference for conformant products from vendors in the OPA Ecosystem;
- Provide clear, affordable and timely process that reduces redundant testing and integration costs;
- Protect the integrity of the technical standard; and
- Provide generic procurement guide to buyers by showing them how to request conformant products during procurement.
Darren Blue, director of the Industrial and Energy Solutions division at Intel (www.intel.com), and Tung's co-presenter at the ARC event, adds that OPAF and its stakeholders collectively determined that the key quality attributes of safety, resilience and maintainability are fundamental to an OPA-compliant product. They also held a workshop to prioritize more than 25 other attributes, and settled on the Top 10:
- Interoperability—ability of two or more systems or components to exchange information and to use the information that has been exchanged;
- Modularity—degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components;
- Standard conformance—process of developing and certifying systems or components to meet 100% of 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 needs or requirements at an acceptable price (to include recurring and nonrecurring 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; and
- Discoverability—ability of a configuration item or its information to be found, and the ability to find an item and understand its information exchanges and capabilities.
"This isn't just about users getting lower prices," says Blue. "It's about gaining key new process monitoring and control capabilities, and bringing in more users, applications and industries that can employ them. We think the whole pie has the ability to grow."
Tung and Blue report that OPAF believes the primary benefits of the OPA standard for end users will be:
- Supports reuse of control system applications,
- Increases value creation,
- Enables continuous innovation,
- Solves system integration issues,
- Is safe and intrinsically secure,
- Empowers workforce, and
- Reduces total cost of ownership (TCO)
They add the main benefits of the OPA standard for suppliers will be:
- Reaches new markets and customers,
- Remains relevant to existing customers,
- Creates new goods and services for expanded markets,
- Increases margins,
- Reduces costs, and
- Eliminates non-differentiated products