In this lesson, you will learn how to maintain bidirectional traceability between safety requirements, design artifacts, and verification test cases to ensure no safety-critical function goes unverified.
The Concept of Bidirectional Traceability
In mission-critical embedded systems, it is not enough to pass a test; you must prove why that test exists and which safety requirement it fulfills. Bidirectional traceability provides two-way visibility:
- Forward Traceability: Ensures every safety requirement is covered by at least one design element and a corresponding verification test case.
- Backward Traceability: Ensures every test case originates from a valid safety requirement, preventing "gold-plating" or redundant, undocumented code.
Structuring the Traceability Matrix
The industry standard for managing this is the Requirements Traceability Matrix (RTM). This matrix acts as a map for auditors, showing that a specific hazard identified during your Hazard Analysis and Risk Assessment (HARA) is mitigated by a software requirement, implemented in the source code, and validated by a specific test.
Consider a safety requirement for an over-temperature sensor:
- Requirement ID (SR-001): The system shall enter a safe state if the CPU junction temperature exceeds 105°C.
- Design Artifact (DA-402): Thermal monitor ISR and state machine transition logic.
- Verification Test (VT-99): Fault injection test where temperature register is forced to 110°C in simulation.
A simplified RTM snippet might look like this:
| Req ID | Design Component | Test ID | Coverage Status |
|---|---|---|---|
| SR-001 | thermal_monitor.c | VT-99 | Pass |
| SR-002 | battery_mgr.c | VT-102 | Pending |
Implementation in Practice
By linking these artifacts, you establish a chain of evidence. If a design component changes, the matrix instantly flags which tests must be re-run, ensuring that you maintain safety compliance even as the system evolves. This practice is mandatory for certification standards like ISO 26262 or DO-178C, where "untraceable" code is considered a major vulnerability.
Key Takeaway: Bidirectional traceability forces a formal link between every safety requirement and its validation test, ensuring that no requirement is forgotten and no test is executed without a clear safety purpose.