Open process automation

Consider migrating a PLC or small unit to OPA to gain in-plant operating experience. Watch the savings increase and then migrate other units as needed. A unit-based migration could be integrated into existing HMIs as a 3rd party system and then expanded to meet your needs, as O-PAS isn't an all or nothing approach. This would allow you to upskill your personnel without overwhelming the available skillsets. The scalability of O-PAS systems limits any wasted efforts.

Other options include building a small-scale development system to train personnel and continue to prove systems internally as you expand in the O-PAS ecosystem or procuring ready-made solutions like COPA QuickStart, which includes expert training.

The Coalition for Open Process Automation (COPA) provides a QuickStart kit for those looking for an out-of-the-box solution. As the market matures, more solutions will emerge, especially in Engineering tools, to reduce integration costs.

The contracting models used today will be very similar for end users to get turnkey projects as well. The single point of contact model used by O-PAS in the System Integrator role allows for the effective delivery of turnkey projects.

This is the role of the support provider and, to an extent, the systems integrator (these may be the same or separate entities). Wood, as an OPA systems integrator, provides integrated lifecycle services support (on-call and remote) by being the focal point and interacting with vendors / suppliers on the owner's behalf. In this way the owner doesn't have to deal with individual vendors / suppliers for troubleshooting, support and warranty issues. These types of interactions with vendors should be a part of the vendor selection process when specifying an OPA system.

OPA's current focus is similar to DCS's, focusing on single facilities. However, the standardization of interfaces behind OPA, OPC-UA and the O-PAS Information model can be applied to wide-area SCADA systems. The application of OPA technology is still very early, and expanding scopes like this are exciting areas to innovate.

The TCO costs were calculated separately from the TIC costs, as budgets were separated between capital projects and operations. Both were made available to the client for their use and calculations.

The O-PAS architecture lends itself to being inherently scalable. The OCF can easily be extended, and the standardized interfaces allow for efficient scaling of hardware. Networks are more closely aligned with IT styles that can be managed at scale much more easily. Our experience to date with systems design from 100 I/O to 14,000 I/O has shown these architectures to look remarkably similar.

Early projects will focus more on the 100 to 10,000 I/O scale to prove systems, but there is no inherent limitation to O-PAS systems.

The goal of OPA is not to end traditional DCS systems. Although OPA can replace them, it is only intended to offer another option. OPA is not one monolithic system but rather a set of standard interfaces and methods designed to achieve interoperability between the various components of a control system. These interfaces are all open alternatives to existing proprietary methods used in today’s distributed control systems.

By defining these open interfaces, OPA gives a spectrum of solutions as an alternative to traditional DCS systems with closed architectures that are tightly controlled by a single vendor. While these systems exhibit proven reliability and robust support frameworks, there is relatively less flexibility, and it comes at a higher cost. On the other end are solutions designed from the ground up to support O-PAS by incorporating new products or adapting existing products from non-traditional DCS vendors, which are, in many cases, available at a lower cost. Between these extremes, some DCS vendors are embracing the open approach and implementing O-PAS based technology within their existing technology stack.

No one approach is going to be right for every use case. Some end users will opt to continue down the road with their current DCS vendors and prioritize predictable performance. However, many end users are looking for a lower-cost option or to incorporate new capabilities, and OPA enables a range of options with open, standards-based architectures that can be scaled with greater ease.

COPA installations (IEC61131-based) offer CPlane Fusion orchestration technology for high DCN availability (cluster technology). The overall concepts of orchestration technology being brought into these new systems allow for greater management of systems. This management process, combined with high availability, enables no downtime upgrades and patching to maintain a secure cyber risk profile.

The O-PAS Standard specifically excludes safety systems today. These systems are driven by other standards and would be difficult to cover with a comprehensive O-PAS solution. That said, safety systems can be integrated through communication into an OPA system in the same way that they are integrated into DCS today.

OPAF is rolling out a certification program for vendors to have their products validated by an independent testing lab as compliant with O-PAS. The first wave of this program will certify the OCF and system management interfaces and the security profile of distributed control nodes. Certification of other functions and interfaces will be rolled out in later waves.

Beyond certification, the system integrator will be responsible for ensuring the compatibility of devices in an OPA system. Wood is working with other COPA members to define rigorous requirements and testing procedures to ensure performance of the system. Wood is also working with end users to align business and technical requirements and procurement strategies.

This can be done with traditional DCS/PLCs and will be easier because OPA is based on open standards.

The OCF allows for secure access to data across the network, allowing for flexibility and integrations not possible with a traditional DCS (Industry 4.0). This means digital twin input data can come directly from the network instead of relying on sourcing the data from a third-party integration or historian.

Standardization with the OCF layer makes integrating technology like Advanced Process Control much easier. Direct access to the data and the option to run on existing DCN or ACP in the O-PAS architecture allows for much faster implementations at a lower cost than is possible today.

The Global Discovery Server is a component defined (as optional) in the OPC-UA standard and adopted (as a required component) by O-PAS. It performs three different functions in supporting distributed communications across the OCF.

• Location Services – Other OPC-UA servers will register with the Global Discovery Server so that clients can locate any server on the network from a single, central access point
• Alias Name Resolution – OPC-UA servers can define aliases (tag names) for particular nodes and register those with the GDS. Then OPC-UA clients can call the GDS to locate a particular alias on the network. This simplifies the configuration of a large OPA system with many servers, since only the alias name and not the specific hardware location of a tag needs to be known. It also allows applications to be moved to a different piece of hardware while online (i.e. via an orchestrator for load balancing or backup control) since other devices can discover the new location of the tag automatically.
• Certificate Management – OPC-UA supports certificate-based authentication to secure communications between devices. The GDS facilitates this secure communication by providing a central service to manage which devices are trusted on the network.

Using Ethernet-APL is a choice that would be left up to the I/O hardware vendor. At least one vendor (R-STAHL) has support for both Ethernet-APL and O-PAS in its roadmap.

OPAF is working with NAMUR to demonstrate MTP approaches within O-PAS systems. In the MTP concept, OPA System Orchestrators can function as the Process Orchestration Layer.

OPA orchestration does not currently cover field-level communication. This may evolve in the future and will be based on end-user demand.

OPC-UA is the current protocol for O-PAS-compliant communication. Other protocols could be added in the future, but there is no development roadmap for them today. Other protocols can be integrated into the network through various means including DCN Gateways.

IEC 62264 is an informative document referenced by the O-PAS standard.

Yes, a DCN, which houses the control logic, replaces a DCS controller and PLC logic processor. DCN is term used for the OPA compute nodes and I/O nodes.

Put another way, a PLC or a DCS controller that adds support for the O-PAS Connectivity Framework and the Redfish system management interface would meet the definition of an O-PAS Distributed Control Node.

As a vendor-independent systems integrator, Wood is well-positioned to provide a tiered and integrated support model to our OPA clients. We currently provide OT lifecycle support solutions on an annual contract basis. Such contracts can be extended to include vendor / supplier coordination support so the client doesn’t have to interact with multiple vendors / suppliers for their OPA system. Wood has dedicated automation resources spread across the globe, and they can support our clients with lifecycle support services, on-call and remotely.

This is not an unfounded concern, and one that end-user risk analysis already considers due to previous incidents in their existing control systems. Risk profiles will be a part of vendor selection, as they are today. There will be implementations where clients choose to limit the vendor optionality intentionally to a small subset where, in other areas, they may allow for more flexibility. Large-scale refineries are already an amalgam of multiple integrated systems. OPA is simply pushing that integration down another level. System integrators are responsible for system performance and will work with end users to put necessary contractual obligations in place.

O-PAS certification will be a key component in testing individual hardware and software solutions and ensuring the interface standards are met. Standardizing interfaces is a key concept for allowing hardware and software flexibility, while maintaining operations.

O-PAS system orchestrators, like CPlane Fusion, will allow zero down time upgrades through high availability and system management. Adopting orchestration technologies from other fields allows greater flexibility in addition to high levels of technical competence in executing upgrades. These orchestration techniques have required higher levels of sophistication to handle the complexities of a modern control system. Moving forward with Linux-based systems allows for updates without downtime or rebooting for continuous operations. High-availability orchestration methods will allow the execution environment to be migrated to other nodes during upgrades if shutdowns are required.

These systems will be built from the ground up to handle flexibility and upgrades from the start and quickly evolving technology.

A primary driver for avoiding lock-in is the open standards-based communications. This allows for multiple vendors offering I/O interfaces, DCNs (Compute Nodes), function block libraries, HMIs, etc. For example, a DCN from Vendor A can run the same control configuration as is running on Vendor B's DCN. The separation of hardware and software allows the software to run multiple vendors' hardware. This software-driven approach allows for access to data through the O-PAS Connectivity Framework (OCF) with standardized interfaces.

This concept allows for flexibility and optionality, which will be brought together through system orchestration and executed by system integrators as a single point of contact.

Moving away from the initial project phases, independent service providers will be able to work on systems due to the standardization being developed.

The data and communications standards embraced in the O-PAS standard make OPA ideally suited for implementing remote systems. OPC-UA is an efficient method to transfer data, both in the OCF layer of the system as well as communicating with external systems. Separating hardware and software can make physical maintenance easier as components can be easily shared between systems, reducing spares and ensuring that technicians travelling to remote locations have what they need.

OPA can offer high-availability solutions today. COPA (amongst others) is ready to implement the OPA production project immediately.

The control runtimes in an OPA system are executed in containers running on the DCNs. CPlane fusion (or other orchestration) can be utilized to run these in a high availability environment giving 1ooN failover options.

The control applications with OPA can utilize IEC61131 or 61499 control logic. Today, IEC61131 control logic allows a fully OPA-aligned solution, and IEC 61499 is working to become fully OPA-aligned in the future.

A common misconception is that 61131 programming is limited to ladder logic as seen in PLCs. IEC61131 offers multiple control languages, ladder logic, structured text, sequential function charts and function block diagrams. The function block diagrams can be implemented with Codesys in continuous function charts to give end users a look and feel similar to application programming commonly seen in many DCSs today.

A field trial is connected to a physical process with real I/O. The ExxonMobil field trial will be controlling a commercial production facility with ~2000 field I/O. The test bed systems use a mix of hardware- and software-simulated I/O.

This will be an ongoing discussion. The business case behind the predicted Total Cost of Ownership (TCO) will become increasingly compelling as market competition remains tight.

OPA unlocks lower hardware costs, eliminates vendor dependence, and allows for rapid technology adoption. This will allow the end-user to keep pace with Cybersecurity, Artificial Intelligence, and other Industry 4.0 integrations that can be difficult to integrate within traditional DCS and PLC systems.

Overall, the exact mix of concepts and business cases that will motivate will vary based on customer preferences, asset age, current technologies and other variables.

O-PAS certification will be done in waves. Wave 1 certifications will be available this year.

There will most likely be more than one. For example, the COPA control platform is based on the Codesys IEC 61131 runtime for control applications. Codesys offers a store where solution providers can publish, and end users can purchase and download libraries, toolkits, add-ons, and other software applications. Other platforms can offer a similar service. This is certainly a place where OPA offers a path for innovation as the markets grow and evolve.

There is a growing list – see the COPA member companies for an initial list.

The Open Process Automation Forum certification programming should be up and running this year. OPAF will maintain a certification registry where users can view all certified hardware and software.