Writing an ASIL-D Safety Case Without Losing Your Mind

A practical structure for FMEAs and safety cases that actually survives an assessor.

Let's be honest about what ASIL-D actually feels like from the inside: it's the automotive functional safety equivalent of being asked to prove a negative, in writing, to someone whose entire job is to find the one sentence in your 400-page document that doesn't quite line up with the sentence on page 217.

I've written safety cases for QM systems that felt like filling out a form. I've written them for ASIL-B that felt like a real but manageable amount of homework. And I've written them for ASIL-D, where at some point around 2am, three days before submission, I found myself genuinely questioning whether the word "shall" in requirement SG-014 was doing the philosophical work I needed it to do. That is the energy of this article.

Why ASIL-D Turns Engineers Into Paranoid Document Archivists

ASIL-D is the top of ISO 26262's risk classification — reserved for failures that could plausibly kill someone, where the combination of severity, exposure, and controllability leaves no room for "probably fine." Which means the standard doesn't just want you to be safe. It wants a paper trail proving that every credible way the system could hurt someone has been identified, that every mitigation for those hazards is traceable to a specific requirement, and that every requirement has evidence — actual test results, not vibes — showing it was verified.

The assessor's job, correctly, is to be suspicious of you. Not personally. Structurally. They are paid to assume that if a link in your traceability chain is missing, it's missing because the underlying engineering is missing too, not because you just forgot to update a spreadsheet. This is a completely reasonable position for them to take, and it is deeply annoying to be on the other side of it when you know — you know — that the engineering is fine and the spreadsheet is just three days out of date.

What a Safety Case Actually Has to Contain

Strip away the ISO 26262 vocabulary and a safety case is really five layers, each one justifying the layer above it:

1. Hazard Analysis and Risk Assessment (HARA) — what can go wrong, how bad is it, how likely, how controllable. This is where ASIL ratings get assigned in the first place.
2. Safety Goals — the top-level "this must never happen" statements derived from HARA. For ASIL-D, these tend to be short, blunt sentences that carry enormous downstream weight.
3. Functional Safety Concept (FSC) — how the system, at a functional/architectural level, achieves each safety goal. Still technology-agnostic at this layer.
4. Technical Safety Concept (TSC) — the FSC made concrete: specific mechanisms, redundancy, diagnostic coverage, specific components responsible for specific safety functions.
5. FMEA / FMEDA — the systematic walk through failure modes at the component level, feeding back to confirm the TSC's mechanisms actually cover what they claim to cover.

Every one of these layers needs to trace both upward (why does this exist) and downward (what verifies this). That bidirectional traceability is, unglamorously, most of what an ASIL-D safety case actually is as a document. The engineering might take months. The traceability discipline is what makes that engineering legible to someone who wasn't in the room for any of it.

The Ways This Goes Wrong, Ranked by How Often I've Seen Them

Writing requirements vague enough to be unfalsifiable. "The system shall detect sensor failures in a timely manner" is not a requirement, it's a wish. What's "timely"? Detected how? Which failures? An assessor will circle this and ask you to define every one of those words, and they will be right to.

Traceability that exists in someone's head but not in a document. This is the single most common failure I've seen, including from teams that are otherwise doing excellent engineering. The mitigation is real. The test exists. The link between them, in writing, in a matrix the assessor can actually open, does not exist yet — because it was "obvious" to the two engineers who built it, six months ago, who have since moved to a different project.

Verification evidence that's asserted rather than shown. A test case that says "PASS" in a spreadsheet is not evidence. The actual test report, execution log, or measured result, referenced by ID, is evidence. This distinction sounds pedantic until you're the one trying to explain to an assessor why you're confident about something you can't actually produce.

The Practical Stuff That Actually Saves You

A live traceability matrix — HARA item → Safety Goal → FSC element → TSC mechanism → requirement → test case → test evidence — maintained continuously, not reconstructed the week before assessment. If your team's answer to "where's the traceability matrix" is "we'll build it before the audit," you have already lost several weekends you don't know about yet.

A consistent document template, applied from day one, not retrofitted later. Assessors read a lot of safety cases. A document structured the way they expect it to be structured lets them find what they're looking for quickly, which — counterintuitively — works in your favor. A confused assessor digs deeper, not less.

A pre-assessment self-review against the questions assessors actually ask, which, after enough of these, become fairly predictable: Show me the test evidence for this specific requirement. Walk me through why this failure mode is covered by this mechanism. What's the ASIL decomposition rationale for this redundant path. If you haven't rehearsed answering these out loud before the room fills up, you'll be rehearsing them live, which is a much worse place to discover a gap.

The Assessment That Almost Went Sideways Over One Missing Link

We once nearly failed an ASIL-D assessment over what turned out to be a single unlinked entry in a traceability matrix. Everything upstream was solid — hazard analysis, safety goals, FSC, TSC, all internally consistent, all reviewed. But one specific technical safety requirement, covering a redundant sensor check, had its verification test case documented — the test existed, had run, had passed — but the link in the matrix connecting that requirement to that specific test ID had been left blank during a document reorganization three weeks earlier.

The assessor found it in about four minutes. Not because they were reading every row (nobody reads every row of a matrix with hundreds of entries), but because they'd asked to see verification for exactly that requirement, specifically, because it covered a mechanism they considered high-risk — and when we pulled up the matrix to show them, the cell was empty.

We had the actual test evidence. We could produce it in five minutes. But "we can produce it if you ask" and "it was already correctly documented" are, to an assessor, not the same finding — one is a process gap, and process gaps are exactly the kind of thing ASIL-D assessment exists to surface. We spent the rest of that day going back through every requirement in that section by hand, and the finding got downgraded from major to minor once we demonstrated the evidence actually existed and the gap was clerical rather than substantive — but it was a genuinely uncomfortable few hours, and entirely preventable by a document review pass that nobody had scheduled after that reorganization.

Safety Is a Process, Not a Document You Finish

The thing I try to remind myself — usually while re-reading the same requirement for the fourth time trying to figure out if it's actually testable — is that the safety case is not the safety. It's evidence of the safety, produced by a process that's supposed to run continuously through the whole development lifecycle, not a document you assemble retroactively and hope holds together.

Teams that treat the safety case as a living artifact, updated as the design changes rather than reconstructed before each milestone, consistently have calmer assessments and fewer 2am moments questioning the word "shall." Teams that treat it as a deliverable to produce right before the deadline consistently have the opposite experience, regardless of how good the underlying engineering actually is.

ASIL-D will always be paperwork-heavy, because the thing it's protecting against is serious enough to deserve that scrutiny. But the paperwork doesn't have to be miserable if the discipline behind it is continuous instead of episodic. That's really the whole trick — and it took me more failed traceability links than I'd like to admit to actually believe it.