Restore unavailable capability
A failed component cannot be repaired or returned to service within the required restoration window.
Home › O-PAS Component Replacement, Obsolescence and Technology Refresh
Replacement · Obsolescence · Qualification · Interoperability · Acceptance
O-PAS component replacement, obsolescence and technology refresh Replace a component without reopening the entire architecture
A practical guide for owners, EPCs and system integrators qualifying replacement products and technology refreshes in an operating O-PAS multi-vendor system.
The short answer
An O-PAS component replacement is a controlled system change, not a like-for-like purchasing exercise.
The owner must establish the accepted installed baseline, define the replacement requirements, verify applicable product conformance evidence, assess interfaces and dependencies, determine effects on IEC 61131 control applications and runtimes, test the replacement in a representative environment, complete project-specific interoperability and regression testing, authorize deployment and update the accepted lifecycle baseline. Product conformance supports that process; it does not by itself establish system interoperability or project acceptance.
01 · Replacement trigger
Start with the reason the installed baseline must change
A replacement decision should begin with a recorded lifecycle trigger and the operating consequence of leaving the current component in service. Obsolescence is one trigger; failure, cybersecurity exposure, support withdrawal, capacity limits and planned technology refresh can create the same engineering need.
Respond to obsolescence
The installed product, version, dependency or required engineering tool is approaching or has reached a support limitation.
Remove unacceptable exposure
A vulnerability, unsupported software dependency or security limitation requires a controlled replacement or upgrade.
Correct a system limitation
The installed component no longer meets required performance, capacity, reliability or diagnostic needs.
Execute planned refresh
The owner deliberately introduces a newer product or supplier option to sustain the architecture or reduce lifecycle dependency.
Address support change
Supplier withdrawal, unavailable spares, licensing changes or support conditions alter the viability of the installed position.
Replacement stop condition: do not select a substitute from catalog characteristics alone. First establish what the installed component does in the accepted system and what the replacement must preserve.
02 · Installed baseline
Define what is actually being replaced
The purchase description rarely captures the complete replacement boundary. Use the accepted lifecycle baseline to identify the installed product, its architecture role, configuration, interfaces, applications, system services and operating dependencies.
Exact installed position
- Product and supplier
- Hardware and software versions
- Applicable profiles and evidence
- Installed location and architecture role
- Approved deviations or exceptions
Controlled implementation
- Configuration and parameters
- Identity and certificate material
- System-management settings
- Backup and restore assets
- Required engineering tools
Connected system behavior
- Information exchanged
- Commands, states and quality
- Failure and restoration behavior
- Performance assumptions
- Provider and consumer dependencies
Execution dependencies
- IEC 61131 control applications
- Libraries and source assets
- Runtime allocation
- Build and deployment method
- Application test evidence
Use the O-PAS System Management and Lifecycle Operations Guide to maintain the inventory, dependency, configuration and recovery evidence needed before a replacement event occurs.
03 · Replacement equivalence
Equivalent means equivalent for the required system role
A candidate replacement does not need to reproduce every characteristic of the retired product. It must satisfy the requirements of the assigned architecture role and preserve or deliberately change the behaviors on which the project depends.
Role equivalence
- Required O-PAS role
- Applicable project functions
- Physical and environmental requirements
- Capacity and performance
- Failure and recovery expectations
Profile and function position
- Applicable O-PAS requirements
- Required profiles
- Optional capabilities used by the project
- Known exceptions
- Functions outside certified scope
Boundary equivalence
- Required information
- Commands and states
- Quality and diagnostics
- Security behavior
- Failure and restoration behavior
Execution equivalence
- Required IEC 61131 behavior
- Runtime capabilities
- Libraries and dependencies
- Resource assumptions
- Deployment and rollback
Lifecycle equivalence
- Inventory and diagnostics
- Configuration management
- Backup and recovery
- Update process
- Monitoring and support
Support equivalence
- Support period
- Replacement availability
- Engineering asset access
- Escalation obligations
- Lifecycle notification
Preserve the boundary definition
The interface register should provide the project-specific requirements against which a replacement is assessed. If those requirements have to be reconstructed from the retired product, the architecture is not yet ready for efficient substitution.
Use the Interface Definition and Boundary Management Guide →04 · Product conformance
Use conformance evidence for the question it actually answers
Product conformance evidence can establish that a specific product and version were evaluated against a defined O-PAS scope. The replacement decision still has to connect that evidence to the project requirements, installed architecture and intended operating use.
Verify exact evidence
- Product identity
- Hardware and software version
- Applicable O-PAS edition
- Profiles and evaluated scope
- Current certificate or register status
Identify what evidence does not prove
- Project configuration
- Interaction with selected products
- Control-application behavior
- Site performance
- Project-specific acceptance criteria
Map evidence to requirements
- Requirement satisfied by product evidence
- Requirement needing supplier evidence
- Requirement needing analysis
- Requirement needing integration test
- Requirement needing project acceptance
Keep three decisions separate: product conformance addresses the evaluated product scope; system interoperability addresses behavior among the assembled products and applications; project acceptance confirms that the changed system satisfies the owner’s contractual and operating requirements.
Use the O-PAS Profiles and Project Requirements Guide to define applicable requirements, and verify dated product evidence using the CSI O-PAS Conformance Certification Tracker and the authoritative certification source.
05 · Interfaces and boundaries
Qualify the replacement at every affected boundary
A component can satisfy its own requirements and still change system behavior at an interface. Replacement qualification should therefore follow each affected provider, consumer and shared-service relationship rather than stopping at the component boundary.
| Boundary | Replacement question | Evidence required |
|---|---|---|
| Information | Does the replacement provide and consume the required information, states, quality and diagnostics? | Interface definition, configuration review and observed exchange. |
| Commands | Are command handling, authorization, acknowledgement and failure responses preserved? | Functional scenarios including normal and abnormal behavior. |
| Performance | Do timing, capacity and resource behavior remain inside project requirements? | Measured representative-load results. |
| Failure | What happens when the replacement, its connection or a dependency becomes unavailable? | Failure, degradation, alarm and restoration tests. |
| Security | Does the replacement participate correctly in project identity, access, certificate, monitoring and update controls? | Security configuration and project verification. |
| Management | Can the replacement be inventoried, monitored, configured, backed up, restored and supported through the operating model? | Lifecycle workflow demonstrations. |
06 · IEC 61131 applications
Protect the control application from hidden replacement dependencies
For IEC 61131 control applications, the replacement assessment must identify whether the application can remain unchanged, requires a controlled rebuild or redeployment, or requires migration because a runtime, library, resource or deployment dependency has changed.
Application assets
- IEC 61131 source
- Libraries and versions
- Configuration and parameters
- Build assets
- Accepted test set
Execution dependencies
- Supported IEC 61131 features
- Runtime version
- Library compatibility
- Resource assumptions
- System-service dependencies
Loading and allocation
- Build method
- Deployment package
- Runtime allocation
- Startup behavior
- Backup and rollback method
Preserve required behavior
- Control functions
- Sequences and interlocks
- Alarms and operator interaction
- Failure response
- Recovery and restart
Application portability does not remove acceptance
A portable application still has to be deployed into a defined runtime environment and verified against the project’s required behavior. Portability reduces avoidable dependency; it does not eliminate engineering, integration or acceptance.
Use the O-PAS Application Portability Guide →07 · System dependencies
Follow the replacement beyond its visible interfaces
A replacement can affect shared services and lifecycle workflows even when its process function appears unchanged. Impact assessment should include every dependency required to operate, secure, diagnose, recover and support the component in the integrated system.
Trust and access
- Identities and accounts
- Certificates and trust relationships
- Roles and privileges
- Remote-support controls
- Audit requirements
System services
- Naming and time
- Monitoring and logging
- Inventory and diagnostics
- Configuration management
- Backup and recovery
Lifecycle security
- Supported software position
- Vulnerability handling
- Update mechanism
- Security monitoring
- Incident evidence
Operating support model
- Supplier coverage
- Diagnostic access
- Escalation path
- Spares and replacement
- Restoration procedure
Use the O-PAS Multi-Vendor Operations and Support Model Guide to confirm that the replacement can be supported and restored through the owner’s operating model.
08 · Qualification environment
Prove the replacement before it enters the operating baseline
Material replacements should be assembled and tested in a representative integration environment before production deployment. The environment must reproduce the affected products, versions, interfaces, applications and system services closely enough for the results to support the release decision.
Reproduce the affected baseline
Establish the relevant installed products, configurations, interfaces, IEC 61131 applications, runtimes, services and test assets.
Introduce the candidate replacement
Install and configure the exact proposed product and version using the intended engineering, identity, security and lifecycle methods.
Verify required interfaces
Exercise information, commands, states, quality, diagnostics, performance and normal operating interactions at affected boundaries.
Exercise failure and recovery
Test loss, degradation, restart, restoration, backup, rollback and abnormal behavior relevant to the replacement.
Run application regression
Confirm required IEC 61131 application behavior, operator interaction, alarms, sequences, interlocks and recovery where affected.
Resolve defects and repeat
Control corrections through the approved baseline, preserve evidence and repeat affected tests until the release criteria are satisfied.
Represent the affected system, not the entire plant
The qualification environment should be sufficient to reproduce the replacement’s material dependencies and consequences. Scope it from the impact assessment rather than rebuilding unrelated parts of the operating architecture.
Use the O-PAS Integration Environment and Testbed Planning Guide →09 · Interoperability and project acceptance
Turn qualification results into a controlled release decision
The project should define which evidence is required before the replacement can enter service. That evidence combines product information, engineering analysis, system interoperability results and project-specific verification; no single certificate or test substitutes for the complete acceptance basis.
| Evidence layer | Question answered | Typical evidence |
|---|---|---|
| Product conformance | Was the exact product and version evaluated against the applicable O-PAS scope? | Current certificate or authoritative register record, evaluated profiles, scope and exceptions. |
| Supplier evidence | Does the supplier support the intended configuration, dependencies and lifecycle position? | Compatibility statements, release information, limitations, support position and engineering documentation. |
| System interoperability | Does the replacement interact correctly with the selected products, applications, interfaces and shared services? | Representative integration tests, boundary scenarios, failure tests and regression results. |
| Project acceptance | Does the changed system satisfy the owner’s contractual, functional, operating, cybersecurity and lifecycle requirements? | Approved acceptance criteria, witnessed results, defect disposition, exceptions and release authorization. |
Use the O-PAS FAT and Interoperability Testing Guide to structure boundary scenarios, expected results, defect correction and the project evidence package.
10 · Deployment and rollback
Treat production introduction as a controlled change window
Successful qualification does not remove deployment risk. The operating change should have a defined entry state, authorized implementation method, rollback position, validation set and return-to-service authority.
Approve the release package
Confirm exact product and version, configuration, application assets, test evidence, open exceptions, supplier positions and implementation authorization.
Prepare recovery
Protect the accepted baseline, backups, configuration, source, credentials and restoration assets needed if deployment cannot be completed.
Control the operating window
Name execution authority, process conditions, supplier coverage, hold points, abort criteria and communications before work begins.
Install and configure
Execute the approved method and record the exact installed state, deviations and actions taken during the change.
Run the release regression set
Verify affected interfaces, IEC 61131 application behavior, system services, cybersecurity controls, failure response and recovery requirements.
Authorize return to service
Review results, defects and temporary conditions before the named owner authority accepts the changed system into operation.
Use the O-PAS Configuration Management, Change Control and Regression Testing Guide to control the release, rollback and regression process.
11 · Lifecycle evidence
Retire the old baseline and establish the new one
A replacement is not complete when the new component starts running. The lifecycle record must show what changed, why it was accepted and which assets now define the recoverable operating state.
Installed state
- New product and version
- Location and architecture role
- Configuration identity
- Applicable product evidence
- Support and lifecycle status
Controlled assets
- Configuration and parameters
- IEC 61131 source and libraries
- Build and deployment assets
- Interface definitions
- Backup and recovery package
Decision record
- Impact assessment
- Qualification results
- Regression evidence
- Defects and exceptions
- Release and acceptance approval
Do not leave the retired component in the documentation. Update inventories, drawings, interface records, recovery procedures, spares, support registers, application dependencies and training material so the next lifecycle decision starts from the actual operating system.
12 · Procurement and future refresh
Make the next replacement easier than the first
The ability to replace a component later depends on requirements written before the original purchase. Procurement should preserve the evidence, rights, interfaces and engineering assets needed to qualify future alternatives without reconstructing the project.
| Requirement area | What to define |
|---|---|
| Lifecycle notice | Required notice for support changes, obsolescence, product withdrawal, software dependencies and replacement recommendations. |
| Replacement basis | Architecture role, applicable profiles, project functions, interfaces, performance, failure behavior and lifecycle requirements that alternatives must satisfy. |
| Engineering assets | Owner access to configuration, source, IEC 61131 applications, libraries, deployment assets, diagnostics, backups and recovery procedures. |
| Supplier evidence | Version compatibility, dependencies, limitations, support periods, update path and product evidence required throughout the lifecycle. |
| Qualification | Representative-environment access, test assets, supplier participation, correction obligations and regression expectations. |
| Transition | Responsibilities for removal, data and configuration transfer, license transition, spares, documentation, training and retirement of the superseded component. Use the O-PAS Decommissioning, System Retirement and Evidence Preservation Guide → |
Use the O-PAS Procurement Specification Checklist to make replacement, lifecycle evidence and supplier obligations contractual before award.
13 · Connected guidance
Connect replacement qualification to the lifecycle authority set
Lifecycle
System Management and Lifecycle
Maintain the inventory, dependencies, recovery assets and operating evidence needed to qualify replacements.
ChangeConfiguration and Regression
Control impact assessment, release, regression, rollback and baseline reconciliation.
BoundariesInterface Definition
Define the project-specific behaviors a replacement must preserve at affected boundaries.
QualificationIntegration Environment Planning
Build a representative environment for replacement qualification before production deployment.
ApplicationsApplication Portability
Control IEC 61131 source, libraries, runtime dependencies, deployment and behavioral verification.
RequirementsProfiles and Project Requirements
Separate applicable O-PAS product requirements from integration and project acceptance requirements.
Frequently asked questions
O-PAS component replacement and technology refresh questions
Can an O-PAS component be replaced with a product from another supplier?
Potentially, when the replacement satisfies the project requirements for the assigned architecture role and the owner verifies the affected interfaces, applications, system services, cybersecurity controls, failure behavior and lifecycle requirements. Supplier substitution remains a controlled engineering change requiring project-specific qualification and acceptance.
Does O-PAS product conformance make a replacement automatically interchangeable?
No. Product conformance addresses the specific product, version and evaluated O-PAS scope. It does not by itself prove interoperability with the installed products and applications or establish project acceptance for the replacement.
What should be checked before selecting a replacement component?
Establish the accepted installed baseline, architecture role, applicable requirements, interfaces, configuration, IEC 61131 application and runtime dependencies, system-management functions, cybersecurity dependencies, performance requirements, failure behavior, recovery needs and support obligations.
Does replacing a runtime require changing the IEC 61131 control application?
Not necessarily. The assessment should determine whether the existing application, libraries and deployment assets are supported by the replacement runtime and whether required behavior can be preserved. A rebuild, redeployment or migration may be required depending on the actual dependencies.
Where should an O-PAS replacement be tested?
Material replacements should be tested in a representative integration environment that reproduces the affected products, versions, interfaces, applications, runtimes, system services and failure conditions closely enough to support the release decision.
What is the difference between interoperability testing and project acceptance?
Interoperability testing verifies required behavior among the assembled products, applications and interfaces. Project acceptance is the owner’s broader decision that the changed system satisfies the applicable contractual, functional, operating, cybersecurity and lifecycle requirements.
What records should change after a component replacement?
Update the installed inventory, configuration baseline, interface records, application and runtime dependencies, backup and recovery assets, product evidence, support register, spares position, test evidence, accepted exceptions and any operating or training documentation affected by the change.
How does CSI support O-PAS component replacement and technology refresh?
CSI helps owners and EPCs define replacement requirements, assess architecture and application dependencies, evaluate candidate products, plan representative qualification environments, coordinate multi-vendor interoperability and regression testing, control deployment and establish the updated accepted lifecycle baseline.
Before obsolescence becomes an emergency migration
Make component replacement a repeatable lifecycle capability
CSI can help define replacement requirements, preserve architecture boundaries, qualify candidate products and build the evidence required for controlled deployment and project acceptance.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This guide is a project and lifecycle planning aid and does not imply endorsement by The Open Group. The applicable contracts, owner standards, approved change procedures, current O-PAS Standard and current certification records govern the delivered and operated system.