If you’re in the automotive industry, you’ve likely heard of ‘ISO 26262’ and ‘ASIL.’ What was once considered merely ‘regulation for regulation’s sake’ has now become the cornerstone of automotive safety. I’d like to share the real-world challenges and solution strategies I’ve experienced while implementing ASIL in my functional safety work.
ASIL Allocation: The Complex Intersection of Technical and Non-Technical Factors
ASIL allocation is far more than a simple technical decision. It’s a process deeply intertwined with cost dynamics and conflicting interests between OEMs (automotive manufacturers) and Tier-1 suppliers.
With each step up the ASIL scale, the processes and safety mechanisms required for development increase exponentially. Particularly for ASIL D requirements, hardware redundancy, formal verification, and extensive documentation are necessary, resulting in an average development cost increase of 35-50%.
In my experience, Development Interface Agreements (DIAs) have been instrumental in resolving these conflicts. By clearly defining the roles and responsibilities of each party, we’ve been able to reduce unnecessary misunderstandings and disputes.
However, ‘gray areas’ in ASIL allocation are inevitable in practice. These situations, arising from a lack of clear criteria, require subjective judgment from experts and strategic decision-making. In one project, we adopted a strategy to mitigate a system initially assessed as ASIL D to ASIL B through design improvements and safety mechanisms, which required not just technical analysis but political consensus and acceptance within the organization.
I’ve also witnessed cases where an overly conservative interpretation of functional safety requirements led to unnecessarily high ASIL ratings, resulting in increased development costs and schedule delays. It’s always important to remember that ASIL is not an end in itself but a framework for managing risk.
HARA: Subjectivity Controversies and New Challenges in the Autonomous Driving Era
HARA (Hazard Analysis and Risk Assessment) is the core process of ASIL allocation, evaluating the Severity, Exposure, and Controllability of risks. Subjective elements often come into play in this process.
The biggest issue is the lack of standardized guidelines and quantitative data. Particularly in Controllability assessment, the criterion of ‘average driver behavior’ lacks clear consensus on what exactly that means.
Global OEMs assign different ASIL ratings to the same functions based on their safety philosophies and regional characteristics (regulations, road environments, etc.). For example, in Europe, an AEB (Automatic Emergency Braking) system might require ASIL D due to emphasis on ethical design, while in North America, a Lane Keep Assist system might be classified as ASIL C primarily for litigation risk management.
These issues become even more complex in the era of autonomous driving. In SAE Level 3 or higher autonomous vehicles, driver intervention is limited or non-existent, making traditional HARA methods no longer applicable. New evaluation metrics such as Take-over time and Fallback Mechanism response time are becoming necessary.
In a recent project, we attempted HARA calibration using real-world driving data and AI-based automated risk analysis, with promising results.
Challenges of Legacy System Integration and Safety Migration Strategies
An automobile is a system of numerous ECUs and sensors connected in complex ways. Beyond individual ASIL requirements, safety architecture design at the system level is essential.
However, aligning legacy systems (older ECUs, MCUs, etc.) with ASIL requirements is a significant challenge. They often have inherently high failure rates or lack internal error diagnosis and reporting mechanisms.
To solve this problem, I’ve employed the ‘Safety Wrapping’ strategy, adding safety mechanisms around legacy systems or redesigning critical functions separately. Additionally, using ‘Proven In Use data’ to guarantee safety based on long operational records has been effective.
Reverse Engineering techniques for safety assurance, while time-consuming and costly, have been essential for integrating legacy systems into the safety framework.
Practical Pitfalls of ASIL Decomposition and Interface Management
ASIL decomposition is a technique to reduce development burden by dividing systems with high ASIL requirements into several sub-elements. While theoretically attractive, it presents several issues in practice.
Single points of failure can occur at interfaces between decomposed elements, potentially leading to Common Cause Failures (CCF). Although ASIL decomposition is possible using virtualization with hypervisors, proving independence (FFI) remains challenging, and protection measures against system interference are necessary.
To minimize these risks, verification of interface accuracy and robustness is essential. In one project, we addressed this issue through thorough risk assessment and convincing certification authorities.
The Impact of Organizational Culture and Human Factors
Just as important as the technical aspects is organizational culture. The successful application of ISO 26262 depends heavily on organizational culture as much as technical capabilities.
Safety activities should be the collective responsibility of the entire team, not just one individual, requiring a collaborative environment with participation from various domains. Open communication channels and freedom to raise concerns are crucial, while overtime and overwork can lead to degraded document quality, negatively impacting safety assessments.
When managing safety activities through KPIs, ‘Goodhart’s Law’ must be considered. Attempting to assess safety solely through quantitative indicators can lead to inefficient or even unsafe behaviors. It’s important to incorporate qualitative assessments and ensure all team members clearly understand that the goal is safety assurance.
Conclusion: Successful Strategies for ASIL Implementation
ISO 26262 ASIL implementation is not simply regulatory compliance but a risk-based engineering process. Successful implementation requires not only technical capabilities but also organizational culture, collaboration abilities, and leadership.
ISO 26262 is a framework that demands a comprehensive approach to achieve system complexity and safety objectives. The key is for organizations to fully understand and integrate this, and the keys to successful ASIL implementation are effective management of safety processes such as HARA performance, safety architecture design, and complexity management, and improving their maturity.
In practice, it’s important to understand the essence of safety and find realistic approaches rather than blindly following regulations. And most importantly – never forget that safety is ultimately for people.
If you are interested in other articles about ISO 2626 Series, please refer to the links below!
[ISO 26262] #1. Part4-6 Technical Safety Concept (TSC)
[ISO 26262] #2. Safety Mechanisms for Electrical and Electronic
[ISO 26262] #3. Safety Mechanism for Processing Unit
[ISO 26262] #4. Safety Mechanisms for IO units and Interfaces
[ISO 26262] #5. Safety Mechanisms for Communication Bus
[ISO 26262] #6. Safety Mechanisms for Power Supply
[ISO 26262] #7. Safety Mechanisms for Temporal monitoring and logical programme sequence monitoring
[ISO 26262] #8. Safety Mechanism for Sensors and Actuator
[ISO 26262] #10. Fault Tree Analysis (FTA)
[ISO 26262] #11. DFA, Dependent Failure Analysis
[ISO26262] #12. Understanding ASIL A Assignment Through Freedom From Interference (FFI) in ISO 26262
From this post onwards, I will be adding podcasts created via Google Notebook lm.