Home › O-PAS for EPCs › FAT and Interoperability Testing
Interoperability · Multi-Supplier FAT · Acceptance Evidence
O-PAS FAT and interoperability testing for EPC teams
A practical framework for proving that selected components work together in the project's architecture, that the delivered system satisfies its requirements, and that the evidence survives handover.
The direct answer
O-PAS product conformance, project interoperability and system acceptance are three different bodies of evidence. Conformance addresses a product against specified requirements or a named profile. Interoperability testing demonstrates that selected components work together in the project's architecture and configuration. FAT and SAT demonstrate that the delivered system satisfies the owner's contractual requirements.
An EPC test strategy should connect all three without treating any one as a substitute for another. The project still needs a representative environment, explicit boundary scenarios, accountable issue resolution, correction-and-retest cycles, and acceptance records.
01 · Verification model
Keep conformance, interoperability and acceptance separate
Product
Conformance evidence
Evidence that a specific product and version meet specified requirements or a named O-PAS profile. The project reviews the evidence and maps its coverage to the owner specification.
System
Interoperability evidence
Evidence that the selected components exchange information and behave together as required in the project's architecture, versions, configuration and operating scenarios.
Project
Acceptance evidence
Evidence that the delivered system meets contractual functional, performance, cybersecurity, recovery, lifecycle and documentation requirements at FAT, SAT and handover.
The key distinction
A product can satisfy its conformance obligations while the project still has unresolved system integration or acceptance work. The project test plan must show which requirement is closed by supplier evidence and which requires project testing.
02 · Test environment
Build a representative integration environment before FAT
The highest-value testing happens before site work begins. The environment does not need to reproduce the entire plant, but it must represent the component boundaries, versions, configurations, applications and loads needed to exercise the project's acceptance scenarios.
| Environment decision | What the test strategy must define |
|---|---|
| Components represented | Which production component types, software versions, interfaces, engineering tools and security services are present or simulated. |
| Configuration baseline | The approved versions, settings, certificates, identities, information models and applications that make each result reproducible. |
| Representative loading | Data volume, update rates, application execution, concurrent users and failure conditions needed to test specified behavior. |
| Supplier access | Who can access the environment, under what controls, during which windows and with what obligation to support correction. |
| Reset and recovery | How the environment returns to a known baseline between tests, corrections and supplier releases. |
| Ownership and duration | Who hosts, controls and funds the environment, and how long it remains available through FAT, commissioning and stabilization. |
| Evidence capture | How procedures, logs, screenshots, configuration records, anomalies, approvals and retest results are retained. |
If a production component cannot be represented, document the substitute, the behavior it cannot prove and the site test that will close the remaining requirement.
03 · FAT scope
Extend conventional FAT to the component boundaries
| Verification area | What the project should demonstrate | Evidence to retain |
|---|---|---|
| Conventional control functions | Loops, sequences, interlocks, alarms, operator displays and control behavior meet approved functional requirements. | Executed procedures, results, exceptions and approvals. |
| Multi-supplier communications | Components exchange specified data with the required semantics, quality, timing and behavior under representative load. | Interface version, configuration, test data, logs and results. |
| Application deployment | Applications can be installed, updated and rolled back through the approved workflow with a repeatable outcome. | Source/version identifiers, deployment record and rollback result. |
| Configuration management | The integrated baseline can be identified, backed up, restored and reconciled across component boundaries. | Baseline manifest, backup, restore test and variance record. |
| Component replacement | A defined component can be replaced and returned to the approved configuration and service state. | Replacement procedure, elapsed time, configuration and regression result. |
| Failure and recovery | Communication loss, component restart, failover and restoration produce the specified system response. | Event sequence, alarms, logs, timing and recovery confirmation. |
| System management | Inventory, monitoring, diagnostics, versions and deployment status are visible and manageable as required across the system. | Inventory export, alarms, audit records and version evidence. |
| Cybersecurity | Identity, access, certificates, communications, logging, hardening and recovery controls satisfy the project requirements. | Configuration records, test results, logs and approved exceptions. |
| Application portability | Where specified, the defined application artifact can be moved or redeployed under the project's stated portability conditions. | Artifact, environment definition, procedure, results and deviations. |
| Performance | The integrated system meets specified capacity, latency, execution, availability or recovery criteria under defined conditions. | Test conditions, measured values, time series and acceptance record. |
04 · Boundary scenarios
Test what happens at the edges, not only the happy path
Loss and restoration
Disconnect, timeout, restart and reconnect. Verify data quality, alarms, state reconciliation and recovery without hidden manual repair.
Invalid and stale data
Exercise out-of-range values, bad quality, stale timestamps, missing attributes and unexpected state transitions.
Version mismatch
Confirm detection, containment and recovery when component, interface, certificate or application versions do not match the approved baseline.
Component substitution
Where replacement is a project requirement, demonstrate the documented workflow and the regression scope needed to restore acceptance.
Security boundary
Verify authentication failure, expired credentials, revoked access, logging and the system response to denied communications.
Partial recovery
Test behavior when one component returns before another, configuration is incomplete or data resumes out of sequence.
Why boundary tests matter
A successful point-to-point data exchange proves the nominal path. It does not prove that the integrated system fails safely, recovers predictably or preserves configuration and application state.
05 · Acceptance criteria
Write criteria that produce a decision
A test step should state the initial condition, action, expected behavior, measurable limit, evidence source and disposition rule. “Verify interoperability” is an objective, not an executable test.
| Criterion element | Question it must answer |
|---|---|
| Requirement reference | Which owner, project or applicable O-PAS requirement is being verified? |
| Configuration | Which products, versions, settings, applications and interfaces are under test? |
| Precondition | What state must exist before execution begins? |
| Action | What event, command, load or failure is introduced? |
| Expected result | What observable system behavior must occur? |
| Measured limit | What timing, accuracy, capacity or recovery threshold determines pass or fail? |
| Evidence | Which logs, records, measurements or approved observations prove the result? |
| Disposition | Who accepts the result, and what happens if it fails? |
06 · Issue resolution
Plan the correction-and-retest cycle before testing begins
1. Record
Capture the failed step, baseline, observable behavior, evidence and immediate operational effect.
2. Assign
Name one issue owner and the suppliers or project parties required to diagnose the boundary.
3. Diagnose
Separate product defect, interface-definition gap, configuration error, application behavior and test-procedure error.
4. Control the change
Approve the correction, identify affected components and update the integrated configuration baseline.
5. Retest
Repeat the failed procedure and the defined regression set under the controlled baseline.
6. Close
Record the final evidence, approver, residual limitation and any lifecycle action carried into handover.
The estimate should include the planned number of formal test and correction cycles, supplier support obligations, decision times and the commercial treatment of additional cycles. See the O-PAS Project Estimating Guide.
07 · Evidence package
Make the test record usable after handover
| Artifact | Minimum content |
|---|---|
| Verification cross-reference | Requirement, verification method, procedure, result, evidence location and approval. |
| Integrated baseline manifest | Components, versions, configurations, applications, interfaces, certificates and approved deviations. |
| Executed procedures | Steps, actual results, measurements, witness signatures and exceptions. |
| Issue and retest record | Failure evidence, cause, owner, correction, affected baseline, regression scope and closure. |
| Supplier evidence register | Product, version, claimed profile or requirement, evidence reference, review status and project gaps. |
| Deferred site-test register | Requirement not closed at FAT, reason, site precondition, owner, procedure and acceptance authority. |
| Lifecycle regression set | Tests to repeat after upgrades, replacements, cybersecurity changes or application revisions. |
Use the O-PAS Responsibility Matrix to assign creation, review, approval, correction and future ownership of every verification artifact.
08 · FAT gate
O-PAS FAT readiness checklist
Final readiness question
Can the project reproduce the accepted configuration, explain every open exception and identify the regression tests required after the first component update? If not, FAT may prove today's demonstration without protecting tomorrow's system.
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 a project verification framework. The applicable contracts, owner requirements, O-PAS Standard profiles, supplier evidence and project-specific safety and cybersecurity requirements govern the actual test program.
Frequently asked questions
O-PAS FAT and interoperability questions
Does O-PAS product certification eliminate interoperability testing?
No. Product evidence addresses the product and requirements or profile against which it was evaluated. Interoperability testing demonstrates that the selected products work together in the project's architecture, versions, configuration and operating scenarios.
What should be added to a conventional FAT for an O-PAS project?
Add the multi-supplier and lifecycle scenarios required by the project: interface behavior, application deployment, configuration backup and recovery, component replacement, failure and restoration, system management, cybersecurity boundaries, specified portability and correction-and-retest cycles.
Who owns interoperability testing?
The contract should name one accountable party. In a common EPC-led model, the EPC retains accountability while a specialist system integrator develops and executes the integrated test program with component-supplier support and owner witnessing.
What makes an integration environment representative?
It includes or credibly simulates the component types, versions, interfaces, configurations, applications, security services and loads needed to execute the acceptance scenarios. Any missing production condition must be documented and closed through a later test.
How many correction-and-retest cycles should an estimate include?
There is no universal number. The estimate should state the planned cycles based on supplier maturity, interface novelty, prototype results and acceptance scope, then define how additional cycles are authorized and paid.
What evidence should be handed to the owner?
At minimum: the verification cross-reference, integrated baseline, executed procedures, issue and retest records, supplier evidence register, deferred site tests, approved exceptions and the lifecycle regression set.
Before FAT becomes the integration workshop
Define the environment, evidence and correction path early
CSI helps owners and EPC teams translate O-PAS requirements into executable interoperability, FAT and lifecycle verification plans.
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.