ASIL-D Functional Safety — From Concept to Tool Qualification (a Tier-1 supplier guide)

1. Why ASIL-D is different

Most ASIL conversations start at the wrong end. Teams design an item, run a HARA, see “D” come out, and immediately reach for ASIL decomposition to bring the parts down to something more tractable. That’s often legitimate. But it’s not where the real ASIL-D effort lives.

The real effort lives in the process discipline ISO 26262 applies to ASIL-D artefacts: the additional confirmation reviews per Table 1, the higher coverage targets per Part 6, the stricter independence requirements between authoring and reviewing teams, and the tool-qualification evidence required for every tool whose output ends up in the safety case.

In our experience with Tier-1 powertrain programs (BMS, PTC, EV controllers, steering), the projects that fail ASIL-D audit don’t fail on the safety mechanism design. They fail on tool qualification, on missing confirmation reviews, and on the safety case being a binder full of documents rather than a coherent GSN-style argument.

2. What the concept phase actually requires

Item definition (ISO 26262-3 §5)

The most under-invested deliverable in the entire safety case, and the one that costs you the most downstream when it’s thin. The standard wants four things:

Functionality & behaviour of the item (including malfunctioning behaviour).
Boundary and interfaces to other items / vehicle systems.
Operational environment (including assumptions about driver, road, climate).
Dependencies on other items.

The mistake we see most: the item definition treats the ECU as a black box that “does the function”. The HARA then has to invent malfunctioning behaviour categories from thin air. The assessor will reject this. Invest in a malfunctioning-behaviour catalogue here, anchored to actual failure modes of the hardware (e.g. stuck-at, oscillation, drift, wrong magnitude, wrong sign, wrong timing) and you’ll save weeks downstream.

HARA (ISO 26262-3 §6)

Three numbers determine ASIL: Severity (S0-S3), Exposure (E0-E4), Controllability (C0-C3). The table in 3-Annex A maps these to ASIL. ASIL-D requires the worst of all three. Two common misreadings:

Confusing Exposure with frequency of vehicle use. Exposure is the duration during which the operational situation is present. Driving at high speed on a motorway is E4 (high) because cars routinely spend large fractions of their operating time at motorway speed. Exposure is not “does this car ever drive on the motorway?”
Treating Controllability as “average driver”. ISO 26262 defines controllability against a representative driver population including non-experts. If you wouldn’t trust your grandmother to control the situation in 99% of cases, it’s not C2.

Functional Safety Concept (ISO 26262-3 §7)

Three sub-deliverables:

Safety goals (from the HARA — one per hazardous event you’ve chosen to mitigate).
Safe states & fault-tolerant time intervals (FTTI).
Functional safety requirements (FSRs), allocated to architectural elements.

The deliverable assessors actually read first is the FTTI argument. If your FTTI is “200 ms because we think that’s reasonable”, you’ll be asked to back it up. Document the analysis (typical: driver reaction time + vehicle dynamics + control-loop period).

3. Where ASIL decomposition is legitimate

ISO 26262-9 §5 spells out the rules. Decomposition splits an ASIL-D requirement across two sufficiently independent elements, allowing each to be developed at a lower ASIL (typically D → B + B, or D → C + A). The magic word is independence.

In practice the assessor will ask three questions:

What does “independent” mean for these elements? (Different cores? Different power domains? Different code paths? Different safety mechanisms?)
Show me the Dependent Failure Analysis (DFA — ISO 26262-9 §7) that proves no common-cause failure invalidates the decomposition.
Show me the architectural argument that the two decomposed requirements together satisfy the original ASIL-D requirement.

If you can’t answer all three, the decomposition won’t hold up. We see this failed on roughly 60% of first-time ASIL-D submissions we’ve walked into for audit prep.

4. Hardware: FMEDA and the metrics

ISO 26262-5 introduces three hardware metrics relevant at ASIL-D:

SPFM (Single Point Fault Metric) — ≥ 99% for ASIL-D.
LFM (Latent Fault Metric) — ≥ 90% for ASIL-D.
PMHF (Probabilistic Metric for random Hardware Failure) — < 10⁻⁸ /h.

All three come out of the FMEDA. The FMEDA itself isn’t difficult once your safety mechanism inventory and diagnostic-coverage assumptions are well documented. The trap: diagnostic coverage values come from your hardware engineer’s assumptions, and they need backing. An auditor will pick three random safety mechanisms and ask you to defend the DC value you assigned. If your answer is “the supplier datasheet says 90%”, that’s often acceptable. If it’s “we assumed”, it’s not.

5. Software: the SWE.x clauses you can’t skip

ISO 26262-6 prescribes structural coverage targets per ASIL. At ASIL-D:

Statement coverage: highly recommended → effectively required.
Branch coverage: highly recommended.
MC/DC (Modified Condition / Decision Coverage): highly recommended.

The combination of branch + MC/DC is where most teams underinvest. Tools like BTC EmbeddedTester or Matlab / Simulink Test handle this on the model side; for handwritten C code you’ll need a structural-coverage tool integrated into your verification toolchain. Tool qualification of the coverage tool is mandatory evidence in your safety case.

6. Tool qualification — the silent killer

ISO 26262-8 §11 covers tool qualification. For every tool whose output ends up in the safety case (autocoders, static-analysis tools, test-generation tools, requirements-management tools that feed traceability), you need to classify the Tool Confidence Level (TCL1, TCL2, TCL3) based on Tool Impact (TI) and Tool error Detection (TD).

TCL1 — no qualification needed.
TCL2 or TCL3 — qualification needed, with methods that scale with ASIL.

The most common audit finding we’ve seen in 8 years of FuSa work: autocoder used in production without tool-qualification evidence in the safety case. Either the customer’s tool vendor supplied a Tool Qualification Kit (TQK) that wasn’t referenced in the project’s safety case, or the autocoder was qualified for a different ASIL than the project requires. Both are findings the auditor will flag.

7. Confirmation reviews — Table 1 of ISO 26262-2

ISO 26262-2 §6.4.7 prescribes a matrix of confirmation measures (configuration review, verification reviews, confirmation reviews, functional safety audit, functional safety assessment) with their required independence level per ASIL. At ASIL-D, several reviews require “I3” independence — performed by an organisation different from the developing organisation.

We see two common compromises:

The customer (OEM) performs the I3 review, and you assume that’s enough. Often it is — but you need it in writing in the customer agreement.
An internal “independent department” performs the review, but the same person has dotted-line responsibility to the project manager. That’s I2 at best, not I3.

8. The safety case — argument, not binder

The safety case is the document the assessor will spend the most time with. Treat it as a binder of artefacts and you’ll get a long list of findings; treat it as a structured argument and you’ll get through faster.

The structure we use:

Top-level claim: “Item X is acceptably safe for its defined operational environment per ISO 26262.”
Decomposition into sub-claims: safety goals achieved, hazards mitigated, residual risk acceptable.
For each sub-claim: an explicit argument (why the evidence is sufficient) and references to the evidence (HARA, FSC, TSC, FMEDA, verification reports, confirmation reviews).

Goal Structuring Notation (GSN) is the de facto standard for this. It’s not required by ISO 26262 — but assessors accept it as the cleanest argument format.

9. Where we’ve seen ASIL-D programs go wrong

Five recurring patterns from our last 12 Tier-1 audit-prep engagements:

Decomposition without DFA (~60% of submissions). The decomposition reads fine on paper but the DFA isn’t there or doesn’t cover the actual common-cause failures.
Tool qualification gaps (~50%). Especially for autocoders and structural-coverage tools.
Diagnostic coverage assumptions unbacked (~45%). FMEDA arithmetic is right but the per-mechanism DC values can’t be defended under questioning.
Confirmation review independence not documented (~40%). Reviews happened but the I-level can’t be proven from organisational structure.
Safety case is a binder, not an argument (~70%). Evidence exists but not synthesised into a defensible top-level claim structure.

10. What to do in the next 30 days if you’re heading to an ASIL-D audit

Re-read your item definition and HARA. If you can’t name the malfunctioning behaviour catalogue and defend the E and C ratings, fix those first.
Audit your tool qualification evidence. List every tool, its TCL, its qualification status, its TQK reference. Find the gaps now.
Verify confirmation-review independence on paper. Match each Table 1 row to an actual person or organisation; check the I-level holds.
Defend three random FMEDA DC values. If you can’t, you have a finding waiting to happen.
Restructure the safety case as an argument. If you have GSN, audit it. If you don’t, write the top-level claim and 5-7 sub-claims and trace evidence to each.

Want a 30-min walkthrough on your project?

No NDA needed. Tell us which ASIL, which item, which assessor, which deadline. Within 48 hours you’ll get a one-page diagnostic mapped to the clauses above — yours to keep, whether or not you hire us.

Book a FuSa walkthrough

Author: Adrian Valea, Founder & Managing Director, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Published 2026-05-25.

ASIL-D Functional Safety: From concept to tool qualification.