Risk analysis for safety-related systems is the foundation on which the entire design and verification process for automotive electronics is built. In the automotive industry this foundation is HARA – Hazard Analysis and Risk Assessment. It is the first major task in the ISO 26262-compliant process and at the same time the step that determines everything that follows: the ASIL level, the scope of tests, the system architecture, and even the way the product’s behavior is thought about.

HARA – how hazard analysis and risk assessment work in vehicle functional safety

Although the name sounds formal, HARA has a very practical purpose: to understand what can go wrong and how serious the consequences might be. This is not a dry theoretical analysis but a process similar to a thorough investigation, in which engineers consider what hazards may arise when a system stops behaving as expected. This makes it possible to consciously design safeguards that reduce the risk to an acceptable level.

Why is HARA so important?

In automotive applications most modern safety functions are implemented by mechatronic and electronic systems: driver assistance systems, brake control, drive and vehicle stability control, or energy management. Any of these can fail. Some faults will be harmless, others can lead to dangerous road situations.

HARA allows separating faults that are at most annoying from those that require rigorous control and a high level of functional safety. Without a clear, systematic risk assessment it is easy to fall into two extreme approaches: excessive caution or dangerously trivializing hazards. The first leads to excessive requirements and high costs. The second can have dramatic consequences.

ISO 26262 leaves no room for interpretation here. HARA is a mandatory element of every system project that affects driving safety. It is thanks to HARA that ASIL — Automotive Safety Integrity Level — is determined. The greater the risk, the higher the ASIL, and consequently the more demanding the design process.

What exactly is done in HARA?

The HARA process can be divided into several logical stages that make up the complete hazard analysis and risk assessment. Although the standard does not prescribe specific tools, it requires achieving concrete results: a list of hazards, their classification and assigned ASIL level.

1. Define the element and its function

At the beginning you specify what the analysis concerns. An "element" in ISO 26262 can mean a system, subsystem, component, or even a combination of hardware and software. It is crucial to describe its function and interactions with the environment. Without a clear scope it is difficult to talk about any meaningful risk assessment.

[Placeholder: illustration showing "system in context"]

At this stage all information about how the system works, its inputs, outputs, dependencies, assumptions and constraints is collected. This forms the basis for hazard identification.

2. Identify operational situations

Vehicle systems operate in different conditions: on the highway, in traffic jams, when pulling away, during turning, emergency braking, on slippery surfaces. Each of these situations carries different risks.

HARA must account for a full review of possible scenarios. This naturally leads to initial conclusions: a function that is harmless at low speeds can become critical at high speeds.

3. Identify hazards

Now comes the actual "problem hunting." The team assesses which dangerous states can result from a system failure. In HARA a hazard is described by combining:

the failure or incorrect behaviour of the function,
the operational situation,
the potential consequences for people.

[Placeholder: table with example hazards]

Example: "The braking system does not generate pressure in the circuit while driving at high speed", which may lead to a collision.

4. Risk assessment: S, E and C

For each hazard three elements are assessed:

Severity (S) – how serious can the consequences be? From minor discomfort up to life-threatening harm.
Exposure (E) – how often might the driver be in a situation where the hazard is relevant?
Controllability (C) – to what extent would the driver be able to control the situation if the failure occurs?

These three criteria are defined in ISO 26262 and have strictly defined values. The combination of S, E and C leads to establishing the ASIL level for a given hazard. Sometimes the result is ASIL A or B, sometimes D, and sometimes the risk is classified as "QM", meaning it does not require special functional safety actions.

HARA as deductive thinking about failures

HARA has a philosophy that distinguishes it from other risk assessment methods. It does not analyse random faults or try to guess "what else we don't know." It starts from the function, its purpose and its impact on safety. Only then does it move to understanding what happens if that function fails.

This is a deductive approach: from effect to cause. Like a detective breaking down a crime into possible scenarios, safety engineers break down a potential function failure into elements from which it may arise. This tells the system designer which parts require protection, monitoring or redundancy.

HARA does not replace more detailed analyses such as FMEA or FTA, but it indicates where they should be performed and how deep they should go.

Example of a simplified HARA flow

The example below illustrates the HARA way of thinking, although in practice the analysis is much more extensive.

[Placeholder: simplified HARA diagram]

Assume an assisted driving system that automatically maintains speed. The key function is torque regulation. A possible hazard is "incorrect acceleration." In the operational situation "driving on the highway" the consequence can be severe. We would rate Severity high. Exposure would also be high because highway driving is common. Controllability depends on the driver's ability — if the acceleration is abrupt, control becomes difficult. The combination of S, E, C gives an ASIL level that leads to specific requirements for the torque control system.

Who participates in HARA?

The HARA process is not a one-person job. It requires an interdisciplinary team, because hazards can arise from various areas: driver behaviour, mechanical system characteristics, electronics operation or control algorithms.

A typical team includes:

functional safety engineers,
system or function specialists,
software engineers,
mechanical and electronic specialists,
human–machine interaction experts.

Each brings a different perspective and experience. Good HARA requires discussion and sometimes disagreement — that's part of the normal process.

What does HARA documentation look like?

ISO 26262 requires that HARA results be recorded as a report. It usually has a tabular structure:

[Placeholder: HARA table]

The report contains:

a description of the analysed element,
a list of functions,
operational situations,
identified hazards,
assigned S, E, C levels,
resulting ASIL,
justification of assessments.

The HARA report later becomes one of the main input documents for defining safety requirements.

Relation of HARA to safety requirements

HARA is not analysis for the sake of analysis. Its outcome is Safety Goals. Each goal defines the expected system behavior in situations where its function has critical importance.

Example safety goal: "The braking system must not introduce an uncontrolled drop in circuit pressure." At this stage we do not yet talk about redundancy or algorithms. This is a high-level abstraction. Only later will design principles, tests and system architecture lead to detailed technical requirements.

The ASIL determined in HARA defines how rigorous the subsequent steps need to be.

Common mistakes in HARA

Even experienced engineers can stumble in this process. Common problems include:

too generic hazard descriptions,
omitting rare operational situations,
unjustified S, E and C assessments,
mixing high-level hazards with technical causes,
defining the element scope too narrowly or too broadly.

HARA requires not only knowledge but also practice and the ability to view the system from different perspectives. This is one reason why the standard emphasizes team competence.

Summary

HARA is one of the key processes in designing safety-related vehicle systems. It allows understanding risks, assessing their impact on safety, and determining ASIL levels that define design requirements. Thanks to this, manufacturers can consciously plan protective functions, fault detection mechanisms and test procedures to ensure an appropriate level of safety.

This is not a formality or a process that can be ignored. A well-executed HARA provides a solid basis for the entire project. A poorly executed one can lead to errors that are difficult to fix at later stages. That is why HARA is given such importance in the automotive industry.