What Is a HARA and Why Does It Define Everything Downstream?
Hazard Analysis and Risk Assessment (HARA) is the cornerstone of ISO 26262 functional safety. Get it right and your safety goals are defensible, your ASIL ratings are traceable, and your audit goes smoothly. Get it wrong and every work product downstream is built on a shaky foundation.
HARA is defined in ISO 26262 Part 3. Its output — a set of safety goals with ASIL ratings — drives everything: Functional Safety Concepts, Technical Safety Concepts, software/hardware requirements, FMEA, FMEDA, verification activities. Everything.
Step 1: Define the Item and Its Operational Situations
Before you can identify hazards, you need to define what the item is and what situations it operates in.
Item: The system or function being analyzed. Example: Electronic Power Steering (EPS) control unit.
Operational situations: The contexts in which the item operates that are relevant to safety. For EPS:
- High-speed highway driving
- Low-speed parking maneuver
- Emergency lane-change at 80 km/h
- Vehicle stationary, engine running
Don't skip this step. Auditors will ask which operational situations were considered and which were excluded (and why).
Step 2: Identify Hazardous Events
A hazardous event is a combination of a hazard (a malfunctioning behavior) and an operational situation in which it could cause harm.
| Hazard | Operational Situation | Hazardous Event |
|---|---|---|
| Unintended steering assist (left) | High-speed highway driving | Vehicle drifts into adjacent lane at 120 km/h |
| Loss of steering assist | Low-speed parking | Driver unable to steer — minor consequence |
| Unintended steering assist (left) | Emergency lane change | Compounded uncontrolled trajectory |
ISO 26262 recommends starting with malfunctioning behaviors of the item (not component failures). The question is: what could the item do wrong?
Step 3: Classify Each Hazardous Event — S, E, C
Each hazardous event gets rated on three parameters:
Severity (S0–S3)
How bad could the injuries be?
- S0: No injuries
- S1: Light to moderate (no life-threatening)
- S2: Severe to life-threatening, survival probable
- S3: Life-threatening to fatal, survival uncertain
Exposure (E0–E4)
How often is the vehicle in this operational situation?
- E0: Incredibly unlikely
- E1: Very low probability
- E2: Low probability
- E3: Medium probability
- E4: High probability (occurs on most drives)
Controllability (C0–C3)
What fraction of drivers could control the situation?
- C0: Controllable by virtually all
- C1: Simply controllable
- C2: Normally controllable
- C3: Difficult to control (less than ~90% of drivers)
Step 4: Determine ASIL
ASIL is determined from S, E, C using the lookup table in ISO 26262-3 Table 4.
Example: Unintended steering assist at highway speed
- S = S3 (potentially fatal)
- E = E3 (highway driving is frequent)
- C = C3 (difficult to control at speed)
- Result: ASIL D
Example: Loss of steering assist during parking
- S = S1 (low speed, minor injury possible)
- E = E4 (parking happens every trip)
- C = C1 (driver can use muscle power)
- Result: ASIL A
When S=S0 or C=C0, the result is QM (Quality Management — no functional safety requirement).
Step 5: Formulate Safety Goals
Each hazardous event with ASIL A–D gets a safety goal. Safety goals are top-level safety requirements — they describe what the item must NOT do (or must do to prevent the hazard).
Example safety goal: The EPS shall not apply unintended steering torque exceeding 3 Nm when vehicle speed is above 60 km/h. [ASIL D]
Safety goals must be:
- Expressed without reference to implementation
- Linked to specific hazardous events
- Assigned a safe state and FTTI (Fault Tolerant Time Interval)
Common HARA Mistakes
- Conflating hazard with failure cause. A HARA hazard is a malfunctioning behavior, not a broken component. "Sensor fails" is not a HARA hazard. "Unintended acceleration" is.
- Underrating exposure. Safety teams often rate E as E2 when E3 or E4 is more defensible. Auditors spot this pattern.
- Missing operational situations. Software update mode, towing, factory test mode — these are operational situations too.
- Safety goals that reference implementation. "The microcontroller shall not send an erroneous CAN message" is an FSC requirement, not a safety goal.
How ISO WIZ Automates HARA
ISO WIZ provides a guided HARA wizard that walks you through item definition, operational situation enumeration, hazardous event identification, S/E/C rating with ISO clause references, and automatic ASIL determination. All entries are linked to downstream safety goals, and the traceability engine flags any safety goal that lacks a complete S/E/C justification.
Safety goals created in HARA automatically propagate to the Functional Safety Concept module, eliminating copy-paste errors. And if a hazardous event is also relevant to your SOTIF or cybersecurity analysis, ISO WIZ surfaces that connection automatically.
ISO 26262 · SOTIF · ISO 21434 · ASPICE — one platform
ISO WIZ harmonizes all four standards into a single workflow with shared traceability, cross-standard gap detection, and no spreadsheet maintenance.
Try ISO WIZ Free →