ARC Leadership Forum, 2026: More Open Process Automation projects are underway. Compliant software-defined automation, open ecosystems and interoperability tests help flexibility, reusability, reliability, capabilities and ease of use at a lower cost than traditional distributed control systems.
Open process automation with software-defined control insights
- Process automation systems that are standards-based, open, interoperable and secure are known to be operating or underway at ExxonMobil, Reliance Industries, Shell and Texas A&M and are applicable to other process industries, as explained at the 2026 ARC Leadership Forum by ARC Advisory Group,
- Software-defined automation (SDA) isn’t sufficient for openness, interoperability or compliance with the O-PAS Standard is a “standard of standards” developed by the Open Process Automation Forum (OPAF).
- Experts involved in this 10-year standards effort recommend specifying OPA compliance in any request for proposal for a process automation system.
Standards-based, open, interoperable, secure process automation architecture systems are known to be operating or underway at ExxonMobil, Reliance Industries, Shell and Texas A&M, as explained at the 2026 ARC Leadership Forum by ARC Advisory Group, Feb. 9-12, 2026, Orlando, Florida. (Theme of the 30th Annual ARC Industry Leadership Forum event is “How AI Is Driving the Future of Industrial Operations and Supply Chain.”)
Speakers cautioned that software-defined automation (SDA) isn’t sufficient for openness, interoperability or compliance with the Open Process Automation System (O-PAS) Standard is a “standard of standards” developed by the Open Process Automation Forum (OPAF). Experts involved in this 10-year standards effort recommend specifying OPA compliance in any request for process automation system proposal. Some close to the effort suggest automation vendors support the standard or lose market share to those who do.
[Editor’s note: The most-read article posted on www.controleng.com during 2025 was
“New insights: 100-controller ExxonMobil Open Process Automation – March 3, 2025,” discussed in detail at the February 2025 ARC Forum.]
Interest extends beyond oil and gas; OPAF said interest includes food and beverage, metals and mining, petrochemical, pharmaceutical, pulp and paper, utilities and other companies using distributed control system (DCS) and industrial control system (ICS) architectures.
OPA projects are real, expanding
Whit McConnell, chief automation and process control engineer, ExxonMobil Technical Engineering Co. (Figure 1), said OPA progress results from a decade of work. OPA is real, as described in the ExxonMobil project, explained in detail last year, where the chief engineer in charge of the project came to the ARC Industry Forum just weeks after startup.
“He wouldn’t have left after a startup in the old days. Now we’re expanding open ecosystems for less engineering, reusable intellectual property, systems integration. Now we’re deploying a new OPA-based system to a tank farm at the Baton Rouge Anchorage Chemical Terminal (ACT) with no issues,” McConnell said (Figure 2).
Last summer, a project in India began an OPA-based system with 2027 deployment expected, McConnell said. Standards in use include IEC 61499 Control Runtime Standard-Open and IEC 61131 controllers standard. With IEC 61499, function blocks encapsulate instructions and its own event-based state machine, allowing integration from different software and hardware suppliers, with libraries of functions, structured communications with other devices and systems. Using an app store analogy, the standard allows portability and reusability (human-machine interface, alarms, historian) for greater options and flexibility. There’s no need for an over-engineered system.
Open systems add efficiencies with structured encapsulation, allowing creation of composite blocks from reusable elements, rather than the typical blob of logic.
State-based control and visual representations of logic and data flow are directly transferable to other systems if conformant to the standard.
Containerized designs allow for quick deployment with hardware independence. Logic can be assigned to other controllers as needed during a failure.
Sequence/condition-based control can coexist in controllers. Distributed logic allows development of failure tolerant control strategies, taking minutes instead of weeks or months in the past. Easier integration of control types is possible with easier upgrades expected in the future.
UniversalAutomation.org (UAO) has more than 100 members (including directors from ASRock, ExxonMobil, Intel, Kongsberg Marine, Kyland Group, Novo Nordisk, Schneider Electric, Wood Group and Yokogawa); the non-profit oversees a shared ecosystem of portable, interoperable, plug and produce software showing the screaming success of IEC 61499, McConnell said.
Testing, certification are helping OPA implementations
Ravi Jagasia, OPA Forum co-chair and director global business development, strategic goals at R. Stahl Group (Figure 3), reminded the audience that the 10-year effort created standards-based, open, interoperable, secure process automation architecture system with O-PAS components (Figure 4). O-PAS testing events and certification are helping ensure products work. Testbeds and production systems from before 2017 to 2024 showed continued improvements in a feedback loop. (Figure 5)
Options: Distributed control node, hybrid applications, replacement
Trevor Cusworth, co-chair of The Open Process Automation Forum, and vice president of sales and marketing for Collaborative Systems Integration, said now attention is on OPA adoption, not testing or demonstrations. Pathways for using OPA are 1) distributed control node [DCN] only, 2) hybrid application or 3) rip and replace. The last is least likely.
More OPA commercial components, skills available
Tyler Soderstrom, energy technology strategy lead, ExxonMobil, said technologies have matured and more commercial offerings are available. Small projects can help with “build skills” on the way to large system installations. We’re building on successes to influence the market.
Soderstrom, offering more details about the ACT project, mentioned above, said that deployment applies automation where there was none. It is a smaller system, but a commercial project, he said, with a business need, beyond the research and development implementation of the Lighthouse project described last year. In the request for proposals for ACT, Soderstrom said, OPA was mentioned. A system integrator helped with implementation. Factory acceptance test (FAT) is done, and it’s ready for production in second quarter. Vendors include OSI, Phoenix Contact, ASI and Phoenix Micro. OPA systems require no middleware, resist vendor lock-in and are ready off the shelf.
OPA systems: Some trade-offs until critical mass
While benefits are available now, Alex Eaton, OPA subject-matter expert with Wood (Figure 6), said there are some trade-offs comparing traditional DCS offerings versus OPA systems. Traditional control system implementations deploy quickly, have proven reliability and have support teams for patches, security updates and product road maps. Commercial OPA systems have maximum design flexibility without vendor lock-in, adaptability and designs can match exact requirements, constraints and innovations. New systems eliminate middleware and the need for “fairy dust on top to make them work,” Eaton said. OPA reduces compromises and the burden of proving strong execution and system integration work (Figure 7), especially with network and failure responses, he added.
OPA and a standards-based ecosystem
Jacco Opmeer, principal automation engineer, Shell (Figure 8), said the vision of OPAF committee and collaboration partners has been to develop an ecosystem of open standards-based systems that could include:
- Advanced Physical Layer (APL) Ethernet
- OPC UA FX data model
- L2 BPCS
- EN MCS
- IEC 61850
- IEC 62714
- OPC UA (PA DIM, MDIS)
- IEC 62443 security
- Software-defined systems (such as COPA’s offerings)
- L3 use of cloud as open.
OPA’s integration conduit to the IT space is based on working standards and open architectures from O-PAS and stakeholders. Processes and engineering must change using toolkits covering procurement, maintenance and operations in an integrated way, Opmeer suggested (Figure 9).
Open Process Automation at Reliance Industries avoids risks
Sunita Devi, group lead for Open Process Automation, Reliance Industries Ltd. (Figure 10), said her company began with OPA in 2018 (Figure 11), and in December 2026 started a phase-2 field trial with operation planned for December 2027; that 250 input/output (I/O) project uses five protocols (Figure 12). Motivation for using Open Process Automation:
- Frequent obsolescence of Microsoft operating systems without patches after, and related security vulnerabilities.
- High costs of backward compatibility
- High demands for profits
- Risks of traditional DCS.
Test-bed objectives include interoperability among multiple vendors, including Schneider Electric, Yokogawa, ZabbiX, ASRock, Stahl, Omega and Stardom. Software architecture in phase one includes DCN interoperability, function blocks, cybersecurity, OPC UA backbone and O-PAS compliance.
Phase 2 improvements and extended testing with about 250 I/O, integration with five protocols (HART, Fieldbus Foundation, Modbus, Profibus, Ethernet APL), level 2 security and TCO evaluation.
OPA system elements: Communications, controller options
Eric Reichert, director of product – automation, for Phoenix Contact USA, said COPA 500 can use the Phoenix Contact controller, but it doesn’t have to (Figure 13). AI process models are available for control with expanded DCNs. Ignition’s Redfish agent is on a DCN I/O. All five parts of the system programmable logic controller (PLC) are turned into a process automation system.
Steve Durbin, Phoenix Contact manager of IIoT system engineering, said the PLCnext Edge Gateway requires no learning to get application access to connectivity, via a configurable web page. Within an hour, comfort equals using what’s on the cloud. The customer-focused product has no code programming. An intern can operate it as easily as someone with 40 years of experience. Code blocks use the same concepts as third-grader programming education training, Durbin said.
COPA 500 uses Ignition automation software from Inductive Automation. Brad Mozisek, Wood business manager-digital integration, system integration Americas, said COPA 500 is designed for 100 to 1000 I/O (Figure 14). COPA 50 handles smaller systems or skid designs with 10 to 100 I/O.
Don Bartusiak, (R. Donald Bartusiak), Ph.D., president, Collaborative Systems Integration Inc. (CSI) (Figure 15), said Texas A&M is using a COPA and OPA-S for a small modular nuclear reactor at College Station for its heat exchanger. Also, the ExxonMobil terminal project in Port Allen near Baton Rouge is expected to reach commissioning in March; the FAT was in January. (Bartusiak retired from ExxonMobil.)
With many traditional DCS nearing obsolescence, O-PAS lowers the cost of traditional solutions, he added.
How software-defined automation helps OPA
As digital transformation helps manufacturing operations, SDA is emerging as a foundational enabler of agility, scalability and innovation. SDA benefits can include faster deployment, improved system interoperability and enhanced responsiveness. These help with market and operational changes with attention to cybersecurity, legacy integration and workforce readiness.
Mark Sen Gupta, director of research, ARC Advisory Group, in discussing the practical impact of software-defined automation on operations, said PLCs and wiring used to be the bottle neck. Now it’s change management and the networks. Software-defined automation is like couples therapy for operational technology and information technology (OT and IT) teams.
Software-defined automation decouples software, hardware
SDA decouples control logic and proprietary hardware. Logic can run on any hardware or virtual controllers, Sen Gupta said. SDA, if compliant with standards, can avoid legacy system limits, proprietary hardware tied systems hinder scalability and innovation. Traditional automation is even more costly to maintain as skilled engineers retire.
SDA provides agility, flexibility and resilience. Digital efforts cannot stop there. Transformation requires business changes. Digital architectures enable digital transformation.
Facilities require attention to IT/OT and cybersecurity. Software platforms can have microservers and open and virtualized automation systems. Open and virtual controllers offer more capabilities and are being more widely used. Don’t get so focused on technology that you forget to focus on beneficial societal changes, Sen Gupta said.
Soderstrom said Open Process Automation offers open, secure standards-based systems that accelerate innovation and value creation. OPA increases supplier competition, reduces barriers to new technology, lowers integration and lifecycle costs, reuses control applications across systems and is secure and adaptable by design.
OPA certification ensures simple devices can work with more complex ones, lowering integration and lifecycle costs. More options and choices are available as Open Process Automation Forum turns 10 this year. More commercial products are available.
What is an O-PAS based system? Attributes include standard information model, decoupling of compute and I/O and software and hardware. Software-defined redundancy for control-logic execution environment and a software-defined architecture. Component certification is underway.
Where does SDA come in? It’s in the standard process control architecture diagram: DCN compute, advanced computing platform, network I/O and marshalling and the IEC 61499 Runtime Application.
Software-defined alone doesn’t mean interoperability
SDA doesn’t necessarily mean compatibility or portability, though SDA can achieve both, Soderstrom said. OPA uses SDA as a core principle, as shown in the commercial ExxonMobil Light House project (see link above).
Activities of ExxonMobil’s collaboration partners and other O-PAF member activities demonstrate value.
Look beyond the marketing hype and be a smart consumer. At this point, OPA compliance needs to be a catalog item versus a roadmap. Make these needs known to vendors. Openness must be in the automation pieces we buy. SDA enables orchestration and lower costs, with an easier load on end users.
Open and standard data model enables easier integration, options for product selection and a larger potential customer base interested in OPA opens the marketplace, Soderstrom said.
SDA leverages modern software engineering concepts with software interchangeability and application portability. End users must make their needs know. It’s commercially demonstrated and advocated for future implementations.
Control libraries are developed, shared
Yihan Zhang, Shell Global Solutions global subject matter expert, procedural automation, discussed the need for an open SDA.
Shell Scotford has two operators for the chemical plant, with carbon capture and solar farms.
In 2008, when the plant started, it had seven operators and no downtime. Laptop-based fixes took a week, “time we didn’t have.” The system started to experience overload with an upset in chemical plant last year. In:
2021 a belt press was installed with an outdated PLC.
2023 an air dryer was used to prove an SDA and UAO can run on different platforms.
2024 test bed of a bio treater project implementation with over 300 I/Os demonstrated high reliability.
Libraries continue to be developed and shared. There’s a need for procedural automation, sequential control, an event-driven approach, to be IEC 61499 compatible along with other standards (S88, ISA-106, and PackML), but also need for a new customized state machine.
Sometimes there’s a need to do something in five minutes without time to document, Zhang said. We want to take those procedures, he said, and ensure they’re implemented with the expertise of the most experienced person on staff.
Composite automation types (CAT) provide a state graph display of a selected model. IEC 61499 generated blocks result from automatically generated code. The HMI also is automatically generated.
The demonstration required the SDA used a CAT and sit on top of the existing DCS. Communications will use OPC UA client-server communication. A simulation emulates the DCS behavior with the SDA-generated HMI.
The simulator mimics the real plant and 90% of possible errors prior to deployment. Zhang said, “You don’t have to rip out old systems.” Experts can perform the transition, working on small successes first, then work with management and others to expand, he said. SDA can be faster, cheaper and safer.
Don’t let SDA substitute for OPA interoperability benefits
Bartusiak provided Control Engineering with notes informing his comments during the session.
“The phrase ‘software defined automation’ started to appear in the marketing messages of the control system vendors about two years ago around 2024.
- Schneider Electric: ‘open software defined automation’ with EcoStruxure Automation Expert [1]
- Rockwell Automation: ‘software defined automation’ with Automation DevOps and FactoryTalk [2]
- Emerson: ‘software defined capabilities’ with DeltaV Version 16 and Boundless Automation [3]
- Siemens: ‘software defined everything’ with Industrial Operations X and Industrial Edge[4]
- Honeywell: ‘software defined insights’ with Aptica, Forge and Experion [5]
- ABB: ‘software defined automation’ with Automation Extended [6]
- Yokogawa: ‘software defined control systems’ explicitly referencing Open Process Automation Standard (O-PAS) based systems [7]
- For completeness, note also that there is a company named Software Defined Automation. [8]
“All DCS vendors are now marketing ‘software defined.’ To relate SDA to OPA, end-users should consider the questions raised by Sen Gupta in his opening remarks.
What is SDA?
| Decouples logic from hardware | yes |
| Run on general purpose hardware | yes |
| Virtual controllers | yes |
| Combines automation with IT applications | maybe, if the vendor allows third-party applications to be installed |
Why is SDA important?
| Proprietary, hardware-defined systems hinder scalability and innovation | yes |
| Rapid reconfiguration, Remote updates | yes |
| Potential business outcomes | yes, potential |
| IT/OT convergence | yes |
| Vendor agnostic architectures, prevent lock-in | probably not |
“Comparing SDA with Open Process Automation, as defined by the O-PAS Standard:
- In short, software defined automation is the adoption of virtualization and container technology.
- In contrast, O-PAS adopts virtualization and containers and goes beyond that to specify industry standard data interfaces, information models, and systems management interfaces for key quality attributes – modularity, interoperability and interchangeability.
“End Users should ask three questions to a vendor that offers SDA:
1. Will the vendor’s SDA system be interoperable with another vendor’s SDA system?
2. Will I be able to port my applications from the vendor’s SDA system to another vendor’s SDA system without rewriting?
3. Will the SDA vendor’s cost savings from the use of general-purpose hardware be passed on to me to lower initial- and total cost of ownership?
Risks for end users with SDA
“A dozen years ago when Steve Bitar and I were doing rigorous, decades-ahead scenario planning for ExxonMobil management to justify the investment in OPA R&D. A couple of the branches in the scenario decision tree we called ‘half-measures’ that, for reasons attributable to defensive actions by the incumbent vendors or risk aversion by the end users, stopped short of achieving the full potential of the OPA vision. My current words of caution to end users is to not let the ‘software defined’ marketing of the incumbent vendors be a half-measure towards solving the root-cause business problems that Open Process Automation is addressing.
Applicable examples from Software Defined Networking
“Several excellent post-mortem technical/business analyses of the telecommunications and cloud computing driven transition to software defined networking occurred about a decade ago. These post-mortems are published in several peer-reviewed articles in IEEE journals [9, 10, 11, 12]. Let me quote from a summary of these articles.
How automation vendors can impair standards efforts
“In the realm of software defined networking, vendor resistance often manifested as strategic delays, protocol fragmentation, and the promotion of proprietary extensions of existing technology. These actions were driven by the internal tug of war between embracing open standards and protecting high-margin, hardware-locked revenue streams. Key instances of vendor impairment included:
- Proprietary vs. open APIs
- Vague interpretations of “Open Flow” (the proposed standard language for the software defined network standard)
- Fragmentation of the buyers through marketing
“Resistance by the vendors resulted in:
- Interoperability gaps
- Operational complexity
- Slow adoption.
“Software-defined networking has a happy ending. The post-mortems tell how the procedures of the Internet Engineering Task Force (IETF) – specifically, its ‘rough consensus and working code’ mantra – overcame the resistance tactics of the incumbent vendors. Automation professionals should understand the intent of ‘software defined automation’ marketing and be aware of the risks of half-measure steps towards the OPA vision. Let’s learn from history in our own industry and from adjacent industry experience and avoid re-making mistakes of the past.”
IT is shocked at how OT does automation
Elias Panasuik, senior director offers enablement, process automation, Schneider Electric, said, “Open-related buzzwords are bubbling up. Open standards create lasting value, and vendors are reluctant to give up vendor lock in. We have to build great hardware. We want safety, on time and on budget control systems. If an end user is better served by another package, we want to embrace that to move the industry forward.” IT is shocked to learn how OT does automation, he added. “This is very exciting time.”
Questions and answers about SDA, OPA
How will openness be established?
Soderstrom: SDA isn’t sufficient for openness. Vendors are going to make it sound as if SDA is all customers need.
Are legacy controller frameworks needed anymore?
Panasuik: End-users cannot have separate libraries per vendor. They need a one-to-one conversion across vendors, or the benefits of IEC 61499 Control Runtime Standard won’t be realized.
Bartusiak: The days of purpose-built appliances and PLCs are over. IEC 61499 needs to be the frame of reference.
Is this the end of non-interoperable process control vendors offerings?
Soderstrom: It may be daunting at first to go to an open, standard-driven interoperable architecture, but in doing so, we don’t have to rely on complex support models. We can count on these [OPA-based] systems just working. Vendors need to provide standards-based interoperable and interchangeable hardware and software.
Bartusiak: We need Open Process Automation, as defined by the O-PAS Standard.
Bartusiak references to comments
References Bartusiak provided supporting his comments follow.
[1] https://manufacturingdigital.com/articles/schneider-electric-software. Accessed 9 Mar 2026.
[2] https://www.rockwellautomation.com/en-us/solutions/software-defined-automation.html. Accessed 9 Mar 2026.
[3] https://www.emerson.com/en-us/news/2026/emerson-advances-software-defined-automation-deltav-v16-lts#:~:text=AUSTIN%2C%20Texas%20(Jan.,capabilities%20in%20a%20single%20release. Accessed 9 Mar 2026.
[4] https://www.siemens.com/en-us/content/software-defined-everything/. Accessed 9 Mar 2026.
[5] https://connectedtechnologysolutions.co.uk/the-software-defined-revolution-is-reshaping-industrial-automation/. Accessed 9 Mar 2026.
[6] https://new.abb.com/news/detail/133775/abbs-automation-extended-flexible-open-sustainable. Accessed 9 Mar 2026.
[7] https://www.yokogawa.com/us/solutions/products-and-services/control/control-and-safety-system/open-automation-software/#Details. Accessed 9 Mar 2026.
[8] https://www.softwaredefinedautomation.io/. Accessed 9 Mar 2026.
[9] Cox JH. Chung j. Donovan s. Ivey J. Clark RJ. Riley G. Owen HL. (2017). “Advancing Software-Defined Networks: A Survey.” IEEEAccess. doi:10.1099/Access.2017.2762211.
[10] Horvath R. Nedbal D. Steininger M. (2015). “A Literature Review on Challenges and Effects of Software Defined Networking.” Procedia Computer Sciences. 64:552-561.
[11] Karakus M. Durresi A. (2018). “Economic Viability of Software Defined Networking (SDN).” Computer Networks. 135:81-95.
[12] Naudts B. Kind M. Westphal P-J. Verbrugge S. Colle D. Pickavet M. (2012). ” Techno-economic analysis of software defined networking as architectures for f=virtualization of a mobile network.” In: 2012 European Workshop on Software Defined Networking.
Mark T. Hoske, editor-in-chief, Control Engineering, WTWH Media, [email protected].
Keywords
Open Process Automation, standards-based interoperability, IEC 61499
Consider this
In your next process control request for proposal, are you specifying OPA compliance?
You also might like
From Control Engineering, see other OPA coverage:
https://www.controleng.com/new-insights-100-controller-exxonmobil-open-process-automation/
https://www.controleng.com/new-cost-analysis-open-process-automation-saves-52-versus-dcs/
For more on IEC 61499, see: https://universalautomation.org/
For more on OPA, see: https://www.opengroup.org/forum/open-process-automation-forum
More from ARC Advisory Group: https://www.arcweb.com/events/arc-industry-leadership-forum-orlando
