ASIL Decomposition: When to Use It and How to Do It Correctly

What Is ASIL Decomposition?

ASIL decomposition is a mechanism in ISO 26262 that lets you split a single high-ASIL safety requirement into two (or more) lower-ASIL requirements — provided the implementations of those requirements are sufficiently independent.

The classic split: ASIL D = ASIL B + ASIL B(D) or ASIL D = ASIL A + ASIL C(D).

The number in parentheses — B(D) or C(D) — means "this requirement has ASIL B rigor, but it was derived from an ASIL D safety goal." The original ASIL context is never lost; it's just split.

Why Would You Decompose?

Two main reasons:

1. Cost. Developing software to ASIL D requires the most stringent processes: formal methods, MC/DC coverage, extensive verification. If you can split a requirement across two independent software partitions (each needing only ASIL B rigor), your overall development effort may be lower.

2. Architecture. Sometimes your system naturally has redundant paths — a primary path and a monitor. Formalizing that as ASIL decomposition makes the architecture explicit and auditable.

The Independence Requirement

ISO 26262-9 Clause 6 is the governing text. Independence means the two implementations must not share a common cause of failure. Specifically:

• Hardware independence: The two channels must not share the same hardware elements (or if they do, you must demonstrate freedom from interference).
• Software independence: The software must be developed separately enough that a design error in one doesn't propagate to the other.
• No shared memory or shared execution context unless you can prove freedom from interference with diagnostic coverage arguments.

If your "two independent channels" both run on the same microcontroller core, share the same OS scheduler, and were written by the same developer using the same code base — you don't have independence.

ASIL Decomposition Table (ISO 26262-9 Table 5)

Note: You cannot decompose ASIL A (it's already the minimum ASIL).

Common Decomposition Mistakes

• Decomposing without specifying the independence rationale — the most common audit finding
• Assuming two software partitions on the same processor are independent — without a freedom-from-interference argument, they are not
• Losing the (D) suffix in downstream requirements — every derived requirement must carry its original ASIL context in the notation

How ISO WIZ Handles Decomposition

ISO WIZ tracks ASIL decomposition natively. When you create a decomposed safety requirement, the platform enforces valid split combinations per ISO 26262-9 Table 5, requires an independence rationale document before marking the decomposition compliant, and propagates ASIL(x) notation to all derived hardware and software requirements. The cross-standard traceability engine also checks whether your ASIL decomposition assumptions are consistent with your cybersecurity architecture — if a cyberattack can compromise one channel of your decomposed system, the independence argument needs to address that.