HARA - Hazard Analysis and Risk Assessment per ISO 26262

HARA - The Foundation of Functional Safety

In many projects, the discussion about functional safety begins with a seemingly simple question: What does the system do? For a HARA, this question is not enough. What matters is not only the intended function, but also which malfunctioning behavior can lead to harm in which operating situation.

HARA, the Hazard Analysis and Risk Assessment, is the systematic hazard and risk evaluation according to ISO 26262. It is the central entry point into the safety lifecycle because it turns an item definition into safety-relevant hazardous events, their risk classification, and the derived safety goals with their corresponding ASIL.

At its core, the HARA answers three questions: Which hazards arise from malfunctioning behavior? How critical are these hazards in realistic operating situations? Which abstract safety goals must be defined so that the risk can be controlled?

Position in the ISO 26262 Process

The HARA is performed after the item definition and before the functional safety concept (FSC). This sequence is not arbitrary: without an item definition, the scope is missing; without a HARA, the safety goals and ASIL are missing as the basis for later requirements derivation.

The input is the item definition. It describes the functional scope, operating boundaries, assumptions, and relevant interfaces of the item under consideration. It does not yet need to contain a technical architecture. Quite the opposite: a HARA should not argue from an already fixed technical solution, because safety mechanisms or architecture assumptions would otherwise influence the risk evaluation too early.

The HARA output includes:

• hazardous events,
• risk classification (S, E, C) for each hazardous event,
• safety goals including ASIL from QM to ASIL D.

This makes the HARA the bridge between a neutral item description and the safety-related decisions in the project. It defines which risks must be addressed with which degree of rigor in the further development process.

What is Evaluated in a HARA

A HARA evaluates risks, not causes. It does not first ask whether a specific sensor fails, a software error occurs, or a communication line is disturbed. It considers malfunctioning behavior at item level and combines this behavior with an operating situation and relevant environmental conditions.

A hazardous event consists of three building blocks:

• the hazard, meaning the danger resulting from malfunctioning behavior,
• the operating scenario,
• the environmental and boundary conditions relevant for the evaluation.

The focus is harm to people. Property damage may be relevant to a project, but it is not the primary evaluation subject of the HARA according to ISO 26262. Likewise, safety mechanisms of the item are not credited in this phase. If the system later includes diagnostics, plausibility checks, or shutdowns, those measures belong in the safety concept and technical implementation, not in the original HARA evaluation.

This separation is not merely formal. It prevents one of the most common practical mistakes: teams downplay a risk because they already have a solution in mind. A HARA must first conservatively evaluate what can happen without considering later countermeasures.

The Four Steps: Situation, Hazard, Safety Goal, ASIL

The HARA follows a clear step logic that appears in every project. Each step reduces a different uncertainty in the workshop.

1. Situation: Where and Under Which Conditions?

The situation is initially neutral. It does not yet describe a hazard or a fault.

Examples:

• The vehicle is driving at 120 km/h on a motorway in dense traffic.
• The vehicle is operated in urban traffic at around 50 km/h in normal traffic flow.

It is important not to choose the situation too broadly or too narrowly. “Driving” is usually too broad. “Cornering at 73 km/h on a wet road at night” may be too specific if it artificially fragments the evaluation. A robust granularity is technically distinguishable while still remaining workable.

2. Hazard: What Goes Wrong?

A hazard is malfunctioning behavior of the item that can lead to harm in the situation under consideration. The combination of situation and hazard creates the hazardous event.

Example: motorway driving plus unintended acceleration. The malfunction alone is not yet a fully evaluable event because its criticality depends strongly on the situation. Unintended acceleration while maneuvering must be evaluated differently from unintended acceleration at high speed in dense traffic.

3. Safety Goal: What Must Be Prevented?

Safety goals are derived from relevant hazardous events. A safety goal is an abstract safety objective at vehicle or item level. It describes which dangerous behavior must be prevented or limited without already defining the technical implementation.

A safety goal is therefore solution-neutral. It does not define which sensor is plausibilized, which software architecture is used, or which actuator is switched off. It describes the safety objective that is later refined into functional safety requirements in the functional safety concept.

4. ASIL: How Critical is the Risk?

The ASIL is derived from the evaluation of severity, exposure, and controllability and assigned to the safety goal. It describes the required safety integrity level. A typical example is S3 x E4 x C3, which leads to ASIL D in the ASIL matrix.

ASIL relates to safety goals, not to components. A component may carry requirements with different ASIL relationships, but the HARA initially assigns the ASIL to the safety goal.

Understanding Severity, Exposure, and Controllability Correctly

The evaluation using S, E, and C is not a mathematical multiplication. It is a classification based on normative categories and matrix logic. This is exactly why the workshop must document cleanly why a value was chosen.

Severity: Severity of Possible Injuries

Severity (S) describes the severity of possible injuries that may result from a hazardous event. It evaluates only the impact on people, not property damage or system impairment. Severity therefore answers the question of how serious the possible injuries are if the hazardous event occurs.

According to ISO 26262-3, severity is one of the three equal risk evaluation parameters alongside exposure (E) and controllability (C). The evaluation is made under conservative assumptions:

• It is assumed that the hazardous event has occurred completely.
• No effectiveness of safety mechanisms is considered.
• A realistic but unfavorable accident constellation is assumed.

Severity is therefore not a probability consideration, but a pure impact evaluation.

Possible injuries to vehicle occupants, meaning drivers and passengers, as well as other road users such as pedestrians, cyclists, or drivers of other vehicles are evaluated. The evaluation considers:

• type of injury, from minor to fatal,
• number of potentially affected people,
• typical accident consequences in the operating situation under consideration.

Pure property damage, economic consequences, and comfort or availability losses are not considered.

ISO 26262 defines four severity classes:

• S0 - no injuries: no health-relevant effects.
• S1 - light to moderate injuries: without permanent impairment, for example bruises or minor cuts.
• S2 - severe injuries with probability of survival: serious injuries, possibly with lasting consequences, but not immediately life-threatening.
• S3 - life-threatening or fatal injuries: one or more people may be fatally injured.

As speed, vehicle mass, and interaction with vulnerable road users increase, severity typically rises quickly to S3.

Severity must be evaluated consistently and conservatively. The standard requires the classification to be based on realistic accident assumptions, known biomechanical limits, and typical traffic accident scenarios. Essential principles are:

• worst credible case instead of an absolute extreme case,
• no arguing away risk through rare boundary conditions,
• the mere possibility of fatal injuries justifies classification as S3.

An overly low severity evaluation is one of the most common systematic HARA errors and directly leads to an underestimation of the safety risk.

Exposure: Probability of an Operating Situation Occurring

Exposure (E) describes the probability that a relevant operating situation occurs in which identified malfunctioning behavior of the item can lead to a hazardous event. Only the operating situation is evaluated, not the probability of a technical fault or system failure.

The exposure evaluation is independent of the item design and is based on representative vehicle use in the target markets. Key points are:

• The failure rate of the item is not considered.
• It is assumed that every vehicle is equipped with the item.
• The number of vehicles in the field must not be used to reduce exposure.

Exposure is estimated based on:

• the frequency of certain operating situations such as overtaking, turning, or urban traffic,
• the duration for which the vehicle is typically in such a situation, for example motorway driving or stop-and-go traffic.

ISO 26262 distinguishes five exposure classes:

• E0 - incredible: operating situations considered extremely unlikely or practically excluded, for example natural disasters. No ASIL derivation is required for E0.
• E1 - very low probability.
• E2 - low probability.
• E3 - medium probability.
• E4 - high probability: situations that occur during almost every drive or over a significant share of the operating time.

The standard explicitly requires every exposure classification to be supported by a traceable rationale. This can be based on:

• typical driving profiles,
• statistical usage assumptions,
• market and application assumptions, for example urban or extra-urban use,
• experience from comparable vehicle functions.

Overly fine-grained splitting of operating situations can lead to an artificial reduction of exposure and therefore to an inappropriate ASIL reduction. The standard therefore recommends aggregating similar operating situations where they are comparable from a safety perspective.

Exposure answers how often the vehicle is in a situation in which a hazardous event could occur. It says nothing about the severity of possible injuries or about controllability by the driver and road users.

Controllability: Ability to Control a Hazardous Event

Controllability (C) describes the ability of the involved people to avoid a hazardous event or limit its consequences through appropriate and timely action after the hazard has occurred. The focus is usually the driver, and in some cases also other road users such as pedestrians, cyclists, or drivers of other vehicles.

According to ISO 26262, controllability is one of the three equal risk parameters alongside severity (S) and exposure (E). It is evaluated under the assumption that the malfunction under consideration has already occurred. Essential normative principles are:

• Correct system behavior is not assumed.
• No additional safety-oriented design is assumed.
• The evaluation is performed without assumptions about future safety measures.

Controllability is therefore not a design evaluation, but a situation- and human-related risk assessment. It answers how likely it is that an average driver or road user can control the hazardous event.

The evaluation considers, among other things:

• time to react, meaning the reaction window,
• possibility to perceive the situation,
• required driving competence,
• complexity of the necessary countermeasure,
• traffic and environmental conditions.

The following are not considered:

• diagnostic capabilities of the system,
• fault tolerance mechanisms,
• warning or emergency functions, because these belong in the safety concept.

ISO 26262 distinguishes four controllability classes:

• C0 - controllable in every situation: no safety-relevant hazard; can be considered harmless.
• C1 - simply controllable: the great majority of drivers or road users can control the event without special difficulty.
• C2 - normally controllable: the majority can react, but increased attention or fast reactions are required.
• C3 - difficult or impossible to control: only few or no people can control the event; often very short reaction time or complex countermeasures.

As the controllability class increases, uncontrollability and therefore the risk increase significantly.

ISO 26262 requires every controllability classification to be supported by a plausible, traceable rationale. This is typically based on assumptions about:

• average driving experience, not a professional or extreme case,
• realistic reaction times,
• typical traffic behavior,
• known human limitations.

C3 is the default when an event occurs suddenly, without warning, and at higher speed. C1 or C2 require clear perception and sufficient time to react.

An overly optimistic controllability evaluation leads to a systematic underestimation of ASIL and contradicts the safety-oriented approach of the standard. Controllability is the only HARA parameter that explicitly considers the human factor.

An example from ASIL logic: S3, E2, and C3 lead to ASIL B. With S3, E4, and C3, ASIL D is typically close.

Separating Safety Goal and Functional Safety Requirement

A common handover mistake occurs when safety goals are already written like requirements. This mixing blurs the later derivation.

A safety goal describes what must be safe at vehicle or item level. Example: unintended acceleration of the vehicle must be prevented. It is abstract, hazard-oriented, and ASIL-classified.

A functional safety requirement describes how this goal is functionally achieved. Example: the system must provide plausibility monitoring for accelerator pedal signals or transition to a safe state within a defined time if the signal is inconsistent. These requirements are created in the functional safety concept and must trace back to the safety goal.

The HARA therefore does not deliver the complete requirements set. It delivers the safety goals and their ASIL. The next step is clean refinement in the functional safety concept.

Continuous Example: Electric Power Steering

The evaluation logic becomes tangible when it is applied to a concrete item. The example is electric power steering, or EPS.

The item is the electric power steering system. Its function is to support the driver by providing steering torque. The considered operation is public road traffic in a speed range from 0 to 140 km/h.

A relevant malfunction is unintended steering torque without driver request. This creates the hazard of an unintended change in vehicle direction while driving.

In a critical operating situation, for example at higher speed in public road traffic, this hazardous event can have severe consequences. Exposure can be rated E4 if the driving situation is very frequent. Severity can reach S3 if life-threatening or fatal injuries are plausible. Controllability can be C3 if an average driver can hardly control the sudden directional input.

The resulting classification E4, S3, C3 leads to ASIL D. The safety goal could be: the electric power steering must not generate unintended steering torque above a defined threshold.

This safety goal is deliberately not yet a technical solution. Whether the project later uses torque limitation, sensor plausibilization, diagnostics, watchdogs, redundant paths, or degradation strategies is defined in the following safety concepts.

Typical Mistakes in HARA Workshops

Many HARA problems do not arise from missing standards knowledge, but from unclear workshop discipline.

A first mistake is dependent evaluation of S, E, and C. If severity is relativized with a view to assumed controllability, or exposure is reduced with a view to an assumed failure probability, the result is distorted. The parameters must be justified independently.

A second mistake is an overly coarse view of malfunctions. If several functionally different malfunctioning behaviors are grouped into one hazard, operating situations, causes, and possible safety goals become blurred. The result does not reduce risk sufficiently because the later requirements derivation remains imprecise.

The opposite mistake is excessive granularity. Too many special cases create a HARA that is hardly reviewable and in which teams get lost in detailed variants. A robust HARA recognizes when a scenario truly needs a different evaluation and when it is only a variant of the same evaluation logic.

A third mistake is missing HARA process expertise. The technical system experts know the function, but methodical evaluation according to ISO 26262 requires moderation, clear terminology, and experience with boundary cases.

A fourth practical mistake is overly optimistic evaluation to keep ASIL and development effort low. This rarely happens openly, but often implicitly: controllability is interpreted generously, exposure is confused with failure probability, or safety goals are formulated so they appear to cause less effort later. A robust HARA is conservative. In justified doubt, the higher class is selected.

What a Robust HARA Provides in the Project

A robust HARA creates clarity before architecture decisions become expensive. It documents which hazardous events are relevant, why S, E, and C were evaluated as they were, and which safety goals follow from them. It makes visible which ASIL controls the further development process and where special depth of evidence is required.

It is also a communication instrument. Engineering, safety management, project management, and suppliers can use the HARA to understand why certain requirements, reviews, tests, and analyses are necessary. This makes the HARA more than a mandatory document; it becomes a steering artifact for the concept phase.

For further context, it is worth looking at the ASIL classification: that article goes deeper into the matrix logic behind severity, exposure, and controllability. For the concrete continuation of the safety goals, the functional safety concept is then decisive.

Conclusion

The HARA is the methodical starting point for functional safety according to ISO 26262. It identifies hazards from malfunctioning behavior, evaluates hazardous events using severity, exposure, and controllability, and derives safety goals including ASIL.

Its quality determines whether the later safety work stands on a robust foundation. Overly coarse malfunctions, weak S/E/C rationales, or safety mechanisms credited too early lead to weak safety goals and later gaps in FSC, TSC, verification, and safety case.

A robust HARA remains solution-neutral, conservative, and traceable. That is precisely how it creates the basis on which functional safety requirements, architecture decisions, and evidence can be built robustly.

Especially with complex E/E systems, the value of a HARA is not shown in the form itself, but in the stability of the decisions that arise from it. The earlier assumptions, boundary cases, and terms are clarified, the more robust the safety goals, requirements, and later evidence become.