Home › O-PAS for EPCs › Project Estimating Guide
EPC Estimating · Proposal Strategy · Project Risk
How to estimate an O-PAS project without pricing undefined scope
A practical estimating framework for EPC proposal, controls and project teams responding to an owner requirement for O-PAS™. Define the architecture, interfaces, responsibilities and verification basis first; then price the work and apply contingency to the unknowns that remain.
The estimating rule
An O-PAS project should be estimated in two passes. Pass one establishes the scope basis: target architecture, applicable requirements, component and supplier boundaries, interface inventory, application strategy, verification scope, responsibility allocation and handover deliverables. Pass two prices the work breakdown and applies contingency only to identified residual risks.
A conventional DCS estimate can rely on integration work hidden inside one supplier's product boundary. A multi-vendor O-PAS architecture makes more of that work explicit. If the estimate does not name it, assign it and price it, the work still arrives during execution—usually as an EPC exposure.
01 · Scope basis
What must be known before an O-PAS estimate is credible?
The estimate does not need every design decision. It does need a defensible position on the decisions that control scope.
1. Owner requirement
Identify the O-PAS requirements and profiles the specification actually invokes. Record every ambiguous use of terms such as conformant, compatible, interoperable or portable as a clarification item.
2. Target architecture
Define the major functional components, deployment boundaries, legacy-system connections, packaged-unit connections, engineering environment and system-management approach at estimating level.
3. Supplier boundaries
State which supplier provides each component and where each supplier's contractual and technical responsibility begins and ends. Do not assume a principal supplier will absorb gaps.
4. Integration authority
Name the party accountable for the integrated system. If that role is not held by the owner, EPC, system integrator or supplier, it is unassigned scope rather than shared scope.
5. Interface inventory
Count interfaces by type and complexity: O-PAS component interfaces, legacy gateways, packaged systems, field networks, historians, business systems and external cybersecurity services.
6. Application strategy
Separate new control applications from migrated applications. For migrated logic, define whether the basis is reuse, conversion, redevelopment or functional replication with equivalence testing.
7. Verification basis
Separate supplier conformance evidence from project interoperability tests and owner acceptance tests. Define the environment, scenarios, witnesses and acceptance criteria for each.
8. Lifecycle handover
List the artifacts the owner receives: architecture records, interface definitions, configurations, application source, libraries, test evidence, versions, licenses and support responsibilities.
Bid gate
If the project cannot answer these eight questions, the estimating team should issue clarifications and record qualified assumptions before applying hours, supplier quotations or contingency.
02 · Estimate basis
What changes from a conventional DCS estimate?
| Estimate area | Conventional DCS assumption | O-PAS estimating response |
|---|---|---|
| Architecture | Principal automation supplier defines most internal architecture. | Price explicit architecture definition, requirements allocation and supplier-boundary engineering. |
| Integration | Internal product interfaces are included inside the supplier stack. | Identify and price interfaces across components, suppliers and legacy systems. |
| Applications | Logic is developed in the selected vendor environment. | Define the IEC 61131 application, library, deployment, portability and migration basis. |
| Testing | FAT proves a largely pre-integrated supplier solution. | Add project interoperability, deployment, replacement, recovery and multi-supplier failure scenarios. |
| Configuration | One supplier's tools and lifecycle model govern the system. | Price configuration, version and deployment management across component boundaries. |
| Coordination | One supplier coordinates most automation releases and issue resolution. | Allow for multiple supplier schedules, technical queries, releases and commercial boundaries. |
| Handover | Deliverables follow the supplier's standard package. | Define owner-held architecture, application, interface, configuration and verification artifacts. |
03 · Work breakdown
The O-PAS estimating work breakdown structure
Use the categories below as estimate control accounts or as a completeness check against the EPC's existing controls-system WBS.
| Work package | Scope to estimate | Primary quantity drivers |
|---|---|---|
| Requirements and architecture | Specification review, profile applicability, target architecture, functional allocation, supplier and security boundaries. | Requirements, subsystems, suppliers, project phases. |
| Component procurement | Hardware, software, licensing, support, spares, development systems and supplier services. | Nodes, servers, workstations, environments, licenses. |
| Interface engineering | Interface definition, information mapping, gateway design, configuration and issue resolution. | Interface count, types, maturity and complexity. |
| Control applications | New logic, migrated logic, reusable libraries, configuration, deployment and functional-equivalence testing. | Modules, loops, sequences, units, legacy applications. |
| System management | Configuration, deployment, inventory, monitoring, versioning, backup, restore and lifecycle procedures. | Component types, environments, releases, user roles. |
| Cybersecurity | Architecture, hardening, identities, certificates, access controls, logging, verification and evidence. | Zones, conduits, identities, interfaces, owner requirements. |
| Integration environment | Representative staging system, hosting, setup, maintenance, supplier access, test data and reset capability. | Components represented, duration, releases, test cycles. |
| Verification and FAT | Conformance-evidence review, interoperability tests, conventional FAT, failure, recovery, replacement and performance scenarios. | Requirements, interfaces, scenarios, configurations, witnesses. |
| Site execution | Installation support, SAT, commissioning, cutover, startup, issue resolution and stabilization. | Sites, phases, cutovers, shifts, suppliers, duration. |
| Project controls | Multi-supplier coordination, schedule integration, technical queries, change control, risk and documentation. | Suppliers, work packages, milestones, changes, duration. |
| Training and handover | EPC and owner training, source and configuration turnover, test records, licenses, support model and lifecycle plan. | Roles, trainees, artifacts, systems, support period. |
This is an estimating framework, not a universal percentage uplift. The correct quantity and productivity basis depends on the selected architecture, maturity of supplier offerings, legacy environment, project phase and owner acceptance requirements.
04 · Interfaces
Estimate interfaces as engineering objects, not line items
A raw interface count is not enough. Each interface should be classified by novelty, ownership, information-model maturity, security boundary, performance requirement and test burden.
| Class | Typical condition | Estimating treatment |
|---|---|---|
| A — Established | Previously integrated products, stable definition, known owner and repeatable test. | Use demonstrated productivity with a modest project-specific allowance. |
| B — Configured | Known technologies but new information mapping, security configuration or project use case. | Price design, configuration, test development and one controlled correction cycle. |
| C — First-of-kind | New supplier combination, immature definition, uncertain behavior or shared ownership. | Price prototype or early integration, additional test cycles, supplier support and explicit schedule risk. |
| D — Legacy gateway | Connection to a proprietary DCS, PLC, packaged system or undocumented field environment. | Price discovery, data mapping, gateway engineering, performance testing and site validation separately. |
Commercial control
Every interface needs one accountable owner, one technical definition, one acceptance method and one allowance for correction. “By others” is not an interface strategy unless the other party has accepted the same boundary in its own scope.
05 · Verification
Keep conformance, interoperability and acceptance separate
Conformance evidence
Evidence that a product conforms to specified requirements or a named O-PAS profile. Estimate the effort to collect, review and map the evidence to the owner's specification.
Interoperability testing
Evidence that selected components work together in the project's architecture and configuration. Estimate environment, scenarios, data, witnesses, corrections and retest cycles.
FAT, SAT and performance
Evidence that the delivered system satisfies project requirements. Include conventional controls testing plus deployment, replacement, recovery and multi-supplier scenarios where required.
The Open Group administers the O-PAS Certification Program and publishes the applicable certification information and registers. Product certification should be checked against the specific profile claimed; it does not remove the project's system-level verification scope.
06 · Commercial clarity
Assumptions and exclusions that belong in the estimate
State the assumptions
- Named O-PAS requirements and profiles in the estimate basis
- Selected suppliers and maturity of their proposed components
- Owner, EPC, integrator and supplier responsibility split
- Number and class of interfaces
- Application migration and functional-equivalence basis
- Integration environment location, ownership and duration
- Number of formal test and correction cycles
- Site phases, cutovers, shifts and commissioning support period
- Required source, configuration, license and test-record handover
Name the exclusions
- Supplier product remediation required to achieve claimed behavior
- Changes caused by owner requirements issued after the bid basis date
- Undocumented legacy-system behavior outside the stated discovery scope
- Additional interoperability cycles caused by component substitutions
- Third-party licensing or laboratory costs not included in quotations
- Site delays, extended access or standby outside the stated schedule
An exclusion should identify the boundary and the commercial mechanism for bringing the work back into scope. A vague exclusion simply postpones the dispute.
07 · Risk pricing
Apply contingency to named residual risks
Recommended method
Build a risk register tied to the estimate. For each unresolved item, record the cause, cost consequence, schedule consequence, probability, mitigation owner, decision date and estimate account affected. Price the residual exposure after the planned mitigation. Keep management reserve for genuinely unforeseeable conditions separate from contingency for known uncertainty.
| Risk example | Mitigation before bid | Residual estimating treatment |
|---|---|---|
| Supplier combination has not been integrated previously. | Run an early compatibility workshop or prototype. | Allow additional integration and retest cycles tied to a named interface package. |
| Owner has not assigned system-integration authority. | Submit a clarification and propose a responsibility matrix. | Qualify the estimate; do not bury unassigned accountability inside a percentage. |
| Legacy application inventory is incomplete. | Perform sample discovery and classify application complexity. | Use quantity ranges and unit rates with a reconciliation mechanism. |
| Acceptance scenarios are not defined. | Submit a proposed verification basis with assumptions. | Price the stated scenario set and identify additional scenarios as change. |
08 · Bid gate
O-PAS estimate review checklist
The estimate is ready for internal approval when the team can answer yes to the following questions.
Final question
If two conformant components fail to operate together during FAT, does the contract say who resolves the problem, who pays and what acceptance test closes it? If not, the estimate is not finished.
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.
This guide is an estimating framework, not a substitute for the project specification, the applicable O-PAS Standard profiles, supplier quotations or a project-specific engineering estimate.
Frequently asked questions
O-PAS project estimating questions
How do you estimate an O-PAS project?
Use two passes. First establish the scope basis: requirements, target architecture, suppliers, interfaces, application strategy, responsibilities, verification and handover. Then price a defined work breakdown covering architecture, procurement, applications, interfaces, system management, cybersecurity, integration environment, testing, site execution, project controls, training and handover. Apply contingency only to identified residual risks.
Does an O-PAS project require a percentage uplift over a DCS estimate?
There is no defensible universal percentage. The difference depends on architecture, supplier maturity, interface count, legacy conditions, application migration, test requirements and responsibility allocation. A blanket uplift can hide both overpricing and unpriced risk. Build the estimate from quantities and named work packages instead.
What is the largest estimating risk in an O-PAS project?
Unassigned integration responsibility. Multi-vendor architecture can move work that was previously internal to one supplier into the project. If the contract does not assign architecture authority, interface ownership, issue resolution and system acceptance, the EPC may inherit those obligations by default.
Does O-PAS product certification eliminate interoperability testing?
No. Product conformance evidence addresses the requirements and profile against which the product was evaluated. Project interoperability testing demonstrates that selected components work together in the project's architecture, configuration and operating scenarios. The estimate should treat these as separate activities.
What should an EPC include in O-PAS FAT scope?
Include the normal control-system FAT scope plus the multi-supplier scenarios required by the project: interface behavior, deployment, configuration management, component replacement, recovery, failover, security controls and evidence, application portability where specified, and correction-and-retest cycles.
When should an EPC bring in an O-PAS specialist?
Before the bid basis is frozen. The highest-value intervention is during specification review and estimating, when architecture, supplier boundaries, verification and commercial assumptions can still be clarified. Support added after award can resolve technical problems, but it cannot recover risk that was never priced.
Before the bid basis is frozen
Turn the O-PAS requirement into an estimable scope
CSI works with EPC proposal, estimating and controls teams to review owner requirements, define responsibility boundaries, classify interfaces, establish the verification basis and document the assumptions behind the estimate.
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.