Home › O-PAS Profiles and Requirements
Edition · Profile Scope · Allocation · Evidence
How owners and EPC teams move from a general O-PAS objective to exact product requirements, supplier responsibilities, traceable evidence and project acceptance criteria.
The short answer
An O-PAS profile identifies a defined set of Standard requirements used to establish a product’s conformance scope. It does not define the owner’s complete automation requirement or certify the assembled project system.
A project specification must name the applicable O-PAS Standard edition, identify the profiles and requirements relevant to each architecture role, require evidence for the exact offered product and version, and add the functional, performance, cybersecurity, integration, migration, lifecycle and acceptance requirements the project needs.
The result should be a requirements-allocation and verification structure—not a general request for “O-PAS compliance.”
01 · Definitions
Standard edition
The named edition and applicable parts of the O-PAS Standard against which the project and product claims are interpreted. The contract should identify the exact edition rather than referring only to the “latest” Standard.
Profile
A defined grouping of requirements associated with product capabilities or an architecture role. A profile narrows what is being claimed and evaluated; it is not a general statement that a product implements everything in O-PAS.
Product certification
Certification applies to the product, version, edition, profiles and limitations identified by the certification program and register entry. It does not transfer automatically to another version or configuration.
Project requirement
An owner or project requirement covering process control, architecture, interfaces, performance, security, migration, testing, documentation, support and lifecycle operation. Some project requirements may be supported by product evidence; others require project engineering and tests.
Interoperability
Project-specific proof that selected products and versions exchange information and behave together as required in the proposed architecture, configuration, loading and failure scenarios.
Acceptance
The owner’s decision that the delivered system meets all applicable contractual requirements, including functions and conditions outside product conformance scope.
02 · Requirement stack
Build the requirement set in layers so bidders and reviewers can see which claims come from the Standard, which come from the owner, and how each will be closed.
Lifecycle independence, modular refresh, application ownership, modernization, competitive sourcing, cybersecurity, availability and other outcomes the architecture must enable.
Control loops, sequences, interlocks, alarms, operator functions, data handling, performance, reliability, process constraints and applicable safety boundaries.
System decomposition, component roles, control applications, interfaces, retained systems, computing boundaries, system management and supplier boundaries.
Named edition, applicable profiles, exact product evidence, certificate or register details, dependencies, exceptions and requirements not covered by certification.
Information semantics, configuration, loading, interface ownership, application deployment, cybersecurity implementation, failure behavior and supplier coordination.
Brownfield coexistence, legacy interfaces, cutover, rollback, field conditions, construction, commissioning, site infrastructure and operating constraints.
Inventory, updates, vulnerabilities, backup, recovery, replacement, obsolescence, support periods, engineering assets, training and change governance.
Evidence source, review method, FAT, SAT, performance tests, lifecycle demonstrations, witness points, exceptions, defect treatment and acceptance authority.
The O-PAS requirements supplement the owner’s complete automation specification. They do not replace process-control design criteria, applicable safety requirements, facility cybersecurity policy or the contractual definition of completion.
03 · Evidence layers
Supplier
What does the supplier state for the exact product, version, options, dependencies and lifecycle position?
Conformance
Which named edition, profiles and requirements are supported through the applicable certification or verification process?
System
Do the selected products work together in the project’s actual architecture, versions, configuration and scenarios?
Project
Does the complete delivered system satisfy the owner’s functional, performance, security, lifecycle and contractual requirements?
The evidence rule
Use product certification where it closes an allocated product requirement. Use project testing and other approved verification methods for integration and owner requirements outside that scope. Do not ask one evidence layer to answer a different question.
04 · Requirements method
Name the O-PAS Standard edition, applicable parts, certification documents, owner standards and other governing requirements. Define how later revisions will be handled.
Identify process scope, component roles, control applications, interfaces, retained systems, packaged equipment, enterprise connections and lifecycle functions. Use the O-PAS Architecture and Component Roles Guide →
Map profiles and specific requirements to each required product or architecture role. Do not require profiles solely because they exist; connect each to a project need.
Include functional, performance, environmental, cybersecurity, application, integration, migration, operational, support and lifecycle requirements not closed by the profile scope.
Name the owner, EPC, system integrator, component supplier or service supplier responsible for delivering, supporting and correcting each requirement.
For each requirement, identify acceptable product evidence, document review, inspection, analysis, demonstration, FAT, SAT or operational test—and the acceptance authority.
Record product, version, edition, profile, certificate or register reference, scope, exceptions, dependencies, lifecycle status and the project work still required.
Reassess substitutions, version changes, deviations and corrections against affected requirements, interfaces, tests and accepted baselines before approval.
05 · Specification language
| Weak wording | What is missing | Required procurement position |
|---|---|---|
| “The system shall comply with O-PAS.” | Edition, boundary, roles, profiles, evidence and acceptance scope. | Name the exact reference basis and allocate applicable requirements by product and project role. |
| “All products shall be O-PAS compatible.” | Meaning of compatible and proof for the offered version. | Require each bidder to classify claims as certified, independently verified, supplier-declared or planned, with evidence and limitations. |
| “Certified products shall interoperate.” | Project architecture, versions, configuration, loading and failure behavior. | Require relevant product evidence plus project-specific interoperability procedures and results. |
| “Applications shall be portable.” | Source, target, dependencies, permitted conversion and proof test. | Define the application package, environments, workflow, functional criteria and acceptance demonstration. |
| “Cybersecurity shall meet O-PAS.” | Facility risk basis, implemented architecture and lifecycle ownership. | Define owner and ISA/IEC 62443 requirements, product evidence, project controls, tests and operating responsibilities. |
| “Equivalent products may be substituted.” | Equivalence criteria and affected regression scope. | Require architecture-role, interface, profile, version, lifecycle and project-test evidence before substitution approval. |
Use the O-PAS Procurement Specification Checklist to carry this structure into the complete RFQ and bidder response schedule.
06 · Bid evidence
| Evidence field | What to record | Why it matters |
|---|---|---|
| Product identity | Manufacturer, product, model, software or firmware, version, options and proposed configuration. | Evidence for another version may not cover the offered baseline. |
| Claim type | Certified, independently verified, supplier-declared, compatible, roadmap or planned. | These positions carry different evidence strength and delivery risk. |
| Reference edition | Exact O-PAS Standard edition and applicable certification-program documents. | Requirement text and scope can change between editions. |
| Profile scope | Profiles and requirements included in the product claim or register entry. | Certification is bounded; it is not a claim against the complete Standard. |
| Certificate or register | Identifier, issuing program, date, status and public register reference where applicable. | Allows the buyer to verify the claim at the authoritative source. |
| Exceptions | Exclusions, optional functions, conditions, unresolved items and approved interpretations. | A certificate summary may not expose every project consequence. |
| Dependencies | Required hardware, operating environment, libraries, licences, services, tools and companion products. | Dependencies can move openness or lifecycle risk outside the certified scope. |
| Lifecycle position | Support term, update path, recertification position, end-of-life notice and replacement options. | The project must sustain the required evidence after versions change. |
| Project gap | Requirements needing integration, configuration, analysis, demonstration, FAT, SAT or operating evidence. | Makes remaining scope visible and priceable before award. |
Check dated product records in the CSI O-PAS Conformance Certification Tracker and map candidate products by architecture role using the O-PAS Vendor and Product Landscape. Verify final procurement claims against the authoritative certification register and supplier evidence.
07 · Bid normalization
The bidder identifies the product or service, evidence, responsible party, deliverable and verification method included in its offer.
The bidder states the assumption, limitation, owner dependency or alternative method and identifies cost, schedule and acceptance consequences.
The project identifies who must perform and fund the missing requirement, evidence, integration, correction or lifecycle obligation.
The bidder provides the planned product, profile, certification or release milestone and a contractual remedy if it is unavailable when required.
The alternative is evaluated against role, interfaces, profiles, dependencies, project requirements, support and regression impact.
A blank cell remains an unresolved commercial and technical position until the bidder takes an explicit position.
08 · Traceability
| Traceability field | Required content |
|---|---|
| Requirement identity | Unique identifier, source, edition, profile or owner document, text and rationale. |
| Applicability | System, subsystem, product, interface, application, service or lifecycle process to which it applies. |
| Allocation | Accountable party, performing party, supporting suppliers and acceptance authority. |
| Offered solution | Exact product, version, configuration, design document, service or procedure satisfying the requirement. |
| Evidence method | Certificate, register, supplier document, analysis, inspection, demonstration, FAT, SAT or operational test. |
| Evidence reference | Artifact identifier, revision, date, location, scope, result and reviewer. |
| Status | Open, submitted, accepted, failed, corrected, deferred, excepted or not applicable with approval. |
| Change history | Substitution, version change, deviation, affected interfaces, regression scope and approval. |
| Handover position | Accepted baseline, residual obligation, lifecycle owner and retained regression requirement. |
Connect the matrix to the O-PAS FAT and Interoperability Testing Guide so every requirement closes through the correct evidence layer and every failure returns to a named owner.
09 · Reference basis
Use the applicable editions of The Open Group O-PAS Standard, Certification Guide, Certification Policy and public Certification Register as the authoritative basis for certification terminology, profile scope and product status. Confirm the documents current for the procurement date rather than relying on an undated summary.
Project requirements still come from the owner’s business, process, risk, architecture and lifecycle needs. The Open Group certification program does not approve the owner’s design, select the project products or accept the integrated system.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI’s guidance does not represent certification, endorsement or an official interpretation by The Open Group.
Frequently asked questions
An O-PAS profile is a defined grouping of Standard requirements used to establish a bounded conformance scope for a product capability or architecture role. A profile does not mean that the product implements every requirement in the O-PAS Standard.
No. Certification supports the named product, version, edition and profile scope. The project still needs requirements and evidence for process functionality, performance, integration, cybersecurity implementation, migration, site conditions, lifecycle operation and complete system acceptance.
No. The project should identify profiles and requirements that correspond to its target architecture, component roles and owner objectives. Requiring unrelated profiles can restrict competition or add cost without improving the delivered system.
The bidder should state the precise claim—such as independently verified, supplier-declared, compatible, roadmap or planned—identify the requirements believed to be supported, provide evidence and limitations, and explain how the project will verify the remaining scope. It should not call the product certified.
No. Product certification addresses a defined product scope. Interoperability depends on the selected products, versions, interfaces, configuration, loading, security services and operating scenarios and should be demonstrated through project-specific testing.
The project should confirm whether the new version is covered by applicable certification evidence, evaluate changed dependencies and interfaces, update the baseline and execute the required regression tests before approval. Evidence for the prior version should not be assumed to transfer automatically.
The owner should retain requirements and acceptance authority. The EPC or system integrator typically maintains allocation, traceability and project verification, while product and service suppliers provide evidence and correction for their assigned scope.
Make every requirement checkable
CSI helps owner/operators and EPCs identify applicable O-PAS requirements, allocate supplier scope, evaluate product evidence, define project tests and maintain traceability through acceptance and handover.