5 Essential Advices for ASIL Decomposition in ADAS Architectures

The High Cost of High Integrity

Picture this scenario. You are architecting a next-generation Automated Emergency Braking (AEB) system for a new vehicle platform. The Hazard Analysis and Risk Assessment dictates the highest level of rigor for the core braking intervention function, classifying it as ASIL D. Achieving this safety target with a single processing unit and a single sensor suite will skyrocket your bill of materials, push your hardware engineers to their limits, and drastically increase the complexity of your software architecture.

Is there a smarter way to architect this system without compromising functional safety? Yes, through strategic ASIL decomposition. By distributing the safety burden across multiple independent elements, you can utilize lower-complexity components while still achieving the top-level safety goal. However, executing this strategy incorrectly can introduce hidden vulnerabilities that compromise the entire vehicle.

Mastering this technique is a critical skill for any modern automotive engineer. Below, we explore five essential advices for implementing ASIL decomposition in Advanced Driver Assistance Systems up to ASIL D.

What is ASIL Decomposition in ADAS?

A flowchart illustrating the concept of ASIL D decomposition into two independent ASIL B(D) paths.

Before diving into the practical advices, we must establish a clear understanding of the core concept. ASIL decomposition is a method used during the architectural design phase to manage complexity and development costs. It allows you to break down a high-level safety requirement into two independent, redundant safety requirements that share the responsibility of fulfilling the original safety goal.

When you decompose a requirement, the resulting lower-integrity requirements are assigned an ASIL that, when combined, equals the rigor of the original target. For example, an ASIL D requirement can be decomposed into two ASIL B(D) requirements. The "(D)" notation indicates that while the element is developed to ASIL B standards, it is part of an architecture fulfilling an ASIL D goal.

This technique is particularly valuable in ADAS, where systems rely on complex sensors, powerful microprocessors, and intricate software algorithms. By decomposing requirements, you can leverage commercial off-the-shelf components or legacy ASIL B software modules, provided they are paired with an independent, redundant element. Let us look at how to apply this correctly.

Advice 1: Prove True Independence Between Elements

The single most critical rule of ASIL decomposition is that the redundant elements must be truly independent. If a single fault can cause both elements to fail simultaneously, your decomposition is entirely invalid. This is known as a Common Cause Failure, and it is the nemesis of redundant architectures.

To prove independence, you must evaluate your architecture across multiple dimensions. You cannot simply place two microcontrollers on the same printed circuit board and declare them independent. You must ask rigorous questions about their shared resources.

• Spatial Independence: Are the elements physically separated to prevent localized thermal events, electromagnetic interference, or physical damage from affecting both?
• Information Independence: Do the elements share communication buses, memory spaces, or software variables that could corrupt both data streams simultaneously?
• Temporal Independence: Are the elements synchronized to the exact same clock source, making them vulnerable to the same timing anomalies?

Consider an Electric Power Steering (EPS) system requiring ASIL D for the steering torque command. If you decompose this into two ASIL B(D) processing paths, but both paths draw from the exact same unmonitored power supply, a voltage spike will disable both paths instantly. True independence requires diverse hardware, separate power domains, and isolated memory partitions.

Advice 2: Apply ASIL Decomposition at the Right Architecture Level

Timing and placement are everything when designing safety architectures. A common mistake teams make is attempting to apply ASIL decomposition too late in the development lifecycle, often restricting it solely to the software architecture. While software-level decomposition is possible, it rarely yields the hardware metric benefits you need for complex ADAS functions.

You should aim to apply decomposition as early as possible, ideally during the system architectural design phase. By defining redundant system-level elements early, you set clear boundaries for both the hardware and software teams. This top-down approach ensures that the entire signal chain (from sensor to processor to actuator) is evaluated for redundancy.

For instance, in an Adaptive Cruise Control (ACC) system, decomposing the acceleration request at the system level allows you to allocate one ASIL B(D) requirement to a radar-based processing path and the other ASIL B(D) requirement to a camera-based processing path. This heterogeneous redundancy is far more robust than trying to decompose a single software algorithm running on a single microprocessor.

Make it a practice to evaluate decomposition opportunities immediately after defining your functional safety concept. This proactive approach prevents costly redesigns and ensures your hardware architecture is optimized for both safety and cost from day one.

Advice 3: Do Not Confuse Hardware Redundancy with Safety Requirements

It is easy to fall into the trap of thinking that simply doubling the hardware automatically grants you the right to lower the ASIL. This is a fundamental misunderstanding of the standard. ASIL decomposition applies to safety requirements, not physical hardware components.

When you decompose a requirement, you are stating that the combined fulfillment of two new, independent safety requirements satisfies the original intent. The redundant hardware is merely the implementation mechanism for those requirements. If the redundant hardware does not actively fulfill a specific, documented safety requirement, it does not count toward decomposition.

Furthermore, homogeneous redundancy (using two identical components with identical software) is often insufficient for achieving high ASIL targets due to systematic faults. If a software bug exists in your ASIL B(D) braking algorithm, running that exact same algorithm on a second identical microprocessor will simply result in both processors outputting the same erroneous command.

To maximize safety, strive for diverse redundancy. If your primary AEB path uses a complex machine-learning algorithm on a high-performance system-on-chip, your redundant path might use a simpler, deterministic physics-based algorithm on a classic automotive microcontroller. This diversity protects against systematic software faults and strengthens your decomposition argument.

Advice 4: Manage the Dependent Failure Analysis Rigorously

You cannot claim independence without proving it, and the tool you use to prove it is the Dependent Failure Analysis. The DFA is a systematic methodology used to identify, evaluate, and mitigate potential coupling factors between your decomposed elements.

A rigorous DFA looks for two specific types of failures. First, it investigates Common Cause Failures, where a single root cause (like a shared clock oscillator or a common software library) takes down both redundant paths. Second, it investigates Cascading Failures, where a fault in one element propagates and causes the second element to fail (such as a short circuit in one microcontroller causing a thermal event that melts the adjacent redundant microcontroller).

"A decomposed architecture is only as strong as the rigor of its Dependent Failure Analysis. Unidentified coupling factors are the silent killers of redundant systems."

When conducting your DFA, you must document every shared resource and interface. If coupling factors are identified, you must implement specific safety mechanisms to mitigate them. These mechanisms (such as a watchdog timer, memory protection unit, or voltage monitor) often inherit the highest ASIL of the elements they are protecting. Your decomposition rationale relies entirely on the completeness and accuracy of this analysis.

Advice 5: Document the ASIL Tailoring and Rationale Clearly

Functional safety is as much about process and traceability as it is about engineering. When an external assessor reviews your ADAS architecture, they will scrutinize your decomposition strategy heavily. If your rationale is not documented clearly, you will face significant compliance hurdles.

Every decomposed requirement must maintain strict traceability back to its parent requirement. You must consistently use the standard notation (e.g., ASIL C(D) + ASIL A(D)) in your requirements management tools so that any engineer reading the requirement understands its context within the broader architecture.

Additionally, you must document the integration and testing strategy for the decomposed elements. While the individual elements may be developed to ASIL B standards, the integration of those elements to form the top-level safety goal must be verified and validated according to the original ASIL D rigor. Your test plans must explicitly demonstrate that the combined elements achieve the required safety targets and that the independence mechanisms function correctly under fault conditions.

Keep a dedicated architectural rationale document that explains exactly why the decomposition was chosen, how independence is maintained, and where the DFA results are located. This transparency builds confidence with assessors and provides a clear roadmap for future engineering teams.

Mastering ASIL for Next-Generation ADAS

Architecting highly automated driving systems requires a delicate balance between cutting-edge performance, hardware costs, and uncompromising safety. By applying ASIL decomposition correctly, you can leverage lower-complexity components to build robust, fault-tolerant architectures capable of meeting ASIL D targets.

Remember to prioritize true independence, apply the technique early at the system level, focus on diverse redundancy, execute a flawless Dependent Failure Analysis, and maintain pristine documentation. These five advices will help you navigate the complexities of redundant safety architectures and avoid common pitfalls.

Are you ready to elevate your functional safety expertise and apply these concepts to your own projects? Dive deeper with our comprehensive ASIL Decomposition guide, or explore the specialized courses available on the ISO 26262 Academy platform. Equip yourself with the knowledge to engineer the safest vehicles of tomorrow.

Abbreviations & Key Definitions

• ACC - Adaptive Cruise Control, an ADAS feature that automatically adjusts vehicle speed to maintain a safe distance from vehicles ahead.
• ADAS - Advanced Driver Assistance Systems, electronic technologies that assist drivers in driving and parking functions.
• AEB - Automated Emergency Braking, a safety system designed to prevent or reduce the severity of collisions by applying the brakes automatically.
• ASIL - Automotive Safety Integrity Level, a risk classification scheme defined by ISO 26262 to specify the necessary safety measures for avoiding unreasonable residual risk.
• CCF - Common Cause Failure, a failure resulting from a single event or root cause that simultaneously affects multiple independent components or paths.
• DFA - Dependent Failure Analysis, a systematic method used to identify and evaluate potential coupling factors and dependent failures between system elements.
• EPS - Electric Power Steering, a system that uses an electric motor to assist the driver in steering the vehicle.
• HARA - Hazard Analysis and Risk Assessment, a core process in ISO 26262 used to identify potential hazards and assign the appropriate ASIL.