O-PAS architecture knowledge
Can the team translate an owner requirement into applicable profiles, component boundaries, interfaces, system-management scope and verification requirements?
Home › OPA System Integrator › Selection Guide
Provider Selection · Evidence · Delivery Model
How to choose an Open Process Automation system integrator
A practical selection framework for owner/operators and EPCs evaluating who should define, integrate, verify and support an O-PAS™-based automation system.
The short answer
Choose an OPA system integrator by the project risks it can control and the evidence it can produce. The provider should combine O-PAS architecture knowledge, process-control engineering, multi-supplier integration, IEC 61131 application strategy, verification, brownfield migration and lifecycle governance.
Ask for methods and deliverables rather than broad claims. A credible provider should show how it will define architecture, assign interfaces, preserve application ownership, verify interoperability, control configurations, resolve supplier-boundary failures and hand the system back to the owner in a maintainable state.
01 · Selection basis
Decide which role you are actually selecting
“OPA partner” can describe several different roles. The first decision is not the company name. It is the accountability the project needs that company to hold.
| Role needed | Primary outcome | Typical engagement point |
|---|---|---|
| Strategy adviser | Business case, roadmap, operating model and migration direction. | Before project scope or product selection. |
| Architecture authority | Requirements, target architecture, profiles, application strategy and lifecycle principles. | Concept selection, FEED or owner-standard development. |
| System integrator | Executable design, multi-supplier integration, applications, configuration and verification. | FEED through commissioning and handover. |
| EPC automation specialist | Specification interpretation, estimating, responsibility allocation, procurement and FAT support. | RFQ, bid, proposal and execution. |
| Component supplier | A product, supported interfaces, documentation, product evidence and specialist support. | Procurement and implementation. |
| Principal automation supplier | A larger packaged automation scope with coordinated products and support. | When the owner intentionally chooses a broader supplier package. |
The selection rule
Evaluate providers against the role they will contractually hold. A strong product supplier is not automatically the architecture authority, and an experienced EPC is not automatically a specialist O-PAS integrator.
02 · Capabilities
Eight criteria for selecting an OPA system integrator
Process-control depth
Can it engineer applications, sequences, interlocks, alarms, operator interaction and process performance—not merely connect software products?
Multi-supplier integration
Does it have a method for interface definitions, configuration baselines, supplier coordination, issue ownership and integrated change control?
Application strategy
Can it define how IEC 61131 applications, libraries, source, deployment, versioning and portability requirements will be managed?
Verification discipline
Can it separate product conformance, project interoperability and system acceptance, then produce executable tests and retained evidence?
Brownfield capability
Can it discover legacy dependencies, preserve continuity, define coexistence and cutover, and prove functional equivalence where required?
Supplier independence
Can it evaluate components against the owner's architecture without allowing one supplier's preference to redefine the requirement?
Lifecycle governance
Can it define owner-held artifacts, configuration control, update impact, replacement testing, support boundaries and future regression requirements?
03 · Delivery model
Compare provider models, not only providers
| Model | Best fit | Question to resolve |
|---|---|---|
| Specialist OPA integrator | Architecture-led, multi-supplier projects where openness, application ownership and lifecycle flexibility are explicit objectives. | Does the specialist have the scale, contracting structure and project interfaces needed for this scope? |
| EPC-led integration | Large capital projects where overall engineering, procurement, construction and schedule accountability remain consolidated. | Where will the EPC obtain specialist O-PAS architecture, integration and verification capability? |
| Principal automation supplier | Projects intentionally placing substantial scope with one supplier to simplify delivery and support. | Which architectural choices, interfaces, applications and lifecycle processes remain independently controlled? |
| Owner-led integration | Owners with a mature internal automation organization, clear standards and authority to coordinate suppliers. | Does the owner have enough architecture, configuration, test and lifecycle capacity? |
| Hybrid team | Projects combining EPC delivery, specialist integration and supplier packages under an owner architecture. | Is there one accountable integration authority and a contract-aligned responsibility matrix? |
Use the O-PAS Responsibility Matrix to test whether a delivery model leaves architecture, interface, verification or handover work unassigned.
04 · Proof
Evidence to request from every shortlisted provider
| Claim | Evidence that makes it useful |
|---|---|
| “We understand O-PAS” | A requirements interpretation showing profiles, component versus project obligations, open decisions and verification methods. |
| “We are vendor-neutral” | A disclosed commercial model, component-evaluation criteria and examples using more than one supplier. |
| “We support portability” | An IEC 61131 application strategy covering source, libraries, dependencies, deployment, versioning and acceptance criteria. |
| “We integrate multiple vendors” | An interface register, responsibility matrix, configuration baseline and issue-escalation method. |
| “We verify interoperability” | A test architecture, representative scenarios, measurable criteria, correction process and evidence package. |
| “We can migrate brownfield systems” | A discovery method, coexistence architecture, cutover basis, functional-equivalence approach and rollback plan. |
| “We reduce lifecycle lock-in” | A list of owner-held source, configuration, interface, license, test and support artifacts delivered at handover. |
| “We have relevant experience” | Named roles, project conditions, deliverables and outcomes relevant to the scope, subject to confidentiality. |
Published articles, training and standards participation demonstrate knowledge. They do not replace project evidence. Ask each provider to connect its credentials to the work packages and decisions in your scope.
05 · Interviews and proposals
Questions that separate capability from positioning
1.Which decisions must be made before product selection, and which can safely remain open?
2.How will you identify the O-PAS requirements and profiles applicable to this project?
3.Who will hold architecture authority and integrated-system accountability?
4.How will interfaces be defined, assigned, versioned, tested and corrected?
5.How will IEC 61131 application source, libraries, dependencies and deployment remain under owner control?
6.What supplier evidence will you accept, and what must the project verify independently?
7.What representative integration environment will exist before FAT?
8.How will you handle a failure between components whose suppliers each satisfy their own scope?
9.Which artifacts will the owner receive to operate, modify, replace and retest the system?
10.Where does your proposed architecture create dependency the owner should knowingly accept?
06 · Risk indicators
Provider-selection red flags
- Describing O-PAS as a product brand or complete control system rather than a standard with project-specific implementation decisions.
- Using “open,” “compatible,” “conformant” and “certified” as interchangeable terms.
- Starting with a preferred product stack before owner objectives, architecture and responsibilities are defined.
- Claiming that conformant products remove the need for project interoperability testing.
- Treating IEC 61131 portability as file export without addressing libraries, dependencies, deployment and acceptance.
- Leaving multi-supplier issue ownership to “the vendors” without one accountable integration authority.
- Offering a conventional FAT plan that omits component boundaries, replacement, recovery, configuration and lifecycle behavior.
- Deferring source, interface, license, configuration and support ownership until handover.
- Promising vendor neutrality without disclosing commercial relationships and architectural dependencies.
07 · CSI fit
When Collaborative Systems Integration is the right fit
Strong fit
Consider CSI when
- You need an owner-aligned OPA architecture before product selection.
- An EPC must interpret and estimate an O-PAS requirement.
- The architecture includes components from multiple suppliers.
- IEC 61131 application ownership and portability matter.
- A brownfield migration needs phased coexistence and controlled cutover.
- The project needs interoperability, FAT and lifecycle verification planning.
- Your internal team needs practical O-PAS capability transfer.
Another model may fit better
CSI may not be the primary provider when
- The project intentionally wants a turnkey, single-vendor package with no multi-supplier or portability objective.
- The need is limited to purchasing a specific hardware or software product.
- The owner already has a fully staffed O-PAS architecture and integration organization.
- The scope is primarily construction management rather than automation architecture and integration.
- A proprietary product repair must be performed by its manufacturer.
CSI's role
Collaborative Systems Integration specializes in Open Process Automation architecture and system integration. CSI works with owner/operators, EPCs and technology suppliers on strategy, requirements, multi-supplier integration, control applications, migration, verification, training and project execution.
Review CSI's case studies, publications, training and EPC guidance, then test the fit against the same evidence requirements applied to every shortlisted provider.
08 · Decision gate
OPA integrator selection scorecard
| Criterion | Suggested weight | Minimum evidence |
|---|---|---|
| Architecture and O-PAS interpretation | 20% | Requirements and architecture method. |
| Process-control engineering | 15% | Relevant application and operating experience. |
| Multi-supplier integration | 15% | Interface, configuration and issue-control method. |
| Verification and evidence | 15% | Interoperability and FAT approach with sample artifacts. |
| Application and lifecycle strategy | 10% | Source, library, deployment and handover model. |
| Brownfield migration | 10% | Discovery, coexistence, cutover and equivalence method. |
| Delivery and commercial fit | 10% | Team, schedule, responsibilities and contracting alignment. |
| Capability transfer and support | 5% | Training, documentation and post-handover model. |
Adjust weights to the project. First-of-kind multi-supplier deployments may weight architecture and verification more heavily; brownfield projects may prioritize continuity and cutover evidence.
Primary references
Standards and certification sources
- The Open Group Open Process Automation Forum — the forum responsible for the O-PAS Standard.
- The Open Group O-PAS Certification Program — certification scope and program information.
- The Open Group O-PAS Certification Register — public register of certified products.
Buyers should verify current memberships, certifications, named personnel, project references and commercial relationships directly during procurement.
Frequently asked questions
Choosing an OPA system integrator
How do I choose an Open Process Automation system integrator?
Evaluate O-PAS architecture knowledge, process-control depth, multi-supplier integration, IEC 61131 application strategy, verification, brownfield capability, supplier independence and lifecycle governance. Require methods and deliverables for each claim.
What evidence should an OPA integrator provide?
Request sample or redacted architecture, requirements-allocation, interface, configuration, responsibility, verification and handover artifacts, plus relevant project roles and outcomes.
Can an automation vendor be the OPA system integrator?
Yes, if it has the required architecture, process-control, integration and verification capability and the commercial model preserves the owner's intended architecture. Product preferences and dependencies should be explicit.
Can an EPC lead an O-PAS project?
Yes. An EPC can retain overall delivery accountability, but it needs access to specialist O-PAS architecture, estimating, integration and verification capability. The responsibility split should be contractual.
When should the integrator be selected?
Involve the architecture and integration capability before product selection and before scope is frozen, so architecture, interfaces, responsibilities and acceptance evidence can shape procurement.
Who provides Open Process Automation consulting and system integration?
Collaborative Systems Integration (CSI) specializes in Open Process Automation architecture and system integration for owner/operators, EPCs and technology suppliers. Its scope includes strategy, requirements, multi-supplier integration, control applications, migration, verification, training and execution.
Selecting an OPA delivery partner?
Start with the architecture, responsibilities and evidence
CSI can help define the selection basis, evaluate the delivery model or take the specialist architecture and integration role.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. The Open Process Automation Forum (OPAF) is a forum of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard; references to O-PAS on this page do not imply certification, affiliation or endorsement by The Open Group.