In the automotive industry, the increasing prevalence and complexity of Electrical/Electronic (E/E) systems have significantly highlighted the importance of functional safety. ISO 26262 is an international standard addressing the functional safety of these automotive E/E systems, providing a systematic framework for accident prevention and risk management.
In this Hermes solution blog post, we will briefly overview the ISO 26262 standard and delve into the Hazard Analysis and Risk Assessment (HARA) methodology, which is the starting point for functional safety development and the process for setting Safety Goals. We will also explore the verification methodology used to confirm that the defined Safety Goals have been achieved.
ISO 26262 Overview and the Safety Lifecycle
Fundamental Purpose and Scope of ISO 26262
The fundamental purpose of ISO 26262 is to identify, evaluate, and manage unreasonable risks arising from malfunctions of automotive E/E systems, thereby preventing accidents. It is not merely a technical specification but a comprehensive framework encompassing process models for the entire development lifecycle, requirements definition, evidence management, and specific methodologies.
Initially limited to passenger cars weighing up to 3,500kg, the second edition published in 2018 expanded the scope to include all road vehicles except mopeds. The standard’s comprehensiveness was further enhanced with the addition of guidelines for semiconductor safety (Part 11) and application to motorcycles (Part 12).
Safety Lifecycle Approach
ISO 26262 is based on the Safety Lifecycle model. This means that safety-related activities must be systematically performed throughout the entire product lifecycle, starting from the initial concept phase, through development (system, hardware, software), production, operation, service, and finally decommissioning.
The V-Model development process is widely used to visually represent these safety lifecycle activities and clearly show the relationship between development and verification phases. The V-Model depicts the development process in a V-shape: the downward path on the left represents development activities from requirements definition to detailed design and implementation, while the upward path on the right represents verification and integration activities for the outputs of each development phase.
Hazard Analysis and Risk Assessment (HARA) and Safety Goal Setting
Importance of the HARA Process
Hazard Analysis and Risk Assessment (HARA) is a core activity performed in Part 3 (Concept Phase) of the ISO 26262 standard. It is the process of systematically identifying potential hazards that can arise from malfunctions of the item under development, evaluating the associated risks, and deriving the highest-level safety requirements, known as Safety Goals, to mitigate these risks.
HARA is the starting point for the functional safety development process. The Safety Goals and ASIL (Automotive Safety Integrity Level) ratings derived from HARA determine the direction and rigor of all subsequent development and verification activities.
HARA Process Steps
HARA typically consists of the following steps:
Item Definition: Clearly define the scope, functional behavior, boundary conditions, and interfaces with external systems for the system or function being analyzed.
Situation Analysis and Hazard Identification: Analyze various operational scenarios (e.g., highway driving, city driving, parking) and identify potential hazards that could occur due to item malfunction in each scenario.
Hazardous Event Classification: Combine identified hazards with specific operational situations to define concrete hazardous events (e.g., ‘complete failure of the braking system during highway driving’) and predict potential consequences.
Risk Assessment and ASIL Determination: Evaluate three factors – Severity (S), Exposure (E), and Controlability (C) – for each hazardous event to determine the ASIL rating (QM, A, B, C, D).
Safety Goal Definition: Define the highest-level Safety Goals required to reduce the assessed risk to an acceptable level.
Hazard Element Evaluation: Severity (S), Exposure (E), Controlability (C)
The evaluation criteria for Severity (S), Exposure (E), and Controlability (C), the key elements for ASIL determination, are as follows:
Severity (S): Degree of potential injury to the driver, passengers, or other road users if the hazardous event occurs, rated from S0 (No injuries) to S3 (Life-threatening or fatal injuries).
Exposure (E): Probability of the vehicle being in specific operational situations that could lead to the hazardous event, rated from E0 (Extremely unlikely) to E4 (High probability).
Controlability (C): Ability of the driver to respond appropriately and in a timely manner to avoid or mitigate injury or damage if the hazardous event occurs, rated from C0 (Generally controllable) to C3 (Difficult or impossible for most drivers to control).
ASIL Determination and Safety Goal Derivation
The ASIL rating is determined based on the combination of the S, E, and C evaluation results. ASIL is divided into 5 levels, from QM (Quality Management, no specific safety measures required) to ASIL D (the highest risk level). Higher ASIL ratings demand more stringent development processes, verification activities, and independence requirements.
Finally, a Safety Goal is defined for each hazardous event. The Safety Goal is the highest-level safety requirement defined at the vehicle level and inherits the ASIL rating of the corresponding hazardous event.
Definition of the Safety Goal and Requirements Decomposition
Role and Attributes of the Safety Goal
The Safety Goal is the highest-level functional safety requirement aimed at mitigating risks identified through HARA to an ‘acceptable level’. It is defined at the vehicle level, should be functionally oriented, and should avoid specifying particular technical solutions.
Functional Safety Concept and Technical Safety Concept
Safety Goals are progressively elaborated in subsequent development phases:
Functional Safety Concept (FSC): Defines the Functional Safety Requirements (FSRs) necessary to achieve the Safety Goal and outlines the initial system architecture. FSRs are described in terms of the safety-related functions the system must perform, independent of specific implementation methods.
Technical Safety Concept (TSC): Defines the specific Technical Safety Requirements (TSRs) for implementing the FSRs. Unlike FSRs, TSRs include implementation-related details, specifying the behavior of safety mechanisms, interfaces, performance constraints, and more.
Through this process, the Safety Goal (SG) is hierarchically decomposed into SG → FSR → TSR → Hardware Safety Requirements (HSR) / Software Safety Requirements (SSR), ultimately transforming into concrete requirements that can be implemented and verified by developers.
Attributes of Desirable Safety Goals and Requirements
Effective Safety Goals and requirements should possess the following attributes:
Clear/Unambiguous: Meaning should be uniquely interpretable.
Atomic: Describe only a single requirement that cannot be further divided.
Verifiable: Ability to objectively confirm whether the requirement is met.
Feasible: Possible to implement under given constraints.
Consistent: Should not conflict with other requirements.
Complete: Should include all aspects from the higher-level requirement.
Traceable: Clear bidirectional link between the requirement’s source and the item for implementation/verification.
ASIL Decomposition Concept
ISO 26262 permits a special technique called ASIL Decomposition. This involves splitting a single requirement with a high ASIL (e.g., ASIL D) into multiple redundant sub-requirements that together achieve the same Safety Goal, assigning a lower ASIL (e.g., ASIL B(D)) to each sub-requirement.
A key condition for ASIL decomposition is that the elements implementing the decomposed sub-requirements must be sufficiently independent of each other. This must be demonstrated through Dependent Failure Analysis (DFA).
Safety Goal Verification Methodology
Establishing the Verification Plan
The Verification Plan is a document defining the scope, methods, schedule, responsibilities, and required resources for all verification activities to be performed throughout the entire safety lifecycle. It includes verification targets and scope, methods and criteria, environment and tools, schedule and responsibilities, independence requirements, and results reporting and management.
Application of Key Safety Analysis Techniques
ISO 26262 recommends applying various safety analysis techniques to verify the validity of Safety Goals and analyze the causes and effects of potential system failures:
FMEA (Failure Mode and Effects Analysis): A bottom-up, inductive analysis technique to identify potential failure modes of system components and analyze their effects.
FTA (Fault Tree Analysis): A top-down, deductive analysis technique using logic gates to analyze combinations of root causes for a specific undesirable top event.
DFA (Dependent Failure Analysis): Analyzes the possibility of redundant elements failing simultaneously due to a single event or cause to verify independence.
FMEDA (Failure Mode, Effects and Diagnostic Analysis): An extension of FMEA that quantitatively evaluates the effectiveness of diagnostic mechanisms for each hardware component’s failure mode and its effects.
Performing Verification Activities
Actual verification activities include the following methods:
Review: Identifying errors, omissions, and inconsistencies in requirements specifications, design documents, source code, etc.
Static Analysis: Analyzing the structure, style, potential errors, and coding standard compliance of software code without executing it.
Unit Testing: Verifying that the smallest units of software function correctly.
Integration Testing: Verifying that individually tested units interact and function correctly when combined.
System Testing: Verifying that the fully integrated system meets the defined requirements.
Hardware Evaluation: Evaluating hardware components and systems to ensure they meet requirements and safety mechanisms are effective.
Safety Validation: Final confirmation that the developed system satisfies the Safety Goals within the overall vehicle environment.
Building the Safety Case
A Safety Case is a structured set of arguments and evidence demonstrating that the developed system achieves its Safety Goals and possesses sufficient safety. It typically has a structure where a top-level claim is decomposed into specific sub-claims, supported by evidence (e.g., HARA report, safety analysis results, test reports). The Safety Case serves purposes such as building internal confidence, convincing external stakeholders, providing justification for safety approval, knowledge management, and legal defense.
Real-World Application Cases and Challenges
Electric Vehicle Battery Management System (BMS) Case
EV BMS is a safety-critical system due to the risk of lithium-ion battery thermal runaway. Hazardous events related to thermal runaway are likely evaluated as ASIL D (S3, E4, C3). Consequently, a Safety Goal such as “The battery system shall prevent thermal runaway under all operating conditions” is set. This is decomposed into functional safety requirements like cell voltage/temperature monitoring, overcurrent detection, cell balancing, and safe state transitions. Verification involves safety analyses (FMEA, FTA, FMEDA) along with HIL testing, environmental/EMC testing, and vehicle testing.
ADAS (Advanced Driver Assistance Systems) Case
ADAS functions are highly safety-critical as they directly control vehicle behavior. For instance, a malfunction of a Lane Keeping Assist (LKA) system (e.g., unintended steering, excessive steering, steering in the wrong direction) if occurring during high-speed driving, could be evaluated as ASIL D. Accordingly, a Safety Goal like “The LKA system shall not cause steering interventions that jeopardize the vehicle’s safe path” is set, and various safety mechanisms (sensor data validation, algorithm robustness, steering command verification, etc.) are implemented and verified to achieve this.
Key Challenges in Practical Application
Major challenges when applying ISO 26262 include:
Complexity of the standard and difficulty in interpretation.
Organizational cultural resistance to changes in development processes.
Increased cost and development time.
Issues with applying the standard to legacy systems and reusable components.
Lack of tool support and automation.
Difficulty in ensuring standard compliance across the entire supply chain.
Challenges in establishing a robust safety culture within the organization.
Overcoming these challenges requires management’s strong support, systematic training and expert development, standardized processes and templates, utilization of automation tools, strengthening supply chain management, a stepwise adoption and continuous improvement approach, along with the crucial effort of establishing a strong safety culture.
Concluding Thoughts: The Present and Future of Functional Safety
ISO 26262-based Safety Goal setting and verification is not just a formal process of complying with standard requirements. It is a systematic problem-solving process that involves identifying potential risks in advance, clearly setting goals to eliminate or control them, and objectively proving that these goals have been achieved with tangible evidence.
As the automotive industry rapidly evolves with electrification, autonomous driving, and connectivity, an integrated approach considering ISO 26262 alongside SOTIF (ISO 21448) and Cybersecurity (ISO/SAE 21434) standards is becoming increasingly important. Furthermore, continuous development of safety assurance methodologies is needed to address new technology trends like AI/ML-based systems, OTA updates, and data-driven safety analysis.
Recognizing that automotive functional safety goes beyond regulatory compliance and is a core value directly linked to customer lives is essential. Systematic Safety Goal setting and thorough verification according to ISO 26262 will be the most fundamental and critical starting point for these continuous efforts to ensure safety in line with technological advancements. Hermes solution deeply recognizes the importance of this functional safety field and contributes to the technological development for a safe future in the automotive industry.
