This is the mechanism that makes redundant channel architectures tractable — instead of building two ASIL D channels, you build two ASIL B channels with proven independence.

The Independence Requirement

The decomposition is only valid if the two elements are sufficiently independent — meaning a single fault that could cause one element to fail is not also likely to cause the other element to fail.

ISO 26262-9 Clause 6 defines what this means formally: freedom from cascading failures and freedom from common cause failures between the elements. The analysis that demonstrates this freedom is the Dependent Failure Analysis (DFA).

The DFA must cover:

  • Electrical independence: shared power rails, shared ground references, electrical coupling between the two elements
  • Thermal independence: shared thermal environment, heat dissipation from one element affecting the other
  • Software independence: shared software libraries, shared operating system components, shared hardware resources (memory, interrupts, buses)
  • Structural independence: physical separation, PCB trace routing, connector sharing

If the DFA identifies a credible common cause that could defeat both elements simultaneously, the decomposition is invalid for that failure mode. The architecture must be modified to eliminate the common cause, or the ASIL D must be met on a single element without decomposition.

Decomposition Notation

ISO 26262 uses specific notation for decomposition that appears in safety concept documents and must be understood correctly.

ASIL D on a single element — no decomposition, full ASIL D requirements apply.

ASIL B(D) — an element contributing to an ASIL D safety goal through decomposition. The element itself has ASIL B functional requirements, but the independence between it and its complementary element is an ASIL D requirement. This means the independence claim (the DFA) must meet ASIL D rigor, even though the functional requirements are ASIL B.

Other valid decompositions defined in ISO 26262-9 Table 5:

  • ASIL D = ASIL D(D) + ASIL A(D) (asymmetric decomposition — one element handles the primary function, one provides monitoring)
  • ASIL C = ASIL B(C) + ASIL A(C)
  • ASIL C = ASIL A(C) + ASIL B(C)

What is not valid: ASIL D = ASIL C + QM. Any element that contributes to an ASIL D safety goal through decomposition must have a minimum ASIL rating, not QM.

Hardware vs. Software Decomposition

Decomposition applies differently depending on whether it is implemented in hardware, software, or a combination.

Hardware Decomposition

The classic hardware decomposition implements two independent hardware channels: a primary channel performing the safety function and a monitoring channel verifying the primary. Common examples:

  • Primary microcontroller + dedicated safety monitor IC (separate die, separate power, separate communication path)
  • Dual-channel redundant braking system (hydraulic primary + electric secondary)
  • Primary sensor + secondary sensor on a different physical principle (e.g., radar + camera for object detection)

Hardware decomposition is architecturally straightforward but requires:

  1. Physical separation documented in the system architecture
  2. Separate power supplies with proven isolation
  3. Independent communication paths between the two channels (not shared CAN bus)
  4. DFA covering all identified common cause failure mechanisms

Software decomposition is more complex because software inherently shares resources with other software. Two tasks running on the same processor share:

  • The processor itself (single point of failure)
  • Memory (a bug in one task can corrupt another task's memory)
  • The operating system (OS faults affect all tasks)
  • Timing resources (interrupts, watchdogs)

For a decomposition implemented entirely in software on a single processor to be valid, the platform must provide certified freedom from interference — typically a safety-qualified hypervisor or RTOS partition manager with a Safety Manual demonstrating that the partition isolation meets ASIL D requirements.

This is a demanding bar. Few commercially available RTOS platforms have ASIL D certification for their partition isolation. The more common valid approach is to implement one channel on the application processor and a second, simpler monitoring function on a dedicated safety monitor implemented in hardware or a separate, simpler processor.

Pure software decomposition on a shared processor without certified partition isolation is one of the most common invalid decomposition patterns encountered in assessments.

Mixed Decomposition

The most common valid decomposition pattern combines hardware independence with software differentiation:

  • Channel A: complex algorithm on application SoC, developed under ASIL B software requirements
  • Channel B: simplified reference algorithm on safety monitor IC (separate die, separate power), developed under ASIL B software requirements
  • Independence claim: electrical isolation between the two channels, separate power supplies, DFA-verified freedom from common cause failures

The two software implementations use different algorithms (software diversity) to reduce the probability of a systematic software fault affecting both channels simultaneously.

ASIL Decomposition in Practice: Common Errors

Treating a dual-core lockstep processor as decomposition. Dual-core lockstep processors (where two identical cores execute in parallel and their outputs are compared) are designed to detect systematic and random hardware faults in a single processor — they are an ASIL D monitoring mechanism, not an ASIL D decomposition. Two lockstep cores on the same die share the same silicon, the same power domain, and the same clock. They are not independent elements for ASIL decomposition purposes.

Software decomposition without certified partition isolation. Two software tasks on the same processor, without demonstrated freedom from interference, are not independent elements.

Asymmetric decomposition without appropriate ASIL assignment. Using ASIL D = ASIL D + QM to claim that one element handles the safety function while the other is QM. ISO 26262-9 does not allow this — both elements in a decomposition must have a minimum ASIL rating.

FTTI violation through monitoring latency. The monitoring channel in a two-channel architecture must detect the primary channel's failure within the FTTI. If the monitoring cycle time is longer than the FTTI, the decomposition architecture cannot achieve its safety goal even if both channels independently meet their ASIL requirements.

How ISO WIZ Tracks Decomposition

ASIL decomposition creates traceability requirements that spreadsheets handle poorly. Each decomposition statement links:

  • The parent ASIL D safety requirement being decomposed
  • The two (or more) child requirements with their ASIL(D) ratings
  • The independence claims that validate the decomposition
  • The DFA work product that demonstrates the independence claims
  • The verification evidence for each independence claim

When any element in this chain changes — an architecture modification alters the power supply configuration, a DFA finding identifies a previously overlooked common cause — every linked element must be reviewed.

This is the infrastructure that makes decomposition architectures maintainable over a multi-year development program — rather than becoming a static diagram that nobody updates when the hardware changes.