ISO 26262 Part 3 Concept Phase: HARA, Hazard Analysis, Risk Assessment, and Safety Goals Explained

Hello, automotive engineers and safety practitioners! Welcome to the third deep-dive post in our comprehensive ISO 26262 series at PiEmbSysTech. In this article, we will thoroughly explore ISO 26262 Part 3 Concept Phase, which is where the entire functional safety journey truly begins for any automotive E/E system.

If Part 1 gave you the language and Part 2 gave you the organizational framework, Part 3 is where you roll up your sleeves and start the actual engineering work. The concept phase is where you define what your system is, identify what can go wrong with it, assess how dangerous each failure scenario is, and establish the top-level safety requirements that will drive every subsequent design decision. Get Part 3 wrong, and every downstream activity – system design, hardware development, software implementation, and testing – will be built on a flawed foundation.

By the end of this article, you will understand every aspect of the ISO 26262 concept phase, from crafting a robust item definition to performing a rigorous HARA, correctly determining ASIL levels, formulating precise safety goals, and developing the functional safety concept that bridges the gap between abstract safety requirements and concrete system design. Let us begin.

Table of Contents

1. What is ISO 26262 Part 3 and Why is It Critical?
2. Structure of Part 3 – The Three Pillars of the Concept Phase
3. Item Definition (Clause 5) – Defining the Scope of Your Safety Analysis
4. What the Item Definition Must Contain
5. Worked Example: Item Definition for an Electric Power Steering (EPS) System
6. Hazard Analysis and Risk Assessment (Clause 6) – The Heart of the Concept Phase
7. HARA Step 1: Situation Analysis and Hazard Identification
8. HARA Step 2: Classification of Hazardous Events
9. Severity (S) Classification – S0 to S3 Explained with Examples
10. Exposure (E) Classification – E0 to E4 Explained with Examples
11. Controllability (C) Classification – C0 to C3 Explained with Examples
12. ASIL Determination – The Complete Lookup Table
13. HARA Step 3: Safety Goal Determination
14. Safety Goal Attributes – ASIL, Safe State, and FTTI
15. Worked Example: Complete HARA for an EPS System
16. Functional Safety Concept (Clause 7) – Bridging Goals to Architecture
17. Functional Safety Requirements (FSRs) – Deriving from Safety Goals
18. Preliminary Architectural Assumptions and FSR Allocation
19. Key Elements of the Functional Safety Concept
20. Verification of Part 3 Work Products
21. Key Work Products of Part 3
22. Common Mistakes in the Concept Phase and How to Avoid Them
23. Frequently Asked Questions
24. Conclusion

1. What is ISO 26262 Part 3 and Why is It Critical?

ISO 26262 Part 3: Concept Phase specifies the requirements for the earliest, most foundational phase of the functional safety lifecycle. It is applied at the very beginning of product development – before any detailed system architecture is designed, before any hardware schematic is drawn, and before any line of software code is written. The concept phase establishes the what and the why of functional safety for a given item, providing the foundation upon which all subsequent how decisions are built.

Part 3 is critical because it determines the entire scope, direction, and rigor of the safety development effort. The ASIL classifications assigned during HARA directly determine which methods and techniques must be used in Parts 4, 5, and 6, how much testing and verification is required, how stringent the hardware metrics targets are, and what level of independence is needed for confirmation measures. An error in the concept phase – a missed hazard, an incorrectly assigned ASIL, an incomplete safety goal – propagates through every downstream activity and can ultimately result in an unsafe product reaching the road.

The concept phase is also where the functional safety concept is developed – the first architectural-level description of how the safety goals will be achieved. This concept defines safe states, fault tolerant time intervals, warning and degradation strategies, and the preliminary allocation of safety requirements to architectural elements. It is the bridge between the abstract world of safety goals and the concrete world of system design.

2. Structure of Part 3 – The Three Pillars of the Concept Phase

ISO 26262-3:2018 is organized around three major normative clauses, each representing a distinct pillar of the concept phase:

Clause 5: Item Definition – This is the starting point. Before you can analyze what can go wrong, you must precisely define what the system is, what it does, how it interfaces with other systems, and under what conditions it operates. The item definition establishes the scope boundary for the entire safety analysis.

Clause 6: Hazard Analysis and Risk Assessment (HARA) – This is the analytical core. Starting from the item definition, the HARA process systematically identifies potential hazardous events, classifies their risk using Severity (S), Exposure (E), and Controllability (C), determines the ASIL for each hazardous event, and formulates safety goals to prevent or mitigate the identified hazards.

Clause 7: Functional Safety Concept – This is the conceptual design response. Based on the safety goals from the HARA, the functional safety concept specifies the functional safety requirements (FSRs), defines safe states and degradation strategies, establishes fault tolerant time intervals, and allocates the FSRs to elements of a preliminary architectural design.

These three clauses flow sequentially but also involve iterative refinement. As the functional safety concept is developed, new insights may require revisiting the item definition or the HARA. This iterative nature is a strength, not a weakness – it ensures that the concept phase outputs are robust and consistent.

3. Item Definition (Clause 5) – Defining the Scope of Your Safety Analysis

The item definition is the first work product of the concept phase and the starting point for the entire ISO 26262 safety lifecycle. An item, as defined in Part 1, is a system or array of systems that implements a function at the vehicle level, to which ISO 26262 is applied. The item definition document describes this system in sufficient detail that the HARA team can systematically identify all relevant hazards.

The quality of the item definition directly determines the quality of the HARA. A vague or incomplete item definition leads to missed hazards, incorrect risk assessments, and gaps in the safety goals. Conversely, a thorough, well-structured item definition enables a comprehensive and efficient HARA process. As Albert Einstein reportedly said, “If I had an hour to save the world, I would spend 59 minutes defining the problem and one minute finding solutions.” The item definition is your 59 minutes.

4. What the Item Definition Must Contain

ISO 26262-3:2018, Clause 5.4.1 and 5.4.2 specify the information that the item definition shall include. The following elements must be addressed:

Description of the item’s functionality: What does the system do at the vehicle level? What is its intended purpose? For example, “The Electric Power Steering (EPS) system provides variable power assistance to the driver’s steering input, reducing the physical effort required to steer the vehicle. The level of assistance varies with vehicle speed – higher assistance at low speeds for parking maneuverability, reduced assistance at high speeds for directional stability.”

Interfaces and interactions with other items, systems, and the environment: How does the item connect to and communicate with other systems in the vehicle? What are the electrical, mechanical, and communication interfaces? For an EPS system, this includes interfaces with the vehicle CAN bus, the vehicle speed sensor, the steering torque sensor, the steering column mechanical assembly, the vehicle power supply, and potentially the electronic stability control (ESC) system.

Known or assumed operational and environmental conditions: Under what vehicle-level conditions does the item operate? This includes speed ranges, temperature ranges, road conditions, loading conditions, and driver behavior assumptions. These operational conditions directly influence the Exposure (E) parameter in the HARA.

Legal requirements and regulations: What regulatory requirements apply to the item’s function? For steering systems, this might include ECE R79 (steering equipment regulations) and national regulations.

Known hazards, if available: Any hazards already identified from prior analyses, field experience with predecessor systems, or published industry data. Leveraging existing knowledge accelerates the HARA and helps ensure completeness.

Boundaries and scope of the item: What is included within the item boundary and what is excluded? Clear boundary definition prevents ambiguity about which components, interfaces, and functions are subject to the safety analysis.

Operating modes: What are the different operating modes of the item? (Active, standby, off, diagnostic mode, calibration mode, etc.) The system’s behavior and potential hazards may differ across operating modes.

Preliminary architecture or block diagram: While detailed design comes later (Part 4), a high-level block diagram showing the major functional elements and their interconnections is typically included in the item definition to provide context for the HARA. This is sometimes called the “item boundary diagram.”

5. Worked Example: Item Definition for an Electric Power Steering (EPS) System

To make the item definition concrete, let us walk through a simplified example for an Electric Power Steering (EPS) system – one of the most commonly analyzed items in ISO 26262 projects due to its ASIL D classification.

Item Name: Column-Assist Electric Power Steering (C-EPS) System

Functionality: The C-EPS system provides electrically generated torque assist to the driver’s steering input via an electric motor mounted on the steering column. The system uses signals from a steering torque sensor (measuring driver input torque), a vehicle speed sensor (via CAN), and a motor position sensor to compute the required assist torque. At low vehicle speeds, higher assist is provided for easy parking. At high vehicle speeds, assist is reduced for stable highway driving. The system also supports Electronic Stability Control (ESC) overlay torque requests for vehicle stability interventions.

Key Interfaces: Steering torque sensor (analog input), motor position sensor (digital input), vehicle speed via CAN bus, ESC overlay torque request via CAN bus, vehicle power supply (12V battery), mechanical coupling to steering column, diagnostic interface (via CAN/UDS).

Operating Modes: Normal driving mode (speed-dependent assist), parking assist mode (maximum assist), standby mode (ignition on, vehicle stationary), limp-home mode (reduced functionality after fault detection), system off (ignition off).

Operational Conditions: Vehicle speed range 0–250 km/h, ambient temperature –40°C to +85°C, battery voltage 9V to 16V, all road surfaces and weather conditions.

Item Boundary: Includes the EPS ECU (with embedded software), the EPS electric motor, the steering torque sensor, the motor position sensor, wiring harness within the EPS assembly, and the mechanical interface to the steering column. Excludes the vehicle battery, CAN bus network, ESC system, vehicle speed sensor (these are external interfaces).

6. Hazard Analysis and Risk Assessment (Clause 6) – The Heart of the Concept Phase

The Hazard Analysis and Risk Assessment (HARA) is the central activity of the ISO 26262 Part 3 concept phase. It is the systematic process through which potential hazards caused by the malfunctioning behavior of the item are identified, the associated risks are assessed, and the resulting safety goals and ASIL classifications are established. The HARA outputs drive the entire downstream development effort.

The HARA process can be broken down into three major steps: situation analysis and hazard identification (determining what can go wrong and in which driving scenarios), classification of hazardous events (assessing Severity, Exposure, and Controllability for each scenario to determine the ASIL), and safety goal determination (formulating top-level safety requirements to address each identified hazardous event).

The HARA should be performed by a multidisciplinary team that includes safety engineers, system engineers with deep domain knowledge of the item, and ideally, experienced drivers or human factors specialists who can provide realistic assessments of controllability. The standard recommends using established analysis methods such as FMEA, HAZOP, or similar systematic hazard identification techniques. The team should consider all relevant operational situations, all plausible malfunctioning behaviors, and all potential consequences at the vehicle level.

7. HARA Step 1: Situation Analysis and Hazard Identification

The first step of the HARA process involves two parallel activities: defining the relevant operational situations and identifying the possible malfunctioning behaviors of the item.

Defining Operational Situations

Operational situations describe the vehicle-level driving scenarios in which the item functions. The set of operational situations should be comprehensive enough to cover all reasonably foreseeable driving conditions. Typical operational situations include parking and maneuvering at very low speed, urban driving at low to moderate speed with frequent stops, rural road driving at moderate speed with curves and intersections, highway driving at high speed, mountain road driving with steep grades and tight curves, driving on slippery surfaces (rain, ice, snow), driving in poor visibility conditions (fog, night), and driving in heavy traffic with pedestrians and cyclists.

The operational situations directly feed into the Exposure (E) parameter of the ASIL determination – more common situations receive higher E ratings.

Identifying Malfunctioning Behaviors

For each function of the item, the HARA team must identify all plausible malfunctioning behaviors – ways in which the function could fail or behave unintentionally. These are typically expressed at the vehicle level in terms of their effect, not in terms of the underlying technical cause. For our EPS example, malfunctioning behaviors might include unintended steering assist (the system applies torque without driver input), loss of steering assist (the system stops providing assist while driving), reduced steering assist (the system provides less assist than intended), excessive steering assist (the system provides more assist than intended), steering assist in wrong direction (the system applies torque opposite to the driver’s intended direction), and intermittent or oscillating steering assist (the system alternates between providing and not providing assist erratically).

Combining to Form Hazardous Events

A hazardous event is a specific combination of a malfunctioning behavior (hazard) and an operational situation. For each identified malfunctioning behavior, the team considers which operational situations are relevant and creates hazardous event entries for each meaningful combination. For example: “Loss of steering assist while driving on a curved mountain road at moderate speed” is one hazardous event. “Loss of steering assist while parking at very low speed” is a different hazardous event – the same malfunction, but in a different operational situation with a very different risk profile.

Not every combination needs to be analyzed separately. If the risk classification (S, E, C) would be identical across several similar operational situations, they can be grouped. The goal is completeness without unnecessary redundancy.

8. HARA Step 2: Classification of Hazardous Events

For each identified hazardous event, the HARA team classifies three risk parameters: Severity (S), Exposure (E), and Controllability (C). The combination of these three parameters determines the ASIL using the standard’s classification table.

9. Severity (S) Classification – S0 to S3 Explained with Examples

Severity describes the extent of potential harm to the vehicle occupants or other road users if the hazardous event leads to an accident. It is classified into four levels:

S0 – No injuries: The hazardous event, even if it results in an accident, would not cause any physical injuries. Example: A malfunction in the interior lighting system that causes momentary distraction but no physical consequences.

S1 – Light and moderate injuries: Injuries that are not life-threatening. Recovery is expected without permanent disability. Examples include minor whiplash, superficial cuts, or bruises. For EPS: a very slow, gradual degradation of steering assist that the driver easily compensates for, resulting at worst in a minor low-speed contact with a curb.

S2 – Severe and life-threatening injuries (survival probable): Serious injuries where survival is likely but with the possibility of permanent effects. Examples include bone fractures, severe head injuries with recovery, or internal injuries requiring hospitalization. For EPS: sudden loss of steering assist at moderate speed, resulting in the vehicle departing the lane and striking a roadside barrier.

S3 – Life-threatening injuries (survival uncertain) or fatal: Injuries where survival is uncertain, or death results. Examples include severe head trauma, spinal injuries, or any scenario resulting in fatalities. For EPS: unintended steering torque application in the wrong direction at highway speed, causing the vehicle to cross into oncoming traffic in a head-on collision scenario.

Severity is assessed based on the worst-case realistic outcome of the hazardous event at the vehicle level. It considers harm to the driver, passengers, other vehicle occupants, pedestrians, and other road users.

10. Exposure (E) Classification – E0 to E4 Explained with Examples

Exposure describes the probability that the vehicle will be operating in the specific operational situation where the hazardous event can occur. It is classified into five levels:

E0 – Incredible: The operational situation essentially never occurs during the vehicle’s lifetime. This classification effectively removes the hazardous event from further consideration (it results in QM regardless of S and C).

E1 – Very low probability: The situation occurs rarely. Example: driving through a deep water crossing, or driving on an extremely steep unpaved mountain trail. This might apply to specialty off-road scenarios that most vehicles encounter only a few times in their lifetime.

E2 – Low probability: The situation occurs infrequently but is not rare. Example: driving on icy roads (for vehicles in temperate climates), or driving in heavy fog. The situation is encountered perhaps several times per year.

E3 – Medium probability: The situation occurs with moderate frequency. Example: driving in heavy city traffic, or driving in rain. The situation is encountered regularly during normal vehicle use — perhaps several times per month or more frequently.

E4 – High probability: The situation is encountered in nearly every driving trip. Example: driving at highway speed, urban driving with pedestrians present, or normal straight-road driving. This is the most common exposure level for typical driving scenarios.

Exposure is assessed based on the general population of drivers and driving conditions, not based on a specific individual’s driving habits. It represents the probability for an average vehicle over its expected operational lifetime.

11. Controllability (C) Classification – C0 to C3 Explained with Examples

Controllability describes the probability that the driver or other road users can take timely and effective action to avoid the harm once the hazardous event has occurred. It is classified into four levels:

C0 – Controllable in general: Almost all drivers can handle the situation. The hazardous event produces a condition that is easily managed through normal driving actions.

C1 – Simply controllable: More than 99% of drivers can typically manage the situation. The required driver action is simple and intuitive. Example: a gradual, slow loss of power steering assist that the driver can compensate for by applying more force to the steering wheel. Most drivers would notice the change and adapt without significant difficulty.

C2 – Normally controllable: Most drivers can manage the situation, but some may not — particularly less experienced drivers, elderly drivers, or drivers who are momentarily distracted. Example: a sudden partial loss of steering assist that requires immediate corrective steering input. Most attentive drivers would manage, but a distracted or inexperienced driver might fail to react in time.

C3 – Difficult to control or uncontrollable: Even skilled, attentive drivers may be unable to prevent the harmful outcome. Example: a sudden application of full steering torque in the wrong direction at highway speed – the unexpected vehicle motion is so fast and counterintuitive that effective driver intervention is extremely difficult or impossible.

Controllability assessment requires careful consideration of driver reaction times, the nature and speed of the failure effect at the vehicle level, the available time for the driver to perceive, diagnose, and respond to the hazard, and the physical capability of the driver to counteract the failure. For systems where controllability assessment is uncertain, empirical studies or expert rider/driver panels may be used, as recommended in the standard.

12. ASIL Determination – The Complete Lookup Table

Once S, E, and C are determined for each hazardous event, the ASIL is determined using the standard’s classification table. The following table shows all possible combinations:

Severity	Exposure	C1	C2	C3
S1	E1	QM	QM	QM
	E2	QM	QM	QM
	E3	QM	QM	A
	E4	QM	A	B
S2	E1	QM	QM	QM
	E2	QM	QM	A
	E3	QM	A	B
	E4	A	B	C
S3	E1	QM	QM	A
	E2	QM	A	B
	E3	A	B	C
	E4	B	C	D

Key observations from the table: ASIL D – the highest integrity requirement – can only be reached when all three parameters are at their maximum relevant levels: S3 (fatal/life-threatening), E4 (high probability situation), and C3 (difficult to control). Any reduction in even one parameter drops the ASIL. This graduated approach ensures that development rigor is proportional to actual risk. Note that S0 and E0 always result in QM regardless of the other parameters, as there is either no injury potential or no realistic exposure.

13. HARA Step 3: Safety Goal Determination

For each hazardous event that is assigned an ASIL of A, B, C, or D, a safety goal must be determined. The safety goal is the top-level safety requirement for the item, expressed as a condition or behavior to be maintained or avoided to prevent or mitigate the hazardous event.

Characteristics of Good Safety Goals

Safety goals must be expressed at the vehicle level – they describe what the vehicle-level behavior should be, not how the internal system should be designed. They must be implementation-independent – they state the required safe behavior without specifying particular technical solutions. They must be testable and verifiable – it must be possible to objectively determine whether the safety goal is achieved in the final vehicle. They must be complete – every identified hazardous event with ASIL A or higher must be addressed by at least one safety goal.

Good safety goal example: “The EPS system shall prevent unintended application of steering torque.” (This states what must be prevented, not how. It can be tested. It addresses the hazard at the vehicle level.)

Poor safety goal example: “The EPS microcontroller shall have a watchdog timer.” (This is a technical solution, not a safety goal. It is implementation-specific. It does not describe the vehicle-level safe behavior.)

Combining Safety Goals

If multiple hazardous events lead to similar safety goals, these may be combined into a single safety goal, provided the combined safety goal is assigned the highest ASIL of all the hazardous events it covers. For example, if “unintended steering torque at highway speed” is ASIL D and “unintended steering torque at moderate city speed” is ASIL C, both can be covered by a single safety goal “prevent unintended steering torque application” assigned ASIL D.

14. Safety Goal Attributes – ASIL, Safe State, and FTTI

Each safety goal is accompanied by several important attributes that guide the downstream development.

ASIL: The safety goal inherits the ASIL of the hazardous event it addresses (or the highest ASIL, if it covers multiple hazardous events).

Safe State: For each safety goal, a safe state must be defined – the operating mode that the item shall transition to if the safety goal cannot be maintained. For EPS, the safe state for “prevent unintended steering torque” might be “motor de-energized, manual steering only” – the driver can still steer, but without electrical assist. For some safety goals, the safe state may be a degraded operating mode rather than complete shutdown.

Fault Tolerant Time Interval (FTTI): The maximum time from the occurrence of a fault to the potential occurrence of a hazardous event if no safety mechanism intervenes. For EPS, the FTTI for an unintended torque fault might be on the order of tens of milliseconds – because an unexpected torque application can cause the vehicle to deviate from its lane within a very short time. The FTTI drives the timing requirements for all diagnostic safety mechanisms in the system.

15. Worked Example: Complete HARA for an EPS System

Let us walk through a simplified but representative HARA example for our EPS item to illustrate how the entire process comes together. Note that a real EPS HARA would contain many more entries — this is a condensed illustration.

Hazardous Event	S	E	C	ASIL	Safety Goal
Unintended steering torque in wrong direction at highway speed	S3	E4	C3	D	SG1: Prevent unintended steering torque application [ASIL D]
Sudden complete loss of steering assist at highway speed	S3	E4	C2	C	SG2: Prevent sudden, unexpected loss of steering assist [ASIL C]
Excessive steering assist at moderate city speed	S2	E4	C2	B	SG3: Prevent excessive steering assist beyond calibrated limits [ASIL B]
Loss of steering assist while parking at very low speed	S1	E4	C1	QM	No specific safety goal required (QM)

This table demonstrates how the same item (EPS) can generate hazardous events ranging from ASIL D to QM, depending on the combination of severity, exposure, and controllability. The highest ASIL – ASIL D for SG1 – drives the most stringent development requirements for the entire EPS system, because any element that contributes to the achievement of SG1 must be developed to ASIL D rigor (or the requirement must be decomposed through ASIL decomposition as defined in Part 9).

16. Functional Safety Concept (Clause 7) – Bridging Goals to Architecture

The functional safety concept (FSC) is the third major work product of the concept phase. It takes the safety goals from the HARA and translates them into functional safety requirements (FSRs) that describe, at a functional level, how those safety goals will be achieved. The FSC also defines the preliminary architectural assumptions, the allocation of FSRs to architectural elements, and the interactions between those elements necessary for safety.

The functional safety concept is the critical bridge between the “what” (safety goals — what must be achieved) and the “how” (technical safety concept in Part 4 – how it will be technically implemented). The FSC remains at an implementation-independent or semi-independent level – it describes the required safety behaviors and mechanisms without fully specifying the hardware and software implementation details.

17. Functional Safety Requirements (FSRs) – Deriving from Safety Goals

At least one functional safety requirement must be specified for each safety goal. In practice, multiple FSRs are typically derived from each safety goal, addressing different aspects of achieving or maintaining the safety goal. FSRs shall address the following aspects (as specified in Clause 7.4.2):

Fault prevention and avoidance: Requirements to prevent the fault from occurring in the first place. Example: “The EPS ECU software shall implement MISRA-C compliant coding standards to minimize the likelihood of systematic software faults.”

Fault detection and notification: Requirements for detecting faults and notifying the driver or other systems. Example: “The EPS system shall detect loss of the steering torque sensor signal within 10 ms and illuminate the EPS warning lamp within 100 ms.”

Transition to safe state: Requirements for transitioning the system to a safe state when a fault is detected that cannot be tolerated. Example: “Upon detection of a fault that could result in unintended torque application, the EPS system shall de-energize the motor drive within the FTTI (e.g., 50 ms) and transition to manual steering mode.”

Fault tolerance: Requirements for continued operation (possibly degraded) in the presence of certain faults. Example: “The EPS system shall maintain reduced steering assist in the event of a single sensor fault, by using the remaining independent sensor for continued operation in a degraded mode.”

Driver warning and degradation strategy: Requirements for how the driver is informed of degraded operation and what actions are expected. Example: “The EPS system shall provide a graduated warning to the driver: amber warning lamp for degraded mode, red warning lamp with audible alert for imminent loss of assist.”

FTTI and timing: Requirements specifying the time constraints for fault detection, reaction, and safe state transition. Example: “The total time from fault occurrence to safe state activation shall not exceed the FTTI of 50 ms, with a maximum fault detection time of 20 ms and a maximum fault reaction time of 30 ms.”

Arbitration: Requirements for managing conflicts when multiple safety functions issue competing demands simultaneously. Example: “In case of conflict between the EPS safety function and the ESC overlay request, the EPS safety function shall take priority.”

Each FSR inherits the ASIL of the safety goal from which it is derived (unless ASIL decomposition is applied as per Part 9).

18. Preliminary Architectural Assumptions and FSR Allocation

The functional safety concept includes preliminary architectural assumptions — a high-level system architecture that identifies the major functional blocks and their roles in achieving the safety goals. This preliminary architecture does not need to be final or detailed (that comes in Part 4), but it must be sufficient to enable the allocation of FSRs to architectural elements.

For our EPS example, the preliminary architecture might identify the following major elements: EPS ECU (processing and control), steering torque sensor assembly, motor position sensor, EPS electric motor and power drive stage, vehicle interface (CAN communication), and driver interface (warning indicators). Each FSR is then allocated to one or more of these architectural elements. For instance, “detect loss of torque sensor signal within 10 ms” might be allocated to the EPS ECU, while “illuminate EPS warning lamp within 100 ms” might be allocated to both the EPS ECU (for generating the warning request) and the vehicle interface (for transmitting the request to the instrument cluster via CAN).

This allocation creates the foundation for the technical safety concept in Part 4 and the subsequent hardware (Part 5) and software (Part 6) safety requirements.

19. Key Elements of the Functional Safety Concept

A complete functional safety concept document typically includes the safety goals and their attributes (ASIL, safe state, FTTI), the complete set of functional safety requirements derived from each safety goal, the preliminary system architecture showing the major functional elements, the allocation of FSRs to architectural elements, the definition of safe states for each safety goal (with justification for why each state is considered safe), the warning and degradation concept (how the driver is informed, what degraded modes are available, what driver actions are expected), the timing concept (FTTI budgets, fault detection intervals, fault reaction intervals), the arbitration strategy for conflicting safety demands, the consideration of external measures (actions by the driver or other systems that contribute to risk reduction and were credited during HARA through the Controllability parameter), and the preliminary assessment of interactions between the item and other vehicle systems relevant to safety.

20. Verification of Part 3 Work Products

All work products of the concept phase must be verified in accordance with ISO 26262-8 Clause 9. This includes verifying the completeness and correctness of the item definition, the completeness and consistency of the HARA (including the correctness of S, E, C classifications and ASIL determinations), the consistency of safety goals with the identified hazardous events, and the completeness, consistency, and feasibility of the functional safety concept and FSRs. Verification is typically performed through formal reviews by qualified reviewers who are independent of the authoring team (as defined by the independence requirements in Part 2 for the applicable ASIL). A confirmation review of the HARA and safety goals is also required as part of the confirmation measures.

21. Key Work Products of Part 3

The concept phase produces the following essential work products: the item definition document, the HARA report (including the complete hazardous event table with S, E, C classifications and ASIL determinations), the safety goals specification (with attributes including ASIL, safe state, and FTTI), the functional safety concept document (including all FSRs, preliminary architecture, FSR allocation, safe state definitions, and timing concepts), and verification reports for each of the above work products. These work products are added to the safety case and form the foundation for all subsequent development activities in Parts 4, 5, and 6.

22. Common Mistakes in the Concept Phase and How to Avoid Them

Mistake 1: Incomplete hazard identification. The most dangerous error is missing a hazardous event entirely. If a hazard is not identified during HARA, no safety goal will be defined for it, and no safety mechanism will be designed to prevent it. Use multiple hazard identification methods (FMEA, HAZOP, brainstorming with domain experts) and cross-reference with industry databases and predecessor system data to maximize completeness.

Mistake 2: Assessing S, E, C at the component level instead of the vehicle level. HARA must be performed at the vehicle level. The question is not “what happens to the ECU?” but “what happens to the vehicle and its occupants?” Always trace the failure effect all the way up to the vehicle-level consequence before classifying severity.

Mistake 3: Overly optimistic controllability assessment. There is a natural temptation to assume that drivers will react perfectly and quickly to any failure indication. In reality, drivers may be distracted, fatigued, elderly, or inexperienced. Base controllability assessments on realistic, evidence-based assumptions about the general driver population, not on the capabilities of an expert test driver.

Mistake 4: Writing implementation-specific safety goals. Safety goals must state what must be achieved or prevented, not how. “The EPS shall prevent unintended torque” is a safety goal. “The EPS shall use dual redundant sensors” is a design decision, not a safety goal. Keep safety goals at the behavioral level.

Mistake 5: Not defining FTTI. The FTTI is a critical parameter that drives the timing requirements for all safety mechanisms. Failing to define FTTI during the concept phase forces ad-hoc timing decisions during hardware and software development, which often results in safety mechanisms that are too slow to prevent the hazardous event.

Mistake 6: Treating HARA as a one-time activity. HARA should be revisited when significant changes occur – new functions are added, the system architecture changes, new operational scenarios are identified, or field data reveals previously unknown failure modes. A robust HARA is a living analysis, not a frozen document.

23. Frequently Asked Questions

Q1: Who should participate in the HARA?

The HARA team should be multidisciplinary: system engineers with deep domain knowledge of the item, functional safety engineers who understand the ISO 26262 methodology, and ideally, human factors or vehicle dynamics specialists who can provide informed assessments of controllability. The team should collectively understand the vehicle-level context, the operational environments, and the potential failure effects.

Q2: How many hazardous events should a typical HARA contain?

There is no fixed number. A simple item (like a horn controller) might have a handful of hazardous events. A complex item (like an EPS or ADAS system) might have dozens or even over a hundred. The goal is completeness – every reasonably foreseeable combination of malfunction and operational situation should be considered. Grouping similar scenarios is acceptable to avoid unnecessary redundancy.

Q3: Can a safety goal have multiple ASILs?

A single safety goal has a single ASIL – the highest ASIL of all hazardous events it addresses. However, different safety goals for the same item can have different ASILs. For example, the EPS might have SG1 at ASIL D and SG2 at ASIL C.

Q4: What if a hazardous event results in QM?

If the ASIL determination results in QM, no specific ISO 26262 safety requirements apply to that hazardous event. Standard quality management processes (as defined by the organization’s QMS) are sufficient. However, it is good practice to document the QM classification in the HARA for completeness and traceability.

Q5: What is the difference between a safety goal and a functional safety requirement?

A safety goal is a top-level, vehicle-level safety requirement that states what must be achieved or prevented. A functional safety requirement is a more detailed requirement that specifies how the safety goal will be achieved at a functional/architectural level — including fault detection strategies, safe state transitions, timing requirements, and warning concepts. Safety goals live at the vehicle level; FSRs live at the system architectural level.

Q6: Can the HARA be performed before the item definition is complete?

The HARA depends on the item definition for its inputs – the functions, interfaces, operational conditions, and boundaries of the item must be understood before hazards can be systematically identified. However, the two activities often proceed iteratively: an initial item definition enables a preliminary HARA, and insights from the HARA may reveal the need to refine the item definition.

24. Conclusion

The ISO 26262 Part 3 concept phase is where the functional safety journey begins in earnest. The item definition establishes the scope, the HARA identifies and classifies the risks, the safety goals define the top-level safety requirements, and the functional safety concept translates those goals into actionable requirements that can be allocated to system elements. Every downstream activity – system design (Part 4), hardware development (Part 5), software implementation (Part 6), and testing – depends on the quality and completeness of the concept phase outputs.

Investing the time and expertise to perform a thorough item definition, a comprehensive HARA, and a robust functional safety concept is the single most impactful investment an organization can make in its functional safety process. Errors caught during the concept phase cost a fraction of what they cost when discovered during integration testing, vehicle validation, or – worst of all – in the field.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech. Next in our series: ISO 26262 Part 4 – Product Development at the System Level, where we will explore the technical safety concept, system architecture design, FMEA/FTA, and system integration testing. Be sure to also review our earlier posts on Part 1 – Vocabulary and Part 2 – Functional Safety Management.

Stay safe. Stay analytical. Keep engineering the future.

— The PiEmbSysTech Team