ASIL decomposition through fault tree analysis

Why decomposition exists at all

ASIL D is expensive. Hardware development to ASIL D requires per-element diagnostic coverage above 99%, latent fault metric above 90%, single-point fault metric above 99%, and PMHF (probabilistic metric for hardware failures) below 10⁻⁸/h. Software development to ASIL D mandates formal methods or at minimum strong static analysis, control-flow monitoring, and an extensive set of techniques in Part 6 Annex C that simply don't apply at lower ASILs. The cost differential between an ASIL B component and an ASIL D component of equivalent function is routinely 3–5×, sometimes more for novel hardware.

Decomposition trades that cost for architectural complexity. The idea: if a single ASIL D safety goal is enforced by two safety mechanisms whose failures are independent, then violating the safety goal requires both mechanisms to fail simultaneously. The combined failure rate is the product of the individual rates, so the two mechanisms can each be developed at a lower ASIL — provided the sum of their ASILs equals the parent.

The decomposition rule (ISO 26262-9:2018 §5.4) is a small table:

The notation "ASIL B(D)" means "developed to ASIL B requirements, retains the integrity context of an ASIL D parent" — the trace back to the original safety goal stays at D for downstream artefacts (audits, change impact analysis), even though the development rigour is B. QM means "quality management" — no functional-safety integrity claim, governed by ISO 9001-style quality processes.

The most common pattern in production vehicles is the second row of ASIL D: ASIL B(D) + ASIL B(D). Two redundant safety mechanisms, each at ASIL B, jointly delivering an ASIL D safety goal. Tier-1 suppliers like it because two ASIL B parts are usually a third the cost of one ASIL D part. OEMs like it because it produces a more diverse, more debuggable architecture. Reviewers like it because the independence claim is auditable through the fault tree.

Step 1The decomposition rule, formally

Suppose the safety goal SG-1 has been classified ASIL D — say "the vehicle shall not unintentionally accelerate". The hazard analysis (HARA) attaches an Exposure / Controllability / Severity classification that yields ASIL D under Part 3 Table 4. Without decomposition, every safety mechanism that contributes to enforcing SG-1 inherits ASIL D in full.

Decomposition rewrites this as: SG-1 is enforced by two safety mechanisms M₁ and M₂, both targeting the same hazard, each developed to ASIL B(D). The safety goal is violated only if both M₁ and M₂ fail. Three conditions all have to hold:

1. Each mechanism, considered alone, is capable of preventing the hazard. Both M₁ and M₂ must be sufficient to enforce SG-1 individually. This rules out partial decompositions like "M₁ handles the high-speed case, M₂ handles the low-speed case" — neither alone covers the whole hazard space, so each is doing different work and the AND structure doesn't apply.
2. The two mechanisms are sufficiently independent. This is the load-bearing condition. ISO 26262 Part 9 §5.4.4 lists the specific independence aspects to consider: shared causes of failure (cascading failures, common-cause failures, common-mode failures) at hardware, software, and execution-environment level. The fault tree is what enumerates and quantifies these aspects.
3. The integrity context (the parenthesised parent ASIL) propagates through the design. Configuration management, change impact analysis, requirements tracing and audit trail all stay at the parent ASIL — only the technical-rigour requirements relax. This is the part most teams forget; it's why an ASIL B(D) Jira ticket is treated differently from an ASIL B ticket on a different project.

Of these, condition 2 is the only one that requires technical analysis to defend. Conditions 1 and 3 are organisational. The whole purpose of running an FTA in the decomposition workflow is to show that condition 2 holds — and that if it doesn't, the decomposition is invalid and the per-mechanism ASIL has to be raised back to the parent.

Step 2The independence requirement, and how FTA proves it

ISO 26262 Part 9 §5.4.4 lists three categories of independence aspect that have to be considered for any decomposition:

1. Random hardware failures — cascading failures (one mechanism's failure causes the other's) and common-cause failures (a shared physical cause fails both at once).
2. Systematic failures — common-mode failures rooted in shared design choices: a shared software component, a shared compiler / toolchain, a shared firmware library, identical implementations of "diverse" code.
3. Shared execution environment — common power supply, common clock, common bus, common RAM, common operating system, common physical enclosure subject to the same EMI / vibration / temperature.

The fault tree is the formal artefact that maps each of these aspects to a structural property of the cut sets. The decomposition stands if and only if the fault tree's minimal cut sets satisfy three conditions:

1. No minimal cut set has order 1. Any single-event cut is a single point of failure that defeats the AND structure entirely.
2. No basic event appears in both mechanism branches. A shared event puts itself at the root of a cascading-failure cut set.
3. No β-factor CCF group spans both branches. Any group that does adds a CCF basic event sitting structurally above both branches at order 1.

Here is the decomposed tree shape that should appear after Step 2:

SG-1 violated
       │
       ▼
      AND
     /   \
    M1   M2     ← two safety mechanisms, ASIL B(D) each
   / \   / \
  …   … …   …  ← branch sub-trees, no shared events

And here are the three patterns that make the decomposition fail in practice. Each one collapses the AND gate to an effective OR by introducing a path that bypasses the redundancy:

Failure pattern 1 — cascading failure

M₁'s actuator overdrives a shared 12 V bus. The bus voltage transient takes out M₂'s controller. In the fault tree, the basic event "bus over-voltage" is a child of an event in M₁'s branch and a parent of an event in M₂'s branch. Once the algebra reduces the tree, the cut set {bus over-voltage} (order 1) appears in the minimal cut set list. The decomposition fails — both mechanisms can be killed by a single hardware event.

Failure pattern 2 — common-cause failure

Both mechanisms use sensors from the same vendor batch with the same calibration drift. Modelled as a CCF group with β = 0.05, the basic event CCFshared-batch is structurally above both mechanism branches and produces a single-event cut set at order 1. The decomposition is degraded by exactly β: the effective parent ASIL of the safety goal is now somewhere between B and D, and the per-mechanism ASIL has to be raised. Article 5 covers the modelling math.

Failure pattern 3 — common-mode failure

The "diverse" software in M₁ and M₂ was written by the same team using the same coding style and the same standard library. A bug in the shared memcpy wrapper trips both. This is the hardest pattern to model — there is no shared basic event in the fault tree because the two mechanisms are distinct code paths; the failure mode lives in a meta-model of "shared design choices". ISO 26262 Part 6 §7.4.13 gives the qualitative argument structure (diversity of teams, languages, toolchains, design philosophies); the FTA gets the residual common-mode probability as an explicit basic event placed above both branches with a defended probability.

The systematic way to run the independence check is to expand the fault tree, run the cut-set analysis, and inspect the order-1 minimal cut sets. If there are none, and no basic event appears in both branches, the decomposition holds. If there are any, the work is to identify which independence aspect they violate and either redesign the mechanism (eliminate the shared cause) or accept the higher-ASIL development burden (no decomposition).

Step 3Worked AEB ASIL D decomposition

To make the workflow concrete, take Automatic Emergency Braking — specifically the safety goal SG-AEB: "The vehicle shall apply emergency braking when a collision with a stationary obstacle is imminent at speeds between 30 and 130 km/h." A standard HARA classification (high speed → S3 severity, no driver override at typical reaction times → C3 controllability, frequently encountered → E4 exposure) places this at ASIL D.

Target the canonical decomposition: ASIL D = ASIL B(D) + ASIL B(D), with two redundant detection-plus-actuation chains. The architecture sketch:

SG-AEB violated (no brake when obstacle imminent)
              │
              ▼
             AND
            /   \
   M1: PRIMARY   M2: SECONDARY
    (ASIL B(D))   (ASIL B(D))
    │             │
    Radar         LiDAR
    Camera        Independent fusion ECU
    Fusion ECU    Independent controller
    Primary ctrl  Secondary brake circuit
    Brake act #1  Brake act #2

First-pass tree — and the SPOF that wrecks it

Every Tier-1's first-cut AEB architecture has a single brake actuator. Production cars have one set of brake calipers per wheel; doubling the actuator means doubling the hydraulic system. So the naive decomposition tree has both M₁ and M₂ issuing brake commands to the same brake controller, and that controller becomes a basic event in both mechanism branches. Cut-set analysis on the naive tree:

Minimal cut sets (naive, single brake actuator):
  {brake-actuator-fail}                            ← order 1, SPOF
  {radar-fail, LiDAR-fail}                         ← order 2, sensor diversity
  {camera-fail, LiDAR-fail}                        ← order 2
  {fusion-ECU-fail, secondary-fusion-fail}         ← order 2
  {primary-controller-fail, secondary-controller-fail}  ← order 2
  ...

The order-1 cut {brake-actuator-fail} means the decomposition is invalid as drawn — a single brake-actuator failure produces SG-AEB violation regardless of how independent the upstream chains are. The whole architecture has to be revised before the decomposition stands: either a dual-redundant brake actuator (expensive), an actuator with full ASIL D diagnostic coverage that's then claimed at ASIL D outside the decomposition (the more common compromise), or a fail-safe actuator design where any internal fault produces brake application (the safest direction).

Second-pass tree — refined architecture

Take the dual-redundant-actuator path for the worked example. M₁ drives a primary brake circuit; M₂ drives an independent backup hydraulic / electromechanical actuator (Continental's MK C2 plus a secondary axle-level actuator is the production reference). The cut-set list becomes:

Every cut set has order 2 with one event in each mechanism branch. Independence condition (i) and (ii) from Step 2 hold structurally. Condition (iii) — no β-factor CCF group spanning both branches — is the next thing to check.

Quantification — the PMHF check

ASIL D requires PMHF ≤ 10⁻⁸ per hour. With the refined architecture, assume each mechanism has a dangerous-undetected failure rate of λ_DU = 10⁻⁷/h (typical ASIL B target for a redundant chain). For a two-channel 1-out-of-2 system, the PMHF formula from ISO 26262 Part 5 §9.4.2.2, with β-factor CCF (vehicle lifetime T = 10⁴ h, β = 0.05):

PMHF ≈ β · λDU + (1 − β) · λDU² · T / 2
     = 0.05 × 10⁻⁷ + 0.95 × (10⁻⁷)² × 10⁴ / 2
     = 5.0×10⁻⁹ + 4.8×10⁻¹¹
     ≈ 5.05×10⁻⁹ /h

5×10⁻⁹/h ≤ 10⁻⁸/h. The decomposition meets ASIL D — but only by a factor of two, and the β·λ_DU term alone consumes half the entire ASIL D budget. The independent-failures term is a rounding error by comparison.

Run the same calculation at three β values to see the sensitivity:

The decomposition is only valid when β < 0.10. Above that, the CCF event alone violates the ASIL D PMHF target, regardless of how good the individual mechanisms are. This is what makes the independence demonstration the central deliverable of a decomposition safety case — without it, the whole architecture is paper.

The design conclusions, ranked by leverage:

• Drive β as low as feasible. Diverse vendors for the two mechanism's components (radar from Bosch, LiDAR from Velodyne; primary controller on Cortex-M7, secondary on PowerPC), separated power supplies, separated communication buses, separated physical mounting, separated thermal zones. Each independence aspect knocked off the shared-cause list reduces β.
• Eliminate the shared brake actuator (or buy diagnostic coverage on it). A high-DC actuator at ASIL D is roughly the same cost as two independent actuators at ASIL B. Either path closes the SPOF. Many production AEBs take the high-DC route because the brake hydraulics are already there.
• Don't bother improving the per-mechanism λ_DU. Once β·λ_DU dominates PMHF (which happens at any β ≥ 0.01 with λ_DU ≈ 10⁻⁷/h), pushing each mechanism from ASIL B to ASIL B+ (using more rigorous techniques) doesn't shift the answer. The independence work is what moves PMHF, not the per-channel reliability.

Step 4How decomposition actually shows up in production

Outside textbook examples, the symmetric ASIL B(D) + ASIL B(D) split is the minority pattern. Four production patterns are more common, each with its own FTA structure:

Whichever pattern is used, the FTA artefact is the same shape: a top-event-violation tree where every minimal cut set has order ≥ 2 (or order 1 with a defended ASIL D basic event), no basic event appears in two branches, and CCF groups are explicitly declared with β-factor values that can be defended.

Five pitfalls a reviewer will catch

• "Diverse" code from the same team. Two implementations of "diverse" software written by the same engineers, in the same language, under the same coding style produce correlated bugs. ISO 26262 Part 6 §7.4.13 lists the diversity dimensions: language, toolchain, design philosophy, team, review process. A decomposition relying on software diversity that fails any one of these has a residual common-mode failure rate that has to be quantified explicitly — not assumed away.
• Shared toolchain treated as independence. Two ECUs from different vendors compiled with the same GCC version, linked against the same AUTOSAR BSW, deployed via the same flash-loader: the shared toolchain is a common-mode source. The classic example is the GCC pre-2018 ICE-bug-class that produced wrong code for any C++ project compiled with -O2; every "diverse" code path under that compiler shared the bug.
• Claiming QM(D) for code originally developed at QM. ASIL B(D) + QM(D) decomposition is allowed by the rule but requires the QM(D) component to have integrity-context propagation (config-mgmt, change-impact, audit at ASIL D). If the QM code was developed under ISO 9001 with no functional-safety integrity context, it doesn't qualify — even though the words "QM" line up.
• Decomposition tree not maintained as design changes. A late-stage architecture change (consolidating two ECUs onto one SoC, switching from two power supplies to one, replacing a dedicated CAN bus with shared Ethernet) can collapse a previously valid decomposition. The FTA has to be re-run on every such change; in practice this is the change-impact-analysis line item that gets forgotten until audit.
• β-factor pulled from textbook tables without justification. Reviewers don't accept "β = 0.05 from IEC 61508 Annex D" without the Annex D scoring sheet filled in — separation, diversity, complexity, environment scored row by row. Article 5 covers the scoring detail. A decomposition safety case with a bare β value and no defence is the most common audit finding in practice.

Where to go next

• Build the decomposition tree. Open FTA Studio — the AEB template ships as one of the eight industry trees, with the decomposition AND-gate already in place. Adjust the basic-event probabilities to your own component data.
• Quantify the β-factor properly. Article 5 covers the IEC 61508-6 Annex D scoring sheet that ISO 26262 inherits. Fill it row by row; the resulting β is what gets reviewed.
• Cross-link the importance ranking. Article 2 shows how F-V and RAW expose the CCF event as the dominant contributor — the same conclusion as the PMHF table in Step 3, in a form that scales to larger trees.
• For the next ASIL D-related guide, the hardware random-failure metrics (PMHF, SPFM, LFM) deserve their own treatment — especially the boundary cases where Part 5 Table 5 thresholds are tight. That's coming as Article 7.