ASIL Decomposition in ISO 26262: Rules, Examples & Best Practices

Hello, automotive safety engineers and system architects! ASIL decomposition is one of the most powerful – and most misunderstood – concepts in ISO 26262. When applied correctly, it can significantly reduce development cost and complexity by allowing safety-critical functions to be implemented using elements developed to lower ASIL methods. When applied incorrectly, it creates a false sense of safety while introducing architectural complexity and dependent failure risks.

In this comprehensive guide at PiEmbSysTech, we will explain exactly what ASIL decomposition is, the complete set of valid decomposition rules from ISO 26262 Part 9, the (D) suffix notation and what it implies for every downstream development activity, fully worked examples for EPS and AEB systems, the critical role of DFA, what does NOT change after decomposition, common misconceptions, and practical best practices. Let us begin.

1. What is ASIL Decomposition?

ISO 26262 Part 9, Clause 5 defines ASIL decomposition as: “Apportioning of redundant safety requirements to elements, with sufficient independence, contributing to the same safety goal, with the objective of reducing the ASIL of the redundant safety requirements that are allocated to the corresponding elements.”

In practical terms, ASIL decomposition takes a safety requirement at a given ASIL and splits it into two (or more) redundant safety requirements, each allocated to a sufficiently independent architectural element. The individual elements can then be developed to a lower ASIL, while the overall safety goal is maintained at the original ASIL through the combination of the redundant paths.

The fundamental principle is simple: if two independent channels each contribute to preventing a safety goal violation, and either channel alone is sufficient to maintain safety, then each channel can be developed to a lower level of rigor – because both channels must fail simultaneously for the safety goal to be violated. This is the essence of safety through redundancy.

2. Why Decompose? – The Cost and Complexity Motivation

The primary motivation for ASIL decomposition is cost reduction. Developing a system to ASIL D is significantly more expensive than ASIL B – ASIL D requires MC/DC software coverage, 99% SPFM, 10 FIT PMHF, formal verification methods, and I3-level assessment. If an ASIL D requirement can be decomposed into two ASIL B(D) requirements on independent channels, each channel is developed using ASIL B methods (branch coverage, 90% SPFM, less formal notation) – which can be 40-60% less expensive per channel than ASIL D development.

Additional motivations include enabling the use of existing components not qualified to the highest ASIL (e.g., using an ASIL B qualified MCU in one channel of an ASIL D decomposed system), improving system availability through redundancy (if one channel fails, the other can maintain operation), and enabling mixed-criticality architectures where safety and non-safety functions coexist.

3. When Can ASIL Decomposition Be Applied?

ASIL decomposition can be applied during the concept phase or development phase – specifically to functional safety requirements (FSRs), technical safety requirements (TSRs), hardware safety requirements, or software safety requirements. It can be applied at the system level, the hardware level, or the software level.

Critically, ASIL decomposition applies to safety requirements only – not to safety goals. The safety goals retain their original ASIL throughout. Only the requirements derived from the safety goals can be decomposed.

Two prerequisites must be met for valid decomposition: the decomposed requirements must be allocated to sufficiently independent elements (demonstrated through DFA), and each decomposed requirement must independently achieve the original safety requirement (each channel alone must be sufficient to prevent the safety goal violation).

4. The Complete Decomposition Rules Table

ISO 26262 Part 9, Table 2 defines the valid two-element decomposition combinations:

Original ASIL	Element 1	Element 2
ASIL D	ASIL D(D)	QM(D)
	ASIL C(D)	ASIL A(D)
	ASIL B(D)	ASIL B(D)
ASIL C	ASIL C(C)	QM(C)
	ASIL B(C)	ASIL A(C)
ASIL B	ASIL B(B)	QM(B)
ASIL A	ASIL A(A)	QM(A)

Key rule: The “sum” of the decomposed ASILs must equal or exceed the original ASIL, using the ordering QM < A < B < C < D. The most common and cost-effective decomposition for ASIL D is ASIL B(D) + ASIL B(D) – two symmetric channels each developed to ASIL B methods.

5. Three-Element Decomposition

ISO 26262 also permits decomposition across three elements. For ASIL D, valid three-element decompositions include: ASIL B(D) + ASIL A(D) + ASIL A(D), ASIL A(D) + ASIL A(D) + ASIL B(D), and QM(D) + ASIL B(D) + ASIL B(D). Three-element decomposition is less common in practice because it requires demonstrating independence between three elements (not just two), which significantly increases the DFA effort. It also increases the architectural complexity of the system. Three-element decomposition is most commonly seen when a voter or comparator architecture is used with three redundant channels.

6. The (D) Suffix Notation – What It Really Means

The notation ASIL X(Y) means: “This element is developed to ASIL X methods, as part of a decomposition from original ASIL Y.” The letter before the parenthesis (X) determines the development methods. The letter inside the parenthesis (Y) is the original ASIL and determines several critical aspects that do NOT change after decomposition. Understanding this notation is essential to avoid the most common ASIL decomposition mistakes.

For example, ASIL B(D) means: this element is developed using ASIL B development methods (branch coverage, semi-formal notation, 90% SPFM), but it is part of an ASIL D decomposition. The “(D)” carries important implications described in the next section.

7. What Does NOT Change After Decomposition

This is where most engineers make critical mistakes. After ASIL decomposition, the following aspects remain at the original (pre-decomposition) ASIL:

1. Confirmation measures (reviews, audits, assessments): The independence level for functional safety assessment is determined by the original ASIL. An ASIL B(D) element requires ASIL D-level assessment independence (I2 or I3). You cannot use ASIL B assessment independence just because the development methods are ASIL B.

2. Hardware metric targets (SPFM, LFM, PMHF): The hardware metric targets at the item level remain at the original ASIL. An ASIL D safety goal still requires 99% SPFM, 90% LFM, and <10 FIT PMHF at the system level – even though individual elements are developed to ASIL B methods. The metrics are evaluated for the complete system architecture, not per-element.

3. DFA requirements: The Dependent Failure Analysis must demonstrate sufficient independence between the decomposed elements – evaluated at the original ASIL rigor.

4. Safety goal ASIL: The safety goal itself never changes. It retains its original ASIL from the HARA forever.

5. Integration and test requirements: The integration testing of the decomposed elements together is performed at the original ASIL level.

8. What DOES Change After Decomposition

After decomposition, the following aspects use the decomposed (lower) ASIL:

1. Development methods: The software and hardware development methods (coding standards, design notation formality, verification methods) for each element follow the decomposed ASIL. An ASIL B(D) software element uses ASIL B software development methods from Part 6 – branch coverage instead of MC/DC, less formal notation requirements.

2. Structural coverage requirements: Software structural coverage targets follow the decomposed ASIL. ASIL B(D) requires branch coverage (highly recommended), not MC/DC.

3. Design notation formality: The formality of architectural and design notation follows the decomposed ASIL.

9. The Independence Requirement – Why DFA is Mandatory

ASIL decomposition is only valid if the decomposed elements are sufficiently independent. If a single failure or common cause can simultaneously affect both decomposed elements, the redundancy is defeated and the decomposition is invalid. ISO 26262 Part 9, Clause 7 requires a Dependent Failure Analysis (DFA) to demonstrate this independence.

The DFA must evaluate three categories of dependent failures:

Common Cause Failures (CCF): A single root cause that can trigger failures in multiple elements simultaneously. Examples: shared power supply failure, shared clock source failure, EMC disturbance affecting all electronics, temperature exceedance affecting all components in the same enclosure.

Cascading Failures: A failure in one element that propagates to cause a failure in another element. Examples: a short circuit in Element A that damages the power supply shared with Element B, a software error in Element A that corrupts shared memory used by Element B.

Freedom from Interference (FFI): Ensuring that non-safety or lower-ASIL elements cannot interfere with the safety function of higher-ASIL elements. This is essential when decomposed elements share physical resources (same MCU, same PCB, same communication bus).

Homogeneous redundancy (two identical elements) is generally not sufficient for demonstrating independence because identical elements are susceptible to common cause failures – the same systematic design error, the same environmental stress, the same manufacturing defect can affect both elements simultaneously. Heterogeneous redundancy (diverse elements using different technologies, different algorithms, or different hardware) provides much stronger independence arguments.

10. Worked Example 1 – EPS Dual-Channel ASIL D Decomposition

Safety Goal: SG-01: “The EPS shall not apply unintended steering torque” – ASIL D.

Decomposition strategy: ASIL D → ASIL B(D) + ASIL B(D), using a dual-MCU architecture.

Element A (Primary Channel – ASIL B(D)): Primary MCU (Infineon TC397) running the EPS application software. Computes the commanded assist torque from the primary torque sensor channel. Controls the motor driver. Developed using ASIL B software methods (branch coverage).

Element B (Monitoring Channel – ASIL B(D)): Secondary MCU (Infineon TC375) running independent monitoring software. Independently computes expected torque from the redundant torque sensor channel. Cross-checks the primary MCU’s commanded torque via dedicated SPI. If discrepancy exceeds threshold, asserts safety relay disconnect. Developed using ASIL B software methods.

Independence evidence (DFA results): Different MCU devices (TC397 vs TC375) – mitigates common silicon design errors. Independent power supply regulators – mitigates shared power failure. Independent clock sources – mitigates common clock failure. Separate torque sensor channels (different ASIC instances, different PCB routing) – mitigates shared sensor failure. Dedicated SPI cross-check interface with E2E protection – mitigates communication corruption. Safety relay controlled exclusively by monitoring MCU – provides independent shutdown path. Physical separation on PCB with separate ground planes – mitigates common EMC coupling.

System-level hardware metrics: SPFM and LFM are evaluated at the system level (both channels combined) against ASIL D targets (99% SPFM, 90% LFM, <10 FIT PMHF).

Confirmation measures: Functional safety assessment at ASIL D independence level (I2 or I3) – despite each channel being developed to ASIL B methods.

11. Worked Example 2 – AEB Safety Monitor Decomposition

Safety Goal: “The FCAB shall only issue an AEB request when a collision is imminent” – ASIL D.

Decomposition strategy: ASIL D → ASIL C(D) + ASIL A(D), using a primary function + safety monitor architecture.

Element A (Primary AEB Function – ASIL C(D)): Main domain controller CPU running the AEB algorithm. Processes radar and camera data to determine collision probability. Issues braking request when collision threshold is exceeded. Developed using ASIL C methods.

Element B (Safety Monitor – ASIL A(D)): Independent safety monitor (separate MCU or separate core) that validates the AEB braking request. Cross-checks the AEB request against independent sensor path. Can override (block) an invalid AEB request. Developed using ASIL A methods.

This asymmetric decomposition (C + A = D) is common for ADAS functions where the primary algorithm is complex (requiring significant development effort) and the safety monitor is simpler (only needs to validate, not compute the full function).

12. Worked Example 3 – Headlight ASIL B Decomposition

Safety Goal: “The vehicle shall provide forward illumination during nighttime driving” – ASIL B.

Decomposition strategy: ASIL B → ASIL A(B) + ASIL A(B), using left headlight + right headlight as independent elements.

This is one of the simplest and most intuitive examples of ASIL decomposition. The two headlights are physically separate, have separate wiring harnesses, separate bulbs/LEDs, and separate driver circuits. If one headlight fails, the other still provides forward illumination (though reduced). The physical separation naturally provides strong independence. Each headlight system is developed to ASIL A methods, while the combination achieves ASIL B safety.

13. Decomposition Between Safety Function and Safety Mechanism

A frequently overlooked use case of ASIL decomposition is decomposing between an intended safety function and its associated safety mechanism. This is actually one of the most common real-world applications of decomposition. For example, an ASIL D torque command function can be decomposed into the torque command path (ASIL B(D)) and an independent torque monitoring mechanism (ASIL B(D)). The monitoring mechanism detects faults in the command path and triggers the safe state transition. Together, they achieve ASIL D safety – but each is developed to ASIL B methods.

This pattern is pervasive in automotive ECU design and is the fundamental architectural pattern behind most dual-MCU safety architectures (primary MCU + monitoring MCU), lockstep CPU architectures, and watchdog-based safety concepts.

14. Hardware vs Software Decomposition – Practical Differences

Hardware decomposition typically involves separate physical components – separate MCUs, separate sensors, separate power supplies. Physical separation naturally provides strong independence evidence, and hardware diversity (different device families, different manufacturers) strengthens the CCF argument. Hardware decomposition is generally more straightforward because physical independence is tangible and verifiable.

Software decomposition is significantly more challenging because software elements typically share the same physical hardware (same MCU, same memory, same bus). Demonstrating sufficient independence between software elements running on the same MCU requires rigorous Freedom from Interference arguments – including memory protection (MPU/MMU), temporal protection (timing monitoring, watchdogs), and communication protection (inter-partition firewalls). Software decomposition also faces the challenge of common systematic faults – if two software channels are developed by the same team using the same tools, common design errors can affect both channels. Diversity in algorithms, development teams, and tools strengthens the independence argument.

15. Homogeneous vs Heterogeneous Redundancy

Homogeneous redundancy uses identical (or very similar) elements for both channels – same MCU type, same software, same algorithms. While this simplifies development and reduces component diversity cost, it provides weak independence against systematic faults and common cause failures. ISO 26262 states that homogeneous redundancy is generally not sufficient for ASIL decomposition because a systematic design error in one channel is likely present in the identical second channel.

Heterogeneous redundancy uses diverse elements – different MCU families (e.g., TC397 + TC375), different sensor technologies (e.g., Hall effect + magnetoresistive), different algorithms, or different software implementations. Heterogeneous redundancy provides strong independence because a systematic error in one element is unlikely to be replicated in the diverse second element. The cost of heterogeneous redundancy is higher component diversity and increased integration effort.

16. Advantages of ASIL Decomposition

Reduced development cost per element (lower ASIL methods are less expensive), ability to reuse existing ASIL B or C components in ASIL D systems, improved system availability through redundancy (if one channel fails, the other can maintain operation), enables mixed-criticality architectures, and allows use of SEooC components developed to lower ASILs within higher-ASIL systems.

17. Disadvantages and Limitations

Increased architectural complexity (more components, more interfaces), significant DFA effort to demonstrate independence, hardware metric targets remain at original ASIL (99% SPFM for ASIL D regardless of decomposition), confirmation measures remain at original ASIL independence levels, additional hardware cost for physical redundancy (second MCU, second sensor, safety relay), potential increase in total system failure rate due to more components (more components = higher total λ, which can make PMHF targets harder to meet), and complexity of managing different ASIL development methods within the same project team.

18. When NOT to Decompose

ASIL decomposition should be avoided when only homogeneous redundancy is achievable and common cause failures cannot be adequately mitigated, when the DFA effort to demonstrate independence is disproportionate to the cost savings from lower ASIL methods, when the additional hardware for redundancy increases the total failure rate to the point where PMHF targets are harder to meet, when the system is already simple enough that ASIL D development is feasible without decomposition, or when the development team lacks experience with managing multi-ASIL projects and the process complexity risk outweighs the cost benefit.

19. 10 Common ASIL Decomposition Misconceptions

1. “ASIL decomposition lowers the safety goal.” False. Safety goals never change. Only the safety requirements allocated to elements are decomposed.

2. “ASIL B(D) means the element is ASIL B.” Partially true. Development methods are ASIL B, but confirmation measures, hardware metrics, DFA, and integration testing remain at ASIL D.

3. “Hardware metrics can use the decomposed ASIL targets.” False. Hardware metric targets (SPFM, LFM, PMHF) are evaluated at the system level using the original ASIL targets.

4. “Two identical MCUs provide valid decomposition.” Generally false. Homogeneous redundancy does not provide sufficient independence against systematic failures. Diversity is needed.

5. “ASIL decomposition is required by ISO 26262.” False. Decomposition is optional. It is an opportunity, not a mandate.

6. “Software decomposition is simpler and cheaper than hardware decomposition.” Often false. Software decomposition on shared hardware requires rigorous FFI arguments, which can be more expensive than adding a second physical MCU.

7. “ASIL decomposition always saves cost.” Not always. The additional DFA effort, redundancy hardware, integration complexity, and original-ASIL confirmation measures can sometimes exceed the savings from lower development methods.

8. “Each decomposed element can be assessed independently at its lower ASIL.” False. The functional safety assessment uses the original ASIL independence level.

9. “ASIL D(D) + QM(D) means the QM element has no requirements.” False. QM(D) means the element is developed to QM methods but must still demonstrate independence from the ASIL D element (via DFA) and is part of an ASIL D safety assessment.

10. “Decomposition eliminates the need for ASIL D expertise on the team.” False. The overall safety concept, DFA, system-level analysis, and confirmation measures still require ASIL D competence.

20. Best Practices for Successful Decomposition

Decompose at the system level: Decomposition adds the most value when applied at the system architectural level (Part 4), where physical separation between elements is natural. Component-level decomposition within a single IC is much harder to justify.

Use heterogeneous redundancy: Diverse hardware (different MCU families, different sensor technologies) and diverse software (different algorithms, different teams) provide the strongest independence arguments.

Perform DFA early: Do not defer the DFA until late in development. Evaluate independence feasibility before committing to the decomposition architecture – discovering that independence cannot be demonstrated after the design is complete is very costly.

Document the (D) suffix implications explicitly: Make sure every team member understands that hardware metrics, confirmation measures, and integration testing remain at the original ASIL. Create a project-specific guide that maps each activity to its applicable ASIL (decomposed vs original).

Consider the total system PMHF impact: Adding redundant hardware increases the total component count and failure rate. Verify that the decomposed architecture can still meet the PMHF target before committing to the approach.

Plan for mixed-ASIL development: A project with ASIL B(D) and ASIL D elements requires the team to manage two different sets of development methods simultaneously. Establish clear processes and tooling to prevent confusion.

21. Frequently Asked Questions

Q1: Can I decompose an ASIL A requirement?

Yes. ASIL A can be decomposed to ASIL A(A) + QM(A). This is rarely done in practice because ASIL A development methods are already the least stringent, and the savings from moving to QM are minimal compared to the added architectural complexity and DFA effort.

Q2: Can I decompose the same requirement more than once (cascaded decomposition)?

ISO 26262 does not explicitly prohibit cascaded decomposition, but it is generally not recommended because each level of decomposition requires additional independence demonstration and the complexity grows exponentially. The standard provides decomposition rules for two-element and three-element cases.

Q3: Does lockstep CPU count as ASIL decomposition?

Lockstep CPUs (as found in Infineon AURIX or ARM Cortex-R52 lockstep) are a safety mechanism for detecting random hardware faults in the CPU. They are typically not used as an ASIL decomposition mechanism because the two cores are identical (homogeneous redundancy) and share the same silicon, making them susceptible to common cause failures. Lockstep is primarily a diagnostic mechanism that contributes to SPFM, not a decomposition mechanism that reduces the ASIL of the software running on the cores.

Q4: What happens if the DFA reveals that independence is insufficient?

If the DFA cannot demonstrate sufficient independence between the decomposed elements, the decomposition is invalid and the elements must be developed to the original (non-decomposed) ASIL. Alternatively, the architecture can be modified to improve independence (e.g., adding separate power supplies, separate clock sources, physical separation).

Q5: Can I mix decomposed and non-decomposed requirements in the same system?

Yes. A system can have some safety requirements implemented without decomposition (at the full ASIL) and other requirements implemented through decomposition. The requirements management must clearly identify which requirements are decomposed and track the (D) suffix implications for each.

22. Conclusion

ASIL decomposition is a powerful architectural tool that, when applied correctly, enables cost-effective implementation of high-ASIL safety functions through redundant, independent elements developed to lower ASIL methods. The key to success is understanding what changes and what does not change after decomposition, investing in heterogeneous redundancy and thorough DFA, and managing the complexity of mixed-ASIL development with discipline and rigor.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. For the foundational Part 9 coverage, see Part 9 – ASIL Decomposition & DFA. For ASIL fundamentals, see ASIL Levels Explained.

Stay safe. Stay independent. Keep engineering the future.

— The PiEmbSysTech Team