Function no longer required
The operating requirement has been removed, replaced or consolidated.
Home › O-PAS Decommissioning, System Retirement and Evidence Preservation
Decommissioning · Retirement · Dependencies · Evidence · Baseline Closure
O-PAS decommissioning, system retirement and evidence preservation Remove the function without removing the knowledge
A practical guide for owners, EPCs and system integrators retiring O-PAS components, IEC 61131 applications, interfaces and supporting services while preserving the evidence required for the remaining operating system.
The short answer
Decommissioning is a controlled architecture change, not simply removing equipment that appears unused.
The owner should prove that the retired function is no longer required, trace every dependent application and interface, preserve required IEC 61131 source and lifecycle evidence, remove identities and access, disposition configuration and engineering assets, verify the remaining system, close supplier obligations and establish a new accepted baseline. Product status alone does not establish that a function can be safely retired; system impact and project acceptance remain project-specific decisions.
01 · Retirement basis
Prove that the function is no longer required
Retirement should begin with the operating requirement, not the age of the equipment. Establish why the function, component or application can be removed and what remaining capability must be preserved.
Function moved
Capability has been accepted in a replacement architecture and the coexistence boundary can close.
Redundant implementation
A duplicate path or temporary migration function is no longer required.
Lifecycle exit
An unsupported product is being removed after required capability has been transferred.
Scope closure
A pilot, temporary environment or transition asset has completed its defined purpose.
Retirement authority
The named owner authority approves the basis, dependencies, evidence and final state.
Retirement stop condition: the team believes a function is unused but cannot trace its consumers, application references, operating assumptions or historical reason for existence.
02 · Installed baseline
Record the retirement boundary before changing it
Identify the exact products, versions, configurations, applications, interfaces, identities, services, suppliers and accepted evidence inside the retirement scope.
Installed assets
Exact identity, architecture role, configuration, location and support position.
Control assets
IEC 61131 source, libraries, runtime allocation, parameters and test records.
Consumers and providers
Information, commands, states, quality, diagnostics and retained-system dependencies.
Operating obligations
Support contracts, spares, licenses, procedures, cybersecurity assets and records.
Use the O-PAS System Management and Lifecycle Operations Guide to establish the authoritative installed baseline.
03 · Dependency analysis
Follow every relationship before removing the source
Retirement impact extends beyond physical connections. Trace applications, information consumers, shared services, operating procedures, security relationships, historical data and support processes.
| Dependency | Retirement question |
|---|---|
| Application | Does any IEC 61131 application read, write, call or assume the retired function? |
| Information | Which consumers depend on its data, quality, state, alarms or diagnostics? |
| Command | Which operating or automated workflows send commands or expect acknowledgement? |
| Security | Which identities, certificates, trust relationships, privileges or remote-access paths exist? |
| Operations | Which procedures, training, maintenance or recovery activities reference the function? |
| History | Which records must remain available after the live function is removed? |
Boundary records make retirement cheaper
A controlled interface register lets the project identify affected providers and consumers without reverse-engineering the retired product.
Use the Interface Definition and Boundary Management Guide →04 · IEC 61131 application retirement
Retire control logic deliberately
Logic that appears inactive may still encode an operating assumption, fallback path or rarely used condition. Separate removal of obsolete logic from functional changes to the remaining application.
Find references
Identify variables, calls, libraries, mappings, alarms, sequences and operator functions tied to the retired scope.
Archive the accepted source
Retain the pre-retirement IEC 61131 source, libraries, versions and documentation under the owner retention policy.
Remove dependencies
Change the remaining application through controlled engineering and impact assessment.
Regression test
Prove required remaining functions, alarms, sequences, interlocks and recovery behavior.
Use the O-PAS Application Portability Guide for source, library, runtime and application-asset control.
05 · Interface closure
Remove the boundary from both sides
Disable or remove providers and consumers in a coordinated sequence so stale endpoints, dead mappings, invalid alarms and hidden dependencies do not remain in the accepted architecture.
Stop the source
Remove the retired information, command or service endpoint through the approved sequence.
Remove expectations
Delete or revise mappings, alarms, logic and displays that expect the retired endpoint.
Update definitions
Revise interface registers, architecture records and accepted configuration.
06 · Security closure
Remove identities, trust and access with the retired function
Decommissioning should close security relationships as deliberately as it removes physical and application assets.
Accounts and privileges
Disable identities, service accounts, roles and emergency access no longer required.
Certificates
Revoke or retire certificates and remove obsolete trust relationships.
Supplier paths
Close remote access, support accounts, credentials and firewall or access rules tied to retired scope.
Use the O-PAS Cybersecurity Requirements Guide for identity, trust, access and secure decommissioning controls.
07 · Evidence preservation
Preserve what the owner may need after the equipment is gone
Retirement should distinguish live operating assets from records that remain necessary for engineering history, regulatory obligations, incident investigation, future migration or reconstruction of prior decisions.
Technical record
Architecture, configuration, IEC 61131 source, libraries, interfaces, versions and change history.
Project evidence
Requirements, tests, defects, deviations, approvals and the final retirement decision.
Lifecycle history
Incidents, maintenance, support, cybersecurity, recovery and relevant operating records.
08 · Asset and commercial disposition
Close the physical and commercial lifecycle
| Area | Required disposition |
|---|---|
| Equipment | Remove, reuse, quarantine, return or dispose under owner policy and applicable requirements. |
| Data | Preserve required records and securely remove data from assets leaving owner control. |
| Spares | Reassign, retain, return or dispose based on the remaining installed estate. |
| Licenses | Transfer, terminate or preserve rights needed for retained records and engineering assets. |
| Support | Close or revise supplier agreements, contacts, warranties and escalation obligations. |
| Tools | Retain engineering capability where historical assets may need to be read or reconstructed. |
09 · Retirement sequence
Control the transition from operating asset to historical record
Approve the retirement basis
Confirm the function is no longer required and define the accepted end state.
Freeze the pre-retirement baseline
Preserve required source, configuration, evidence and records.
Remove dependent use
Update applications, consumers, procedures and operating workflows.
Close interfaces and access
Remove endpoints, identities, certificates, trust and supplier paths.
Remove or disposition assets
Execute equipment, data, spares, licenses and contract disposition.
Verify the remaining system
Run selected regression and confirm required operation without the retired scope.
Establish the new baseline
Update architecture, inventory, interfaces, applications, recovery assets and lifecycle records.
10 · Retirement verification and acceptance
Prove the remaining system, not the removed product
Retirement acceptance should demonstrate that required functions remain correct, no unresolved dependencies remain and the authoritative baseline reflects the actual operating system.
| Evidence layer | What it establishes |
|---|---|
| Product and supplier records | Identity, lifecycle position and obligations associated with the retired product; product conformance does not establish retirement acceptability. |
| System interoperability and regression | Remaining products, applications and interfaces operate correctly after removal. |
| Project acceptance | The owner accepts the retirement scope, evidence, residual risk, retained records and new operating baseline. |
Use the O-PAS Configuration Management, Change Control and Regression Testing Guide to control the retirement change and regression scope.
11 · Brownfield retirement
Close temporary coexistence boundaries when migration is complete
Brownfield projects often create gateways, duplicate functions, temporary interfaces and transitional operating procedures. Define retirement criteria for these assets when each migration increment is planned.
Do not let temporary architecture become permanent by default
Assign an owner, exit condition and evidence requirement to each transitional boundary.
Use the Brownfield Open Process Automation Migration Strategy Guide →12 · Responsibility
Assign retirement authority and evidence custody
| Party | Typical accountability |
|---|---|
| Owner/operator | Retirement basis, record retention, risk acceptance and final operating baseline. |
| System integrator | Dependency analysis, coordinated removal, regression and baseline reconciliation. |
| Component suppliers | Product-specific shutdown, data handling, license, return and disposal information for assigned scope. |
| Cybersecurity authority | Identity, trust, access, data-removal and security-record requirements. |
| EPC/project team | Execution planning, contractual closeout, evidence and handover of the final state. |
13 · Connected guidance
Connect retirement to the lifecycle authority set
Lifecycle
System Management
Maintain the authoritative baseline before and after retirement.
ChangeConfiguration and Regression
Control removal and verify the remaining system.
InterfacesBoundary Management
Trace consumers and close retired boundaries.
ApplicationsApplication Portability
Preserve and retire IEC 61131 application assets deliberately.
SecurityCybersecurity Requirements
Close identity, trust, access and data exposure.
ReplacementComponent Replacement
Coordinate retirement when a replacement enters the accepted baseline.
Frequently asked questions
O-PAS decommissioning and retirement questions
When is an O-PAS component ready to be decommissioned?
When the owner has approved the retirement basis, all required functions have been removed or transferred, dependencies are understood, required records are preserved, access and interfaces can be closed and the remaining system can be verified and accepted.
Should retired IEC 61131 source be deleted?
Not automatically. Preserve source, libraries, versions and related evidence according to owner retention requirements before removing the live implementation.
What dependencies should be checked before retirement?
Check applications, information consumers, commands, alarms, interfaces, shared services, identities, certificates, operating procedures, recovery assets, support obligations and historical-record requirements.
What cybersecurity work is required during decommissioning?
Remove or disable identities, privileges, certificates, trust relationships, remote access and support paths, preserve required security records and securely handle data on equipment leaving owner control.
Does product conformance determine whether a component can be retired?
No. Product conformance addresses the evaluated product scope. Retirement is a project decision based on system dependencies, remaining functionality, evidence, regression and owner acceptance.
How does CSI support O-PAS decommissioning?
CSI helps owners and EPCs define retirement boundaries, trace dependencies, preserve IEC 61131 and lifecycle evidence, coordinate interface and security closure, plan regression and establish the updated accepted baseline.
Before an old function disappears with its engineering history
Retire the asset and preserve the system knowledge
CSI can help define retirement scope, dependency analysis, evidence preservation, secure closure, regression and final baseline 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. Applicable contracts, owner standards, record-retention requirements, current O-PAS Standard and current certification records govern the delivered and operated system.