Introduction to Open Process Automation

For most of four decades, the architecture of industrial process control has not really changed. A plant buys a Distributed Control System (DCS) from a single supplier. The controllers, the I/O, the engineering software, the operator interface, and the historian are all that supplier's. The system runs reliably for fifteen, twenty, sometimes thirty years — and then it reaches the end of its supported life, and the plant faces a replacement project whose shape was largely decided the day the original system was purchased.

Open Process Automation is an attempt to change the shape of that decision. This paper explains what it is, the problem it is meant to solve, where the standard behind it actually stands today, and how an owner-operator should think about whether it belongs in the facility's future. It is written for the people who carry that decision: plant managers, engineering leaders, and the capital-committee members who will be asked to approve a control system's replacement.

The problem with the closed model

There is nothing wrong with a Distributed Control System as a piece of engineering. The DCS is one of the most reliable classes of industrial equipment ever built, and the established suppliers are very good at what they do. The problem is not the technology. The problem is the structure of the relationship the technology creates.

When a plant's control system comes from a single supplier — hardware, software, and the interfaces between them all proprietary — the operator's options narrow with every passing year. Expanding the system means buying more of the same supplier's equipment. Upgrading it means accepting that supplier's upgrade path and timeline. Integrating a better third-party application means whatever integration that supplier chooses to support. And when the system reaches end-of-life, the replacement is, in practice, another system from a supplier with strong commercial reasons to keep the architecture closed.

This is not a complaint about vendor conduct. It is a description of incentives. A supplier whose business depends on selling complete, proprietary systems has no reason to make those systems easy to mix with a competitor's. The closed architecture is working exactly as designed — for the supplier. The cost of that design falls on the operator, and it falls in three places:

Capital cost at replacement. Because a proprietary DCS cannot be replaced piece by piece, end-of-life triggers a large, discrete capital project. The operator replaces a working system on the supplier's schedule, not the plant's, and absorbs the full cost of a wholesale migration.

Lifecycle cost across the decades of operation. The larger cost is not the purchase — it is everything after it. Proprietary spare parts, supplier-specific engineering labor, mandatory support contracts, and upgrade cycles dictated by the supplier rather than the plant's needs accumulate quietly over twenty-plus years and typically exceed the original capital outlay by a wide margin.

Strategic cost — the cost of foreclosed options. The hardest cost to put a number on is the value of the choices the operator no longer has. A closed system cannot easily adopt a better control application from a specialist vendor, cannot take advantage of falling general-purpose compute prices, and cannot be modernized incrementally. The operator is committed, for the life of the asset, to one supplier's pace of innovation.

None of this is new information to anyone who has lived through a control system migration. What is new is that there is now a credible alternative architecture — and a published standard behind it.

What Open Process Automation actually is

Open Process Automation is a different answer to the same engineering problem. Instead of one supplier providing a complete proprietary system, OPA describes a system assembled from conformant components — hardware and software from potentially different suppliers — that interoperate because they all implement the same publicly defined interfaces.

The crucial idea is the separation of the interface from the implementation. In an OPA system, the standard specifies how components talk to one another and what information crosses the boundary between them. It does not specify how any individual component is built internally. That is left to the supplier. Two controllers from two different vendors can be interchangeable — not because they are identical inside, but because they present the same standardized interface to the rest of the system.

That single principle is what makes the architecture open. If interfaces are standardized and public, then:

• A component can be replaced by an equivalent component from another supplier without redesigning the system around it.
• Components from multiple suppliers can interoperate in one system without custom integration for each pairing.
• Engineering — the control logic itself — becomes portable, because it is expressed in standardized form rather than bound to one vendor's runtime.
• The system can be modular: changed, expanded, or modernized one component at a time, rather than all at once.

Those four properties — interchangeability, interoperability, portability, modularity — are not marketing language. They are among the formally defined quality attributes the standard is built to deliver, and they are the practical difference between an open architecture and a closed one.

An OPA system is still a real, rugged, industrial control system. It still has controllers in the field, still has I/O wired to instruments, still runs deterministic real-time control. What changes is that the controller, the I/O, the connectivity, the applications, and the management software are no longer required to come from one source — and the operator, not the supplier, decides how the system evolves.

The standard behind it: O-PAS

An idea this structural only becomes real when it is written down as a standard that suppliers can build to and operators can demand. That standard exists. It is the O-PAS™ Standard — the Open Process Automation Standard — published by The Open Group and developed by its Open Process Automation Forum (OPAF), a body whose membership spans owner-operators, suppliers, systems integrators, and standards organizations.

O-PAS is best understood not as a single specification but as a "standard of standards." Where a proven international standard already exists for part of the problem, O-PAS adopts it rather than reinventing it. Its connectivity framework is built on OPC UA, the established industrial communication standard. Its security requirements are built on the ANSI/ISA-62443 family of cybersecurity standards. Its control-application formats build on the IEC 61131 and IEC 61499 programming standards. O-PAS's contribution is to assemble these into a coherent architecture and to define the additional interfaces — system management, configuration, conformance — needed to make a genuinely multi-vendor system work.

The standard is organized into parts, each addressing one aspect of the architecture: the technical architecture overview, security, profiles, the connectivity framework, system management, the information and exchange models, and the physical platform. It is not a finished and frozen document — some interfaces are fully specified today and others are identified for future versions — and a clear-eyed evaluation has to account for what is mature versus what is still developing. But the foundation is in place, it is public, and it is being actively extended.

Critically, O-PAS is backed by a conformance and certification program. A component is "conformant" when it satisfies the requirements of a defined profile, and conformance is verified — through The Open Group's certification program, using independent test labs — rather than simply asserted by the supplier. This matters more than it might first appear. The whole value of an open standard collapses if "open" is a marketing claim each vendor interprets for itself. Independent conformance testing is what turns interoperability from a promise into a property you can specify in a purchase order.

This is no longer theoretical

For most of its history, the reasonable objection to Open Process Automation was that it was an aspiration rather than a working reality. That objection no longer holds.

The vision was first set out publicly in 2016, when ExxonMobil — frustrated with the constraints of closed-architecture DCS systems across its enormous installed base — challenged the industry to build something different. In the years since, that challenge moved from concept to prototype to field trial. The decisive milestone came with ExxonMobil's Lighthouse Project: a resin plant near Baton Rouge, Louisiana, automated using an OPA system designed against the O-PAS standard, with a systems integrator assembling third-party hardware, third-party control software, and other components into a conformant whole. The plant has been running in production since November 2024.

That is the threshold that matters. A standard exists. Conformant products exist. And a real plant — not a pilot skid, not a laboratory testbed, but a production facility — has been operating on an OPA architecture without significant incident. The question facing an operator today is no longer "will this ever be real." It is "is this right for my facility, and on what timeline."

How to think about it for your facility

Open Process Automation is a genuine option. It is not a universal answer, and any honest introduction has to say so plainly. The right way to approach it is not as a technology to adopt or reject in the abstract, but as an architecture to evaluate against your facility's specific situation.

A few principles for that evaluation:

The decision is driven by lifecycle timing. The natural moment to evaluate OPA is when a control system is approaching end-of-life and a major capital decision is already unavoidable. An operator with a healthy DCS and a decade of supported life ahead of it is not under pressure to act — but is well-placed to begin learning. An operator facing a replacement decision in the next few years has a genuine choice to make, and making it without evaluating the open option is leaving an option unexamined.

The economics are real but must be modeled, not assumed. The case for OPA is fundamentally a lifecycle-cost case — the savings accrue across decades of operation, not at the moment of purchase. A lifecycle-cost analysis presented by the systems integrator Wood at the ARC Industry Forum in February 2024 indicated total-cost-of-ownership reductions on the order of 60–70% over a 25-year horizon for an open architecture relative to a traditional closed system. That is a significant figure, and it is consistent with the structural logic of the open model — but a figure from one analysis is a reason to model your own facility, not a number to adopt for it. The credible version of the OPA business case is the one built on your plant's own parameters: your installed base, your labor rates, your expansion plans, your maintenance history.

Brownfield is the normal case, and the architecture is built for it. A common misconception is that OPA is only for new plants. In practice the opposite is true: most OPA opportunity is in brownfield facilities, and the standard explicitly accommodates this. An OPA system can sit alongside an existing DCS, with gateway components exposing the legacy system through conformant interfaces, allowing migration to proceed in phases rather than as a single high-risk cutover. The realistic OPA adoption path for most operators is incremental, not wholesale.

"Open" is a property to verify, not a label to trust. As OPA gains visibility, the word "open" will be applied to products with varying justification. The discipline that protects an operator is to anchor on conformance: ask what O-PAS profiles a component is certified against, and treat independent conformance certification — not a supplier's characterization — as the test.

Where this leaves you

The architecture of industrial control is being rebuilt around an open standard, and the change is far enough along that it has crossed from vision into operating reality. For an owner-operator, that does not translate into an obligation to act immediately. It translates into an obligation to evaluate — to make the next control-system decision as an informed choice between a closed architecture and an open one, rather than defaulting to the closed model because it is familiar.

For some facilities, on some timelines, OPA will be the clear answer. For others it will not, or not yet. The purpose of this paper is not to argue that every operator should adopt Open Process Automation. It is to establish that every operator facing a control-system lifecycle decision now has a real second option — one with a published standard, a conformance program, conformant products, and a production track record behind it — and that the option deserves a rigorous, facility-specific evaluation rather than a reflexive answer.

This whitepaper is published by Collaborative Systems Integration (CSI). CSI is a vendor-independent systems integrator specializing in Open Process Automation. CSI's founding principal, Don Bartusiak, served as Co-Chair of the Open Process Automation Forum; CSI's Trevor Cusworth served as an OPAF Co-Chair for six years and leads marketing and outreach within the Forum's Business Working Group. CSI operates under a commercial license from The Open Group for the O-PAS Standard. O-PAS™ is a trademark of The Open Group. Views expressed here are CSI's and do not represent positions of The Open Group or the Open Process Automation Forum.