ISO 26262 traceability: from safety goals to verification

ISO 26262, Road vehicles — Functional safety, is the standard that governs how safety-critical electrical and electronic systems in production vehicles are developed. Adapted from the broader IEC 61508 and now in its second edition (2018), it covers the full safety lifecycle — from initial hazard analysis through development, production, and operation.

For software and systems engineers, ISO 26262 has one organizing principle: the rigor you apply must match the risk, and you must be able to trace that rigor from the hazard all the way to the evidence that you mitigated it.

ASILs: how risk drives rigor

ISO 26262 classifies each hazard with an Automotive Safety Integrity Level (ASIL), from A (lowest) to D (highest), plus QM (quality management only) for hazards that carry no safety integrity requirement. The ASIL is derived from three factors:

• Severity — how bad the harm would be.
• Exposure — how often the situation occurs.
• Controllability — how well a driver could control the situation if the failure happened.

A hazard that is severe, common, and hard to control becomes ASIL D and attracts the most demanding requirements; a minor, rare, easily controlled one may be ASIL A or QM. The ASIL then flows down to every requirement and component involved in addressing that hazard, setting the verification and confirmation rigor for each.

The safety lifecycle and the V-model

ISO 26262 organizes development around a safety lifecycle, commonly drawn as a V:

• Item definition and hazard analysis and risk assessment (HARA) identify hazards and assign ASILs.
• Safety goals — the top-level safety requirements — are derived from the hazards.
• These flow down into functional safety requirements, then technical safety requirements, then hardware and software requirements, and into implementation (the left side of the V).
• Verification and validation climb back up the right side of the V, each level confirming the level it descended from.

Part 6 of the standard covers software development specifically; Part 8 covers supporting processes including requirements management, configuration management, and change management.

Traceability through the V

The V-model only works if the two sides are connected, and that connection is traceability. ISO 26262 expects you to demonstrate an unbroken chain:

safety goal → functional safety requirement → technical safety requirement → hardware/software requirement → implementation → verification result.

Both directions matter. Forward, you prove every safety goal is fully decomposed, implemented, and verified — no safety requirement left unaddressed. Backward, you prove every requirement and test traces to a safety goal, so nothing safety-relevant exists without a rationale. When a requirement changes, that chain tells you exactly which downstream items — and which verification evidence — are now suspect and must be re-confirmed.

Work products and confirmation

ISO 26262 is evidence-driven. Each phase produces work products, and the standard defines confirmation measures — reviews, audits, and (for higher ASILs) independent assessments — that check the work products and the safety argument. Assembling that argument at the end, from data scattered across tools, is where many programs lose time. The safety case is far stronger when the trace between requirements, risk, and verification is maintained continuously.

Keeping the safety case current

The hardest part of ISO 26262 in practice isn’t any single artifact — it’s keeping the whole chain consistent as the design evolves across a long program. A change to one technical safety requirement can ripple through dozens of downstream items and their verification, and a trace maintained by hand across separate tools rarely keeps up.

A living requirements traceability matrix — one where changing a requirement automatically flags every linked item for re-verification — is what keeps the safety case audit-ready between assessments. That’s the model TraceUnified is built on: safety goals, requirements, risk (including ISO 14971-style analysis), and verification as linked records in one system, with suspect-on-change flagging and live coverage analysis. The functional-safety work is still yours to do; the system is engineered to keep the thread from safety goal to evidence intact and current.