Open Process Automation for Distributed Control Systems

Distributed control systems are the backbone of modern chemical plants and refineries. Challenges associated with these systems are driving a shift toward a standards-based, interoperable, and secure industrial process control architecture.

Over the past 40 years, distributed control systems (DCSs) have become a foundational component of chemical process industries (CPI) facilities. DCSs are reliable and contribute to profitability by serving as the computing and control platform in industrial facilities.

Recent advances in the technology landscape are enabling a step change in capability that could be achieved if industry transitioned to a standards-based, open, secure, and interoperable process control architecture. Such a transition will require industry to overcome many technical and business challenges.

The Open Process Automation Forum (OPAF) of The Open Group is leading the transition to this next generation of DCSs. The OPAF includes representatives from more than 90 companies. Members of the OPAF are working together to select industry standards that support interoperability, portability, and interchangeability of components in future systems.

This article describes the challenges and drawbacks associated with traditional DCSs and discusses the benefits of an open process control architecture. The article concludes with a case study that presents early lessons learned from a prototype open process automation system.

Motivation and enablers for change

As refineries and chemical plants age, their control systems reach the end of their lives and become obsolete. Historically, to replace the aging control system, the company would survey the DCS market, select the best-in-class system, and execute a series of DCS migration projects.

Industrial control systems became widely used in the hydrocarbon processing industries starting in the late 1970s as plants began to migrate from analog controls to digital control systems. Today’s DCSs are an integral component of the infrastructure that enables the safe and stable operation of facilities. Their capabilities provide the basis for the many advanced process control and real-time optimization applications that improve the economic performance of the plants.

However, although existing DCSs provide many capabilities, they are associated with several challenges. These include:

• replacement and/or technology refresh are costly
• integration of third-party components is expensive
• system components are bundled, and some of the components in a bundle might not be the best in their class
• systems do not scale economically
• the security model is traditionally not intrinsic, but implemented as an addition to the basic system architecture.

The root cause of these challenges is often the closed, proprietary nature of traditional industrial control systems. As DCS architecture was developed, a primary objective was to ensure the highest possible system availability to support continuous plant operations and avoid unit upsets caused by system downtime.

As the automation industry was developing, DCS suppliers chose to create tightly coupled proprietary interfaces for their exclusive components. This gave rise to deployed systems in which new components could be procured only from the original supplier.

Another key challenge arises when a platform becomes obsolete and a wholesale replacement and application redevelopment must be done. The closed proprietary nature of these systems requires plant owners to commit to the supplier for the long term once the system is installed. It is difficult for users to mix and match fit-for-purpose components or do incremental system upgrades with components from other suppliers.

Observations from other industries and developments within the information technology (IT) arena are making it clear that there could be significant benefits to moving to open, standards-based architecture for industrial control systems. Removing the requirement to have tightly coupled software and hardware in closed, supplier-provided components could allow real-time virtualization and software-defined networking, as well as other technological improvements. Other major factors that support a change include:

• innovations in cybersecurity, as well as increases in threats on industrial systems
• rapid growth and interest in the industrial internet of things (IIoT)
• greater integration of information technology and operational technology (OT)
• changes in user expectations due to the development of lower-cost sensors, wireless technology, data analytics, big data analytics, and cloud services.

Vision for open process automation

The goal of the OPAF is to create a standards-based, open, secure, and interoperable industrial process control architecture. Expectations for such a system include:

• commercial availability. The system must be supported by a robust ecosystem of hardware, software, and suppliers. The system should not be custom-built for a single company. Demand must exist from many companies across multiple industries that use today’s DCSs.
• best-in-class components. The system should support the integration of best-in-class components, independent of the supplier.
• built-in and adaptable security. Security must be integrated at both the component and system levels. Industry standards should provide the capabilities to continue to enhance security throughout the lifetime of the components and system.
• conformant components that can integrate to create an open system. Standard interfaces must be used to enable interchangeability and interoperability between components. Any system created from components that comply with the standards must remain open and available for future expansion.
• fit-for-purpose for the user’s needs. The architecture must be scalable and adaptable for different applications. One size will not fit all. The standards must support a range of industries and a wide variety of equipment. Examples include batch and continuous processes ranging in size from a small specialty chemical or pharmaceutical facility to a large-scale refinery or steam cracker.
• portable software. Operating companies invest large amounts of engineering effort into developing unit-specific control applications. Such user development of configuration information and software must be portable across components from different suppliers. A user should be able to move their engineered application to an upgraded or new component from any supplier without the need to duplicate the original effort.
• simple replacements. The tightly integrated nature of today’s DCSs often requires a wholesale replacement when a single component becomes obsolete. Since the many components that make up an industrial control system have different lifecycles, the new system should support component-based replacements on an as-justified or as-needed basis.
• innovation and value creation. Creating an open environment for which anyone can develop applications is expected to greatly expand the offerings for advanced control applications and future data analytics, which will drive value capture.

Figure 1 illustrates a reference open process control architecture. This new architecture is less hierarchical than the classical Purdue model, and it attempts to ensure data is always available to the desired user with minimum effort. While the Purdue model allocates specific tasks to levels in an automation stack, the vision for the future eliminates the hierarchical boundaries and allows tasks such as advanced control and big data applications to be executed anywhere in the architecture.

---

▲Figure 1. The open process automation (OPA) reference architecture ensures data is always available to the desired user. Foundational to the new architecture is the concept of a distributed control node (DCN) as the edge device connected to the field wiring. A real-time bus sits above the DCNs and supports the transport of data to all components in the system.

Foundational to the new architecture is the concept of a distributed control node (DCN) as the edge device connected to the field wiring. Many of the functions of today’s DCSs and programmable logic controllers (PLCs) might migrate to the DCN. A DCN will include input/output signal processing at a minimum, and could have expandable computing capability. Depending on the functional requirements, the DCN could host regulator controls, more advanced control applications, and even advanced optimization and analytics applications. In the future, we may be able to run the latest applications directly at the edge if required for data latency or availability. This opens up a new world of possibilities for plant operation and monitoring.

A real-time bus sits above the DCN and supports the transport of data to all components in the system. Legacy devices should be able to integrate into the new architecture via gateway devices. A high-availability advanced computing platform (ACP) supports the system and provides the computing power to host applications that do not need to be run at the edge, such as abnormal event detection, procedural automation, advanced control, and process optimization.

A critical feature of the new architecture is the ability to send data directly from the source in the DCN to either a local enterprise-level IT data center or external data centers. This ability eliminates the need for data to flow through each layer of the DCS, which was historically required.

The key advantages provided by the reference open process control architecture include:

• interchangeable edge devices that support replacement of devices independent of the original supplier
• computing at the edge, which enables applications to execute near the data with maximum availability and minimum latency
• improved data access by providing a path directly from the edge to the cloud without the need to send all sensor data through the classical Level 2, 3, and 4 platforms
• portable software that can be written once and then deployed across many platforms and moved to newer devices without the need to repeat the development effort
• higher availability for the advanced computing platform compared to today’s Level 3 platform.

Selecting industry standards

The Open Group is an organization created to support the development and use of industry standards. The Open Process Automation Forum within the Open Group is focused on specifying a defined, open, and interoperable automation architecture. More than 90 member companies make up the OPAF, including end-users, suppliers, and system integrators.

Governance is through collaboration and consensus among member companies. The OPAF is working to establish standards required to support an open process automation platform.

The O-PAS Standard is intended to be a standard of standards. The goal is to identify and assemble standards that, when combined, are sufficient to support creating an industrial control system. The approach leverages existing and developing standards to define the interfaces between components that can be assembled into an industrial control system. Table 1 shows the structure of the O-PAS Standard. Early in 2019, the OPAF issued the O-PAS Standard, Version 1.0 (1), which focuses on interoperability between components.

Case Study: Developing and testing an open architecture

ExxonMobil is a founding member of the OPAF. To complement the activities being progressed by the OPAF, ExxonMobil is executing an internal research and development (R&D) program. The company launched its gated R&D program in 2016 with the goal to begin industry field trials in late 2020 (Figure 2). Thus far, ExxonMobil has completed proof-of-concept and prototype systems as the first steps in demonstrating the advantages of an open, standards-based control architecture.

---

▲Figure 2. ExxonMobil launched its R&D program to complement the activities of the Open Process Automation Forum (OPAF). Thus far, the company has completed proof-of-concept and prototype systems.

ExxonMobil worked with Lockheed Martin as a complex system integrator to create its proof-of-concept (PoC) system (Figure 3). The primary objectives of the PoC project were to explore the technical feasibility of an open process automation architecture and to create a system with components from multiple suppliers. Existing standards were utilized where possible, including OPC-UA (2), IEC 61131 (3), and IEC 61499 (4).

---

▲Figure 3. The proof-of-concept (PoC) system was created in a laboratory setting. It controlled a simulation of a fired heater, which emulated the connections to a typical unit in a physical plant. The PoC system used components from 10 different suppliers.

The PoC system was created in a laboratory setting as a test unit. A simulation of a fired heater was connected to it to emulate connections to a typical process unit in a physical plant. The PoC system consisted of components from ten suppliers integrated to operate as one system. Functions were intentionally distributed across components to support testing key concepts.

The PoC analysis demonstrated four of the key quality attributes (as identified by the OPAF) of an open process control architecture (Figure 4):

• interoperability — the ability of two or more systems or components to exchange information and to use the information that has been exchanged. This was demonstrated by combining components from 10 different suppliers into a single system. For example, three components were used to execute a simple proportional-integral-derivative (PID) control loop: one component provided input, another component performed the PID calculation, and a third component sent the output to the field.
• interchangeability — the ability of one component to be replaced with another component while the system continues to function. Basic I/O and regulatory control was initially executed in an IEC 61499 environment on a Raspberry Pi device. That device was replaced in-kind by a DCN provided by Intel.
• configuration portability — the ease with which configuration information can be exported from one application, imported, and then deployed into a different application. Control function was initially executed in an IEC-61499 environment in a run-time engine provided by 4DIAC, which is an open-source implementation of the IEC-61499 standard. The configuration for this application was exported and imported into another IEC-61499 environment. Finally, the information was deployed and successfully executed in a different run-time engine, provided by NXTControl, which is a commercial implementation of the IEC-61499 standard.
• application portability — the ease with which an application that is running in one environment can be reassigned and deployed to a different environment. A simple PID control algorithm was executing at the edge in a DCN provided by Intel. The controller was reassigned and deployed to an NXTControl environment running in the ACP.

---

▲Figure 4. The open process automation architecture must offer interoperability, interchangeability, and configuration and application portability.

Building on the success of the PoC demonstration, ExxonMobil continued to work with Lockheed Martin to create a prototype open process automation system. The primary goal of the prototype is to extend the concepts of the open, standards-based architecture to a system that can be used in actual control of a physical unit.

ExxonMobil selected a small hydrocarbon pilot plant as the target installation. The pilot plant operates with hydrocarbon feeds at typical process temperatures and pressures. The unit includes pumps, reactors, separators, and a process gas analyzer, all controlled by a legacy DCS. The actual I/O count is 130, and there are about 500 total points in the system. The prototype was required to:

• duplicate functionality in the existing control system
• provide an acceptable user experience for the console operator and engineers
• demonstrate control system stability and availability.

Construction, integration, and testing of the prototype were completed in the fourth quarter of 2019. The system (Figure 5) was installed and began to operate the pilot unit during the first quarter of 2020. Performance data obtained during more than two months of continuous use confirmed the potential to operate industrial process units using an industrial control system based upon the principles of an open and interoperable architecture.

---

▲Figure 5. ExxonMobil installed a prototype open process automation system in a hydrocarbon pilot plant. The system was in continuous use over two months in the first quarter of 2020.

Accelerating technical readiness

Transforming manufacturing to an open, standards-based architecture for industrial control systems requires expanding the demand beyond ExxonMobil. The new architecture must be applicable to a wide range of industries. Suppliers must also be convinced that a large number of manufacturers believe there is value in moving beyond today’s closed, proprietary systems. To achieve these goals, ExxonMobil sought out operating companies that are members of the OPAF and are interested in working together to accelerate the technology development.

In February 2019, ExxonMobil announced that seven companies have joined as collaboration partners: Aramco Services Co., BASF, Conoco Phillips, Dow, ExxonMobil, Georgia Pacific, and Linde. The goal is to collaborate on testing of OPA standards and components while each company works toward independent field trials.

ExxonMobil is taking the lead to create a test bed to evaluate candidate components and standards. ExxonMobil has selected Yokogawa to be the complex system integrator to execute the task. The test bed will provide the basis for moving open process automation technology into initial industrial field trials. Once the test bed is built and functional, the collaborators will nominate components to evaluate using the test bed. A standard set of tests will be completed on each new component and the results shared with all collaboration partners. Using the common test bed should reduce the cost and time required for each company to move forward with their independent field trial.

Parallel, independent field trials will provide a great starting point toward demonstrating demand from the companies involved. Execution will also require additional system integrators and a growing supply of O-PAS Standard-compliant components. Each field trial across a different industry and process area will also provide important feedback to the OPAF as it continues to refine the standards.

Closing thoughts

The move to standards-based, open, secure, and interoperable industrial control systems will provide many benefits (Table 2). Next-generation process control systems should support reuse of applications across different supplier platforms — application developers will be able to create an application one time and deploy the application across many different platforms. No longer will developers need to create unique versions of an application to implement on each generation of each supplier’s platform. Enabling the deployment of independently developed software and breaking the dependency between a supplier’s software and hardware will also support value capture. Security will be designed in from the beginning and incorporate the latest technology to address evolving cybersecurity threats.

In summary, the time has arrived to explore moving from the traditional closed proprietary industrial control systems to an open architecture. A growing number of manufacturers, suppliers, and system integrators are actively engaged in selecting standards. Companies are collaborating to accelerate the development of field trials, which is driving the need for commercially available components. Key to success will be far-reaching demand from end-users, which will encourage suppliers to bring products to the market.