1. Safety evidence traceability fundamental

Safety evidence traceability is the discipline of maintaining an explicit, verifiable, and auditable link between every safety claim and the concrete artifacts that support it. In functional-safety engineering, a claim such as "the braking controller detects wheel-lock within 20 ms" is only credible if an assessor can follow a continuous chain from that claim down to the specific test conditions that exercised it and the model or implementation element that realizes it. Traceability is therefore not a documentation afterthought; it is the structural backbone that makes a safety argument defensible.

Three terms must be separated precisely, because they are frequently conflated in practice:

• Traceability — the ability to navigate in both directions (upward and downward) between related artifacts: requirements, design elements, model components, test cases, test conditions, and results.
• Evidence — an artifact that supports a claim with sufficient objectivity: a test log, a coverage report, a formal proof, an analysis result, or a review record.
• Safety argument — the structured reasoning (often expressed via GSN — Goal Structuring Notation) that connects top-level safety goals to sub-goals and, ultimately, to evidence.

Traceability is the mechanism; evidence is the payload; the safety argument is the consumer. A traceability link that points to an artifact which does not actually substantiate the claim is worse than no link at all, because it creates false confidence.

Regulatory drivers and what each standard actually demands

The three dominant standards approach traceability from different angles, and a practitioner working across domains must understand where their requirements converge and where they diverge.

ISO 26262 Part 6 (software) and Part 4 (system) require that each safety requirement be traceable to its implementation and to the verification evidence that demonstrates its satisfaction. DO-178C is more prescriptive about the direction of traceability and mandates that trace data be reviewed as part of the software accomplishment summary. IEC 61508 provides a generic framework that national derivatives (e.g., IEC 61511 for process industry) refine. The common thread: no claim without a traceable evidence path.

The test-condition-to-model evidence chain

The central object of this course is the chain that runs from a concrete test condition, through the test case and its execution, up to the model element or code unit that the test exercises, and finally to the safety requirement the model element satisfies. This chain has a specific directionality that matters for tooling and for review.

Consider a concrete example from an automotive context. A technical safety requirement states: TSR-042: The motor controller shall de-energize the inverter within 10 ms of detecting an overcurrent condition exceeding 400 A. The evidence chain looks like this:

1. Test condition — inject a 450 A current step at the inverter input with a rise time of 50 µs, at ambient temperature 25 °C, with the controller in RUN state.
2. Test case — TC-OC-017, which encodes the stimulus profile, the measurement points (gate-drive signal, DC-link current), and the pass criterion (de-energization ≤ 10 ms).
3. Model element — the overcurrent detection block OC_Detect and the shutdown sequencer SafeShutdown in the Simulink model, plus the corresponding generated code unit.
4. Result — measured de-energization time of 7.3 ms (example value), logged with timestamp, stimulus record, and measurement trace.
5. Link back to requirement — the result is attached to TSR-042 as verification evidence, and the model element is linked to TSR-042 as its implementation.

The traceability requirement is that each of these links is explicit and machine-navigable. If an assessor asks "what evidence supports TSR-042?", the answer must be retrievable in one query. If a model element changes, the impact analysis must reveal which test cases and which requirements are affected.

Why the chain breaks in practice

In real projects, the chain most often fails at three points. First, test conditions are recorded as prose in a test report rather than as structured parameters, so the link from test case to test condition is implicit and cannot be queried. Second, model elements are identified by name only, so a rename silently orphans every link that referenced the old name. Third, results are stored in a separate tool from the requirements, and the link is a manual cross-reference that drifts out of date after the first change request.

The engineering response is to treat traceability as data, not documentation: assign stable identifiers to every artifact, store links in a repository with referential integrity, and generate the human-readable trace matrix from that repository rather than maintaining it by hand. The following diagram shows the evidence chain as a directed graph with the artifact types and link semantics that this course will use throughout.

The diagram makes the two traversal directions explicit. Forward traversal (blue) answers "what implements and verifies this requirement?" Backward traversal (orange) answers "what does this result justify?" A review that only checks forward links will miss orphaned evidence — results that no longer support any current requirement because the requirement was revised. A review that only checks backward links will miss untested requirements. Both directions must be validated, and the validation should be automated as a repository query rather than a manual reading exercise.

Establishing the traceability baseline

Before any test is written, the project needs a traceability baseline: a defined set of artifact types, a naming and identifier convention, and a repository that enforces link integrity. A workable convention for the example above is:

Artifact ID patterns
  Requirement      : TSR-###        (technical safety requirement)
  Model element    : MDL-<block>    (e.g., MDL-OC_Detect)
  Code unit        : SWU-<unit>     (e.g., SWU-OC_Detect)
  Test case        : TC-<area>-###   (e.g., TC-OC-017)
  Test condition   : TCN-<area>-###  (e.g., TCN-OC-017-A)
  Result           : RES-<tc>-<run> (e.g., RES-TC-OC-017-R03)

Link types (typed edges)
  implements       : MDL/SWU -> TSR
  verified_by      : TSR -> TC
  executed_under   : TC -> TCN
  produces         : TC -> RES
  evidences        : RES -> TSR

With this baseline, the impact analysis for a change to MDL-OC_Detect is a single graph query: find all TSR nodes reachable via implements, then all TC nodes reachable via verified_by, then all RES nodes reachable via produces. The result is the exact regression set. If the query returns a requirement with no test case, that is a traceability gap and must be resolved before the change is accepted.

The remainder of this course builds on this foundation: subsequent chapters will address how to structure test conditions so they are machine-linkable, how to represent model elements with stable identity across refactoring, how to automate bidirectional link validation, and how to present the resulting evidence graph to assessors in a form that satisfies ISO 26262, DO-178C, and IEC 61508 review objectives without duplicating effort across the three frameworks.