Balancing Safety and Efficiency: New Challenges in Modern Automotive Systems
As modern automotive systems evolve into more integrated and cost-optimized platforms, mixed ASIL (Automotive Safety Integrity Level) environments have become commonplace. It’s no longer unusual for ASIL D safety-critical components to share the same ECU with Quality Management (QM) elements or even legacy software. How then can we ensure these lower ASIL elements don’t compromise the safety integrity of the overall system?
The answer lies in the concept of Freedom From Interference (FFI). A central concept in ISO 26262, FFI provides the foundation for system protection in mixed safety level environments. In this blog, we’ll explore in depth why ASIL A is assigned to components not directly linked to safety goals, and examine both the theoretical justification and practical implementation based on advanced FFI analysis.
Why Assign ASIL A to Components Without Safety Goals
In ISO 26262, ASIL A represents the lowest safety criticality level. However, sometimes this level is assigned to components not derived from HARA (Hazard Analysis and Risk Assessment). This practice may be counterintuitive, but it’s driven by the need to protect higher ASIL functions from unintended interference.
Key Logic: If a lower ASIL component could potentially interfere with a higher ASIL component through timing delays, memory corruption, or resource depletion, it must be developed and verified with sufficient safety rigor to ensure FFI.
ASIL A Assignment Justification Mechanisms Through FFI
1. FFI Analysis: The Foundation for Justification
FFI analysis systematically identifies interference paths across memory, execution timing, communication, and resource sharing. If a QM component cannot guarantee non-interference through basic architectural mechanisms, it must be treated as ASIL A.
🔍 Example: A diagnostic logger (QM) that can overload the CAN bus and delay ASIL C communications triggers an ASIL A reassignment.
2. FFI-Centered Safety Analysis: FTA, FMEA, DFA
Even without safety goals, a component’s failures can escalate to violations if not properly managed.
- FTA (Fault Tree Analysis): Model interference-causing failures as top events.
- FMEA (Failure Mode and Effects Analysis): Focus on interference failure modes such as timing errors or corrupted data.
- DFA (Dependent Failure Analysis): Examine propagation paths and shared resource vulnerabilities between ASIL-separated components.
These analyses help derive targeted safety requirements for interfering components, even if indirect in nature.
3. Isolation Through Robust Architecture
Design-level mitigations are essential. Key techniques include:
Hardware Level:
- Memory Protection Units (MPUs)
- Peripheral firewalls
- Dedicated MCU cores
Software Level:
- OS partitioning (e.g., AUTOSAR application partitioning)
- Hypervisors
- Watchdogs
Interface Protection:
- End-to-end (E2E) protection using checksums, sequence counters, and defensive programming
Lightweight safety mechanisms appropriate for ASIL A (e.g., basic range checks, CPU usage limits, and timeout monitors) can provide sufficient isolation while remaining cost-effective.
4. Rigorous Documentation
ISO 26262 is a document-based standard. When ASIL A is assigned due to FFI:
- FFI reports must detail interference paths and countermeasures.
- Design specifications must clearly specify MPU configurations, OS policies, or isolation techniques.
- Safety cases must explicitly argue how FFI is achieved for non-SG components.
- Verification results must be traceable and independently reviewed.
📑 Important: Certification bodies like TÜV require detailed FFI justification and supporting traceability for ASIL A components during audits.
5. Targeted Verification and Validation (V&V)
Verification must not be limited to functional behavior checks. Instead, it should provoke and detect interference scenarios:
- Stress testing for shared resource saturation
- Fault injection simulating QM failures
- Static code analysis for memory access violations
- Independent reviews for verification objectivity
This layer ensures theoretical FFI mechanisms hold under real conditions.
Real Engineering Cases
Common Triggers for ASIL A Elevation:
- Buses or cores shared with ASIL components
- Memory access overlap with safety-critical buffers
- Legacy QM software integration where isolation is partial or certification impractical
- Runtime environments such as OS/hypervisors or watchdog circuits essential to ASIL D scheduling
Cross-Functional Challenges:
- OEM-Tier1 negotiations on FFI roles and responsibilities
- Resource planning for interference path verification
- Documentation pressure during certification audits
- Misunderstandings about FFI and ASIL A scope
Correcting Common Misconceptions
| Misconception | Reality |
|---|---|
| FFI is the same as ASIL decomposition | FFI ensures coexistence, decomposition divides safety requirements |
| QM = safe | QM ensures only quality, not non-interference |
| MPU guarantees complete FFI | MPU covers memory but not timing or communication |
| ASIL A = low-effort QM | ASIL A still requires safety analysis and controls |
| Indirect influences need no analysis | Any component that can affect SGs must be analyzed |
Strategic Recommendations
Tips for Engineers:
- Prioritize FFI analysis in early architecture
- Conduct FMEA focusing on interference failure modes
- Select isolation mechanisms based on realistic interference risks
Tips for Managers:
- Allocate dedicated resources for FFI verification
- Include FFI topics in functional safety training
- Clarify FFI responsibilities in DIA documents
Tips for Organizations:
- Establish process guidelines for mixed ASIL systems
- Maintain a knowledge base of verified FFI patterns and techniques
- Invest in tools for FFI simulation and verification
Conclusion
Assigning ASIL A to components beyond the direct scope of safety goals is not a workaround. It’s a deliberate and rigorous practice based on ISO 26262’s FFI principles. When performed correctly, it enables cost-effective and safe coexistence of diverse functions within shared hardware platforms. Through detailed analysis, careful architecture, and rigorous verification, engineers can ensure safety beyond traditional boundaries.
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
From this post onwards, I will be adding podcasts created via Google Notebook lm.