Before walking through the process, it is worth being explicit about what a HARA is supposed to produce, because the deliverables structure the entire analysis.
A completed HARA produces:
- A list of hazardous events — specific combinations of hazardous situations and operating scenarios that can result in harm
- An ASIL rating for each hazardous event, derived from severity (S), exposure (E), and controllability (C) ratings
- A list of safety goals — functional requirements at the highest level of abstraction that must be satisfied to prevent or mitigate each hazardous event
- A ASIL rating for each safety goal, inherited from the highest-ASIL hazardous event that the safety goal addresses
Everything else in ISO 26262 is derived from this output.
Step 1: Define the Item
The HARA scope is the item — the system or subsystem being analyzed. ISO 26262-3 Clause 5 requires an item definition that specifies the item's functions, the interfaces between the item and other systems, and the operating modes and scenarios relevant to the item.
Getting the item boundary right matters. If the item is defined too narrowly — for example, defining the AEB ECU as the item while excluding the radar sensor — you will miss hazardous events that arise from the interface between the ECU and sensor. If the item is defined too broadly — the entire vehicle — the HARA becomes unmanageable.
For most ADAS systems, the item includes the processing unit, its input sensors, its output actuators (or the commands it sends to actuators), and the human-machine interface elements relevant to the system's safety function.
The item definition must include operating scenarios: the conditions under which the system is used. For an AEB system, relevant scenarios include highway driving, urban driving, parking, system activation/deactivation, driver distraction conditions, and system fault conditions.
Step 2: Identify Hazards
Hazard identification should be systematic, not brainstorming. Useful structures include:
Function-based hazard identification. For each function the item performs, identify: What happens if this function activates unintentionally? What happens if this function fails to activate when needed? What happens if this function activates at the wrong time? What happens if this function activates with incorrect magnitude or direction?
For an AEB system: the function "apply emergency braking when collision is imminent" produces hazards: unintended braking (function activates when no collision is imminent), failed braking (function does not activate when collision is imminent), delayed braking (function activates too late), insufficient braking (function applies braking but at insufficient deceleration).
This systematic approach catches hazards that intuition misses. Unintended activation hazards are commonly underanalyzed compared to failure-to-activate hazards, but unintended braking at highway speed can be as dangerous as failure to brake in an imminent collision.
Step 3: Identify Hazardous Events
A hazardous event is a hazard in a specific operational scenario. The same hazard may have different risk levels in different scenarios.
"Unintended braking" as an abstract hazard has no ASIL. "Unintended braking at >100 km/h on a multi-lane highway with traffic following at normal inter-vehicle distances" is a hazardous event with an ASIL rating.
For each hazard identified in Step 2, enumerate the relevant operational scenarios. The scenarios should come from the item definition. Do not limit the analysis to the scenarios you expect to be common — analyze scenarios where the risk level is high, even if their frequency is low.
Practical guidance: a thorough HARA for a mid-complexity ADAS system typically produces 20–50 hazardous events. Fewer than 20 suggests important scenarios were missed. More than 100 suggests the granularity is too fine — you are analyzing sub-hazards rather than hazards.
Step 4: Rate Severity (S)
Severity rates the potential harm to persons if the hazardous event occurs, assuming no safety mechanism intervenes.
Severity is rated for the worst-case credible outcome given the scenario — not the average or most likely outcome. "Unintended braking at highway speed" has S3 severity because, in the worst case, it causes a rear-end collision at speed with multiple fatalities.
Severity does not account for probability. It does not matter how unlikely the worst case is — if the worst-case credible outcome is S3, the severity rating is S3. Probability enters through the exposure rating.
Step 5: Rate Exposure (E)
Exposure rates how often the hazardous situation (the operational scenario) occurs in a vehicle's lifetime.
For a highway AEB system, the hazardous situation "vehicle traveling at >100 km/h on a multi-lane highway with following traffic" is an E4 scenario — it describes typical operating conditions for vehicles in markets with high highway usage.
Exposure is sometimes confused with the probability of the hazard occurring. Exposure is the probability that the vehicle is in the operational scenario — not the probability that the hazard occurs during that scenario. The probability of the hazard itself is addressed by the safety mechanisms and is not an input to HARA.
Step 6: Rate Controllability (C)
Controllability rates the probability that the driver (or other road users) can avoid harm once the hazard occurs.
Unintended emergency braking at highway speed, with no warning to the driver, is C3: the driver has insufficient time to react, and following drivers have insufficient time to brake. The hazardous event is not controllable by the subject vehicle's driver.
Controllability assessments should be grounded in human factors data. ISO/TR 14121-1 and published human factors research provide reaction time data that can be used to evaluate whether a given scenario allows adequate response time for a skilled driver.
Step 7: Calculate ASIL
ASIL is determined from the combination of S, E, and C ratings using the matrix defined in ISO 26262-3 Table 4.
QM (Quality Managed) means no specific ISO 26262 safety requirements apply — normal quality management processes are sufficient.
The table has many combinations not shown here; the full matrix should be used for normative ASIL determination.
Step 8: Derive Safety Goals
For each hazardous event with ASIL A or higher, derive one or more safety goals — functional requirements that must be satisfied to prevent or adequately mitigate the hazardous event.
Safety goals must be:
- Functional: Stated in terms of what the system must do, not how it achieves it
- Verifiable: Capable of being confirmed at the vehicle level
- Traceable: Linked to the hazardous event they address
Example: For the hazardous event "unintended AEB activation at >100 km/h on highway" with ASIL D:
Safety Goal SG-01: "The AEB system shall not apply braking force greater than 0.3g without driver request when vehicle speed exceeds 80 km/h, except in the presence of a confirmed collision threat."
This safety goal is functional (specifies behavior), verifiable (defines a measurable threshold), and traceable (addresses the unintended braking hazard).
The safe state — the state to which the system should transition when a failure is detected — must be defined for each safety goal. For SG-01, the safe state is "AEB function deactivated with driver notification." The FTTI — the maximum time between the onset of a fault and the transition to the safe state — must also be defined; for highway braking, this is typically in the range of 50–100 ms.
Common HARA Mistakes to Avoid
Mixing hazards with causes. "Sensor failure causing unintended braking" is a cause-hazard pair, not a hazardous event. The HARA should identify the hazardous event (unintended braking in a specific scenario) without presuming its cause. Causes are the domain of FMEDA and fault tree analysis.
Rating severity based on most likely outcome, not worst-case. If the worst-case credible outcome of unintended braking is S3, the severity rating is S3 regardless of how rarely the worst case occurs.
Forgetting omission hazards. Teams analyzing AEB systems typically cover false activation (commission) but spend less time on failure to activate when needed (omission) — which can be equally or more severe in high-speed collision scenarios.
Deriving safety goals that are not independently verifiable. "The system shall be safe" is not a safety goal. If the safety goal cannot be verified at the vehicle level without reference to lower-level design, it is too abstract.
ISO WIZ structures the HARA process to prevent these mistakes by enforcing field-level data entry (severity, exposure, and controllability are selections, not free text), by automatically calculating and displaying ASIL, and by linking safety goals to hazardous events as traceable data relationships — so a change to the hazardous event immediately flags the downstream safety goals for review.