ASIL Decomposition
About 1705 wordsAbout 6 min
2026-03-25
What Is ASIL Decomposition?
ASIL decomposition is the technique of splitting a safety requirement with a given ASIL into two (or more) redundant requirements with lower, combined ASILs — provided that the implementations of those requirements are sufficiently independent.
The rationale is that two independent mechanisms with lower individual integrity can together provide the same risk reduction as one highly integrated mechanism. ISO 26262 Part 9 (clause 5.4) defines the normative rules for ASIL decomposition.
Core principle: If two elements are independent, a common-cause failure must be excluded. The probability that both fail simultaneously is the product of their individual failure probabilities → the combined mechanism achieves the same ASIL as the original single-element requirement.
Decomposition Notation
ISO 26262 uses the following notation:
ASIL D ──────── decomposes to ──────► ASIL B(D) + ASIL B(D)
└─────┘ └─────┘
Part A Part B
(residual B) (redundant B)
The notation "ASIL B(D)" means:
- The element carries ASIL B process requirements
- The original requirement was ASIL D before decomposition
- Both parts together must satisfy the ASIL D safety goalThe parenthetical (D) is critical: it records the original ASIL and prevents "ASIL washing" — improperly downgrading requirements.
Valid Decomposition Combinations
ISO 26262 Part 9, Table 4 defines the permitted combinations:
| Original ASIL | Part A | Part B |
|---|---|---|
| ASIL D | ASIL D | QM — only if full independence guaranteed |
| ASIL D | ASIL C | ASIL A |
| ASIL D | ASIL B | ASIL B |
| ASIL C | ASIL C | QM |
| ASIL C | ASIL B | ASIL A |
| ASIL C | ASIL A | ASIL B |
| ASIL B | ASIL B | QM |
| ASIL B | ASIL A | ASIL A |
| ASIL A | ASIL A | QM |
The most commonly applied decompositions in practice:
- ASIL D → ASIL B(D) + ASIL B(D): Two independent ASIL B channels
- ASIL C → ASIL B(C) + ASIL A(C): Common for sensor/actuator monitoring structures
- ASIL D → ASIL C(D) + ASIL A(D): Asymmetric decomposition
Independence Requirements
Decomposition is only valid if the two implementing elements satisfy the independence criterion specified in ISO 26262 Part 9 clause 5.4.5.
Freedom from Interference (FFI)
The two elements must not be able to corrupt each other. Without FFI, a single fault in element A could cause element B to also fail — eliminating the redundancy entirely.
Software freedom from interference:
Sources of SW interference that must be excluded:
├── Shared memory: Element A overwrites Element B's data
├── Shared stack: Stack overflow in A corrupts B's stack frame
├── Shared execution time: A starves B in the scheduler
├── Shared I/O: A's writes to a hardware register corrupt B's peripheral state
└── Shared OS resources: A's deadlock blocks B's mutex
Mechanisms to achieve FFI in SW:
├── Memory Protection Unit (MPU): hardware enforcement of memory region access
├── AUTOSAR OS: separate OS applications with MPU-backed partition isolation
├── AUTOSAR MultiCore: separate cores running separate partitions
├── Hypervisor: Type-1 hypervisor with hardware-backed isolation
└── Separate ECUs: strongest independence — no shared siliconHardware freedom from interference:
Sources of HW interference that must be excluded:
├── Shared power supply: single voltage fault kills both channels
├── Shared ground: ground bounce causes both channels to malfunction
├── Shared clock: crystal fails → both channels stop
├── Shared bus: CAN/SPI/I2C fault readable by both channels
└── Thermal coupling: both components on same PCB area fail together
Mechanisms for HW FFI:
├── Separate power supply rails with independent regulators
├── Separate PCB layout areas for channel A and channel B
├── Separate clock sources
└── Separate ECU hardware (strongest independence)Independence vs. Diversity
Independence means freedom from common-cause failure. Diversity means implementing the same function in two different ways to reduce systematic common-cause failures (design defects shared by identical implementations):
| Technique | Type | Addresses |
|---|---|---|
| Memory partitioning (MPU) | Independence mechanism | Random HW failure interference |
| Separate MCU die | Independence mechanism | Random HW failure coupling |
| Different algorithms for same function | Diversity | Systematic design faults |
| Different compilers | Diversity | Compiler bug as systematic fault |
| Different programming language (C vs. Ada) | Diversity | Language-specific systematic faults |
| Different software supplier for channel B | Diversity + Independence | Systematic faults in SW development process |
Dependent Failure Analysis (DFA)
ISO 26262 Part 9 clause 7 requires a Dependent Failure Analysis (DFA) to confirm that independence claims between decomposed elements are valid.
A DFA identifies:
- Initiators: potential sources of dependent failures (shared resources, coupling elements)
- Propagation paths: how the initiator affects both elements
- Countermeasures: existing or planned mechanisms that prevent propagation
DFA Worksheet Example (Partial)
Item: EPS ECU with ASIL D → ASIL B + ASIL B decomposition
(Main CPU: function channel; Safety Monitor MCU: monitoring channel)
Initiator ID: DFA-03
Initiator: 12V supply rail feeds both Main CPU and Safety MCU
Coupling: Both processors share VSYS_12V → VCORE_1.25V from same LDO
Propagation: LDO failure → both processors lose power simultaneously
Effect: Both channels fail → no monitoring → safety goal SG-01 violated
Countermeasure: Separate LDO per channel;
Independent TVS protection per power rail;
Power-on-reset detection per channel independent
Residual risk: LDO failure in one channel → safe state → no simultaneous failure
DFA verdict: Independence MAINTAINED with countermeasure implemented
Reference: Schematic Rev B, Power Section, nodes VCC_MCU1 and VCC_MCU2ASIL Decomposition in Practice
Common Architectural Patterns
1. Dual-Channel Architecture (Most Common for ASIL D)
Input ──────┬──────── Channel A: Main Execution (ASIL B(D))
│ SW: Control algorithm, setpoint calculation
│ HW: Main MCU, RAM, Flash
│ │
│ ▼
│ Voter / Comparison logic
│ ▲
│ │
└──────── Channel B: Safety Monitor (ASIL B(D))
SW: Independent plausibility check, range check
HW: Safety MCU (e.g., Aurix TC3xx LS "lock-step" core)
↑
Uses different code path, same requirement2. Lock-Step Core (ASIL D without explicit full decomposition)
Modern MCUs like the Infineon Aurix TC3xx and NXP S32K families implement lock-step cores:
MCU with Lock-Step Architecture:
┌──────────────────────────────────────────────────┐
│ Core 0 (Master) Core 0 LS (Comparator) │
│ ┌──────────┐ ┌──────────┐ │
│ │ Execute │◄───────►│ Execute │ │
│ │ same │ │ same │ │
│ │ code │ │ code │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ └──────► Compare ◄───┘ │
│ (every cycle) │
│ If mismatch → NMI → safe state │
└──────────────────────────────────────────────────┘
Lock-step achieves ASIL D single-point-fault detection because:
- The Hamming Distance between the two instruction streams is maintained
- Permanent faults (stuck-at, bridging faults) are detected within one clock cycle
- Transient faults (soft errors from cosmic rays) detected before state is committedLock-step does NOT decompose the ASIL — it achieves ASIL D on a single core by adding the lock-step comparator, which provides sufficient single-point fault detection coverage for ASIL D PMHF targets.
3. Diverse Redundancy (Highest Independence, ASIL D)
System A System B
────────── ──────────
MCU: Renesas RH850 MCU: Infineon TC3xx
SW: C, developed by Team A SW: Ada, developed by Team B
Algorithm: PID with LQR Algorithm: Fuzzy logic with table lookup
Tool: Green Hills MULTI Tool: TASKING Compiler
│ │
└──────────── Arbiter ──────────┘
(vote / crosscheck)
│
▼
Actuator OutputDiverse redundancy maximizes protection against systematic faults (developer-introduced bugs that would appear in both channels if they used the same code).
Co-Existence of Different ASILs on the Same Platform
When ASIL D and QM software run on the same MCU, freedom from interference must be proved. This is the co-existence problem:
Problem:
ASIL D safety function in task T_SAFETY
QM infotainment mirror feature in task T_QM
Both running on same OS
If T_QM has a buffer overflow:
→ Corrupts T_SAFETY's memory
→ T_SAFETY produces incorrect output
→ ASIL D violation — QM code caused ASIL D failureSolutions for ASIL / QM Co-Existence
| Solution | Mechanism | ASIL Achieved |
|---|---|---|
| Memory Protection Unit (MPU) | Hardware enforces read/write access per task | ASIL B sufficient with MPU |
| AUTOSAR OS with OS applications | Partitioned OS applications with MPU hooks | ASIL D possible |
| Hypervisor | Full VM separation: ASIL VM + QM VM | ASIL D |
| Separate cores (MultiCore MCU) | Different cores → no shared execution | ASIL D |
| Separate physical ECUs | No shared silicon | ASIL D, strongest independence |
AUTOSAR OS Application Partitioning
OS Application "Safety_Partition" OS Application "QM_Partition"
ASIL D QM
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ Runnable: TorqueSafetyCheck │ │ Runnable: BluetoothStack │
│ Runnable: VehicleSpeedCheck │ │ Runnable: UsbFileSystem │
│ TRUSTED (kernel mode) │ │ NON-TRUSTED (user mode) │
└─────────────────────────────┘ └─────────────────────────────┘
│ │
│ MPU enforces region separation │
└────────────────────┬────────────────────┘
│
OS Kernel (ASIL D)
(context switch saves MPU config)If the QM partition violates its memory region, the MPU generates a MemoryFault exception → OS reports to the safety monitor → system enters safe state. The ASIL D partition was never corrupted.
ASIL Decomposition and ASPICE Process Requirements
When ASIL decomposition is applied, both resulting elements carry their individual ASIL process requirements:
Original Requirement: SG-01 ASIL D
↓ decompose
Element A: FSR-01a ASIL C(D) → SW development must satisfy ASIL C process requirements
Element B: FSR-01b ASIL A(D) → SW development must satisfy ASIL A process requirements
ASIL C process requirements include:
├── SW coding guidelines (MISRA C compliant, ASIL C table)
├── SW unit testing: branch coverage + MC/DC (ASIL C: recommended/highly recommended)
├── SW architectural design: modular, no dynamic memory, no recursion
└── Review methods: formal technical review for SRS, architecture, detailed design
ASIL A process requirements include (subset of ASIL C):
├── SW coding guidelines (MISRA C, ASIL A table)
├── SW unit testing: statement coverage
└── Review: peer review sufficientCommon Mistakes in ASIL Decomposition
Mistake 1: ASIL Washing
ASIL washing occurs when decomposition is applied without genuine independence, resulting in requirements with a lower ASIL label that are in fact not independent.
Example of ASIL washing:
Safety goal SG-01: ASIL D
Decomposed to:
Element A: ASIL B(D) — Main function in software module A
Element B: ASIL B(D) — "Monitoring" in software module B (in the same task,
sharing the same stack, compiled with the same tool,
on the same memory region)
Problem: Module A and Module B share all resources. A fault in A affects B.
This is NOT a valid decomposition — independence is not achieved.
Correct label: SG-01 cannot be decomposed this way → must remain ASIL DMistake 2: Not Recording the Original ASIL
Writing "SWR-089: ASIL B" when the derivation was from a decomposed "ASIL D" safety goal means the full context is lost. Assessors, safety managers, and auditors cannot verify the decomposition chain without the (D) notation.
Mistake 3: Decomposing Without DFA
Decomposition without DFA means independence is claimed but not verified. The DFA is normatively required by ISO 26262 Part 9. Finding DFA absent is a Major non-conformance in a functional safety audit.
Mistake 4: Assuming Architectural Diversity Is Sufficient for Random HW Failures
Using two different algorithms in software (diversity) addresses systematic faults. It does not address random hardware failures caused by silicon defects. PMHF targets still require quantitative hardware fault metrics (PMHF calculation, FMEDA) regardless of software diversity.