Home › O-PAS for EPCs
For EPC Organizations · Specification · Estimating · Project Execution
O-PAS for EPCs Specification, estimating and project execution
An owner specification that requires O-PAS™ changes the automation scope, the responsibility boundaries and the estimating basis. This page sets out what changes, what to price, who owns what, and what conformance does and does not establish.
The short answer
An O-PAS requirement in an owner specification changes more than the product selection. It affects system architecture, supplier responsibility boundaries, control application strategy, interoperability verification, conformance evidence, factory and site acceptance testing, and the lifecycle artifacts handed over at project close. Treating it as one more clause in a conventional DCS specification leaves scope undefined — and undefined scope becomes either contingency the EPC carries or execution risk the EPC absorbs.
The practical response is not to price O-PAS as a line item. It is to decompose the requirement into architecture, application, integration, verification and handover scope; assign every element to the owner, the EPC, the system integrator or a component supplier; and close the remaining questions before the bid basis is frozen.
Collaborative Systems Integration (CSI) does that work with EPC engineering, estimating and project teams.
01 · Scope
What changes when an EPC specification requires O-PAS?
O-PAS is not a substitute product selection. It is a set of requirements about how a system is composed, how its components interface, how they are managed, and what evidence exists that each of those things is true. That shifts work into the EPC's architecture and integration functions — work a conventional DCS bid assumes a principal automation supplier will absorb.
| Project area | What an O-PAS requirement changes | Where it lands in the estimate |
|---|---|---|
| System architecture | The system is decomposed into components with defined interfaces, rather than procured as one supplier's integrated stack. | Architecture and requirements-analysis engineering, earlier in the schedule than a conventional project expects. |
| Applicable profiles | Requirements apply through the O-PAS profiles named in the specification. “O-PAS” on its own does not identify which requirements are in force. | Specification review, and assessment of which requirements are covered by supplier evidence versus project testing. |
| Supplier boundaries | Functions previously delivered by one principal automation supplier may be distributed across several component suppliers. | Interface engineering, procurement coordination, and genuinely multi-vendor project management. |
| Control applications | Application strategy, libraries, deployment and portability requirements become explicit project scope rather than a supplier default. | Application engineering, migration or redevelopment of existing logic, and library development. |
| Connectivity | Data exchange between components follows the connectivity framework defined by the applicable profiles, with interfaces that have to be specified rather than inherited. | Interface definition, information modeling, and interface testing. |
| System management | Configuration, deployment, versioning and monitoring have to work across components from more than one supplier. | Engineering effort, tooling, and acceptance criteria that a conventional FAT scope does not include. |
| Cybersecurity | Security requirements apply through the applicable O-PAS profiles alongside the owner's own security standards. | Design, configuration, verification and documented evidence — not a configuration task at the end of engineering. |
| Verification | Product conformance evidence and project interoperability testing become two separate activities with two separate owners. | Test environment, test development, and additional factory acceptance testing. |
| Deliverables and handover | Architecture documentation, interface definitions, configuration artifacts, application source and test records are lifecycle assets the owner will expect to hold. | Documentation effort and a defined handover scope. |
The point
An O-PAS requirement changes the technical architecture and the project's responsibility boundaries. The second effect is the one that shows up in the estimate, and it is the one most often left undefined in the RFQ.
02 · Commercial risk
Why O-PAS can create estimating risk
A conventional DCS bid rests on an assumption that is rarely written down: one principal automation supplier delivers a tightly integrated stack, and that supplier carries the integration risk inside its own product boundary. Interfaces between the controller, the operator environment, the engineering tools and the historian are the supplier's problem, priced into the supplier's number.
An O-PAS project may distribute those functions across several suppliers. When it does, the integration risk does not disappear with the single-supplier assumption. It moves — usually toward the project architecture and system-integration function, and often toward the EPC by default rather than by decision.
That is the estimating problem in one sentence: the work is real whether or not anyone has been assigned to it.
The failure mode is not that EPCs price O-PAS wrongly. It is that they price it against a scope basis that was never established. Two bidders can read the same specification and produce numbers that differ by a wide margin, not because they disagree on rates, but because one has assumed integration responsibility sits with a supplier and the other has assumed it sits with the EPC.
Both are guessing. Only one of them finds out during execution.
Where the uncertainty concentrates
Each of these is a normal, resolvable question. Left unresolved at bid, each becomes a priced assumption that may not survive contact with the project.
| Estimating uncertainty | The question that resolves it before pricing |
|---|---|
| System-integrator scope | Who holds single-point responsibility for the integrated system, and is that role priced inside this bid, contracted separately by the owner, or unassigned? |
| Supplier boundaries | Which functions are supplied by whom, and where does each supplier's responsibility begin and end? |
| Interface engineering | How many interfaces exist, who defines them, and who resolves behavior that does not match the definition? |
| Integration test environment | Does the project require a representative integration or staging environment? Who builds it, who hosts it, and who pays for it? |
| Interoperability verification | What has to be demonstrated, against what acceptance criteria, at whose facility, and at what point in the schedule? |
| Application migration | Is existing control logic being migrated, re-engineered or replaced — and who owns functional equivalence to the legacy system? |
| Additional FAT effort | Which multi-supplier scenarios are in FAT scope beyond conventional loop checks, graphics review and alarm testing? |
| Conformance documentation | What evidence must be collected from each supplier, who verifies it, and what happens if it does not cover a requirement in the specification? |
| Configuration and lifecycle management | What configuration management is required during execution, and what has to be handed over at close? |
| Failed interfaces | When two products that each meet their stated requirements do not work together, who is contractually responsible for resolving it — and at whose cost? |
| Division of responsibility | Has the owner stated the intended owner / EPC / integrator / supplier split, or is the RFQ silent and the bidder expected to propose one? |
Callout
If these responsibilities are not explicit in the RFQ, the risk does not disappear. It becomes contingency — and contingency is either money the EPC loses on price, or money the EPC does not have when the interface problem arrives.
03 · Bid scope framework
What scope should an EPC include when bidding an O-PAS project?
Six scope areas. An O-PAS bid should state a position on every item below — included, excluded, or qualified as an assumption. Items with no stated position are the ones that generate claims.
Architecture
- Target O-PAS system architecture for the project
- Equipment, software and licensing boundaries
- Interfaces to existing systems, packaged units and third-party skids
- System-integration responsibility — explicitly assigned
- Applicable profiles identified against the owner's requirements
Application scope
- Control application design and configuration
- Migration or redevelopment of existing applications, with a functional-equivalence basis
- IEC 61131 application strategy and programming environment
- Reusable library development and ownership
- Application deployment, versioning and lifecycle requirements
Supplier integration
- Vendor interface definitions and data exchange specifications
- Component compatibility assessment across the selected suppliers
- Profile applicability per component
- An integration responsibility matrix agreed with the owner
- Technical query and issue-resolution process across suppliers
Verification and testing
- Collection and review of supplier conformance evidence
- Project interoperability testing scope and acceptance criteria
- Factory acceptance testing, including multi-supplier scenarios
- Site acceptance testing and commissioning verification
- Application testing and control-behavior verification
- Recovery, failover and component-replacement testing
Engineering deliverables
- Architecture documentation
- Interface definitions and data models
- Configuration artifacts and configuration management records
- Control application source and libraries
- Test procedures and executed test records
- Lifecycle and handover documentation
Training and support
- EPC engineering, estimating and proposal team competency
- Owner training obligations carried in the contract
- Commissioning and startup support
- Post-handover support model and its boundaries
- Competency transfer where CSI or another integrator is engaged
Related: How to work with CSI · EPC Certification Program · OPA Architecture Explorer
04 · Conformance
What does O-PAS conformance mean in an automation specification?
Direct answer
Conformance is a statement about a product, measured against a specific profile, verified through a defined process. It is not a statement about a system, and it is not a substitute for project acceptance. An EPC reading “O-PAS conformant” in a specification needs to establish four separate things: which profiles the owner is actually invoking, which of those are covered by supplier conformance evidence, which are covered only by the project's own testing, and what the owner will accept as proof at handover.
| Term | What it establishes | What it does not establish |
|---|---|---|
| An O-PAS requirement in the specification | A contractual requirement written by the owner, referencing the standard or specific parts of it. | That any particular product satisfies it, or that the project scope needed to satisfy it has been defined. |
| An applicable profile | A defined set of conformance requirements a product can be measured against. Requirements apply through profiles — not to “O-PAS” in the abstract. | That every profile is relevant to this project, or that the profiles named cover the whole of the owner's requirement. |
| Product conformance certification | Independent verification, through a Recognized Verification Laboratory, that a specific product meets the requirements of a specific profile. Certified products are listed in a public register maintained by The Open Group. | That the product will interoperate with every other certified product in your architecture, in your configuration, under your loading. |
| Project interoperability | Demonstrated, tested behavior between the specific components in this project's architecture, in this project's configuration. | Anything about components, versions or configurations that were not in the tested arrangement. |
| Project acceptance | The owner's contractual criteria for accepting the delivered system, which the EPC has to satisfy. | Nothing is automatically satisfied by conformance evidence alone. Acceptance criteria are their own scope. |
The distinction that matters commercially
Product conformance does not eliminate system integration or project acceptance testing. Conformance is evidence about a product against a profile. Interoperability is a property of a system, demonstrated by test. A bid that treats the first as though it delivers the second has under-scoped the project.
What an EPC can actually check
The Open Group announced the O-PAS Certification Program on 1 October 2024, initially covering the Connectivity Framework and Global Discovery Server profiles, with further profiles anticipated. Certification is granted against a named profile and verified by a Recognized Verification Laboratory rather than self-declared by the supplier — a distinction end users specifically asked for. The current list of certifiable profiles, certified products, recognized test tools and recognized verification laboratories is published by The Open Group.
Two practical consequences during bid evaluation:
- A supplier's conformance claim can be checked against the public register rather than accepted at face value.
- The profiles a product is certified against may be narrower than the scope of the owner's specification. The specification review has to establish which requirements are covered by supplier evidence and which are covered only by the project's own verification — because the second set is project scope somebody has to price.
A note on language in bids and proposals
Where CSI describes components or systems it has integrated, it uses the term “O-PAS compatible” unless a specific product holds certification against a specific profile, in which case the certification is named. That distinction is worth adopting in bid documents. A claim of certification is checkable against a public register, and an overstated claim is a commercial exposure that survives the whole life of the contract.
External references: The Open Group — O-PAS Certification Program · O-PAS certification process · O-PAS certification register · CSI OPA glossary
05 · Estimating
How should an EPC estimate an O-PAS project?
Direct answer
Estimate it in two passes. The first pass establishes the scope basis: the target architecture, the supplier boundaries, the integration responsibility, the verification scope and the handover deliverables. The second pass prices that basis and applies contingency only to the unknowns that remain identified and named. Reversing the order — pricing first, then discovering the scope — produces either an uncompetitive number carrying blanket contingency, or a competitive number carrying unpriced risk.
| Cost area | What the EPC is actually estimating | Where estimates commonly fall short |
|---|---|---|
| Architecture | Requirements analysis, system decomposition, interface definition, supplier boundary definition. | Treated as an extension of conventional specification review, when it is a distinct engineering activity that has to complete before the rest of the estimate is credible. |
| Control application engineering | Control logic, configuration, information modeling, library development, application deployment. | Existing application migration assumed to be a like-for-like transfer, rather than re-engineering with functional-equivalence testing attached. |
| Multi-supplier integration | Interface engineering, integration sequencing, and issue resolution across supplier boundaries. | Assumed to be absorbed by a principal supplier that this architecture may not have. |
| Test environment | A representative integration or staging environment, and the effort to build, operate and maintain it. | Omitted entirely, or assumed to be a supplier's facility without a contractual basis for access or duration. |
| Factory acceptance testing | Conventional FAT plus interoperability, component replacement, deployment, recovery and system-management scenarios. | Scoped from a conventional single-supplier DCS FAT baseline, then compressed when the schedule slips. |
| Cybersecurity | Requirements from the applicable O-PAS profiles and the owner's own standards: design, configuration, verification and evidence. | Treated as a configuration task at the end of engineering rather than a design-and-verification scope carried throughout. |
| Supplier coordination | Multi-vendor project management, technical query handling, alignment of several supplier schedules and release cycles. | Priced at conventional single-supplier project-management ratios. |
| Training and competency | EPC engineering, estimating and proposal team competency, plus any owner training carried in the contract. | Assumed rather than scoped — particularly on a first O-PAS project, where the learning happens on the client's schedule. |
| Commissioning | Site integration, cross-supplier issue resolution, cutover and startup support. | Under-resourced wherever interface issues are allowed to surface for the first time on site. |
| Contingency | Priced risk against identified, named, unresolved unknowns. | Applied as a blanket percentage in place of a scope basis — which either loses the bid or buries the risk. |
On contingency
Contingency is a legitimate answer to a known unknown. It is an expensive answer to an undefined scope. The estimating work is to move items out of the second category before pricing the first. CSI's role with EPC teams is usually to establish that scope basis — before contingency is applied, and before the bid basis is frozen.
For lifecycle economics over the operating life of the asset rather than the project, see the CSI OPA ROI calculator and CSI's published lifecycle cost work.
06 · Division of responsibility
The responsibility matrix
Most O-PAS estimating disputes are responsibility disputes wearing a cost argument. The matrix below is a defensible starting position for a project where the owner sets the requirement, the EPC holds delivery, and a specialist system integrator supports architecture and integration.
A Accountable — single point of answerability · R Responsible — performs the work · C Contributes or is consulted · — Not typically involved
| Activity | Owner | EPC | System integrator | Component supplier |
|---|---|---|---|---|
| Defining the O-PAS requirement and applicable profiles | A | C | C | — |
| Interpreting the requirement into project scope | C | A | R | C |
| Target system architecture | C | A | R | C |
| Component selection and technical bid evaluation | C | A | R | C |
| Control application design | C | A | R | C |
| Multi-supplier integration | — | A | R | C |
| Cybersecurity design and configuration | A | R | R | C |
| Product conformance evidence | C | C | C | A |
| Project interoperability testing | C | A | R | C |
| Factory acceptance testing | C | A | R | C |
| Site acceptance and commissioning | C | A | R | C |
| Configuration management during execution | — | A | R | C |
| Lifecycle handover and documentation | C | A | R | C |
How to use this
This is an illustrative default, not a prescription. The allocation shifts with the contracting model, the owner's internal automation capability, whether a principal automation supplier is retained, and whether system integration is contracted separately. The purpose of the matrix is not to fix the answer — it is to force the question to be asked for every row before the bid basis is frozen. Any row the RFQ leaves silent is a row the EPC is implicitly pricing.
ARC Advisory Group's guidance on early production deployments of open architectures emphasizes explicit multi-vendor accountability and a focus on day-two operations — the same two things this matrix is intended to make contractual rather than assumed.
07 · Verification
What changes in FAT on an O-PAS project?
Direct answer
A conventional FAT is largely a functional test of one supplier's delivered system: loops, graphics, alarms, sequences, interlocks. On a multi-supplier O-PAS project, the functional test is still necessary but no longer sufficient, because a new class of failure exists — behavior at the boundaries between components from different suppliers. FAT scope has to be extended to cover those boundaries, and that extension is engineering effort and test-environment cost that has to be in the estimate.
| Verification area | What the test has to demonstrate |
|---|---|
| Multi-supplier communications | That components from different suppliers exchange the specified data, with the specified semantics, under representative load. |
| Interface behavior | That interfaces behave as defined at the edges — on loss of connection, on restart, on out-of-range and invalid data, and on version mismatch. |
| Application deployment | That control applications can be deployed, updated and rolled back through the defined workflow, with a repeatable result. |
| Component replacement | That a defined component can be replaced and returned to service within the project's stated criteria, with configuration intact. |
| Configuration recovery | That system configuration can be backed up and restored across components from more than one supplier. |
| Failover and recovery | That the redundancy and recovery behavior specified for the project actually occurs, and within the specified bounds. |
| System management functions | That configuration, versioning, monitoring and diagnostics operate across the whole system rather than per supplier island. |
| Cybersecurity acceptance | That the security requirements carried in the applicable profiles and the owner's standards are demonstrably met and evidenced. |
| Control application behavior | That control behavior in the target runtime environment matches the design intent — and, on a migration, the legacy system it replaces. |
These are project requirements and verification activities. O-PAS defines requirements and provides a conformance mechanism for products against profiles. It does not, on its own, guarantee that a given system will interoperate, fail over, recover or perform to a particular project's criteria. Those remain properties a project establishes by design and demonstrates by test — which is precisely why the test scope belongs in the estimate.
Related reading: DCS migration strategies for brownfield facilities · Cybersecurity architecture for OPA systems
08 · Services
How Collaborative Systems Integration (CSI) supports EPC organizations
Six engagement modules. Most EPC relationships start with the first two, because that is where the commercial exposure is largest and the cost of getting it right is smallest.
O-PAS Specification Review
CSI reads the owner's specification and requirements against the standard and identifies what is ambiguous, what is missing, what is commercially significant, and which requirements are covered by supplier evidence versus project testing. The output is a list of clarifications worth raising before the bid basis is frozen.
EPC Estimating Support
CSI helps define the architecture, integration scope, supplier responsibilities, verification requirements and stated assumptions that the estimate rests on — so that contingency is applied to named unknowns rather than to an undefined scope.
Architecture & Engineering Support
Target architecture development, control application strategy, interface definition and project engineering support through FEED and detailed design.
Multi-Vendor Integration
CSI coordinates and integrates O-PAS compatible components and applications into the project architecture, and holds the integration workstream where the EPC does not carry that capability in-house.
FAT & Verification Planning
Development of project-specific interoperability, functional, recovery and lifecycle acceptance tests — with acceptance criteria written so they can be evidenced at handover.
EPC Team Training
Practical O-PAS training for proposal, estimating, engineering and project teams, through CSI Academy and the EPC Certification Program — three assessed credentials built around the EPC project lifecycle.
09 · Timing
When should an EPC bring CSI into the project?
Direct answer
Ideally before the bid basis is frozen. Every question on this page is cheaper to answer while the commercial position is still open. After award the same work is still worth doing — it just has less room to change the outcome, because the scope has already been priced.
| Stage | What CSI does at this point | What it protects |
|---|---|---|
| RFQ review | Reads the owner specification and identifies ambiguous, missing or commercially significant requirements. | The quality of the clarification questions you get one chance to ask. |
| Bid / no-bid | Assesses whether the scope is definable on the information available, and what would have to be true for it to be. | A bid built on a basis that does not exist. |
| Proposal development | Defines architecture, integration scope, supplier responsibilities, testing requirements and the assumptions to state explicitly. | The scope basis underneath the price. |
| Clarification phase | Drafts technical clarifications and qualifications for submission to the owner. | Responsibility boundaries, in writing, before award. |
| FEED | Develops target architecture, interface definitions and application strategy. | Rework in detailed engineering. |
| Supplier evaluation | Checks conformance claims against published evidence and assesses component fit to the architecture. | Selection decisions that are expensive to reverse. |
| Detailed engineering | Application strategy, interface definition, integration planning and sequencing. | Schedule. |
| FAT planning | Builds project-specific interoperability, functional and lifecycle acceptance tests. | The last point at which integration problems are still cheap. |
| First O-PAS project | Works alongside the EPC's own team so the capability transfers rather than being rented indefinitely. | The margin on the second project. |
10 · Failure modes
Common EPC mistakes on O-PAS projects
- Treating O-PAS as a conventional DCS product requirement. The requirement is about composition and evidence, not about which brand of controller is quoted.
- Assuming “O-PAS compatible” defines sufficient project scope. It describes a component. It says nothing about who integrates, tests or accepts the system.
- Leaving integration ownership ambiguous. Whoever is accountable, it should be a decision rather than a discovery.
- Treating product conformance as system acceptance. Conformance evidence and acceptance criteria are two different documents with two different owners.
- Underestimating multi-supplier FAT. The scenarios that matter most are the ones a single-supplier FAT never had to include.
- Failing to specify application lifecycle requirements. Deployment, versioning, backup and restore are scope, not features.
- Pricing before supplier responsibility boundaries are defined. The number is then an opinion about a scope nobody has written down.
- Waiting until detailed engineering to resolve architecture questions. By then the answers change the price and the schedule rather than informing them.
Download
EPC O-PAS Bid Readiness Checklist
A working checklist for proposal, estimating and engineering teams responding to a specification that requires O-PAS. Structured as questions to answer before the bid basis is frozen — not as a marketing overview.
- Architecture and system decomposition questions
- Supplier responsibility and boundary questions
- Control application and lifecycle requirements
- Conformance and evidence questions
- FAT and verification considerations
- Estimating assumptions to state explicitly
- Commercial risk questions to close before pricing
Vendor-neutral • No product content • Immediate delivery
Get the checklist
EPC O-PAS Bid Readiness Checklist
Collaborative Systems Integration (CSI)
Your information is sent to the CSI team only. No marketing lists, no third-party sharing.
Evidence
Why an EPC would work with CSI on this specifically
Collaborative Systems Integration (CSI) is a specialist Open Process Automation firm based in Boulder, Colorado, founded in 2017. The relevant credentials for an EPC are the ones that bear on specification interpretation, integration and verification.
Principals from inside the Forum
Don Bartusiak, CSI's President and co-founder, was elected Co-Chair of The Open Group Open Process Automation Forum from 2016 to 2023 — the period through which the O-PAS Standard was defined — and was previously Chief Engineer of Process Control at ExxonMobil. Trevor Cusworth is a past Forum Co-Chair and leads marketing and outreach within the Forum's Business Working Group.
Commercial license from The Open Group
CSI operates under a commercial license from The Open Group authorizing use of the O-PAS Standard in commercial publications, offerings and services, with attribution. CSI is an independent licensee; the license is not an endorsement.
Coalition for Open Process Automation
CSI is a co-founding partner of COPA, a group of suppliers and integrators aligned around vendor-neutral, modular process control. COPA's system-integrator membership, including CSI, has been reported in the trade press since 2022.
Multi-vendor integration in practice
CSI's published work includes the Texas A&M AI-assisted nuclear control deployment on the COPA 500 open platform, integrating third-party hardware as distributed control nodes inside a safety-critical architecture.
The reference book and the annual report
CSI publishes Open Process Automation: Architecture, Execution, and Transformation and the annual State of OPA report, including material on project execution, migration, governance and failure modes. See publications →
An EPC-specific competency program
The CSI EPC Certification Program assesses competency across five domains anchored to the EPC project lifecycle — standard and architecture literacy, specification and procurement, system and network design, execution and commissioning, and commercial, risk and lifecycle.
Independent references
Sources an EPC can check without going through CSI:
- The Open Group — O-PAS Certification Program. What certification covers, how conformance is verified, and the public registers of certified products, recognized test tools and recognized verification laboratories.
- The Open Group Open Process Automation Forum. Membership, working groups and the standard itself.
- ARC Advisory Group on ExxonMobil's Resins Finishing Plant in Baton Rouge, Louisiana — reported as the first production O-PAS-aligned distributed control system, cut over at the end of 2024 and running through 2025 without significant interruption to operations.
- Control Global (Jim Montague, March 2022) on O-PAS conformance testing, interoperability workshops, the verification-laboratory model, and COPA's system-integrator membership.
External references are provided so that claims on this page can be checked independently. CSI is not affiliated with ARC Advisory Group or Control Global, and none of these sources constitutes an endorsement of CSI.
Frequently asked questions
O-PAS questions EPC teams ask
How should an EPC respond to a specification requiring O-PAS?
Start by establishing what the requirement actually invokes. Identify which O-PAS profiles the owner is referencing, which requirements are covered by supplier conformance evidence and which will only be satisfied by project testing, and where the owner intends the system-integration responsibility to sit. Then decompose the requirement into scope: architecture, control applications, supplier interfaces, verification and testing, and lifecycle deliverables. Assign each element to the owner, the EPC, a system integrator or a component supplier, and raise the unresolved items as formal clarifications before the bid basis is frozen. The response that fails is the one that treats O-PAS as a product clause and prices it as a substitution. The response that works treats it as a change to the project's responsibility structure and prices that structure explicitly.
How do you estimate an O-PAS project?
In two passes. The first establishes the scope basis: target architecture, supplier boundaries, integration responsibility, interface count and complexity, application migration approach, verification scope, test environment requirements and handover deliverables. The second prices that basis across defined cost areas — architecture, control application engineering, multi-supplier integration, test environment, factory acceptance testing, cybersecurity, supplier coordination, training, commissioning — and applies contingency only to unknowns that remain identified and named. Estimating in the reverse order produces either a number carrying blanket contingency, which loses competitive bids, or a competitive number carrying unpriced risk, which loses money during execution. The discipline is to reduce the undefined scope before pricing the residual risk.
What scope should an EPC include when bidding an O-PAS project?
Six areas, each with an explicit position of included, excluded or qualified. Architecture: target system architecture, equipment and software boundaries, interfaces to existing and packaged systems, and a named system-integration responsibility. Application: control application design, migration or redevelopment of existing logic, IEC 61131 application strategy, reusable libraries, and deployment and lifecycle requirements. Supplier integration: interface definitions, component compatibility, profile applicability per component, and an integration responsibility matrix. Verification and testing: conformance evidence review, project interoperability testing, factory and site acceptance testing, application testing, and recovery and failover testing. Engineering deliverables: architecture documentation, interface definitions, configuration artifacts, application source, test procedures and records, and handover documentation. Training and support: EPC team competency, owner training obligations, commissioning support and the post-handover support model.
What does O-PAS conformance mean in an automation specification?
Conformance is a statement about a product, measured against a specific profile. Profiles are defined sets of requirements; a product is certified against named profiles, not against “O-PAS” in general. Under The Open Group's O-PAS Certification Program, announced on 1 October 2024, conformance is verified independently through a Recognized Verification Laboratory rather than self-declared, and certified products are listed in a public register. What conformance does not establish is system-level interoperability. Two certified products may still fail to work together in a particular architecture, configuration or loading condition. That is why project interoperability testing and the owner's acceptance criteria remain separate scope. An EPC should read a conformance requirement as one input to system assurance, not as a replacement for it.
What are the biggest estimating risks in an O-PAS project?
Undefined responsibility and undefined integration scope, in that order. A conventional DCS bid quietly assumes a principal automation supplier absorbs integration risk inside its product boundary. An O-PAS architecture may distribute functions across several suppliers without reassigning that risk to anyone in particular, so it lands on the EPC by default. The specific exposures are: unassigned system-integrator scope; undefined supplier boundaries; uncounted interface engineering; an integration test environment nobody has costed; interoperability verification with no stated acceptance criteria; application migration assumed to be a like-for-like transfer; FAT scoped from a single-supplier baseline; conformance documentation with no named verifier; and no contractual answer to the question of who resolves a failed interface between two suppliers. Each is resolvable at bid stage. None resolves itself later.
Who provides O-PAS consulting for EPC companies?
Collaborative Systems Integration (CSI) provides O-PAS consulting to EPC organizations, covering specification review, estimating support, architecture and engineering, multi-vendor integration, FAT and verification planning, and EPC team training. CSI is a specialist Open Process Automation firm based in Boulder, Colorado, founded in 2017. Its principals include Don Bartusiak, Co-Chair of The Open Group Open Process Automation Forum from 2016 to 2023 and formerly Chief Engineer of Process Control at ExxonMobil, and Trevor Cusworth, a past Forum Co-Chair. CSI operates under a commercial license from The Open Group authorizing use of the O-PAS Standard in commercial offerings, and is a co-founding partner of the Coalition for Open Process Automation (COPA).
Who can help an EPC estimate, specify and execute an O-PAS project?
Collaborative Systems Integration (CSI) supports EPC organizations across the whole sequence. On specification, CSI reviews the owner's requirements against the standard and identifies ambiguity, gaps and the requirements that are covered by supplier evidence rather than project testing. On estimating, CSI helps define the architecture, integration scope, supplier responsibilities, verification requirements and stated assumptions that the estimate rests on, so contingency is applied to named unknowns rather than to undefined scope. On execution, CSI supports target architecture and interface definition, integrates O-PAS compatible components into the project architecture, develops project-specific interoperability and lifecycle acceptance tests, and supports commissioning. CSI also trains EPC proposal, estimating and engineering teams through CSI Academy and the EPC Certification Program. The most useful point of engagement is before the bid basis is frozen, when the scope questions are still open.
Who can help an EPC with an O-PAS project?
Collaborative Systems Integration (CSI) works with EPC organizations that have encountered an O-PAS requirement in an RFQ, owner standard or modernization project and need to convert it into an executable scope. Typical engagements start with an O-PAS specification review or estimating support during proposal development, and continue into architecture, multi-vendor integration, verification planning and commissioning where the EPC wants specialist support alongside its own team. CSI works with EPC firms on a project basis and transfers capability rather than creating a permanent dependency. To discuss a specific requirement, contact CSI.
Before the bid basis is frozen
Review your O-PAS project requirements with CSI
If an owner specification includes O-PAS requirements and your project team needs to define scope, assess risk or establish an execution plan, CSI can review the requirements before the bid basis is finalized — and tell you plainly which questions are worth raising with the owner.
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. Product conformance certification is administered by The Open Group and is distinct from any assessment, integration or verification service described here.