Mapping Safety Requirements to Lifecycle Phases

In this lesson, you will learn how to maintain safety integrity by ensuring every high-level safety requirement is explicitly traced and verified across every stage of the embedded development lifecycle.

The Traceability Matrix

When building safety-critical systems (like those governed by ISO 26262 or IEC 61508), you cannot simply "test in" safety at the end. Instead, you must maintain a Traceability Matrix. This document maps a high-level hazard—for instance, "System must transition to a safe state within 10ms of a watchdog timeout"—down to specific architectural components, source code modules, and validation tests.

The goal is to eliminate "orphan" requirements (requirements that are never tested) and "unjustified code" (code that serves no safety purpose).

Lifecycle Mapping

Mapping occurs in four primary stages:

1. Requirements Phase: Define the Hazard Analysis and Risk Assessment (HARA). Each safety goal is assigned a Safety Integrity Level (SIL/ASIL).
2. Design Phase: Map safety goals to specific architectural mechanisms, such as Hardware Watchdogs or Stack Overflow Detection.
3. Implementation Phase: The code must reflect these requirements. If a requirement mandates an atomic state transition, the implementation should explicitly use atomic primitives.
4. Verification Phase: Link test cases directly to the requirements.

Example: Traceable Safety Implementation

Consider a requirement: "The system must verify the integrity of the data buffer before processing to prevent fault propagation."

/* Requirement ID: REQ-MEM-001 (Mapped to Verification Test: VT-MEM-001) */
void process_buffer(uint8_t *buffer, size_t size) {
    if (calculate_crc(buffer, size) != expected_crc) {
        // Trigger safe state as defined in the lifecycle hazard analysis
        enter_safe_state(); 
    }
    // ... process data
}

By explicitly labeling your code with REQ-ID tags, you create a direct audit trail. During the verification phase, when you execute unit tests or perform formal verification, you can prove that REQ-MEM-001 has been exercised. If an auditor asks why a specific branch of code exists, you can point directly to the requirement it satisfies. This bidirectional mapping ensures that no safety requirement is lost during the evolution of the system architecture.

Key Takeaway: Rigorous safety compliance is achieved by maintaining a bidirectional traceability matrix that links every hazard-mitigating requirement to its corresponding architectural design, implementation, and validation test.