In this lesson, you will learn how to maintain safety certification integrity by enforcing rigorous configuration management and systematic change impact analysis during the product maintenance lifecycle.
The Challenge of Configuration Drift
In safety-critical systems (e.g., ISO 26262 or DO-178C environments), a certification is only valid for a specific "frozen" state of hardware and software. Once you have documented your safety case and verified your requirements, any modification—no matter how trivial—threatens to invalidate your compliance. Configuration management is the discipline of ensuring that every change is identified, documented, and analyzed before it ripples through the system.
Change Impact Analysis (CIA)
Before committing a code change, you must perform a formal Change Impact Analysis. This process bridges the gap between your requirements traceability (established in previous lessons) and the proposed modification.
When a change is requested, you must map it through the following traceability matrix:
- Requirements Traceability: Identify which safety requirements are affected by the change.
- Verification Coverage: Determine which unit tests or model-checking proofs must be re-run.
- Safety Case Re-validation: Assess if the change alters the hazard assessment or requires a re-calculation of the diagnostic coverage metrics.
For example, if you decide to optimize a function to meet a new Worst Case Execution Time (WCET) requirement, your configuration control process requires:
# Example of a configuration audit trail entry
CHANGE_ID: REQ-104-OPT
TARGET: Timer_Interrupt_Handler.c
IMPACT: Requires re-run of WCET analysis and regression unit tests.
SAFETY_RELEVANCE: Low (No change to safety logic, only timing behavior).
VERIFIED_BY: [Test_ID_099, Model_Check_022]
Enforcing Integrity
Strict configuration management prevents "silent" changes. By tagging every build with a unique version identifier that corresponds to a specific evidence set in your safety case, you ensure that the system currently running on the hardware matches the documentation submitted to the certification body. If a change occurs without triggering this audit trail, the system loses its "certified" status, and the evidence generated during your earlier testing and formal verification phases becomes effectively orphaned.
Key Takeaway: Maintaining certification requires that every system change be formally scoped through impact analysis to ensure traceability to requirements, tests, and safety evidence remains intact.