COPA Case Study: ExxonMobil ACT Commercial O-PAS Deployment

Executive summary

ExxonMobil's Open Process Automation Lighthouse proved that an open, multi-vendor control system could operate at commercial scale. The Anchorage Chemical Terminal project, known as ACT, addressed the next question: could the same approach be delivered as a normal commercial automation project?

ACT was a smaller greenfield application involving tank storage, chemical metering, pumps, valves and basic control loops at ExxonMobil's Baton Rouge complex. The terminal had previously been operated manually.

CSI designed the COPA 500 system and worked with Wood and CPLANE to implement it for ExxonMobil. Wood led system integration and project execution. CPLANE supplied the Fusion orchestration layer used to provision and manage the multi-vendor system.

The project completed factory acceptance testing and entered production on June 24, 2026. Its importance was not its size. It showed that an O-PAS-based system could be specified, competitively procured, integrated and commissioned through a conventional commercial project structure.

The business need

The Anchorage Chemical Terminal is a midstream tank-storage and chemical-metering facility serving other ExxonMobil sites in the Baton Rouge area. Before the project, operators managed the facility manually.

ExxonMobil therefore had a genuine automation requirement. Unlike the earlier Lighthouse project, ACT was not selected primarily to test the limits of Open Process Automation. The project had to stand on its own as the appropriate solution for the facility.

OPA requirements were incorporated into the request for proposals, and the work proceeded through a competitive commercial bid. The project did not receive a separate R&D delivery structure.

Project responsibilities

Organisation	Project role
ExxonMobil	Owner, end user and operator of the Anchorage Chemical Terminal
CSI	Designed the COPA 500 system and collaborated on implementation
Wood	Systems integration and project execution
CPLANE	Fusion orchestration software and collaboration on implementation
COPA ecosystem partners	Supplied the control, I/O, computing and supporting system components

This division of responsibility matters. ACT was not an owner-led technology experiment requiring ExxonMobil to develop the solution itself. It was delivered through named commercial suppliers with defined roles.

The COPA 500 solution

The COPA 500 packaged multiple vendor technologies into a commercially available Open Process Automation system. The ACT implementation included CSI controllers, Phoenix Contact I/O, ASRock and Supermicro computing hardware, and CPLANE Fusion orchestration software.

Fusion provides a common management layer across the system lifecycle:

Start up: provisioning and configuration
Operate: monitoring, cybersecurity and failure recovery
Evolve: updates, expansion and component replacement

That orchestration layer is important in a multi-vendor architecture. It allows applications, computing, networking and security components to be managed as one operational system rather than as a collection of separate vendor tools.

Removing the middleware dependency

The Lighthouse project required custom middleware to bridge components that did not yet interoperate through their native vendor software. Although the deployment worked, that bespoke integration represented additional engineering and lifecycle responsibility.

ACT reported a significant change: the system used first-party vendor firmware and software without custom middleware connecting the participating products.

This was a practical sign of maturity. Lessons from the Lighthouse project had been incorporated into the commercial COPA offering, reducing the custom engineering required from the next end user.

Factory acceptance and commissioning

The project completed factory acceptance testing before entering production. Because open, multi-vendor systems still carry a greater burden of proof than established proprietary DCS platforms, the FAT included extensive network-resilience testing.

The testing was intended to demonstrate how the system would respond to network and component failures, not merely that its normal control functions worked under ideal conditions.

The project team reported that the most notable difficulties were familiar capital-project problems rather than failures unique to OPA. These included the loss of a key team member and delays obtaining information during the early project stages.

The system was commissioned and placed into production on June 24, 2026.

Lighthouse and ACT compared

ExxonMobil Lighthouse	Anchorage Chemical Terminal
R&D-oriented deployment	Standard commercial project
Replacement of an obsolete DCS	Greenfield automation of a manual facility
Live hydrocarbon production unit	Tank storage and chemical metering
More than 100 controllers and 1,000 I/O points	Smaller application with pumps, valves and basic loops
Required bespoke integration and middleware	Used first-party vendor firmware and software
Proved commercial-scale technical feasibility	Demonstrated repeatable commercial delivery

The two projects should not be judged by size alone. Lighthouse deliberately tested a difficult, broad application. ACT tested whether the lessons could be packaged into a system that an end user could procure and implement through normal project channels.

What the project demonstrated

ACT provided evidence for five important conclusions:

OPA could be selected for a business need rather than as a research exercise. The terminal needed automation, and the solution was expected to justify itself commercially.
The work could be competitively procured. OPA requirements were embedded in the project specification and issued through a conventional request-for-proposal process.
Commercial suppliers could carry the implementation burden. ExxonMobil did not have to recreate the technology-development model used for the Lighthouse.
Multi-vendor integration could proceed without custom middleware. Participating products used their vendors' firmware and software.
The remaining challenges looked like normal project risks. Knowledge transfer, information availability and assurance planning mattered more than novel technology failures.

Lessons for future O-PAS projects

Assign responsibility before the bid is frozen

The owner, systems integrator, platform designer, orchestration provider and component suppliers need clearly defined responsibilities. This becomes particularly important when two conformant products do not behave as expected together.

CSI's O-PAS Responsibility Matrix provides a starting point for making those boundaries explicit.

Treat interoperability as an acceptance activity

Conformance evidence does not replace project-level testing. The FAT must cover component interaction, degraded network conditions, recovery behaviour and the operational scenarios that matter at the facility.

The O-PAS FAT and Interoperability Testing Guide explains how to convert those concerns into an acceptance plan.

Procure a supported system, not a collection of parts

Commercial packaging, orchestration, pre-testing and defined support responsibilities reduce the amount of technology development an owner must perform. The OPA System Integrator Selection Guide identifies the capabilities required to deliver that model.

Preserve project knowledge

ACT reinforced the importance of documentation and proactive knowledge transfer. On projects involving an unfamiliar technology stack, critical decisions cannot remain with one engineer or inside one supplier's inbox.

Evidence note

This case study describes project facts reported by the project participants and in the COPA account of the deployment. It does not claim an ACT-specific percentage reduction in capital cost or lifecycle cost because the project has not publicly disclosed the cost data needed to calculate those results.

Sources

Planning an O-PAS project? Start with CSI's EPC O-PAS Bid Readiness Checklist, or talk to CSI about system design, integration and verification planning.