An ASIL D classification on a perception function is not a severity stamp you cite and move past. It is a demand for a specific kind of argument: every safety goal traced to the test that exercised it, every failure mode covered, every decomposition justified. Teams that miss this read the label as “run more tests.” The label actually says “make the argument auditable” — and those are not the same instruction. We see this misread regularly. A perception team scoping a function classified ASIL D under ISO 26262 attaches a denser test report — more frames, more scenarios, a fatter coverage matrix — and submits it as the evidence the level requires. Volume is not the demand. The demand is a chain a reviewer can follow from each safety goal to the concrete test that exercised it, with the failure modes that goal is meant to control named and shown to be covered. A pile of passing test runs with no requirement-to-test linkage does not clear an ASIL D review; it triggers a clarification cycle. How Does ASIL D Work, and What Does It Actually Demand? ISO 26262 assigns an Automotive Safety Integrity Level to each safety goal of an item, derived from three factors of the hazard it addresses: severity (how bad the harm), exposure (how often the operating situation occurs), and controllability (how well a driver could avoid the harm). The combination maps to QM (quality-managed, no ASIL) or ASIL A through D. ASIL D is the highest — the combination of high severity, high exposure, and low controllability, the hazards where the system must work because the human cannot recover the situation. What rises with the level is not a single number but the rigour of the safety argument the evidence has to support. Higher ASIL means stricter requirements on systematic-fault avoidance, on hardware metrics, on verification methods, and — the part perception teams most often underweight — on the completeness and traceability of the case that ties it all together. The standard does not say “test more.” It specifies recommended methods and the level of independence and coverage expected, and it expects you to show that the residual risk has been argued down to an acceptable level for that hazard. This is the divergence point. A team that grasps why ASIL D raises the bar maps each safety goal to an evidence surface and structures the pack so the chain is visible. A team that treats ASIL D as a severity stamp produces a thick report with no spine — and a reviewer cannot sign against volume. What Separates ASIL A from ASIL D — and How the Level Gets Set The level is not chosen; it is derived from the hazard analysis and risk assessment. The same function can carry different ASILs in different vehicles or operating designs because exposure and controllability change with context. The table below is a working summary of how the levels differ in what they demand of an evidence pack — not a substitute for the standard’s risk-graph tables, which are the authoritative source. Axis ASIL A ASIL B / C ASIL D Hazard profile Lower severity / exposure / better controllability Rising on one or more axes High severity, high exposure, low controllability Systematic-fault rigour Baseline methods recommended Stricter methods, more independence Most rigorous methods, highest independence expected HW fault-metric targets Looser Tighter Tightest (per ISO 26262 Part 5 targets) Traceability expectation Each goal linked to verification Same, with more coverage Each goal traced to the specific test + failure-mode coverage shown Decomposition leverage Limited benefit Useful Most valuable — lets you split the goal across redundant elements The practical takeaway for a perception team: when a function lands at ASIL D, the question is not “how many more frames” but “can a reviewer trace each safety goal to the test that exercised the failure modes that goal controls.” That mapping is the substance of a perception validation evidence package reviewers actually trust, and it is what the ASIL classification means for perception evidence more broadly across levels. What Specific Evidence Demands Does ASIL D Place on a Perception Pack? Three demands, in our experience (observed across automotive perception engagements; not a published benchmark), are where ASIL D packs most often fall short: Failure-mode coverage. The pack must show that the failure modes each safety goal is meant to control are enumerated and exercised. For a perception function this includes degraded inputs, out-of-distribution scenes, sensor faults, and the perception-specific failures — false negatives on a vulnerable road user, misclassification under glare or occlusion — that a generic test sweep does not target by construction. Coverage is against the named failure modes, not against scenario count. Decomposition rationale. If you used ASIL decomposition to allocate the safety goal across redundant elements, the pack has to justify why the decomposition is valid — that the elements are sufficiently independent and that their combined behaviour still meets the goal. More on this below. Requirement-to-test traceability. Each safety requirement links to the test that exercised it, and each test links back to the requirement it satisfies. This is the spine. Without it the reviewer cannot confirm that a given goal was verified at all, regardless of how many tests ran. Computer-vision teams building these chains — and the broader perception engineering that feeds them — should treat the trace as a first-class deliverable, not a byproduct of running tests. How Do You Trace a Safety Goal to the Test That Exercised It? The trace is a directed chain, and ASIL D is the level at which it has to be complete and bidirectional. The minimum viable structure looks like this: Safety goal — the top-level statement of what must not happen (e.g. “the perception function shall not fail to detect a pedestrian in the planned path under defined operating conditions”). Derived safety requirements — the technical requirements that, if met, satisfy the goal, including the failure modes to be controlled. Verification specification — for each requirement, the test or analysis that exercises it, with the pass criteria. Test results — the executed evidence, linked to the verification spec and through it back to the requirement and goal. When this chain is intact, a reviewer reads top-down (does every goal have requirements, do those requirements have tests, did the tests pass) and bottom-up (does every test trace to a requirement, or is it noise). A pack that supplies step 4 in volume but skips the linkage in steps 1–3 is the classic ASIL D clarification trigger: the evidence exists but the argument does not. What Traceability Gaps Most Often Trigger a Clarification Cycle? The recurring ones, again as an observed pattern across engagements rather than a benchmarked rate: a safety goal with no derived requirement that names its failure modes; tests that pass but trace to no requirement; a decomposition asserted without an independence argument; and pass criteria stated in the test but never tied back to the requirement’s acceptance condition. Each of these is a break in the chain. A reviewer who finds one cannot clear the function and sends the pack back — and the rework that follows is exactly the cost ASIL D fluency is meant to avoid. The first-pass clearance rate on safety-relevant functions rises sharply when the chain is built before submission rather than reconstructed after a bounce. How Does ASIL Decomposition Let You Allocate a D-Level Goal? ASIL decomposition is the mechanism in ISO 26262 that lets you allocate one ASIL D safety goal across two sufficiently independent elements at lower levels — for instance ASIL B(D) plus ASIL B(D), or ASIL D(D) plus QM(D) — so that the redundant architecture, not a single element, carries the integrity. It is one of the most valuable tools at ASIL D because it can make a target achievable that no single element would meet. The catch is what the resulting evidence has to demonstrate. Decomposition is only valid if the elements are genuinely independent — no common-cause failure that takes both out at once — and the pack must argue that independence, not assume it. For perception this is subtle: two models trained on overlapping data, or two sensors degraded by the same fog, are not as independent as the architecture diagram suggests. The decomposition rationale in the evidence pack has to confront that head-on. A decomposition asserted without a freedom-from-interference and independence argument is, in review terms, no decomposition at all. Does an ASIL D Label Prove the Function Is Safe? No — and this is the limit worth stating plainly. ASIL D is a classification of the integrity demanded of the function, derived from the hazard. It says nothing, by itself, about whether the function as built meets that demand. The proof is the argument: failure-mode coverage, valid decomposition, and the requirement-to-test trace that shows each goal was actually verified. The label sets the bar; the evidence pack clears it. Treating the label as the proof is the original misread that this whole piece is about. There is also a scope limit. ASIL D addresses the systematic and random hardware faults the standard is built to manage. Perception carries failure modes — distributional shift, adversarial conditions, the open-world problem of “things the model has never seen” — that sit at the edge of what classical functional safety was designed for, which is why what robustness means for an automotive perception model in practice is a distinct concern that an ASIL D classification frames but does not fully resolve. ASIL D vs DAL A: Same Instinct, Different Argument Engineers crossing from aerospace ask how ASIL D relates to DAL A (Design Assurance Level A under DO-178C / ARP4754). The instinct is right — both are the highest integrity level in their domain, both reflect catastrophic-consequence functions. The difference is in the shape of the argument each demands. DAL A leans heavily on structured development assurance, MC/DC code coverage, and process objectives with strong independence; ASIL D combines systematic-fault avoidance with quantified hardware fault metrics and a risk-based safety case. They are not interchangeable, and an evidence pack built for one will not satisfy the other — but the underlying discipline, a complete and traceable argument from goal to verification, is the same instinct in both worlds. FAQ How does ASIL D work, and what does it mean in practice? ASIL D is the highest Automotive Safety Integrity Level under ISO 26262, assigned to safety goals where a hazard combines high severity, high exposure, and low controllability. In practice it raises the rigour demanded of the safety argument — stricter fault-avoidance methods, tighter hardware metrics, and a complete, traceable case from each safety goal to its verification. It is a demand for an auditable argument, not simply for more testing. What is the difference between ASIL A, B, C and D, and how is the level determined? The level is derived, not chosen: severity, exposure, and controllability of the hazard map onto QM or ASIL A through D via the standard’s risk tables. ASIL A is the lowest non-QM level and ASIL D the highest. As the level rises, so do the rigour of recommended methods, the hardware fault-metric targets, the expected independence, and — critically for perception — the completeness and traceability of the evidence. What specific evidence demands does an ASIL D classification place on a perception validation pack? Three demands dominate: failure-mode coverage against the modes each safety goal controls, a justified decomposition rationale where redundancy is used, and bidirectional requirement-to-test traceability linking every safety goal to the test that exercised it. Volume of test runs does not satisfy any of these. The pack must let a reviewer follow the chain from goal to verification. How do we trace each safety goal to the test that exercised it for an ASIL D function? Build a directed, bidirectional chain: safety goal → derived safety requirements (naming the failure modes) → verification specification with pass criteria → executed test results. At ASIL D this chain must be complete in both directions, so a reviewer can confirm every goal has tests and every test traces to a requirement. A pack with test results but no linkage is the classic clarification trigger. Does an ASIL D classification by itself prove a perception function is safe — what are the limits? No. ASIL D classifies the integrity demanded of the function; it does not prove the function meets that demand. The proof is the evidence argument — coverage, valid decomposition, and the requirement-to-test trace. ASIL D also addresses systematic and random hardware faults, so perception-specific failures like distributional shift and open-world cases sit partly outside what the classification resolves. What ASIL D traceability gaps most often trigger a reviewer clarification cycle? The recurring breaks, as an observed pattern across engagements, are: a safety goal with no requirement naming its failure modes, passing tests that trace to no requirement, a decomposition asserted without an independence argument, and pass criteria never tied back to the requirement’s acceptance condition. Each is a hole in the chain that prevents clearance. Building the chain before submission, not after a bounce, is what lifts first-pass clearance. How does ASIL decomposition let you allocate an ASIL D safety goal across redundant elements, and what does the resulting evidence have to demonstrate? Decomposition allocates one ASIL D goal across two sufficiently independent elements at lower levels (e.g. ASIL B(D) + B(D)), so the redundant architecture carries the integrity. It is valid only if the elements are genuinely independent with no common-cause failure. The evidence must argue that independence — for perception this means confronting shared training data or shared sensor-degradation conditions, not assuming the architecture diagram implies independence. What is the difference between ASIL D and DAL A (aerospace) in terms of the evidence and argument each demands? Both are the highest integrity level in their domain, but the argument differs. DAL A under DO-178C / ARP4754 leans on structured development assurance, MC/DC coverage, and process objectives with strong independence; ASIL D combines systematic-fault avoidance with quantified hardware fault metrics and a risk-based safety case. The packs are not interchangeable, though both rest on the same discipline: a complete, traceable argument from goal to verification. The cleanest way to internalise ASIL D is to stop asking “is this function ASIL D?” and start asking “can a reviewer trace each safety goal to the test that exercised its failure modes?” That second question is the one the perception validation package reviewers sign against is built to answer — and the function the integrity level was always pointing at.
