Tyler Soderstrom started his presentation with an admission. “I was really hoping that I could stand up here and say that we’ve completed another project,” the ExxonMobil lead control engineer told the room at the ARC Industry Leadership Forum 2026. “But unfortunately, due to the timing of things, we’re not quite to that point yet.”

The candor was disarming and revealing. Here was an engineer who had spent years fighting to prove that open, multi-vendor process automation could work in a real plant, and he was now discussing his next deployment with the same matter-of-fact tone you’d use for any routine capital project running a few weeks behind schedule. That shift in tone is itself the headline.

Open Process Automation has stopped being theorical and is now real.

Two Projects. One Complex. A Critical Distinction.

To understand why this moment matters, you have to understand what the two projects are, and crucially, what they are not.

The Lighthouse project, completed at the end of 2024, replaced an obsolete legacy distributed control system at ExxonMobil’s Resins Finishing Plant in Baton Rouge. It was the world’s first commercial-scale deployment of an O-PAS-aligned control system: over 100 distributed control nodes, more than 1,000 I/O points, running a live hydrocarbon production unit around the clock. It was assembled as an R&D project that was deliberately broad in scope, intentionally complex, designed to prove the outer limits of what OPA could do. It succeeded.

The ACT project, at the Anchorage Chemical Terminal, is a separate mid-stream tank storage and chemical metering facility within the same Baton Rouge complex.

Not bigger. Not flashier. Smaller, simpler, and in every meaningful sense more important.

LIGHTHOUSE vs. ACT: THE KEY DIFFERENCE

The Shift That Changes Everything

The Lighthouse was chosen because it was hard. The ACT project was chosen because it made business sense. That sentence represents one of the most significant transitions in the decade-long OPA story.

“When we started looking for where we could apply open process automation next, it wasn’t just to show that we could do it anymore. It was to look for places where there’s a business need and that an OPA solution really is the best option there — something that can stand on its own.”
— Tyler Soderstrom, ExxonMobil [4:04]

The Anchorage Chemical Terminal needed automation. It was running manually. Operators managing tank storage and chemical metering by hand, sending product to other ExxonMobil sites in the Baton Rouge area. OPA wasn’t forced onto that problem to prove a point. It was selected because its scalability, interoperability, and total-cost-of-ownership profile made it the right answer on the merits.

Equally significant: the entire project was run as a standard commercial undertaking.

Competitive open bid. Requests for proposals with OPA specifications embedded as requirements. Systems integrator, Wood, driving execution. No special R&D carve-outs, no bespoke oversight processes. Just a project.

COPA and OPA: Validated by the Second Deployment

Alex Eaton of Wood laid out the framework clearly. In the OPA landscape, there are three types of systems: traditional vendor DCS (proven, locked-in), bespoke OPAS implementations (flexible, but requiring significant end-user investment in testing and validation), and commercial OPA products like the COPA 500 system used for ACT.

“I like to think of commercial OPA products as the commercial realization of an OPAS system. It’s a group of system integrators and different vendors that have come together as a coalition of sorts, and they’ve made a product that’s available in the marketplace for sale, ready for implementation that day. No R&D required by you as the end user.”
— Alex Eaton, Wood [11:50]

That last phrase, “No R&D required by you as the end user”, is where the Lighthouse and ACT diverge most sharply. The Lighthouse required ExxonMobil’s engineers to do substantial technology development work. The ACT project did not. ExxonMobil handed the specification to Wood, Wood selected and integrated the COPA system, and the project proceeded. That is what “standard practice” looks like.

The COPA 500 system itself, assembled from CSI controllers, Phoenix Contact I/O, ASRock and SuperMicro hardware, and unified by CPLANE Fusion orchestration software, is the commercial packaging of the OPA standard. It carries the pre-testing, pre-validation, and vendor support that makes the difference between a technology demonstration and a procurable product.

Fusion: The Orchestration Layer That Makes Multi-Vendor Work

Underneath the COPA architecture sits one of its least-discussed but most important components: CPLANE Fusion, the orchestration software developed by CPLANE of Silicon Valley. Where other components in the COPA stack handle the physical control work, CPLANE Fusion handles something equally critical: making all those components behave as a single, unified system across their entire operational life.

CPLANE brings a background that is unusual in industrial automation: the company built its orchestration technology for Tier 1 telecommunications networks–environments where thousands of distributed components must be provisioned, monitored, updated, and recovered from failure automatically, often without any human intervention. That telecoms-grade discipline is now applied to industrial control systems through Fusion.

Fusion manages three lifecycle phases of an OPA system: startup (provisioning and configuration), operate (monitoring, failure recovery, cybersecurity), and evolve (updates, expansion, component swaps). Critically, it does this across the multiple vendor layers simultaneously (applications, virtualization, networking, and security). What would otherwise be a patchwork of separate vendor tools is managed as one coherent management surface.

The practical impact was demonstrated directly in a joint pilot with ExxonMobil: using CPLANE Fusion, a simulated multi-vendor plant was fully provisioned and configured in approximately 10 minutes. The same task by conventional methods was estimated at 50 to 100 person-hours. Don Bartusiak, then ExxonMobil’s Chief Engineer for Process Control, said the results “exceeded our expectations” and that orchestration findings from the pilot would “help us shape the evolution of our standards.”

This is precisely why the ACT project’s 100% first-party firmware achievement matters so much in combination with Fusion: there is no middleware bridging gaps between vendors, and there is a purpose-built orchestration layer managing the whole. The result is a system that can be provisioned rapidly, updated safely, and expanded without re-engineering the control architecture from scratch. That is a fundamentally different total-cost-of-ownership proposition than a traditional DCS and it is what COPA’s own figures quantify as up to 50% lower initial system cost and up to 70% lower lifetime TCO.

The Middleware Problem: Solved

One of the lingering criticisms of the Lighthouse, documented at the 2025 ARC Forum, was the need for middleware which is custom software glue between components that didn’t natively interoperate. It worked, but it was a friction point that represented a real gap between the OPA vision and the OPA reality.

Eaton reported that the ACT project closed that gap entirely:

“The ACT project is actually the realization of that goal because it actually is 100% first-party vendor firmware and software. These vendors are bought in not only to the ecosystem but also to OPAS as a whole. And everybody’s playing to their strengths.”
— Alex Eaton, Wood [13:00]

This is a direct, measurable improvement from the Lighthouse to ACT. The middleware problem was identified, fed back into the commercial OPA ecosystem, and resolved in the next project. That is exactly what a maturing technology standard is supposed to do.

The Most Important Word in the Room: Boring

If one moment from Eaton’s presentation encapsulates the state of OPA in 2026, it is this:

“Tyler and I were talking earlier. It was pretty boring. There wasn’t a lot of excitement from an OPA standpoint. A lot of the issues that we actually saw on the project were related to traditional project execution methodologies.”
— Alex Eaton, Wood [16:20]

In process control engineering, “boring” is not a criticism. It is the highest possible compliment. It means the technology performed as expected. The challenges ACT encountered, a key team member lost mid-project, data-availability delays in the early phases, are the ordinary friction of any capital project, not evidence of OPA-specific fragility. The project had standard problems, not new-technology problems. Watch the full session.

That distinction is everything. Critics of open, multi-vendor architectures have long argued that the reliability of traditional DCS systems comes from their tight, factory-tested integration and that assembling components from multiple competing vendors would inevitably produce unexpected failure modes. The ACT project’s “boring” implementation is a direct refutation of that argument. ExxonMobil’s own reporting on the Lighthouse confirms the same pattern: no major issues, no significant interruptions to operations.

Lessons Learned Compound: The Commercial Advantage

Eaton identified two OPA-specific lessons from ACT that will directly benefit future projects — and here again the difference between the Lighthouse era and the commercial-OPA era becomes visible.

The first lesson is practical: knowledge-sharing discipline matters enormously when team members change on a project that involves a technology stack most engineers haven’t seen before. Proactive documentation and communication — “that extra CC on the email” — is the mitigation.

The second concerns network and system assurance: OPA projects still carry a higher burden of proving reliability to clients, particularly around network failure response. The ACT Factory Acceptance Test included exhaustive network resilience testing. Eaton expects this burden to decline as the installed base grows and operator confidence accumulates.

Critically, the commercial OPA model is designed to accelerate exactly this kind of learning transfer:

“You get to apply lessons learned from an existing project and apply it to the next one and the next one and the next ones, and shorten that iteration cycle, and then take those lessons learned and apply them back to the standard as a whole.”
— Alex Eaton, Wood [18:55]

This is the compounding advantage of standardization. Each COPA deployment improves the product. Each improvement reduces the friction for the next deployment. The Lighthouse fed lessons back into the standard and into the commercial ecosystem. ACT is the direct beneficiary and ACT’s lessons will benefit the projects that follow.

What This Means: OPA Is Now a Procurement Decision, Not a Research Decision

Soderstrom’s closing message was a call to action but it was also a statement of where ExxonMobil now stands relative to OPA. The company is no longer in the business of proving the concept. It is in the business of applying it. Join the Open Process Automation Forum if you’re ready to do the same.

“ExxonMobil is really interested in building on the success of that Lighthouse project. We want to show that we’re leveraging our OPA knowledge as the technology matures. We’re really waiting for more stuff to come out in the marketplace. We’d like to also invite the other people to do things like join the forum and join us in looking into your own open process automation implementation so that we can really create some influence in the market.”
— Tyler Soderstrom, ExxonMobil [19:31]

The invitation is significant. ExxonMobil understands that the OPA ecosystem matures faster with more end-users buying, more system integrators delivering, and more lessons being shared. Every new deployment, however small, however “boring”, is a vote of confidence that accelerates the next one.

The Lighthouse proved that OPA could work. The Anchorage Chemical Terminal (ACT) is proving something more valuable: that it works reliably, repeatably, and commercially, for a different application, through a standard procurement process, with a product you can buy off the shelf.

That is what validation looks like.