A single ASIL D requirement doesn't have to be implemented by one ASIL D element. ISO 26262 lets teams decompose it across independent, lower-ASIL channels — but only if the independence is real, not assumed.
Our note on ISO 26262 functional safety basics covers how ASIL classification (A through D, plus QM) sets the rigor a given function needs. What it doesn't cover is one of the standard's most useful — and most commonly misapplied — mechanisms for managing that rigor: ASIL decomposition, addressed in ISO 26262-9. Decomposition lets a team implement a high-ASIL requirement using elements that individually carry a lower ASIL, provided the decomposition is structured correctly. Done well, it can meaningfully reduce the development and verification burden on parts of a system; done carelessly, it produces an architecture that looks compliant on paper but doesn't actually deliver the safety integrity the original requirement demanded. This is a description of how the mechanism works structurally — applying it to a specific architecture always needs sign-off from a qualified functional safety assessor. Teams building toward a first formal safety case, rather than already deep in one, may also find our note on staying ASIL-ready before a safety case exists useful context for when decomposition decisions like these actually get made.
Decomposition works by allocating a safety requirement to two or more redundant elements such that no single fault in any one element causes the safety goal to be violated. The classic example is splitting an ASIL D requirement into ASIL B(D) + ASIL B(D) — two independent elements, each developed to ASIL B rigor, whose combined behavior still satisfies the original ASIL D safety goal. The "(D)" notation matters: it signals the decomposed requirement still traces back to an ASIL D safety goal, and it's not being quietly downgraded to ASIL B for the whole system. This isn't a way to avoid the discipline a high ASIL demands — it's a way to distribute where that discipline is concentrated, based on genuine architectural redundancy.
The standard is explicit that decomposition is only valid if the redundant elements are independent with respect to the failure modes being mitigated. That independence has to hold across several dimensions at once: no shared power rail that can take out both channels at once, no shared clock or reset line, no single microcontroller running both "independent" software paths as separate tasks (a bug in the RTOS scheduler, or a stack overflow in one task, can compromise both), and no shared sensor feeding both decision paths if the failure mode being guarded against is a bad sensor reading. Teams new to decomposition often build a design that looks like two channels on a block diagram but shares more physical or software infrastructure than the diagram shows — at which point a common-cause failure can take out both "independent" paths simultaneously, and the decomposition doesn't hold up under a rigorous common cause failure analysis.
Decomposition tends to earn its complexity in a few recurring patterns: a monitoring/actuating pair, where a lower-ASIL actuation path is watched by an independent lower-ASIL monitor that can force a safe state if the actuator misbehaves, together satisfying a higher ASIL safety goal than either channel alone; diverse redundancy, where two channels use different hardware, different suppliers, or even different physical measurement principles (e.g., two different sensor technologies measuring the same physical quantity) specifically to avoid shared systematic faults; and voting architectures, where three or more channels' outputs are compared and a disagreement triggers a defined fallback. In each case, the payoff isn't just lower documentation burden per channel — a genuinely independent architecture is also more robust in the field, because it doesn't rely on any single component being perfect. Fleet-scale systems that depend on this kind of redundancy in the field — for example the sensor fusion tradeoffs covered in our note on fleet telematics system design — benefit from the same independence discipline, even outside a formal safety-goal context.
The failure pattern worth naming explicitly: a team under schedule pressure decomposes a requirement on paper to reduce the ASIL rigor two teams need to carry, without actually re-architecting for physical and software independence. The result satisfies an auditor skimming a requirements matrix but not a rigorous dependent failure analysis, and worse, doesn't actually reduce risk in the field the way the safety case claims. Decomposition has to be a genuine architectural decision made early — choosing separate microcontrollers, separate power domains, separate sensor technologies where warranted — not a retrofit applied to an existing single-channel design to make the paperwork easier.
ASIL decomposition is a powerful tool for managing the cost of high-integrity requirements, but it only works if the independence it depends on is designed in from the architecture stage, verified with a real common cause and dependent failure analysis, and not treated as a documentation shortcut. We design redundant and fail-safe embedded architectures with that discipline built in from the start — see our firmware work and embedded hardware work for how this fits into a full engagement. Update mechanisms that touch decomposed, safety-relevant channels have their own constraints too, which we cover in our note on automotive OTA updates. This is the kind of redundant-architecture discipline we bring to automotive IoT development engagements.
