Home › O-PAS Architecture and Component Roles
Architecture · Component Roles · Interfaces · Project Evidence
A practical guide for owners and EPC teams defining where control, computing, connectivity, applications, system services and lifecycle responsibilities belong in an Open Process Automation system.
The short answer
O-PAS provides a reference architecture and requirements for an open, interoperable process automation system. It does not provide a finished plant architecture or prescribe one universal product arrangement.
The project must translate the reference architecture into a defined system boundary, allocate functions to component roles, select products and versions, define every supplier interface, place control applications and services, establish cybersecurity and lifecycle responsibilities, and specify the evidence required for acceptance.
The architectural value comes from preserving defined boundaries between functions, applications and products so that change can be controlled without allowing one supplier’s implementation to become the architecture by default.
01 · Architecture principles
An O-PAS project should preserve the owner’s required architectural properties through procurement, integration and operation.
Control execution, field connectivity, higher-level computing, engineering, information exchange, system management and operations functions should be visible in the architecture rather than hidden inside one supplier stack.
Every exchange needs an owner, information definition, direction, timing expectation, security treatment, failure response, version basis and verification method.
A product may implement one role or several roles. The architecture should show which functions are combined, why they are combined and what lifecycle dependency that choice creates.
Control applications, libraries, configuration, information models and test assets need defined ownership and deployment boundaries so they are not silently bound to one hardware or engineering environment.
Inventory, configuration, monitoring, diagnostics, identity, certificates, backup, recovery, patching, replacement and supplier coordination are architectural functions, not post-startup administration.
Product conformance, project interoperability, functional performance, resilience, cybersecurity and lifecycle demonstrations answer different questions and must be planned separately.
02 · Conceptual map
This is a functional view, not a prescribed physical topology. Actual projects may distribute, combine or replicate roles according to process, performance, resilience, security and lifecycle requirements.
The architecture rule
Do not confuse a functional role with a purchasing category. The project decides how roles are packaged into products and where boundaries are placed; that decision must remain traceable to owner objectives and acceptance requirements.
03 · Architecture roles and functions
Use the terminology of the applicable O-PAS Standard edition for formal component concepts. Control applications, system management and shared infrastructure also have to be allocated explicitly, but should not be treated as interchangeable labels for physical O-PAS components.
Distributed Control Node
A DCN is a distributed computing node allocated to defined control-system functions. Depending on the project and product, those functions can include control-application execution, I/O processing, communications, diagnostics or combinations of these capabilities.
Project decisions: hosted functions, execution characteristics, I/O boundary, redundancy, environmental requirements, lifecycle support and replacement method.
Advanced Compute Device
An Advanced Compute Device provides computing capacity for functions that require more resources or a different operating environment than the distributed control layer. The project determines which supervisory, optimization, information, engineering or shared-service workloads belong there.
Project decisions: workload placement, availability, virtualization or orchestration approach, performance, data boundaries, security zones and support model.
O-PAS Connectivity Framework
The O-PAS Connectivity Framework (OCF) defines connectivity requirements for information exchange among O-PAS components. It is a connectivity framework, not the control-application runtime. The project still defines the information, endpoints, behavior, loading and failure scenarios required at each interface.
Project decisions: information models, namespaces, ownership, timing, quality, subscriptions, security configuration and boundary tests.
Control applications
Control applications carry regulatory control, sequences, interlocks, calculations and other process behavior. IEC 61131 remains the primary practical programming model for most industrial control applications, while actual portability depends on libraries, extensions, runtime behavior, interfaces and deployment assets.
Project decisions: language, libraries, ownership, execution placement, dependencies, build and deployment workflow, rollback and portability proof.
System management
System-management capabilities support inventory, provisioning, configuration, version awareness, monitoring, diagnostics, updates, backup, recovery and controlled replacement across component and supplier boundaries.
Project decisions: authority, tools, access, records, workflows, failure handling, supplier coordination and lifecycle evidence.
Shared infrastructure and services
Identity, trust, certificate services, time, discovery, naming, logging, engineering repositories and other shared capabilities can affect many dependent components. Their architecture, ownership and recovery sequence must be explicit.
Project decisions: service location, resilience, dependencies, cybersecurity controls, monitoring, backup, restoration and change authority.
Terminology and applicable requirements are governed by the named O-PAS Standard edition. Use the O-PAS Profiles and Project Requirements Guide to map architecture roles to the required edition, profiles, product evidence and project-added requirements.
04 · Role-to-product allocation
Architecture roles are logical responsibilities. Procurement packages them into products, software and services. The allocation decision changes integration scope and lifecycle flexibility.
| Allocation choice | Potential value | Questions to resolve |
|---|---|---|
| One product, one principal role | Clear boundaries, ownership and replacement scope. | What supporting services or dependencies still cross the boundary? |
| One product, several roles | Fewer components and potentially simpler deployment. | Does combining roles recreate a lifecycle or supplier dependency the owner intended to avoid? |
| One role across several products | Scale, redundancy, distribution or supplier choice. | Who owns consistency, synchronization, failover, version alignment and correction? |
| Use the O-PAS Availability, Redundancy and Resilience Engineering Guide → | ||
| Shared platform for several workloads | Resource efficiency and flexible application placement. | How are resources, timing, security, failure containment and change impact controlled? |
| Supplier-packaged subsystem | A defined commercial boundary with integrated support. | Which internal interfaces remain proprietary, and what must be exposed for owner lifecycle control? |
| Retained legacy function | Lower migration risk and incremental adoption. | How are coexistence, data semantics, trust, operations, failure and retirement handled? Use the O-PAS Decommissioning, System Retirement and Evidence Preservation Guide → |
A component can satisfy applicable product requirements and still be a poor architectural fit. Selection must consider interfaces, application dependencies, engineering workflow, lifecycle support and the owner’s intended replacement boundary.
05 · Project boundaries
Process units, functions, I/O, packaged equipment, utilities and operating modes included in the system.
Field devices, remote I/O, drives, analyzers, safety-system boundaries and the treatment of quality, diagnostics and failure states.
Source, libraries, runtimes, mappings, system-service calls, configuration, test assets and deployment packages.
Who defines, supplies, configures, integrates, corrects, supports and warrants each component and interface.
Security zones, conduits, identities, certificates, privileged access, monitoring, remote support and incident ownership.
Versions, configuration authority, backup, restore, patch qualification, component substitution, obsolescence and regression testing.
Product evidence, project tests, expected results, witness points, defect rules, approved exceptions and final acceptance authority.
Retained DCS functions, gateways, temporary interfaces, cutover, rollback, operating ownership and retirement conditions.
06 · Architecture method
State the lifecycle, sourcing, application, modernization, availability, cybersecurity and operating objectives the architecture must preserve.
Identify process scope, retained systems, field interfaces, packaged equipment, enterprise connections, users and lifecycle functions.
Separate control, I/O, computing, applications, connectivity, engineering, operations, security and system-management functions.
Map functions to the applicable O-PAS component concepts and to project-defined application, system-management and shared-service responsibilities without selecting products prematurely.
Record endpoints, information, direction, timing, quality, security, ownership, failure response, configuration and verification method.
Assign the O-PAS edition, applicable profiles, owner requirements, product evidence and project tests to each role and boundary.
Evaluate exact versions against role requirements, dependencies, support, conformance evidence, integration responsibility and lifecycle fit.
Test interfaces, functions, loading, failure, recovery, deployment and lifecycle workflows; then hand over the accepted architecture and change-control basis.
07 · Interface register
| Interface field | Required content | Acceptance evidence |
|---|---|---|
| Identity | Unique interface ID, source role, destination role, supplier boundary and responsible owner. | Approved architecture and responsibility cross-reference. |
| Information | Data objects, semantics, units, quality, timestamps, state, commands, events and diagnostics. | Interface definition and representative data review. |
| Behavior | Update, timing, sequence, loading, persistence, startup, shutdown and degraded-state expectations. | Normal, load and transition test results. |
| Security | Identity, authentication, authorization, trust, certificates, permitted flows, logging and access ownership. | Configuration inspection and boundary tests. |
| Failure | Loss, stale data, invalid values, mismatch, partial recovery, alarms, fallback and safe operating response. | Failure-injection and recovery records. |
| Configuration | Versions, namespaces, mappings, parameters, dependencies, tools and approved baseline. | Baseline manifest, backup and restore result. |
| Change | Approval authority, substitution rules, regression scope, rollback and record updates. | Witnessed update or replacement workflow. |
Interface definitions should feed the O-PAS FAT and Interoperability Testing Guide. A line on an architecture drawing is not complete until its normal behavior, failure behavior, owner and proof method are known.
08 · Architecture deliverables
Owner objectives, governing requirements, assumptions, constraints, principles, decisions and approved deviations.
Component roles, deployed products, application placement, networks, zones, locations, redundancy and retained systems.
Endpoints, information, behavior, ownership, configuration, security, failure treatment and verification.
Programs, libraries, runtimes, dependencies, build assets, deployment targets, versions, source ownership and tests.
Product conformance evidence, project tests, results, defects, exceptions, approvals and residual obligations.
Architecture authority, configuration control, monitoring, backup, recovery, updates, replacement, suppliers and regression assets.
Carry these deliverables into procurement using the O-PAS Procurement Specification Checklist and allocate accountable parties with the O-PAS Responsibility Matrix.
09 · Architecture evidence
Requirements
Design basis, role allocation, interfaces, requirements, responsibilities and acceptance criteria.
Product
Exact product, version, capabilities, profile scope, dependencies, limitations and lifecycle evidence.
System
Integrated configuration, interface, loading, failure, cybersecurity, recovery and replacement test results.
Lifecycle
Handover assets, authority, competence, repositories, procedures, supplier model and retained regression evidence.
The acceptance rule
An architecture is not accepted because its diagram resembles the reference model. It is accepted when the selected products, applications, interfaces, responsibilities and lifecycle workflows demonstrably satisfy the project’s requirements.
10 · Related guidance
Map roles to the applicable edition, profiles, product evidence, project requirements and acceptance methods.
ApplicationsDefine languages, libraries, runtimes, dependencies, handover assets and the portability proof test.
OperationsTurn the distributed architecture into a supportable operating system after project handover.
11 · Reference basis
The applicable edition of The Open Group O-PAS Standard governs the formal architecture terms and requirements. This guide explains how an owner or EPC can turn that reference basis into project decisions; it is not a substitute for the Standard or an official interpretation.
Architecture teams should identify the exact Standard edition in the project basis and reassess terminology, profiles and requirements when that reference changes.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This guidance does not represent certification, endorsement or an official interpretation by The Open Group.
12 · FAQ
No. O-PAS provides a reference architecture, component roles and requirements. The project must develop the actual functional and physical architecture for its process scope, products, applications, interfaces, performance, security and lifecycle needs.
A Distributed Control Node is a distributed computing node allocated to defined control-system functions. Depending on the project and product, those functions can include control-application execution, I/O processing, communications, diagnostics or a combination of capabilities.
The roles support different workload and placement needs. DCNs are used for distributed control-system functions, while advanced computing provides capacity for workloads requiring a different scale or operating environment. The project must define which functions and applications belong on each and verify the required behavior.
No. The O-PAS Connectivity Framework addresses standards-based connectivity and information exchange among components. Control applications execute in an assigned runtime or execution environment, whose behavior, libraries, resources and lifecycle requirements must be separately specified.
Potentially. Architecture roles are logical responsibilities and may be packaged together. The owner should assess whether combining them changes supplier dependency, failure containment, cybersecurity, support, replacement scope or the intended lifecycle boundary.
No. Product certification supports conformance within a defined product and profile scope. The project must still demonstrate interoperability, functional behavior, loading, failure response, cybersecurity, recovery and lifecycle workflows in the integrated architecture.
At minimum: the architecture design basis, functional and physical views, role-to-product allocation, application placement, interface register, network and security views, requirements and verification matrix, accepted configuration baseline, responsibilities, operating procedures and lifecycle change model.
Before products define the architecture
CSI helps owner-operators and EPC teams define O-PAS architecture, allocate component and supplier roles, protect application assets, specify interfaces and create the evidence plan required for procurement and acceptance.