The Essential Role of Software Architecture in ISO 26262 Functional Safety
Hello, this is Hermes Solution! This week’s blog post delves into the crucial role of software architecture within ISO 26262 functional safety, the core safety standard in the automotive industry.
In today’s automotive industry, the safety of electrical/electronic (E/E) systems is paramount, and the ISO 26262 standard has become the key guideline for ensuring this safety. This standard provides a comprehensive risk-based framework to identify potential hazards, evaluate risks, and implement safety mechanisms to prevent system failures that could lead to accidents. It applies to all aspects of the vehicle development lifecycle, from concept and design to implementation, verification, production, and decommissioning, ensuring systems operate safely in both normal and fault conditions. In this context, software architecture must be recognized as more than just a development phase; it’s a fundamental foundation for achieving functional safety objectives.
Innovations in modern vehicles, such as Advanced Driver-Assistance Systems (ADAS), autonomous driving technologies, and Electric Vehicle (EV) control systems, are driven by software, and its role and complexity are increasing exponentially. The rapid growth and networking of in-vehicle E/E systems further highlight the importance of functional safety, meaning that ensuring software safety is a critical component of overall vehicle safety. Functional safety cannot be achieved merely by adhering to coding rules or conducting thorough testing. How a system is structured, how safety requirements are implemented, how potential faults are managed, and how system integrity is maintained are all fundamentally determined by the software architecture. A well-defined architecture serves as a blueprint for safety.
ISO 26262 encourages a proactive approach to safety by emphasizing safety activities throughout the entire development lifecycle, integrating safety considerations from the design phase. Addressing safety issues late in development incurs significant costs and time, and often makes it difficult to find optimal solutions. Conversely, architectural decisions made during the concept and design phases have the greatest impact on achieving safety objectives effectively and efficiently. A flawed architecture, no matter how much it’s tested, struggles to guarantee inherent safety. Furthermore, ISO 26262 mandates traceability and compliance at every stage of development, and a clear, well-documented software architecture is essential for demonstrating this traceability. The architecture provides a structure that identifies components, boundaries, and interfaces, offering a clear path from safety requirements to actual implementation, which serves as key evidence to support the Safety Case.
In this blog post, we will delve into how the ASIL (Automotive Safety Integrity Level) classification, a core element of automotive functional safety, specifically influences software architecture design decisions, and what considerations are necessary for each level.
ASIL Levels: How Automotive Risk Levels Shape Architecture Strategies
At the heart of ISO 26262 is the ASIL risk classification scheme. ASIL, short for Automotive Safety Integrity Level, indicates the potential risk level of an automotive system and dictates the rigor of the safety measures required. ASIL is divided into four levels: A, B, C, and D, with ASIL A representing the lowest risk and ASIL D the highest. Non-safety-related items are classified as QM (Quality Management).
ASIL levels are determined by evaluating three factors for each hazardous event:
Severity (S): The potential injury severity that can result from a malfunction (e.g., injury or fatality).
Exposure (E): How frequently the vehicle is exposed to specific driving situations where the hazard could occur.
Controllability (C): The ability of the driver or other systems to prevent or mitigate harm after a fault occurs.
The combination of these three factors determines the ASIL level for each hazardous situation, which in turn leads to the ASIL level of the safety goal that the system must meet to mitigate that hazard. The core principle is that a higher ASIL level demands stricter safety requirements, more robust safety mechanisms, and more rigorous development and verification processes.
ASIL levels are not merely labels attached to a system; they are fundamental drivers that determine architectural strategies from the initial design phase. ASIL defines safety goals and directly impacts the system architecture. For instance, an ASIL D safety goal necessitates robust mechanisms for fault tolerance and freedom from interference from the very beginning of architectural conception, whereas an ASIL A system might suffice with relatively less complex safety measures. Thus, the choice of architectural patterns, redundancy strategies, and error handling mechanisms are all directly influenced by the assigned ASIL level.
Furthermore, ASIL levels are closely linked to the “cost of safety.” Generally, a higher ASIL level requires more effort and resources for development and verification. However, architectural choices can significantly impact these costs. For example, designing an ASIL D system with a complex monolithic architecture can exponentially increase the cost and time involved in proving freedom from interference or implementing robust fault tolerance. Conversely, a well-partitioned and modular architecture can enable efficient implementation and verification of safety requirements, contributing to optimizing the “cost of safety.” This is a crucial business consideration for automotive manufacturers and suppliers.
Foundational Architectural Principles for Safety-Critical Software
In safety-critical software development, the robust application of several universally beneficial software architecture principles is crucial to meeting the requirements of specific ASIL levels. The importance and rigor of applying these principles increase with higher ASIL levels.
Modularity and Componentization: Break down software into manageable, clearly defined components, with each component designed to have a single responsibility. This enhances software understanding, maintainability, and verifiability. It’s essential for fault isolation and complexity management, crucial for ensuring safety.
Cohesion: Elements within a component should be closely related, contributing to a single purpose or tightly coupled purposes. This strengthens encapsulation, reduces the likelihood of error propagation, and improves maintainability, robustness, and reusability, leading to a less complex software architecture.
Coupling: Minimize dependencies between components, with interactions occurring only through well-defined, minimal interfaces. This reduces the ripple effect of changes, improves testability and reusability, and limits error propagation.
Hierarchical Structure: Organize components into layers of abstraction. This enhances overall system understanding and promotes structured design.
Interface Design: Interfaces between components should be minimal and explicit, clearly defining how components interact. This promotes simplicity, verifiability, and encapsulation, reduces testing effort, and is key to managing interactions and potential interference.
Testability and Maintainability by Design: The architecture should inherently support ease of unit testing, integration testing, and system testing, and allow for easy future modifications. As ASIL levels increase, verification and validation (V&V) efforts intensify, making an architecture that is difficult to test significantly increase cost and risk.
These foundational principles serve as the bedrock for the advanced safety strategies required at higher ASIL levels. For instance, strategies like Freedom from Interference (FFI) heavily rely on clear boundaries and controlled interfaces, which are outcomes of modularity, loose coupling, and well-defined interface principles. A monolithic “spaghetti code” structure cannot effectively implement FFI or ASIL decomposition. Therefore, mastering these foundational principles is not just good software engineering practice; it’s an essential step toward achieving high ASIL compliance.
Software Architecture Design Considerations by ASIL Level
The ASIL levels defined in ISO 26262 directly influence the required design complexity and sophistication of safety mechanisms in software architecture.
A. ASIL A & B: Building a Robust Foundation
ASIL A and B levels address relatively lower risk levels, but focus on establishing fundamental principles for safe software development. The architectural focus is on simplicity, readability, maintainability, and basic error detection capabilities. The architecture should support clear logical flows and intuitive data flows. Coding and design practices should include basic coding rules (e.g., meaningful variable names, using constants instead of magic numbers) and simple error handling mechanisms like basic input validation. Safety mechanisms primarily focus on detecting obvious errors, and extensive fault tolerance may not be required. V&V focuses on proving functional correctness and adherence to basic design principles.
B. ASIL C: Enhancing Safety and Design Rigor
From ASIL C onwards, the system’s safety and design requirements significantly increase. An architecture that supports enhanced robustness, improved error handling and recovery capabilities, and more stringent V&V activities is required. All input data must be thoroughly validated, and the system must be able to recover safely from error states. Advanced coding techniques considering reusability, modularity, and testability are necessary, and adherence to coding standards like MISRA C becomes more critical. The architecture must also consider how software interacts with hardware components and responds to environmental stresses. More sophisticated error detection mechanisms and some fault tolerance concepts are introduced. Evaluation of Diagnostic Coverage for residual faults is required. Extensive testing, including unit, integration, and system testing, is mandatory, and formal code reviews and static analysis tools are strongly recommended.
C. ASIL D: Architecture Design for Highest Integrity and Fault Tolerance
ASIL D represents the highest safety requirement level. The architecture must ensure the highest level of integrity, comprehensive fault tolerance, and the ability to operate safely (fail-operational) or transition to a safe state (fail-safe). The architectural focus is on implementing methods to identify and address potential errors in all parts of the system, aiming for the highest level of safety by considering all possible fault scenarios. Demonstrable independence and freedom from interference are essential. Coding and design practices require detecting and handling all abnormal behaviors, and the system must remain in a safe state under any circumstances. Extensive safety mechanisms include:
Fault Tolerance: Using hardware or software redundancy and diversity to prevent single failures from violating overall safety goals.
Error Detection and Correction: Utilizing ECC for memory errors and robust communication protocols.
Timing and Execution Monitoring: Employing watchdog timers and deadline monitoring to detect abnormal program halts or timing violations.
Memory Protection: Using Hardware Memory Protection Units (MPUs) to enforce spatial isolation between components and block unauthorized memory access.
Transition to Safe State (Fail-Safe): Ensuring the system transitions to a pre-defined safe state upon critical fault detection.
The most stringent level of V&V is required for ASIL D. All development stages and changes must be fully documented, and independent verification is necessary to prove code safety. Formal Verification methods are strongly recommended, along with extensive use of static and dynamic analysis tools and Fault Injection Testing. Confirmation measures, including Functional Safety Audit and Functional Safety Assessment by independent parties, are extremely important.
The transition from ASIL B/C to ASIL D signifies not just a quantitative increase in requirements but a qualitative shift. ASIL D explicitly demands that the system either continues to operate safely or transitions to a safe state upon fault occurrence, requiring demonstrable protection of these capabilities from interference. This may necessitate architectural patterns like N-version programming, Triple Modular Redundancy (TMR) considerations, or robust partitioning, which are uncommon in lower ASIL levels.
Key Architectural Strategies for Achieving Functional Safety
To meet ISO 26262 requirements, especially for higher ASIL levels, it’s crucial to understand and apply several key architectural strategies.
A. Freedom From Interference (FFI) in Mixed-ASIL Systems
The “Freedom From Interference” principle is critical when software components of different ASIL levels (or QM components) coexist on the same ECU. Higher ASIL components must not be negatively affected by lower ASIL components. FFI includes three essential requirements: memory protection, execution time guarantees, and data transfer integrity. Architectural techniques to achieve FFI include partitioning (logical and often physical separation), spatial isolation (MPU/MMU), temporal isolation, controlled interfaces, shared resource management, and data integrity at interfaces. Standards like AUTOSAR and microkernel-based OSs contribute to FFI by providing foundational mechanisms for partitioning and memory protection.
B. ASIL Decomposition and Its Architectural Impact
ASIL decomposition is a technique for dividing high ASIL safety requirements into multiple redundant and independent lower ASIL requirements, assigning them to different architectural elements. This reduces the complexity, development cost, and required tool level for individual elements. Architectural prerequisites for ASIL decomposition include redundancy and independence. The architectural implementation may involve diverse redundant channels, separate microcontrollers, or functionally distinct software paths. It’s crucial to ensure that a failure in one decomposed path does not affect other redundant paths. While ASIL decomposition can lower the ASIL level of individual elements, the overall safety goal must still be met.
C. Architectural Integration of Safety Mechanisms
Various safety mechanisms are distributed and integrated throughout the architecture. These include:
Error Detection and Handling: Input validation, range checks, plausibility checks, and internal error detection (e.g., control flow errors, data corruption). Architecturally, these checks can be located in specific architectural layers or modules.
Fault Tolerance Techniques: Designing the architecture to withstand faults and continue safe operation or transition to a safe state. This includes redundancy (hardware, software, information, temporal), watchdog timers, and Error Correction Code (ECC). Redundancy requires careful architectural planning for managing redundant elements, voting mechanisms, and switching logic.
Diagnostic Functions: Mechanisms to detect, report, and record faults to aid maintenance and prevent further risks. This may include dedicated diagnostic modules and communication paths.
Fail-Safe / Fail-Operational Design: Ensuring the system transitions to a pre-defined safe state upon critical fault, or in some very high ASIL functions, maintains limited functionality (fail-operational). This requires clear definition of safe states and architectural logic to achieve them.
These safety mechanisms are often implemented distributed across the architecture rather than concentrated in a single “safety module.” Therefore, the architecture must define where these mechanisms are located, how they interact, and how their combined operation contributes to the overall safety goals.
Verification and Validation (V&V) of Safety-Centric Architectures
ISO 26262 compliant V&V is not limited to code testing. The software architecture itself must undergo rigorous verification and validation, with methods and intensity adjusted according to the ASIL level. While code V&V focuses on implementation accuracy for unit design, architectural V&V focuses on ensuring the architecture correctly implements system-level safety requirements, supports FFI, properly allocates functions, and defines and uses interfaces correctly.
Higher ASIL levels demand more formal, comprehensive, and often independent architectural V&V. For ASIL A/B, reviews or walkthroughs may suffice, but for ASIL C/D, more formalized methods, extensive analysis, and tool-supported verification are necessary.
Key architectural V&V methods include:
Architecture Design Review: A systematic evaluation of the architecture against safety requirements and design principles.
Architecture Static Analysis: Using tools to check consistency, adherence to architectural rules, interface discrepancies, and potential FFI violations.
Model-Based Verification: Applying formal verification or simulation to the architecture when it’s represented as a model (e.g., SysML, AUTOSAR models).
Dependent Failure Analysis (DFA): A critical analysis to identify potential Common Cause Failures (CCF) and Cascading Failures (CF) that could violate independence or FFI. It’s used to inform and verify architectural choices regarding redundancy and partitioning. DFA analyzes various aspects of software architecture, including timing, memory, and information exchange.
Fault Injection Testing (System/Integration Level): Considered part of system testing, its results can validate the architecture’s resilience to faults.
Confirmation Measures under ISO 26262 Part 2 are independent checks to ensure that ISO 26262 processes and objectives have been met. Regarding architecture, this includes verifying correct ASIL decomposition, confirming DFA execution and resolution, and proving sufficient independence between elements implementing redundant safety requirements. For ASIL (B), C, and D items, Functional Safety Audits and Assessments are crucial.
Early validation of the architecture through static analysis and formal reviews significantly reduces project risk and rework. Therefore, investing in robust architectural V&V methods and tools pays off in terms of reduced integration issues, cost savings, and improved confidence in safety. The V&V activities for architecture are part of building the “argument” or “case” that the architecture is safe and meets its assigned safety requirements, and the related deliverables (review reports, analysis results, tool outputs, etc.) are essential components of the overall safety case submitted for assessment and certification.
Proactive Architecture Design for a Safer Automotive Future
As we’ve explored, ASIL levels are more than just compliance items; they are essential guidelines that direct software architecture to manage risks appropriately. Integrating functional safety considerations into the architecture design process from the early stages of development is far more effective than attempting to “add” safety later. A well-designed and ASIL-appropriate architecture plays a fundamental role in creating reliable, robust, and certifiable safe automotive software.
The automotive industry faces new challenges, including the increasing complexity of ADAS and autonomous driving systems, ensuring the safety of AI/ML components, the interaction between cybersecurity (ISO 21434, etc.) and functional safety, and managing high-voltage systems in electric vehicles. In this environment, the importance of architectural solutions will only grow.
Companies that skillfully execute ASIL-driven architectural design can develop safer systems more efficiently. Smart architectures that effectively meet high ASIL requirements can shorten time-to-market, reduce development costs, and build a strong reputation for safety and reliability. This can be a significant competitive advantage in the automotive industry. Therefore, investing in architectural capabilities and expertise for functional safety is not just a technical decision but a strategic business decision.
As new technologies (AI, SoCs, multi-sensor fusion, etc.) are introduced, software architecture must evolve to address new types of risks and ensure safety. While the principles of ISO 26262 will remain, their application in architectural design will require continuous adaptation. The field of safety-critical software architecture is dynamic, and continuous learning and adaptation of architectural patterns, as well as the development of new V&V techniques for architecture, will be essential for the industry. Ultimately, a proactive, safety-first architectural design approach will be the core driving force in creating a safer automotive future. Partner with Hermes Solution to build a safer automotive future!
