Need for the OPAF
Distributed control systems, used for controlling the operations of manufacturing plants, are made of many software modules like Human Graphical Interface, Alarm Summary and management consoles, and Data Historization. Distributed control system vendors provide a complete package that has all software modules to control the plant, and usually, operators and engineers are not comfortable in using all the software modules a distributed control system has to offer. It is possible they are experienced in working with the distributed control system (DCS) of another vendor earlier, and now have to switch to a different DCS and find operating the user interfaces different. Though, it should be noted that, functionally, all DCS deliver the same result. Even among the features, not all DCS vendors provide the same set of features in all their software modules.
This is where users feel the need to plug and play among the software modules of different vendors. Let’s assume that they would like to buy the HMI interface from Vendor A, the Alarm and Events module from Vendor B, and the analytics from Vendor C. This is something that is not possible as all modules are proprietary in nature and cannot be interoperated.
The Open Process Automation Forum (OPAF) initiative can make capability in one vendor system transferable to another vendor system.
Exxon is one of the largest oil refiners in the world, and they have many aging control systems in their plants. When they were looking to migrate to newer control systems, they found all control systems to be proprietary in nature, with each having some great features and, at the same time, some features that were not up to their expectations. They could not select the right control systems without compromises here and there in the features. That is when they decided to create and promote the Open Standards for control systems and formed the OPAF (Open Group Open Process Automation Forum).
- OPAF’s objective is to create/select standards and specifications for an open, interoperable, secure process automation architecture so end users of control systems can choose the modules offered by different vendors into one basket.
- OPAF largely comprises members from Exxon, Lockheed Martin, and Schneider Electric, and they are creating these open standards with help from others in the industry.
How OPAF would address customer challenges
- Proprietary or Closed systems are expensive to upgrade and maintain. Although the newest automation systems incorporate some aspects, it can be challenging to integrate best-in-class, third-party components into closed, proprietary systems.
- Additionally, although automation vendors are working towards the adoption of security industry standards and best practices, today’s systems generally lack the built-in cybersecurity needed to protect operations, equipment assets, and other capital investments.
- An open, interoperable, secure-by-design process automation architecture mitigates these impediments. Open, interoperable systems foster growth in the supplier market, lowering costs through increased choice and competition.
- In addition, open systems can enable the integration of products from multiple vendors, allowing the adoption of best-fit and best-in-class components.
- Ensuring future automation systems adopt and reinforce standards that achieve true heterogeneity while providing intrinsic security, multi-vendor interoperability, future-proof innovation, and an easy pathway for systems migration will help end-users reap far more value and profitability from the operations they control.
- The Open Process Automation initiative can make capability in one vendor system transferable to another vendor system. With this portability, end users can improve their resource utilization.
- integrators will no longer be tied to specific hardware vendors. Integrators will see reduced training costs for their staff, as they will not need to learn multiple proprietary systems.
- Software suppliers will deliver significant value. Interoperability, portability, and security standards will lower the costs and risks associated with upgrading and replacing software.
The work done so far
- The OPAF first came out with a set of standards called the Open Process Automation Standards, or O-PAS Standards, version 1.0 in 2019. Now the latest version is 2.0. Though 2.0 is not officially released as of the date and still is in the evaluation stage, it will eventually supersede version 1.0. Even among the released 2.0 versions, there are many API details planned for version 2.1 and beyond, and most probably by the middle or end of 2022, OPA standards would be ready to be used for building application modules that are interoperable.
Future for the OPAF
- The OPAF is here to stay. Though the standards are not completed, and it may take the end of 2021 to start building applications based on these standards, OEMs and, most importantly, end users are looking to such systems.
- It is comparable to AUTOSAR standards of automotives in all respects, and creating tools for application development will certainly put HCLTech in the driver’s seat. AUTOSAR was started in 2003, and by 2006, the Version Classic Platform 2.1 was released. OPAF today is in the same state. It would be right to say OPAF is the industrial equivalent of AUTOSAR