ASIL-D safety cases: where the discipline diverges from ASIL-B and below

Key takeaways

• An ASIL-D safety case is not a deeper ASIL-B safety case. The diagnostic coverage thresholds, the independence requirements, and the audit-evidence depth all step up. Treating ASIL-D as "ASIL-B with more rigor" is the most common reason programs underestimate the work.
• The numeric step from ASIL-B to ASIL-D under ISO 26262 Part 5 is real. The Single-Point Fault Metric target moves from 90% to 99%, the Latent Fault Metric target moves from 60% to 90%, and the recommended PMHF (Probabilistic Metric for Hardware Failures) target moves from 100 FIT to 10 FIT. Hitting those numbers is a diagnostic coverage problem first and an architecture problem second.
• ASIL decomposition under ISO 26262 Part 9 can convert an ASIL-D requirement into two independent ASIL-B(D) requirements, but only when the two implementations are demonstrably independent. The decomposition argument is itself an audit artifact and is where many decomposed safety cases collapse.
• Freedom from interference, also defined in ISO 26262 Part 9, is the discipline that makes a mixed-ASIL software architecture defensible. Without explicit memory, timing, and communication partitioning, the lower-ASIL software can corrupt the higher-ASIL software and the safety case fails.
• LHP's Safety Supervisor Software is one engagement model for an independent ASIL-D safety mechanism on a high-performance vehicle compute platform. The Sonatus ASIL-D Automator Safety Interlock is the published example of that pattern in production-bound work.

The teams that get into trouble on ASIL-D programs are the ones that staffed and scoped them as if ASIL-D were the next dial position above ASIL-B. ASIL-D is not a dial position. It is a different category of safety case, with different evidence requirements, different analysis methods, and different architecture constraints. Programs that underestimate that step pay for it twice. Once when the random-hardware failure analysis returns numbers the architecture cannot support. And again when the audit team asks for the independence argument that the program never produced.

This piece is for engineering leaders deciding how to scope an ASIL-D program and for working engineers building the artifacts that the safety case will rest on. The goal is to make the step from ASIL-B and below to ASIL-D concrete enough that the decisions get made before the analysis exposes them.

Why this matters now

The set of automotive functions that classify ASIL-D has grown across two product trends. The first is electrified powertrain. Inverter shutdown on traction motors, brake-by-wire, and steer-by-wire functions classify ASIL-D under most HARA (Hazard Analysis and Risk Assessment) outcomes because uncontrolled torque or loss of vehicle control combines maximum severity, high exposure, and low controllability. The second is the safety-relevant overlay on top of high-performance perception and planning compute. ADAS interventions, automatic emergency braking, and AV-grade interlocks are increasingly classified ASIL-D when the failure mode is uncommanded actuation or failure to act in a safety-critical scenario.

The implication: more 2026 programs carry at least one ASIL-D requirement than carried one in 2018, and the teams writing those safety cases often built their FuSa muscle on ASIL-B work. The gap shows up first in the random-hardware analysis, then in the architecture, and finally in the safety case argument.

What changes when a requirement steps from ASIL-B to ASIL-D?

Three things change, and they compound.

The diagnostic coverage thresholds change. ISO 26262 Part 5 Annex C defines recommended targets for the Single-Point Fault Metric (SPFM) and the Latent Fault Metric (LFM). At ASIL-B the targets are SPFM ≥ 90% and LFM ≥ 60%. At ASIL-D the targets are SPFM ≥ 99% and LFM ≥ 90%. Practically, that means the hardware safety mechanism that was acceptable at ASIL-B (a single watchdog plus a basic plausibility check) is not enough at ASIL-D. The architecture needs additional diagnostic mechanisms, often a redundant computation path or a dedicated safety microcontroller, to achieve the coverage ISO 26262 recommends.

The independence requirements change. ISO 26262 Part 9 Clause 6 ("Criteria for coexistence of elements") and the freedom-from-interference framework apply at every ASIL, but the bar for what counts as sufficient independence rises with ASIL. At ASIL-D, qualitative arguments ("we partition the tasks") rarely survive an audit. The expected evidence is a documented and analyzed Dependent Failure Analysis (DFA) showing that no single fault can compromise both the safety function and the safety mechanism.

The audit-evidence depth changes. The same artifact (a unit test report, a FMEDA spreadsheet, a code review record) carries different weight at ASIL-D than at ASIL-B. Test coverage targets in ISO 26262 Part 6 step up. Configuration management discipline tightens. The traceability between safety goals, functional safety requirements, technical safety requirements, hardware/software safety requirements, and verification evidence has to actually trace, in both directions, with no broken links.

The takeaway: scoping an ASIL-D program at ASIL-B effort levels is the most common single budget mistake on FuSa programs. The cost difference is not a percentage. It is a different work-breakdown structure.

The hardware metric math, and why it changes the architecture

The random-hardware metrics in ISO 26262 Part 5 are not "nice to hit." They are the technical safety case for hardware. Three numbers do most of the work.

SPFM (Single-Point Fault Metric). The fraction of a hardware element's failure rate that is covered by safety mechanisms against single-point and residual faults. ISO 26262 Part 5 Annex C recommends SPFM ≥ 99% at ASIL-D and ≥ 90% at ASIL-B. The 99% target is where diagnostic coverage must be in the high-99s on the dominant failure modes, which often forces a redundant or diverse architecture.

LFM (Latent Fault Metric). The fraction of failure rate covered against latent multi-point faults. ASIL-D target is ≥ 90%; ASIL-B is ≥ 60%. Hitting 90% LFM is typically a periodic-test discipline (power-on self-test, runtime cyclic test) rather than an architecture change, but it is a discipline the program has to build into its software safety mechanisms from the beginning.

PMHF (Probabilistic Metric for Hardware Failures). The probability per hour of a violation of the safety goal due to random hardware failures of the safety-related hardware. ISO 26262 Part 5 Annex F recommends a target of ≤ 10 FIT (10⁻⁸ per hour) at ASIL-D and ≤ 100 FIT at ASIL-C and ASIL-B. PMHF rolls up SPFM, LFM, and the underlying base failure rates of the components; missing it is usually a base-failure-rate problem (chosen components are not safety-grade) more than a diagnostic coverage problem.

The reason these numbers drive architecture is that hitting SPFM 99% on a single-MCU, single-channel design is generally not feasible for safety-critical actuation paths. Most ASIL-D programs land on a Loop-Locked-Step dual-core MCU, or a primary controller plus an independent safety microcontroller running an ASIL-D safety supervisor, or a redundant sensor and actuator path with cross-checks. Those architecture choices are made before the FMEDA runs, but the FMEDA proves them.

LHP's FMEDA explainer covers the analysis methodology in detail (linked under "FMEDA explainer" below). The point here is that the metric targets are not negotiable; the architecture has to be chosen so that they are reachable.

When is ASIL decomposition worth it?

ASIL decomposition is the most commonly misapplied tool in the ASIL toolkit. ISO 26262 Part 9 Clause 5 allows an ASIL-D requirement to be decomposed into two independent requirements at lower ASILs, with the decomposition rules summarized as:

• ASIL D → ASIL C(D) + ASIL A(D)
• ASIL D → ASIL B(D) + ASIL B(D)
• ASIL D → ASIL D(D) + ASIL QM(D)
• and similar at lower ASILs

The "(D)" notation means the requirement is decomposed from ASIL-D; the inheriting ASIL applies to the implementation, but the decomposition origin must be tracked through the safety case.

The reason teams reach for decomposition is the assumption that "two ASIL-B implementations" cost less than "one ASIL-D implementation." Sometimes that is true. Often it is not. The hidden cost is the independence argument. ISO 26262 Part 9 requires that the two decomposed implementations be independent in their failure modes, which means a documented Dependent Failure Analysis covering hardware faults, software faults, common-cause faults, and cascading faults. Building two genuinely independent ASIL-B paths from scratch (different MCU, different power supply, different software stack, different team if possible) often equals or exceeds the cost of one well-engineered ASIL-D path with a strong safety mechanism.

Decomposition is most defensible when the two paths exist for reasons other than decomposition. A primary control function on a high-performance compute platform plus an independent safety microcontroller for actuator interlock is a real architecture pattern that maps cleanly onto ASIL-D = ASIL-B(D) + ASIL-B(D), because the two channels were independent before the decomposition argument was constructed. Decomposition retrofitted onto a single-channel design rarely survives an audit.

A practical decision filter: if the architecture already has two independent channels for product reasons, decomposition documents what exists. If the architecture is single-channel and the decomposition is being constructed to avoid building an ASIL-D channel, the decomposition cost will exceed the avoided cost.

Independence and freedom from interference

ISO 26262 Part 9 Clause 6 (freedom from interference) is the cross-cutting discipline that makes mixed-ASIL software defensible. It applies to every mixed-ASIL software architecture, but the audit bar at ASIL-D is meaningfully higher than at ASIL-B.

Three interference modes have to be argued explicitly:

Memory. Lower-ASIL software must not be able to corrupt the memory of higher-ASIL software. The mechanism is typically MPU-enforced (Memory Protection Unit) partitioning, with the partitioning configuration itself protected and verified during integration. For ASIL-D, the MPU configuration is a safety-relevant configuration and is subject to the same change-control and verification discipline as the application code.

Timing. Lower-ASIL software must not be able to starve higher-ASIL software of execution time. The mechanism is a partitioned scheduler (time-partitioned in AUTOSAR Classic, often resource-budgeted in AUTOSAR Adaptive) with a runtime monitor that catches budget overruns and triggers a safety reaction.

Communication. Inter-partition communication must be controlled. Shared variables, message queues, and IPC channels have to be analyzed for their interference potential, and the analysis has to back the integrity argument for the higher-ASIL data.

The auditing community treats freedom-from-interference as the most common single weak spot in ASIL-D safety cases on platforms that mix ASIL-D safety functions with ASIL-B or QM application code. The fix is not retroactive analysis at the end of integration. It is partitioning architecture decisions made at the system architecture stage and documented as the program proceeds.

How LHP approaches ASIL-D safety cases

LHP's ASIL-D engagement model has two pieces. The first is a product: LHP's Safety Supervisor Software, an independent safety mechanism that runs on a dedicated safety microcontroller alongside a primary compute platform. The Safety Supervisor architecture is one of the patterns that makes the SPFM 99% target reachable on platforms where the primary compute (often an ADAS or zone controller) cannot itself be qualified to ASIL-D. The "ASIL-D safety supervisor architecture" piece on the LHP blog covers the design pattern.

The second piece is engineering services. The Sonatus ASIL-D Automator Safety Interlock engagement is the published example: LHP delivered the ASIL-D-rated safety supervisor for Sonatus's vehicle automator platform, with full ISO 26262 lifecycle artifacts and the independence and freedom-from-interference arguments behind the safety case. The role-level point is that an LHP functional safety expert with FSCAE (Functional Safety Certified Automotive Engineer) credentials is typically embedded in the program from concept phase through item integration, not parachuted in for safety case authoring at the end.

The pattern that earns the audit is that the ASIL-D evidence is built as the program proceeds, in the program's normal ALM and configuration management tooling, with the safety case derived from it rather than authored on top of it. Programs that try to compose a safety case from incomplete artifacts after technical development is "done" almost always end up rebuilding the artifacts.

What this means for your next program

Three concrete decisions to make at the start of an ASIL-D program rather than the middle.

Decide the channel architecture before the FMEDA runs. Choose dual-core lockstep, primary plus independent safety microcontroller, or redundant channel architecture based on the SPFM 99% target you have to hit. The FMEDA will prove or break the choice; do not let it surprise you.

Decide the decomposition position before the safety requirements are decomposed. If the architecture has natural independent channels, document the decomposition. If it does not, do not invent it. The audit will find it.

Decide the freedom-from-interference partitioning at the architecture stage. MPU configurations, scheduler budgets, and IPC controls are program-level decisions that get codified into the platform. Retrofitting them at integration is more expensive than building them in.

If a current program is sitting on an ASIL-D requirement and the architecture conversation has not happened yet, that conversation is the highest-leverage place to spend the next 30 days of engineering leadership attention. The safety case will eventually rest on the architecture, and the architecture is decided long before the safety case is written.

Frequently asked questions

What is ASIL-D?

ASIL-D is the highest Automotive Safety Integrity Level under ISO 26262 Part 3. ASIL is determined for each hazardous event by combining three factors: Severity (S), Exposure (E), and Controllability (C). ASIL-D applies when the severity is life-threatening or fatal, the exposure is high, and the driver controllability is low or non-existent. Common examples include unintended brake release, unintended steering input, and unintended high-torque application in an electrified powertrain. ASIL-D triggers the most rigorous evidence requirements in the standard: highest diagnostic coverage targets, strongest independence requirements, and deepest verification and validation evidence.

How is ASIL determined?

ASIL determination happens during HARA (Hazard Analysis and Risk Assessment), defined in ISO 26262 Part 3 Clause 6. The HARA team identifies hazardous events at the vehicle level, then assigns S (Severity, S0 to S3), E (Exposure probability, E0 to E4), and C (Controllability, C0 to C3) for each. The combination of S, E, and C maps to an ASIL classification of QM (Quality Management; no FuSa requirements), A, B, C, or D per the ISO 26262 Part 3 Table 4 lookup. HARA outputs become the safety goals at the top of the safety requirements hierarchy, and each safety goal carries its ASIL down through the requirements and the architecture.

What are the ASIL-D random hardware failure thresholds?

ISO 26262 Part 5 recommends three quantitative targets for ASIL-D random hardware failure analysis. Single-Point Fault Metric (SPFM) ≥ 99%, Latent Fault Metric (LFM) ≥ 90%, and Probabilistic Metric for Hardware Failures (PMHF) ≤ 10 FIT (10⁻⁸ per hour). The FMEDA (Failure Mode, Effects, and Diagnostic Analysis) is the analytical method that demonstrates these targets are met. Hitting SPFM 99% generally requires a redundant or diverse hardware architecture; hitting PMHF 10 FIT generally requires safety-grade components with documented base failure rates. The targets are recommendations in the standard, but they function as de facto requirements in audits and supplier qualification.

Can you decompose an ASIL-D requirement?

Yes, under ISO 26262 Part 9 Clause 5. The allowable decompositions for ASIL-D are: ASIL-D = ASIL-C(D) + ASIL-A(D), ASIL-D = ASIL-B(D) + ASIL-B(D), or ASIL-D = ASIL-D(D) + ASIL-QM(D). The "(D)" notation tracks that the decomposed requirement originated from an ASIL-D safety goal. Decomposition is allowed only when the two resulting requirements are independent in their failure modes, which has to be argued through a documented Dependent Failure Analysis. Decomposition is most defensible when the architecture already has independent channels for product reasons; constructing decomposition to avoid building an ASIL-D channel often costs more than the avoided cost.

What is freedom from interference under ISO 26262?

Freedom from interference, defined in ISO 26262 Part 9 Clause 6, is the discipline that allows software of different ASILs to coexist on the same hardware without lower-ASIL software compromising higher-ASIL software. Three interference modes have to be argued explicitly: memory (typically via MPU partitioning), timing (typically via partitioned scheduling and budget monitors), and communication (typically via controlled IPC channels with integrity-checked data). The independence has to be backed by Dependent Failure Analysis and is a frequent weak spot in mixed-ASIL safety cases.

When does LHP recommend ASIL decomposition versus a native ASIL-D architecture?

LHP's working answer is that decomposition follows the architecture; it does not lead it. If a program's architecture already has independent channels for product reasons (a primary compute platform plus an independent safety microcontroller, two redundant sensor-actuator paths, a primary-and-backup actuation strategy), then decomposition documents what exists, and ASIL-D = ASIL-B(D) + ASIL-B(D) is often the most cost-effective decomposition. If the architecture is single-channel and the decomposition is being constructed retroactively to avoid building an ASIL-D path, the engineering cost of constructing genuine independence usually exceeds the cost of building one ASIL-D path with a strong safety mechanism (often LHP's Safety Supervisor Software on a dedicated safety microcontroller). The decision filter is whether the independence is real or invented.

About LHP Engineering Solutions

Since 2001, LHP Engineering Solutions has helped companies deliver technology that must perform as intended, every time. Our clients operate in safety-critical, operation-critical, and mission-critical environments such as on-highway, off-highway, aerospace, defense, and oil & gas, where failure is not an option, and delays cost market share.

LHP helps organizations design, architect, validate, and monitor complex systems. Our global team of engineers supports the development of advanced technologies, including high-voltage power electronics, hybrid and electric powertrain controls, connectivity, and ADAS platforms, enabling OEMs and Tier-1 suppliers to bring next-generation products to market quickly and with confidence.

In compliance-driven industries, LHP uses our model-based systems engineering (MBSE) approach, enhanced through AI, to help companies move quickly while meeting rigorous standards, including functional safety, ASPICE, and cybersecurity. Our teams have helped global technology companies achieve functional safety certification and ASPICE compliance in months rather than years, and established enterprise-grade safety and cybersecurity management systems for leading OEMs.

When organizations must make major technology leaps, such as launching next-generation platforms, future-proofing vehicle architectures, or proving new concepts to secure market-defining programs, LHP delivers the engineering disciplines, solutions, and on-time execution required to succeed.

Because in industries where technology must perform as intended, precision engineering matters.