Exact products and versions
Manufacturer, model, orderable configuration, hardware revision, firmware, operating environment, software release and license position.
Home › O-PAS Configuration Management and Change Control
Baselines · Dependencies · Change Control · Regression · Rollback
O-PAS configuration management and change control Keep the accepted system reproducible as it changes
A practical guide for owners, EPCs and system integrators controlling multi-vendor products, configurations, control applications, interfaces, patches and evidence from project execution through lifecycle operation.
The short answer
An O-PAS multi-vendor system needs one controlled baseline that connects exact product identities, versions, configurations, applications, interfaces, infrastructure services, dependencies and accepted evidence.
Every proposed change should identify the affected configuration items, assess architectural and operating consequences, define approval and rollback authority, select proportionate regression tests and update the owner’s records. A component patch is not isolated when its identity, interface behavior, security services, application runtime or management dependencies can affect the assembled system.
01 · Controlled baseline
Control the assembled system, not separate supplier inventories
The baseline must describe what is installed, how it is configured, what it depends on and which evidence supports its accepted state.
Reproducible system state
Settings, identities, certificates, mappings, schemas, endpoints, access rules, infrastructure services and approved backups.
Controlled owner assets
Source, libraries, dependencies, build inputs, deployment packages, runtime allocation, versions and recovery artifacts.
Boundary definitions
Providers, consumers, information semantics, states, timing, quality, security, failure behavior and version assumptions.
Accepted verification basis
Requirements traceability, product evidence, integration results, FAT, SAT, defects, deviations and acceptance approvals.
Named lifecycle authority
Custodian, technical approver, operating authority, cybersecurity authority, test authority and supplier responsibilities.
Control stop condition: the owner can identify individual products but cannot reproduce the accepted integrated baseline or determine which evidence becomes invalid when one item changes.
02 · Configuration-item model
Define what the project controls and at what level
A configuration item should be small enough to identify and change deliberately, but broad enough to include the records and dependencies needed to restore it.
Hardware and supplied software
- Physical and virtual execution platforms
- I/O and field-interface components
- Operator, engineering and management products
- Operating systems, firmware and drivers
- Security and infrastructure services
Control and supporting applications
- IEC 61131 source and libraries
- Build and deployment packages
- Application parameters and allocations
- Runtime and toolchain dependencies
- Functional and recovery test assets
Interfaces and data definitions
- Endpoint and interface records
- Information models and mappings
- Naming, identity and time dependencies
- Quality, state and alarm behavior
- Failure and restoration expectations
Lifecycle control assets
- Backup and restore packages
- Monitoring and diagnostic configuration
- Certificates, accounts and access rules
- Procedures, inventories and support records
- Approved deviations and temporary changes
The practical rule
If an item can be patched, replaced, configured, deployed, restored or supplied independently, the baseline should identify it and connect it to its dependencies, approvals and verification evidence.
03 · Dependency control
A change boundary is usually wider than the purchase order
Multi-vendor lifecycle risk concentrates in relationships among configuration items. Record those relationships before a patch, substitution or application release forces the project to discover them.
| Dependency | What to record | Change question |
|---|---|---|
| Product to profile evidence | Exact product, version, applicable profile, evidence record, limitations and status. | Does the proposed version remain inside the evidenced scope? |
| Application to runtime | Runtime release, supported language features, libraries, build tools, resource assumptions and deployment method. | Must the application be rebuilt, migrated or functionally reverified? |
| Interface provider to consumer | Endpoint, semantics, states, quality, timing, security, failure behavior and version compatibility. | Could either side observe different behavior after the change? |
| Component to system services | Identity, naming, time, certificates, monitoring, logging, backup, update and recovery services. | Will the changed item still participate in whole-system operations? |
| Product to cybersecurity controls | Hardening, accounts, access, certificates, vulnerabilities, patch assumptions and monitoring. | Does the change close one exposure while changing another control? |
| Baseline to acceptance evidence | Tests and records applicable to each identity, configuration, application and boundary. | Which accepted results remain valid and which require regression? |
Use the O-PAS Interface Definition and Boundary Management Guide to define the relationships that make impact assessment possible.
04 · Change workflow
Use one governed path from request to accepted baseline
Project changes, supplier updates, cybersecurity patches, component substitutions and emergency corrections can use different approval speeds while preserving the same control principles.
| Change class | Typical example | Minimum control position |
|---|---|---|
| Standard | Repeatable, low-risk maintenance already covered by an approved method and evidence set. | Authorized procedure, prerequisites, execution record, validation and baseline update. |
| Normal | Application release, product update, configuration revision or planned component replacement. | Full impact assessment, approval, test plan, rollback, implementation record and release decision. |
| Major | Architecture change, supplier substitution, runtime migration or material interface revision. | Architecture authority, supplier coordination, representative integration environment and expanded regression. |
| Emergency | Urgent correction needed to protect safe, secure or reliable operation. | Defined emergency authority, bounded implementation, verified fallback and retrospective normalization. |
05 · Impact assessment
Follow the change through the architecture before approving it
The assessment should explain what can change, what evidence is affected and why the proposed verification is sufficient.
Fix the starting identity
Record the current accepted item, version, configuration, application allocation, interfaces, dependencies and recovery package.
Define the proposed difference
Describe exactly what will change, why it is required, which supplier statements support it and what remains uncertain.
Trace direct and indirect dependencies
Follow affected applications, interfaces, system services, security controls, operating procedures, spares and support obligations.
Reassess evidence validity
Identify product, integration, FAT, SAT, cybersecurity, performance and recovery evidence that remains applicable or becomes conditional.
Define implementation and fallback
State the window, sequence, responsible parties, prerequisites, backups, hold points, rollback triggers and restoration method.
Select regression and release criteria
Choose tests from affected requirements and failure paths, then name the authority that accepts results and releases the new baseline.
06 · Regression testing
Test the consequences of the change, not only the changed item
Regression scope should follow requirements, dependencies, failure paths and operating consequences. Repeating every prior test is rarely practical; testing only the supplier’s changed feature is rarely sufficient.
| Changed area | Direct verification | Regression that may remain |
|---|---|---|
| Firmware, operating environment or product software | Identity, installation, configuration retention, health and supplier-stated correction. | Interfaces, timing, resource use, redundancy, restart, monitoring, backup, restore and cybersecurity controls. |
| Control application or library | Build, deployment, changed functions, alarms, sequences and expected process behavior. | Dependent applications, shared libraries, runtime loading, operator interaction, rollback and recovery. |
| Interface or information model | Provider and consumer behavior for changed data, commands, states and quality. | Loss, restoration, stale or invalid data, alarms, diagnostics, performance and downstream consumers. |
| Identity, certificate or access configuration | Authentication, authorization, certificate chain, approved access and audit record. | Application communication, monitoring, remote support, expiry behavior, recovery and incident procedures. |
| Component replacement or supplier substitution | Physical, functional, profile, configuration and interface equivalence. | Application execution, system management, performance, failure behavior, recovery, spares and lifecycle support. |
| System-management service | Changed deployment, monitoring, inventory, backup, update or diagnostic function. | Managed components across suppliers, failure isolation, alerts, auditability and restoration of the whole system. |
Run material changes in a representative environment first
The integration environment should reproduce the affected products, versions, interfaces, applications, services and failure conditions closely enough for the regression result to support the release decision.
Use the O-PAS Integration Environment and Testbed Planning Guide →07 · Patches and supplier releases
Separate supplier urgency from project release authority
A supplier can recommend or require a patch. The owner still needs an integrated decision about applicability, dependencies, timing, verification, operating risk and rollback.
Confirm exact exposure
Identify affected products, versions, configurations, enabled functions and compensating controls.
Collect release evidence
Purpose, prerequisites, limitations, compatibility, installation method, known issues and support consequences.
Trace shared dependencies
Applications, interfaces, identity, certificates, monitoring, backup, failover and supplier boundaries.
Compare action and deferral
Exposure, process consequence, outage need, temporary controls, resource availability and production constraints.
Test before release
Representative environment, direct verification, regression scope, defects, deviations and acceptance criteria.
Control the operating event
Sequence, backups, communications, hold points, rollback triggers, release authority and baseline update.
Use the O-PAS Cybersecurity Requirements Guide to assign vulnerability, patch, identity, monitoring and incident responsibilities across suppliers.
08 · Emergency change and rollback
Move quickly without losing control of the system state
Emergency procedures can compress review and approval, but they should not remove identity, authorization, recovery, validation or evidence.
Define who can act
- Conditions that qualify as an emergency
- Named operating and technical authority
- Required supplier participation
- Time-bounded temporary approvals
- Escalation and communications
Preserve the prior state
- Verified configuration and application backup
- Required credentials and licenses
- Retained product or installation package
- Rollback trigger and decision deadline
- Safe restoration and restart method
Prove minimum safe operation
- Changed function and affected boundaries
- Protection, alarms and operator visibility
- Control and application behavior
- Monitoring, diagnostics and recovery
- Known limitations and temporary controls
Close the temporary state
- Retrospective impact assessment
- Remaining regression tests
- Defect and root-cause records
- Permanent approval or removal
- Baseline, procedures and evidence updated
09 · Evidence and records
Make every accepted change traceable and recoverable
The change record should allow another qualified team to understand the decision, reproduce the accepted state and determine what must be tested when the next change arrives.
Why the change was approved
- Request, need and urgency
- Alternatives and deferral risk
- Impact and dependency assessment
- Required approvals and conditions
- Accepted limitations or deviations
What was implemented
- Before-and-after identities
- Procedure and actual sequence
- Personnel, suppliers and timestamps
- Configuration and application changes
- Issues, corrections and rollback events
What the evidence supports
- Requirements and tests selected
- Environment and test configuration
- Expected and actual results
- Defects, retests and disposition
- Formal release approval
What now governs operation
- Updated inventory and dependencies
- As-operated configuration
- Applications and recovery packages
- Interface and procedure revisions
- Superseded records retained
10 · Governance and contract
Assign authority across owner, integrator and suppliers
The process fails when every supplier controls its own product but nobody controls the integrity of the assembled system.
| Control decision | Position required |
|---|---|
| Baseline custody | Who maintains the authoritative product, configuration, application, interface and evidence records? |
| Technical impact | Who assesses cross-component, application, interface, security and system-management consequences? |
| Architecture approval | Who approves substitutions, boundary changes, dependencies, exceptions and major releases? |
| Operating authorization | Who approves the implementation window, process conditions, return to service and emergency action? |
| Regression authority | Who decides which prior evidence remains valid and which tests must be repeated? |
| Supplier correction | Who diagnoses cross-supplier failures, coordinates correction and carries the cost of retest? |
| Release acceptance | Who accepts results, deviations and residual risk and declares the new baseline operational? |
| Lifecycle audit | Who checks periodically that installed state, recovery assets, records and support positions still agree? Use the O-PAS Multi-Vendor Operations and Support Model Guide → |
Use the O-PAS Responsibility Matrix and O-PAS Procurement Specification Checklist to make change assessment, correction, regression and baseline ownership contractual.
11 · Connected guidance
Connect change control to the complete lifecycle evidence chain
Handover
Commissioning and Cutover
Create the accepted operating baseline and transfer its custody to the owner.
OperationsSystem Management and Lifecycle
Operate, monitor, update, recover and govern the multi-vendor system.
VerificationFAT and Interoperability Testing
Define requirements, boundary tests, acceptance criteria and evidence.
ApplicationsApplication Portability
Control source, libraries, toolchains, runtime dependencies, deployment and rollback.
ProductsCertification Tracker
Check exact product, version, edition and profile evidence during change assessment.
DeliveryOPA System Integration
Coordinate architecture, suppliers, boundaries, correction, testing and lifecycle governance.
Frequently asked questions
O-PAS configuration and change-control questions
What belongs in an O-PAS system baseline?
The baseline should identify exact products and versions, configurations, control applications, source and libraries, runtime allocations, interfaces, information definitions, infrastructure services, cybersecurity settings, dependencies, recovery assets, accepted deviations and supporting evidence.
Does a supplier-approved patch still require project testing?
Usually yes. Supplier approval supports the changed product within the supplier’s stated scope. The owner must still assess effects on project configuration, applications, interfaces, security controls, system management, failure behavior and operating requirements and select proportionate regression tests.
How much regression testing is enough?
The scope should cover the changed requirement, affected configuration items, direct and indirect dependencies, credible failure paths and operating consequences. The impact assessment should explain why retained evidence remains valid and why the selected tests are sufficient.
Where should material changes be tested?
Use a representative integration environment before the operating system whenever the change can affect applications, interfaces, shared services, cybersecurity, failure behavior or recovery. The environment must reproduce the affected baseline closely enough to support the release decision.
How should emergency changes be controlled?
Define qualifying conditions, named authority, minimum impact review, a recoverable prior state, bounded validation and rollback triggers. Complete retrospective assessment, remaining regression and baseline normalization after the urgent operating need is controlled.
Does product conformance evidence remain valid after an upgrade?
Do not assume it transfers automatically. Confirm the exact product identity, version, configuration, applicable O-PAS edition, profile scope, certification record and limitations for the proposed release, then address system-level effects through project change control and testing.
Who should own the integrated baseline?
The owner should retain lifecycle authority and access to the authoritative baseline. A system integrator may maintain and assess it under the owner’s governance, while each supplier remains responsible for accurate evidence and support for its assigned products and changes.
Before the first patch becomes an integration event
Make the O-PAS change process executable
CSI can help define the controlled baseline, dependency model, approval workflow, integration environment, regression strategy and supplier responsibilities needed to change a multi-vendor system safely.
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; the applicable contract, owner standards, approved change procedures, current O-PAS Standard and current certification records govern the delivered and operated system.