SPONSORED BY: UTTHUNGA
Introduction
Embracing new technologies in this digital realm is the need of the hour for next generation process and factory control automation. As a result, companies are anticipating a data deluge from intelligent sensors, actuators and robots among other industrial equipment. They are gearing up for exponential adoption of computing power, 5G, AI, ML, Big data analytics, 3D technology, new HMIs with touchscreens, and AR/VR capabilities among others to help them in their digital transformation journey.
However, the current scenario in the process control automation industry in the lower layers like L0, L1 and L2 is a closed, highly proprietary, and distributed setup with several OEMs, multiple vendors, systems integrators and business stakeholders being directly involved.
They are challenged by end-user demand for standardization in the OT layer, enabling interoperability among process automation technologies, along with providing a holistic view. The business need is to reduce capital and lifecycle costs for process control; making scalability and cybersecurity an integral part of these systems is another compelling factor.
The Open Process AutomationTM Standard (O-PASTM Standard) or “Standard of Standards” addresses this immense pressure to provide an open, interoperable, and secure-by-design process automation systems architecture. This standard ensures interoperability among existing control systems at every level, providing certified systems and components that conform to an agreed-upon set of standards. This will also address both business and technical challenges in process automation seen in many different vertical industries.
Open Process Automation Standard (O-PAS Standard) Evolution
The “Standard of Standards” is an initiative started in 2016 by The Open Group’s Open Process Automation Forum (OPAF). This global consortium of end-users, system integrators, suppliers, and other industry standards organizations works together to ensure that future automation systems meet true multi-vendor interoperability, adaptive intrinsic security, and an easy pathway for systems migration.
The new architecture brings more standardization and flexibility in the existing process automation systems that use Distributed Control Systems (DCSs) and Programmable Logic Controllers (PLCs). As automation applications require ultra-high availability and real-time performance, process automation systems have always been highly proprietary.
So, here’s why we need the totally new standard that adds value for end-users, integrators and sellers in this new-age IT and OT integration.
- Easy integration of various components used in setup
- Enables innovative value creation
- Automation of provisioning, initiation, and life-cycle management of legacy as well as OPAF compliant devices
- Overall reduced cost of control system upgrades or replacements
- Discover new business markets and customers
- Stay relevant to existing customers with new products and services
- Empowers workforce with a safe and secure design
Before we deep dive into the intricacies of the O-PAS Standard, there are three versions of the standard that the OPAF has created or are in the pipeline.
- Version 1, first published in 2019, addresses the key quality attribute of interoperability.
- Version 2, published in January 2020, addresses configuration portability.
- Version 3, coming in 2022 will address application portability and orchestration.
Why the O-PAS Standard is a Future Requirement for Industries
In the automation industry, the lower L1, L2 layers are heavily proprietary with a tight vendor control over the devices where the PLCs, DCSs, sensors, actuators and IO devices operate. Here, the industrial process data is continuously collected, transformed, transmitted, and ingested across the network/communication layers for it to make sense by the various stakeholders like operators, system integrators, and business leaders.
In the current setup, with OPC UA we can obtain unified and consistent data from any layer (from L1, L2, to L4, L5). With this standard, the intent is any component in the OPAF architecture should talk to any component across the network/communication layers.
With OPC UA providing standardization in the higher layers, the automation industry faced additional pressure to provide standardization even in the lower network levels. The question now is how to leverage the O-PAS Standard and its various Open Process Automation (OPA) technologies in next generation process control systems. This is possible with an OPA-based control system designed to support integration of best-in-class components and provide both configuration and application portability across components from different suppliers. This standardization will not only affect the hardware but also the software inside these components.
OPAF Architecture
In a nutshell, the OPAF architecture allows secure data exchange and flow from Distributed Control Nodes (DCNs) and/or legacy non-complaint DCSs, PLCs and IO devices over a common O-PAS Connectivity Framework (OCF) bus. This bus is based on the OPC UA communication standard that allows the gateway DCNs to provide the raw process data to the Advanced Computing Platform (ACP) for further data processing. All this data orchestration and system management is handled by the Orchestration and System Management (OSM) that is basically the brains behind the entire OPAF architecture.
The architecture of the O-PAS Standard is as shown below. This shows the different components that form the building blocks of this standard.
Figure 1: DCNs in an Open Process Automation System
Source: ARC
A brief understanding of the various terminologies mentioned above is necessary to grasp the overall architecture of the OPAF standard.
Distributed Control Node (DCN)
It is evident from the above figure that the DCN is the heart of this architecture. This essential component is OPAF complaint and is the module that brings standardization to the OT layer. They are basically field edge devices connected to the field wiring.
DCNs are capable of control, running applications, and other functions for seamless data exchange with the higher layers. This small, low-cost IO and process control component combines the capabilities of today’s DCS, I/O modules and controllers. In an open process automation system, there may be just a few or up to several thousand DCN modules. The runtime software can be configured to selectively provide control application-level communication and function block execution services.
O-PAS Connectivity Framework (OCF bus)
The real-time bus is present across the OPAF Testbed and supports the transport of data to all components in the system. OPC UA based communications and data models that are standardized for OPAF are used for communicating over OCF. This connectivity framework with message bus architecture allows different DCNs to communicate with each other. Even legacy or non-OPAF compliant devices can be integrated into the new OPAF architecture.
Advanced Computing Platform (ACP)
The ACP is a computing platform with different applications running on a hardware-agnostic platform for better maintenance, energy monitoring, management and optimization prescriptions. It performs data processing with different functional requirements and presents it to the OCF bus as per the standard interfaces. Some of the functional requirements that are handled by the ACP are data acquisition, filtering, data and event historization, data presentation, audit trails, diagnostics monitoring and prescriptions. The gateway DCN is used to host simple applications to have a base ACP.
O-PAS Communication Interface (OCI)
Device vendors are allowing end-users to add, configure and program the software components of the hardware devices based on their requirements. In order to make the device visible as a DCN to the rest of the system, the software layer OCI can be added as an embedded application on to any such non-compliant flexible architecture-based device.
Orchestration and System Management (OSM)
Orchestration and System Management is a centralized system that deploys, configures and manages the entire OPAF architecture. Most of the vendor-specific tools, orchestration masters, system management clients etc., are used to develop and build OSM. Different scripts and other custom tools that are developed to meet the OSM requirements are deployed and executed from here.
Gateway DCN
Existing PLC and DCS controller devices that are not compliant with OPAF standards are integrated into the new system architecture through a Gateway DCN. These gateways facilitate easy configuration and data exchange from various endpoints like IO, PLCs, DCSs, etc. Their multi-platform, scalable and portability features enable easy configuration of the end points for data point mapping, data source, alarms, events and HDA of the aggregated data over OPC.
Figure 2: DCNs in an Open Process Automation System
Why Utthunga for O-PAS Standard Implementation
Industries are quickly realizing the business and technical value the O-PAS Standard brings to the table. The OPAF specification is evolving at a fast pace and currently only a few components have been specified in great detail by the OPAF Forum. With such limited insights, we at Utthunga serve as global advisors and a technology partner for the OPAF community. Our exclusive focus will mainly be on:
- Contribution to the OPAF specification to make a positive impact in the industrial automation space
- Serve as trusted partner for OPAF adoption for industries and suppliers
- Collaborate with end-users for OPAF test bed & DCN implementation in production environments
- OPAF compliant suppliers for connectivity and simulation for specific industry needs
Utthunga is a Silver member of The Open Group and our close association with various industry consortiums such as OPC Foundation, ISA, and FieldComm Group among others, provides us direct access to technologies and strategies available for the enhancement of the O-PAS Standard. Our OPAF consultation services are an initiative to ensure your platform achieves operational excellence and cost optimization as well as to validate the components for compliance with the OPAF standard.