ASIL Decomposition – a term that might sound like a complex jargon even for those working with the automotive safety standards. ASIL stands for Automotive Safety Integrity Level which corresponds to the criticality associated with a particular function of the system and it comes with four levels from A to D.
The ASIL dictates the safety requirements that must be met during the design and development of the system to ensure an adequate margin of safety. However, developing a system to the highest ASIL level may not always be practical due to factors such as cost and complexity. In such scenarios, the technique of ASIL decomposition can be considered.
Understanding ASIL Decomposition
Let’s begin by dissecting the formal definition provided by ISO 26262: „Allocation of redundant safety requirements to elements, with sufficient independence, conducing 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 simpler terms, ASIL Decomposition is a method of breaking down safety requirements into redundant ones, allocating them to independent elements, and potentially assigning lower ASILs. This technique comes with specific conditions and schemas, offering a strategic approach to reduce complexity and associated costs.
ASIL Decomposition Schemas
The permissible schemas for ASIL Decomposition are outlined in the standard. For instance, an original ASIL D can be decomposed into C(D) + A(D), providing flexibility and optimization in requirement capture methods. The below table from ISO 26262 illustrates acceptable schemas for ASIL decomposition.
ASIL Decomposition can be applied in all the phases of product development starting from concept phase to HW/SW development. While applying decomposition, one should keep in mind that the decomposed requirements-
• must comply with the initial safety requirement itself
• must inherit the same safety goal
• must address the same safe state
• must be independent to each other
Why ASIL Decomposition?
The primary motivation is to align with the methods and processes required for the decomposed ASIL, leading to potential savings in terms of cost, time, or tools. By strategically decomposing ASIL levels, organizations can tailor their development approaches to specific safety requirements, offering a more practical and efficient solution.
For instance, ASIL D development needs semi- formal notations for SW architectural design, which needs some kind of modelling tool like UML. Also, the SW development is always coupled with SW tools which has to be developed as per initial ASIL as well. By decomposing to a lower ASIL you can exclude such requirements.
Scenarios for ASIL Decomposition
ASIL Decomposition finds application in various development scenarios, particularly when aiming to reduce system complexity. Some instances include.
• Dealing with legacy code that are not developed as per ISO 26262
• Incorporating third-party components that are not ASIL rated
• Managing high software complexity
• Addressing coupled software-tool development
• Redundancy exists as part of system (E.g. headlight)
Constraints and Limitations
While ASIL Decomposition presents advantages, it’s crucial to acknowledge its constraints.
• Hardware metrics, probability of safety goal violation targets cannot be reduced and remain at the original level
• Integration activities, and confirmation measures remain at the original ASIL level
• Demonstrating independence between decomposed elements can pose challenges, especially when applied at the system or ECU level
Conclusion
In the realm of safety design, ASIL Decomposition emerges as a valuable tool, offering tailored solutions for diverse challenges. However, it’s not a one-size-fits-all approach, and careful analysis of the trade-of between cost, complexity and safety is essential. If the complexity of ASIL Decomposition still leaves you with questions, feel free to connect with us for further clarification.
Gnanagiri Balasubramanian is a Chief Safety Expert at CYRES Consulting, with extensive experience in both the automotive and medical sectors. A seasoned professional in Functional Safety (ISO 26262), Automotive Cybersecurity (IEC 21434), and Medical Risk Management (ISO 14971), Gnanagiri has a proven track record of guiding organizations through the complexities of developing safety-critical systems, from risk assessment to safety lifecycle management. With a strong consulting background, he is committed to delivering high-quality safety concepts while ensuring compliance with industry standards. Gnanagiri holds a bachelor’s degree in electrical and Electronics Engineering, specializing in microcontroller and SoC safety, and is also a TÜV-certified Automotive Cybersecurity Professional.
Comments are closed.