Name the lifecycle, sourcing, portability, obsolescence, cybersecurity or innovation outcome the architecture must deliver. Otherwise compliance becomes the objective.
Home › O-PAS Procurement Specification Checklist
RFQ · Bid Basis · Acceptance · Handover
O-PAS procurement specification checklist Define the work before suppliers price it
A practical checklist for owner-operators and EPC teams preparing an RFQ, reviewing a specification or qualifying a bid for an O-PAS™-based automation system.
The short answer
An O-PAS procurement specification must define more than a requirement to comply with O-PAS. It must state the target architecture, applicable standard edition and profiles, product and supplier boundaries, system-integration responsibility, application requirements, evidence, project testing, handover and lifecycle obligations.
If those items are left implicit, bidders will make different assumptions. The lowest number may simply contain the least work. The missing work returns during execution as change, contingency consumption, interface disputes or acceptance delay.
01 · Owner decisions
Three decisions must exist before the specification
The procurement document cannot repair an undefined owner strategy. Set these positions first so the RFQ has a stable basis.
Define the process scope, retained systems, packaged equipment, field interfaces, enterprise connections and functions included in the project.
Name the authority that approves requirements, component substitutions, interfaces, exceptions and acceptance evidence throughout execution.
Do not start with products
Selecting products before defining architecture and responsibility allows the available product stack to become the specification. Use the O-PAS Vendor and Product Landscape only after the required architecture roles and evidence have been defined.
02 · Working checklist
Ten sections every O-PAS RFQ should address
For each section, the specification should state the requirement, require evidence in a comparable format and expose the ambiguity that would otherwise become project risk.
01
Business objectives and system scope
Define what the project must change and where the supplied system begins and ends.
Specify
- Project drivers and required lifecycle outcomes
- Process units, I/O, applications and retained systems
- Brownfield interfaces, cutover and coexistence limits
- Required availability and operational constraints
Require from bidder
- Scope statement and boundary diagram
- Inclusions, exclusions and assumptions
- List of owner dependencies
- Proposed deviations from the stated boundary
Stop condition
The bidder cannot identify which functions, interfaces or lifecycle outcomes are included in its price.
02
Target architecture and design authority
State the architecture the project must preserve and who can approve changes to it.
Specify
- Required architecture layers and functions
- Control, I/O, compute, HMI and management roles
- Interface and segregation principles
- Named owner architecture authority
Require from bidder
- Proposed architecture and bill of materials
- Mapping from products to architecture roles
- Proprietary elements and dependencies
- Architecture assumptions and exceptions
Stop condition
The architecture is represented only as a supplier product list, with no explicit functions, boundaries or approval authority.
03
Applicable O-PAS edition, profiles and requirements
Replace general compliance language with a requirement set that can be traced and tested.
Specify
- Applicable O-PAS Standard edition
- Profiles invoked for each component role
- Owner requirements beyond O-PAS
- Rules for later profile or edition changes
Require from bidder
- Requirements-compliance matrix
- Product-to-profile mapping
- Evidence reference for every claimed requirement
- Exceptions, gaps and proposed project tests
Stop condition
The response says only “O-PAS compliant” or “O-PAS ready” without naming the edition, profiles, products and evidence.
04
Products, versions and supplier boundaries
Make the proposed baseline and every supplier interface visible before award.
Specify
- Required component classes and environmental ratings
- Rules for substitutions and version changes
- Required vendor support and lifecycle status
- Boundary-document format
Require from bidder
- Exact manufacturers, products and versions
- Interface owner at every supplier boundary
- Dependencies, licences and support terms
- Qualification evidence for substitutions
Stop condition
Major components remain “vendor to be confirmed,” or the price assumes substitutions without an evidence and retest process.
05
System integration and interface accountability
Name the party responsible for the assembled system, including failures between conformant products.
Specify
- Single-point system-integration responsibility
- Interface definition and approval process
- Technical query and dispute process
- Responsibility for correction, retest and delay
Require from bidder
- Named integrator and project team
- Responsibility and interface matrices
- Relevant multi-vendor project references
- Integration environment and issue workflow
Stop condition
Each supplier warrants its own product, but no party accepts responsibility for the integrated system.
06
Control applications and engineering assets
Protect the logic, libraries and deployment assets that carry the owner’s operating knowledge.
Specify
- Application language and runtime requirements
- IEC 61131 strategy and approved libraries
- Source, configuration and documentation ownership
- Portability, deployment and rollback expectations
Require from bidder
- Engineering and deployment workflow
- All runtime, library and tool dependencies
- Application test and migration method
- Complete source and build package at handover
Stop condition
The owner receives a working runtime but cannot rebuild, test, deploy or move the applications without one supplier.
07
Connectivity, information and system management
Define the interfaces and day-two management functions that make the components one operable system.
Specify
- Required information and communication interfaces
- Identity, discovery, naming and time requirements
- Provisioning, monitoring and inventory functions
- Backup, restore, patching and update rules
Require from bidder
- Interface and data-model records
- System-management architecture
- Certificate, identity and access approach
- Operational maintenance workflows
Stop condition
Each component can be configured independently, but no integrated method exists to operate, monitor, update and recover the whole system.
08
Cybersecurity and lifecycle governance
Allocate security work across the owner, integrator and suppliers for the full operating life. Use the O-PAS Cybersecurity Requirements Guide →
Specify
- Applicable owner and industry security requirements
- Zones, conduits, identity and access controls
- Vulnerability, patch and incident responsibilities
- Support periods and obsolescence notification
Require from bidder
- Security architecture and responsibility matrix
- Product security certificates and limitations
- Hardening, patching and recovery procedures
- Lifecycle support and escalation model
Stop condition
The design cites product security features but leaves cross-supplier vulnerability response, patch qualification and incident ownership undefined.
09
Conformance, interoperability and acceptance testing
Separate product evidence from proof that the delivered system works in the project configuration.
Specify
- Required product certification and profile evidence
- Integration, FAT, SAT and performance scope
- Failure, recovery, replacement and cybersecurity tests
- Acceptance authority and defect rules
Require from bidder
- Evidence register tied to exact products
- Integrated test strategy and environment
- Procedures, expected results and traceability
- Correction and regression-test allowance
Stop condition
Product certificates are offered as a substitute for project interoperability, functional, resilience and lifecycle acceptance testing.
10
Handover, training and support
Define what the owner must receive to operate and change the system without recreating the project.
Specify
- Required as-built architecture and interface records
- Source, configuration, certificates and test records
- Training and competency requirements
- Warranty, support, spares and escalation model
Require from bidder
- Deliverables register with dates and formats
- Operational and recovery procedures
- Training plan and acceptance criteria
- Post-handover support responsibility map
Stop condition
The owner can operate the plant on day one but lacks the records, access, tools or competence needed to support and modify it on day two.
03 · Comparable bids
Require one position for every line of scope
Every bidder should mark each requirement using the same three positions and attach the supporting assumption or evidence.
Priced and committed
The bidder identifies the responsible party, deliverable, evidence and acceptance basis included in the offered price and schedule.
Outside the offer
The bidder states the excluded work and the party assumed to perform it. The owner decides whether that boundary is acceptable.
Conditional or unresolved
The bidder states the assumption, information needed, commercial effect and deadline for closing the qualification.
The comparison rule
A blank cell is not an exclusion. It is an unresolved commercial position. Do not compare headline prices until every bidder has taken an explicit position on architecture, integration, testing, handover and support.
04 · Evidence hierarchy
Procure evidence at four separate levels
Each layer answers a different question. None can be assumed to close the layer below it.
| Evidence layer | Question answered | Required record |
|---|---|---|
| Supplier evidence | What does the supplier claim for the exact offered product and version? | Datasheet, declaration, supported profiles, dependencies, limitations and lifecycle status. |
| Product conformance | Which named requirements or profiles have been verified through a recognised process? | Current register entry, certificate, product identity, version, edition, profile and exceptions. |
| System interoperability | Do the selected products operate together in the proposed architecture? | Project-specific procedures and results for interfaces, loading, failure, recovery and replacement. |
| Project acceptance | Does the delivered system satisfy the owner’s complete contractual requirements? | Requirements traceability, FAT and SAT records, deviations, defects, closeout and acceptance approval. |
Use the O-PAS Certification Tracker for current product records and the FAT and Interoperability Testing Guide to define project verification.
05 · Responsibility
Name an accountable party for every activity
The procurement package should assign responsibility at activity level rather than relying on broad role descriptions.
| Activity | Position required before award |
|---|---|
| Architecture authority | Who approves the target architecture, exceptions and substitutions? |
| Requirements interpretation | Who decides how O-PAS profiles and owner requirements apply to each component? |
| System integration | Who carries single-point accountability for the operating multi-vendor system? |
| Interface ownership | Who defines, implements, verifies and corrects each supplier boundary? |
| Application ownership | Who creates, verifies, controls and hands over source, libraries and deployment packages? |
| Verification | Who develops procedures, provides the environment, witnesses tests and accepts results? |
| Correction and retest | Who pays when two products do not work together or a requirement is not met? |
| Lifecycle support | Who coordinates vendors, patches, replacements, incidents and future changes after handover? |
Use the detailed O-PAS Responsibility Matrix to allocate owner, EPC, integrator and component-supplier roles.
06 · Bid-review gate
Do not freeze the bid basis until these answers exist
Architecture
The proposed system is visible
Products map to defined roles, interfaces are counted, retained systems are shown, and proprietary dependencies are disclosed.
Scope
The work is allocated
Architecture, integration, applications, testing, cybersecurity, handover and support each have a named responsible party.
Evidence
Every claim can be checked
Products, versions, profiles, certificates, exceptions and project tests are tied to a traceable evidence register.
Commercial
Unknowns are named
Inclusions, exclusions, qualifications, owner dependencies and contingency drivers are explicit and comparable across bids.
Acceptance
Completion has a definition
Tests, expected results, witness points, defect rules and acceptance authority are defined before execution begins.
Lifecycle
Day two is designed
The owner receives the access, assets, records, skills and support model needed to operate and change the system.
If one answer is missing, price the work to close it
Do not hide an undefined responsibility inside general contingency. Name the decision, assign the person who must close it, state the date required and show the cost or schedule consequence if it remains open.
07 · FAQ
O-PAS procurement questions
Is an O-PAS compliance clause enough for an RFQ?
No. A general clause does not identify the applicable edition and profiles, target architecture, products, supplier boundaries, integration responsibility, required evidence, project testing or acceptance criteria. Those items must be defined or explicitly assigned for the bidder to develop.
When should products be selected?
After the owner has defined the business objective, system boundary, architecture principles, required roles, evidence and acceptance model. Product evaluation can then test candidates against those needs rather than allowing the available product stack to define the architecture.
Who should own multi-vendor integration?
One named party should hold accountability for the integrated system. That may be a specialist OPA system integrator, an EPC with demonstrated capability or another delivery entity, but the role must include interface resolution, correction, retest and acceptance support.
Does product certification replace FAT?
No. Certification provides evidence for a product against a named scope. FAT verifies the selected products, applications and configuration as an assembled system under project-specific operating, failure, recovery and lifecycle scenarios.
How should bids be compared?
Require every bidder to mark each requirement included, excluded or qualified and attach its assumptions and evidence. Normalise the bids for omitted integration, testing, handover and lifecycle work before comparing price.
When should CSI review an O-PAS specification?
The highest-value point is before the RFQ is issued or while bidder questions can still change the scope basis. CSI can also review an issued specification, identify commercial ambiguity and help prepare clarifications before the bid is frozen.
Specification review
Turn the checklist into an executable procurement package
CSI helps owner-operators and EPC teams define the architecture, requirements, supplier responsibilities, evidence, testing and handover obligations before those decisions become project change.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This checklist is a procurement-planning aid; the applicable contract, owner standards, project requirements and current certification records govern the delivered system.