Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-3:2018 Road Vehicles — Functional Safety — Part 3: Concept Phase
Hazard Analysis and Risk Assessment (HARA) — Item Definition, Functional Safety Concept for Automotive
1. The Concept Phase: Foundation of Automotive Functional Safety
ISO 26262-3:2018 defines the requirements for the concept phase of automotive functional safety development. This phase is the critical front-end engineering stage where the fundamental safety architecture is defined, hazards are identified and classified, and the initial safety requirements are established. The quality of work performed during the concept phase directly determines the effectiveness and efficiency of all subsequent development activities.
The concept phase consists of three primary activities: item definition (Clause 5), hazard analysis and risk assessment (HARA, Clause 6), and functional safety concept development (Clause 7). These activities form a logical sequence where understanding what the system is (item definition) leads to understanding what can go wrong (HARA), which in turn drives what must be done about it (functional safety concept).
Invest sufficient time in the item definition phase. A well-defined item boundary, with clear interfaces and dependencies documented, makes the subsequent HARA more efficient and reduces the likelihood of missing hazards due to incomplete scope definition.
| Concept Phase Activity | Objective | Key Output |
|---|---|---|
| Item Definition (Clause 5) | Define the item, its boundaries, interfaces, and dependencies | Item definition document |
| Hazard Analysis & Risk Assessment (Clause 6) | Identify and classify hazardous events, determine safety goals and ASILs | HARA report, safety goals |
| Functional Safety Concept (Clause 7) | Derive functional safety requirements from safety goals | Functional safety requirements specification |
2. Hazard Analysis and Risk Assessment (HARA)
The HARA process is the cornerstone of ISO 26262 risk determination. It systematically identifies potential hazards caused by the malfunctioning behaviour of E/E systems and evaluates the associated risk to determine the required Automotive Safety Integrity Level (ASIL) for each safety goal. The HARA follows a structured methodology: situation analysis and hazard identification, hazard classification, and determination of safety goals.
Hazard classification uses three parameters: Severity (S) — the potential harm to persons, ranging from S0 (no injuries) to S3 (life-threatening injuries); Exposure (E) — the likelihood of the operational situation where the hazard could occur, ranging from E0 (incredible) to E4 (high probability); and Controllability (C) — the ability of the driver or others to avoid harm, ranging from C0 (controllable in general) to C3 (difficult to control or uncontrollable). The combination of S, E, and C determines the ASIL (A through D) or QM.
The most common HARA mistake is underestimating exposure. Engineers often classify operational situations based on their personal experience rather than objective usage data. Always use field data, fleet studies, and usage statistics when available to support exposure classifications.
The 2018 edition introduced important refinements to the HARA process. The management of variances in T&B (trucks and buses) was added, recognizing that commercial vehicles have different operational profiles and risk characteristics than passenger cars. The standard also provides more detailed guidance on the verification of the HARA, requiring that the analysis be reviewed for completeness, correctness, and consistency.
3. Functional Safety Concept and Engineering Design Insights
The functional safety concept (FSC) translates the safety goals into functional safety requirements (FSRs) at the system level. Each FSR specifies a safety mechanism or measure to be implemented, along with its associated ASIL, fault-tolerant time interval, and safe state. The FSC also defines the necessary fault detection and failure mitigation mechanisms, the transition logic to safe states, and the driver warning concepts.
A well-structured functional safety concept should clearly separate the “what” from the “how.” The FSC defines what safety mechanisms are required (e.g., “detect sensor plausibility failure within 100ms”), while the technical safety concept and hardware/software design define how to implement them.
Safety validation criteria (Clause 7.4.3) are defined during the concept phase to establish how the adequacy of the safety goals and functional safety concept will be demonstrated. These criteria should include the methods for validating that each safety goal is correct, complete, and sufficiently tolerant of faults. The safety validation typically includes vehicle-level tests, system-level tests, and analysis.
Verification of the functional safety concept (Clause 7.4.4) must ensure that the FSCs are consistent with the item definition, the safety goals, and the classification parameters. The verification also checks that the FSRs are allocated to the system architecture elements appropriately and that the resulting safety mechanisms are capable of achieving the required risk reduction within the specified timing constraints.
Critical design consideration: The FTTI (fault-tolerant time interval) defined in the FSC must be feasible for the intended implementation technology. A common issue is specifying an FTTI that cannot be achieved by the selected sensors, actuators, and processing hardware. Always perform a timing feasibility analysis before finalizing FTTI requirements.
Frequently Asked Questions
Q1: How many safety goals should a typical item have?
There is no fixed number, as it depends on the complexity of the item and the number of distinct hazardous events. Typical items may have 3-15 safety goals. Each distinct hazardous event that requires a different risk reduction strategy should have its own safety goal. However, similar hazards with the same ASIL may be combined into a single safety goal if they can be addressed by the same safety measures.
There is no fixed number, as it depends on the complexity of the item and the number of distinct hazardous events. Typical items may have 3-15 safety goals. Each distinct hazardous event that requires a different risk reduction strategy should have its own safety goal. However, similar hazards with the same ASIL may be combined into a single safety goal if they can be addressed by the same safety measures.
Q2: Can a safety goal have ASIL D for one parameter but lower for others?
No. The ASIL is determined by the combination of Severity, Exposure, and Controllability according to the ASIL determination table in ISO 26262-3. The highest severity rating dictates the ASIL, but the specific combination must be evaluated using the standard’s matrix. Each hazardous event receives a single ASIL rating.
No. The ASIL is determined by the combination of Severity, Exposure, and Controllability according to the ASIL determination table in ISO 26262-3. The highest severity rating dictates the ASIL, but the specific combination must be evaluated using the standard’s matrix. Each hazardous event receives a single ASIL rating.
Q3: What is the difference between a safety goal and a functional safety requirement?
A safety goal is a top-level safety requirement for a hazardous event (e.g., “The vehicle shall not exceed 5 km/h when the driver is not detected”). A functional safety requirement is derived from a safety goal and specifies a safety mechanism or measure at the system level (e.g., “The occupant detection system shall verify driver presence every 100ms and trigger a safe stop if the driver is absent for more than 2 seconds”).
A safety goal is a top-level safety requirement for a hazardous event (e.g., “The vehicle shall not exceed 5 km/h when the driver is not detected”). A functional safety requirement is derived from a safety goal and specifies a safety mechanism or measure at the system level (e.g., “The occupant detection system shall verify driver presence every 100ms and trigger a safe stop if the driver is absent for more than 2 seconds”).
Q4: How do you handle hazards that are not related to E/E system malfunctions?
ISO 26262 specifically addresses hazards caused by malfunctioning behaviour of E/E systems. Hazards from other causes (e.g., electric shock, fire, toxicity) are excluded unless directly caused by E/E system malfunction. These other hazards should be addressed by other applicable standards or domain-specific safety requirements.
ISO 26262 specifically addresses hazards caused by malfunctioning behaviour of E/E systems. Hazards from other causes (e.g., electric shock, fire, toxicity) are excluded unless directly caused by E/E system malfunction. These other hazards should be addressed by other applicable standards or domain-specific safety requirements.
