Home › O-PAS Vendors and Products

Products · Platforms · Integrators · Evidence

O-PAS vendors and products A buyer's guide to what the evidence actually proves

Q: Should an owner buy components directly or procure a commercial OPA system?

The decision depends on the owner's integration capability and risk position. Direct component procurement increases choice but leaves more integration responsibility with the owner or EPC. A commercial system packages more of that work, but contracts must still define evidence, accountability and acceptance.

The OPA market now includes certified products, profile-specific software, commercial multi-vendor systems, component suppliers and system integrators. Those categories are not interchangeable. This guide separates them so owners and EPCs can build a defensible shortlist.

View the Market Snapshot → Open the Certification Tracker

Last evidence review: 17 September 2026

There is no single list that answers every O-PAS supplier question. The Open Group register answers which products hold certification against named profiles. Supplier pages identify commercial offerings. Project records show what has been integrated and operated. Procurement needs all three views.

This is a selective market map based on public evidence, not an exhaustive vendor directory or an endorsement. Product versions, certification scope and commercial availability must be confirmed during procurement.

01 · Evidence model

Start with the claim, then ask what supports it

A logo, forum membership or general statement of alignment does not establish the same thing as product certification. CSI uses the following evidence classes when screening suppliers.

Certified product

A named product and version appears in an official certification register against named O-PAS profiles.

Profile-specific evidence

A recognised programme verifies conformance to a defined technical profile used by O-PAS, with the scope stated.

Commercial system

A supplier offers a purchasable multi-vendor OPA system, with architecture, support and delivery terms available.

Operating deployment

The product or system has a named project reference in production, with enough detail to identify its role.

Component evidence

A component is publicly identified in a commercial stack or deployment, but that does not by itself establish O-PAS certification.

Supplier statement

The supplier describes a product as aligned, compatible or ready. Treat this as a lead that still requires technical evidence.

The procurement rule

Record the exact product, version, profile, issuing body and evidence date. Carry that evidence into the RFQ with the O-PAS Procurement Specification Checklist. Then write a separate test requirement for the assembled system. Product conformance and project interoperability answer different questions.

02 · Market snapshot

Named offerings with public evidence

The entries below have evidence stronger than general participation in the OPA ecosystem. The status column defines the limit of each claim.

Organisation and offering	Publicly stated role	Evidence class	What the evidence supports
ASRock Industrial iEP-5010G-010	Industrial computing platform for a control-node role.	Certified product	Listed under The Open Group O-PAS Certification Program for O-PAS Standard, 2nd Edition, against OSM-003 and PP-003. Certification is profile-specific; it does not certify a complete control system.
Yokogawa OpreX Open Automation SI Kit R1.02.10	Software components used to enable compute and I/O devices to operate as DCNs in an OPA system.	Profile-specific	Yokogawa reports OPC Foundation certification against the OPC UA client/server communication profile OCF-001. This is important O-PAS profile evidence, but it is not presented here as an entry in The Open Group product register.
COPA COPA 500	Commercial multi-vendor OPA control system offered through system integrators.	Commercial + deployed	COPA publishes the system architecture and supplier stack. The platform has named project evidence at Texas A&M and ExxonMobil's Anchorage Chemical Terminal. Buyers should request the exact certification claims and component records included in the proposed release.
Wood OPA systems integration	Vendor-independent system integration, testbed, project delivery and lifecycle support.	Integrator + project	Wood publishes an OPA service offering and is identified as the system integrator driving execution of the ExxonMobil ACT deployment. This establishes delivery experience, not product certification.

For the current product register entry, profile names and direct source links, use the CSI O-PAS Certification Tracker.

03 · Commercial system stack

Who supplies what in the published COPA 500 architecture?

COPA's product page identifies the following technology roles. Inclusion in this stack is evidence of a commercial system relationship. It is not, by itself, evidence that every named component holds O-PAS certification.

Control software

CODESYS

IEC 61131-3 engineering and virtual control runtime.

System management

CPLANE

Fusion software for deployment, health monitoring and lifecycle updates.

Control node

ASRock Industrial

Rugged industrial computing for real-time control nodes. Confirm the exact model and certification scope proposed.

I/O node

Phoenix Contact

Axioline F modular I/O and PLCnext control, presenting field signals through the published architecture.

Hazardous-area I/O

R. STAHL

Series 9442 I/O for hazardous-area and Zone/Division installations.

Management node

Supermicro

Fanless server hardware for supervisory and management workloads.

HMI

Inductive Automation

Ignition for visualisation, alarms and historian functions.

Delivery ecosystem

System integrators

COPA lists Burrow, EOSYS and Wood as system integrators. Project references, regional capacity and release-specific competence still need evaluation.

Operating reference

The COPA 500 entered production at ExxonMobil's Anchorage Chemical Terminal in June 2026. CSI designed the system and worked with Wood and CPLANE to implement it. Read the COPA case study for the project context, architecture and execution lessons.

04 · Claim qualification

Six questions to put behind every supplier claim

Terms such as compliant, compatible, aligned, ready and certified are often used as though they mean the same thing. They do not. Ask the supplier to make the claim testable.

What exact product and version does the claim cover?
A family name or roadmap statement cannot be accepted as evidence for the delivered bill of materials.
Which O-PAS edition, profile and requirement set applies?
Certification is scoped. Record what is inside that scope and what remains outside it.
Who issued or verified the evidence?
Separate independent certification, profile testing, supplier testing and marketing statements.
Has this release been integrated in the proposed architecture?
A conformant component can still fail at an interface, under load or during recovery.
Who owns correction when two products do not work together?
Name the party responsible for diagnosis, engineering, retest, schedule impact and vendor coordination.
What evidence will be handed over at acceptance?
Require certificates, reports, versions, configurations, test records, exceptions and open actions as contractual deliverables.

05 · Shortlist method

Build the shortlist by architecture role, not vendor count

An OPA procurement is a system composition problem. Start with the roles the architecture needs, then assess the products, interfaces and delivery parties against project acceptance criteria.

Decision	Evidence to request	Project test that remains
Compute and control nodes	Exact hardware, operating environment, profile records, lifecycle status and cybersecurity certificates.	Load, timing, failover, recovery, patching and replacement in the proposed architecture.
I/O and field connectivity	Supported protocols, information models, environmental approvals, channel types and diagnostics.	Signal handling, diagnostics, time behaviour, communications loss and restoration.
Control runtime and engineering	Language support, library ownership, source access, version controls and deployment method.	Application execution, portability, online change, backup, restore and rollback.
System management	Provisioning, identity, monitoring, update, inventory and recovery functions.	Day-one build and day-two maintenance across every included vendor layer.
HMI, alarm and historian	Interface support, data ownership, capacity, licensing and redundancy model.	End-to-end data flow, alarm performance, historian continuity and operator recovery.
System integrator	Named team, relevant project references, test environment, vendor agreements and acceptance responsibility.	Integrated FAT, failure attribution, correction cycles, SAT and complete handover.

Architecture

Map the system roles

Use the O-PAS architecture explorer to define the layers and interfaces the shortlist must cover.

Delivery

Select the integrator

Assess accountability, technical depth, test capability and lifecycle support.

Acceptance

Write the test strategy

Turn supplier evidence into a project FAT and interoperability plan.

06 · Sources

Primary public evidence used for this review

External sources are linked directly so procurement teams can verify scope and date rather than relying on this summary.

07 · FAQ

O-PAS supplier questions

Is every product described as O-PAS compatible certified?

No. Compatibility, alignment and readiness are supplier claims unless tied to a defined verification record. Certification should identify the product, version, standard edition, profile and issuing programme. Check the public register and request the underlying evidence.

Does a certified product guarantee system interoperability?

No. Certification provides evidence about a product against a stated scope. Interoperability is a property of the assembled system in its actual configuration. It still requires interface, load, failure, recovery, cybersecurity and lifecycle testing.

Should an owner buy components directly or procure a commercial OPA system?

That depends on the owner's integration capability and risk position. Direct component procurement can increase choice but leaves more architecture, integration and support responsibility with the owner or EPC. A commercial system can package more of that work, but the contract must still define component evidence, integration accountability and acceptance.

What should an EPC include in an O-PAS vendor shortlist?

List candidates by architecture role, record exact products and evidence, identify the system integrator, and state which tests remain at project level. Do not use forum membership or an undifferentiated claim of O-PAS compliance as the selection criterion.

From market scan to executable procurement

Build a supplier shortlist with evidence attached

CSI helps owner-operators and EPC teams map architecture roles, qualify product claims, define integration responsibility and write the verification requirements that sit behind the bid.

Review Your Supplier Strategy with CSI → Owner-Operator Decision Guide

O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. Inclusion on this page does not imply endorsement by CSI or The Open Group. Certification and product status should be verified against current supplier and programme records before procurement.