ASIL Decomposition and Safety Architecture for an AEB Function

The problem

Implementing a whole AEB chain at a high ASIL is expensive. ISO 26262 allows decomposing a requirement into redundant elements with lower ASILs, but only if they are sufficiently independent. Wrong decompositions, where elements share a sensor, power supply or software library, give false confidence. This project compares realistic decomposition options and tests their independence systematically.

Objectives

• Start from an AEB safety goal and functional safety requirements with ASILs.
• Propose at least three architecture options, including decomposition variants.
• Model the options in SysML with allocations and interfaces.
• Perform dependent failure analysis to check freedom from interference and common causes.
• Evaluate options with fault trees and a simulated fault-injection study.

What you need

Key concepts

ASIL decomposition

Splitting a safety requirement into redundant requirements on independent elements, each with a lower ASIL, such that the combination still meets the original ASIL, for example ASIL D into ASIL B(D) plus ASIL B(D).

Independence

The decomposed elements must not fail together from a common cause, such as shared hardware, software, power, clock or development errors.

Dependent failure analysis

A systematic search for common-cause and cascading failures that could defeat redundancy or independence.

Freedom from interference

The absence of cascading failures from one element to another, for example a lower-ASIL software component corrupting the memory of a higher one.

Step-by-step guide

1. 1

   Set the inputs

   Take the AEB safety goal of avoiding unintended full braking without an obstacle, with an assumed high ASIL from a prior HARA, and a second goal of braking when a collision is imminent within the operating range at a lower ASIL. List functional safety requirements for each. State clearly that these ASILs are assumptions for the study. Note that the two goals pull the architecture in opposite directions.

   Checkpoint: An input sheet with safety goals, ASILs and functional safety requirements.

2. 2

   Define architecture options

   Define at least three options: A, a single ADAS ECU at the full ASIL; B, a main channel with radar and camera fusion plus an independent monitor channel that must confirm before full braking, decomposed into two lower ASIL elements; C, two diverse sensor channels each able to veto, with a brake controller performing a final plausibility check. Describe the hardware, software and communication for each.

   Checkpoint: Three option descriptions with block diagrams and a short rationale for each.

3. 3

   Model in SysML

   In a SysML tool or System Composer, model each option with block definition and internal block diagrams: components, ports, interfaces and flows. Allocate functional safety requirements to components and annotate each component with its ASIL, including decomposition notation such as ASIL B(D). Model power supplies, clocks and network links explicitly, because they are often hidden sources of dependence. Use the same component names across all models so options can be compared side by side.

   Checkpoint: SysML models of all options with requirement allocations and ASIL annotations.

4. 4

   Check decomposition validity

   For each decomposed requirement, check that the redundant elements each fully satisfy the safety requirement on their own, that the ASIL combination is one the standard allows, and that a mechanism exists to combine them, such as an AND gate for braking authority. Record which requirements remain undecomposed and why. Note where decomposition adds new requirements on the combining element.

   Checkpoint: A decomposition table with allowed combinations and combining elements identified.

5. 5

   Perform dependent failure analysis

   Build a checklist of dependent failure initiators: shared power supply, shared clock, shared sensor or sensor mounting, shared software libraries or operating system, shared development tools and teams, environmental effects such as heat or vibration, and communication through the same bus. Walk through every pair of redundant elements in each option and record whether each initiator applies and what mitigation exists.

   Checkpoint: A completed dependent failure analysis for every redundant pair in every option.

6. 6

   Build fault trees for each option

   For the unintended-braking and missed-braking top events, build fault trees per option including common-cause basic events identified in the dependent failure analysis, using a beta-factor model for common causes. Assign illustrative failure rates and compute top-event probabilities and minimal cut sets with a script. Compare how much each option's result depends on the beta factor. State the beta values used and explain why the range was chosen.

   Checkpoint: Top-event probabilities and cut sets per option, with a sensitivity plot against beta factor.

7. 7

   Build the simulation model

   In Simulink, model the AEB function for each option with separate main and monitor channels where applicable, using Automated Driving Toolbox scenarios: lead vehicle braking, stopped vehicle, ghost target from radar and false camera detection. Implement the combining logic. Add fault injection for single faults and common-cause faults such as both channels receiving the same corrupted sensor data. Check that each option's combining logic behaves as described before injecting faults.

   Checkpoint: Each option runs the scenario set fault-free with no unintended braking or missed collisions.

8. 8

   Run fault-injection comparison

   Inject single faults in each channel and common-cause faults defined by the dependent failure analysis across the scenario set. Record unintended braking events, missed braking and minimum time to collision for each option. Common-cause faults should defeat poorly separated options, confirming or challenging the analysis. Count how many faults each option tolerates. Keep all scenarios and fault definitions identical across options for a fair comparison.

   Checkpoint: A comparison table of vehicle-level outcomes per option for single and common-cause faults.

9. 9

   Compare options

   Build a decision matrix with safety outcomes from fault trees and simulation, dependent failure findings, availability (how often the monitor wrongly blocks braking), estimated hardware and software effort, and development rigour needed per ASIL. Weight criteria with justification and choose a preferred option. Run a sensitivity check on the weights to show whether the choice is robust. State the weights before scoring to avoid fitting them to a preferred answer.

   Checkpoint: A weighted decision matrix with a justified choice and weight sensitivity check.

10. 10

    Report

    Present inputs, options, SysML models, decomposition checks, dependent failure analysis, fault trees, simulation results and the decision. Explain where decomposition was valid and where independence could not be argued. State limits: assumed ASILs and failure rates, simplified models and no hardware metric calculations. Include model files and scripts. Add a summary diagram of the chosen architecture with ASILs and independence arguments marked. Close with the open questions a real project would still need to answer.

    Checkpoint: A report with traceable architecture decisions and released models.

Testing & validation

• Decomposition combinations checked against those the standard allows.
• Dependent failure analysis completed for every redundant pair.
• Fault tree results per option with common-cause sensitivity.
• Simulation outcomes for single and common-cause faults per option.

Expected results

Three AEB safety architecture options modelled in SysML and compared through decomposition checks, dependent failure analysis, fault trees and fault-injection simulation, with a justified preferred option.

Take it further

• Calculate hardware architectural metrics for the preferred option with assumed component data.
• Add software partitioning analysis for freedom from interference on a shared processor.
• Model a fail-operational variant for higher automation levels.
• Automate dependent failure checks from SysML model attributes.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.