Hazard Analyses and Risk Assessment (HARA) in ISO 26262

Before one deploys a mission-critical system, a simple question has to be answered: what are the safety risks possible in the system?

Miss a risk, and it ships into production undetected, awaiting a hazard in the field. Overstate a risk, and millions of dollars are spent in over-protecting a feature that didn’t need it. Every safety budget, every redundant sensor, every line of certified code traces back to how well that question is answered.

In ISO 26262, the structured process for identifying risks is called HARA - Hazard Analysis and Risk Assessment. It's where engineers systematically identify what can go wrong, how bad it would be, and how much rigor the system needs to prevent it. It's the most used safety analysis technique in the entire functional safety lifecycle.

What is a HARA?

HARA is defined in ISO 26262 Part 3, Clause 6. It sits at the top of the concept phase, right after the Item Definition is defined. Its job is to take a proposed automotive feature, identify the ways it could harm someone, and quantify the risk, so one knows how rigorously to engineer solutions to mitigate it.

The outputs of HARA shape everything downstream: ASIL ratings, safety goals, functional and technical safety requirements, hardware metrics, and software development rigor. The architecture of the safety case is set here.

The Starting Point: Item Definition

The first step in development of a mission-critical system is the Item Definition. It is a description of the system's boundary, its functions, its interfaces with other systems, its operating modes, and the assumptions it makes about the driver and the environment. It provides a basic set of information on "what is the system that we are working on ?"

Fig: Where the HARA fits in the safety lifecycle

The HARA workflow

Once the Item is defined, the HARA can be developed. It is a 5-step process, as shown in the figure below

Fig: Overall HARA workflow

Step 1: Situation Analyses

The first real step of HARA is not asking what can go wrong. It's asking, "what can go wrong, and where?"

A stuck throttle on a clear highway is a fundamentally different event from a stuck throttle in a parking garage. Same malfunction, completely different consequences. The operating context is what turns a malfunction into a hazardous event and capturing that context systematically is what operating scenarios are for. 

An operating scenario is a structured description of the conditions a feature will encounter in the real world: road type, traffic density, weather, lighting, vehicle state, driver attention, and the interactions between them. 

Structured scenario taxonomies, such as those developed by the PEGASUS project , are increasingly used to make this enumeration repeatable and reviewable. 

Step 2: Hazard Identification

Once operating scenarios are created, a function-by-function analyses is performed to ask what deviations from nominal behavior could harm someone. The HAZOP is a systematic process of identing hazards in a system. HAZOP-style guidewords work well here: too much, too little, too early, too late, wrong direction, unintended, etc.

Consider an example of Cruise Control, which maintains vehicle speed:

• Too much - unintended acceleration

• Too little - failure to maintain speed on a downhill stretch

• Too late - delayed deceleration when a lead vehicle brakes hard

• Unintended - acceleration when the driver expects the system to be disengaged

Each deviation, paired with a situation, becomes a candidate hazardous event, the basic unit of HARA.

Step 3: The Three Dials: Severity, Exposure and Controllability

For every hazardous event, three independent dials are required to assess the risk, each defined precisely by the standard.

• Severity (S0 – S3) - how bad the injuries would be if the event happens, anchored in the AIS injury scale 

• Exposure (E0–E4) - how often the operating scenario occurs (not the malfunction itself - that's a common mix-up)

• Controllability (C0–C3) - what percentage of drivers/ traffic participants are able to mitigate harm

  
  

Consider unintended acceleration during highway cruising. The severity is high - a high-speed collision likely causes serious or fatal injury (S3). Highway driving is a frequent situation for most drivers (E4). Controllability depends on the dynamics of the specific vehicle and the driver’s ability to reach: a heavy truck with low achievable acceleration may sit at C0–C1, where the driver has time to recognize the fault and intervene, while a high-performance car capable of strong acceleration can push the rating to C2 or C3, where even an attentive driver may not have time to override the fault and bring the vehicle to a safe stop. 

Step 4: From Dials to ASIL

The three parameters - Exposure, Severity, and Controllability are feed into the below table of the ISO 26262. Out comes an ASIL (Automotive Safety Integrity Level), ranging from A through D, or QM (Quality Managed, meaning standard automotive quality with no additional functional safety process required).

Fig: ASIL Calculation according to ISO 26262 from Exposure, Severity, and Controllability

ASIL D is the highest rigor the standard defines. It demands redundant architectures, high diagnostic coverage, formal methods in some cases, and the most stringent process discipline across the V-model.

For the cruise control example, the severity and exposure are fixed at S3 and E4, but the ASIL depends on which controllability rating applies. A high-performance vehicle at S3 + E4 + C3 lands at ASIL D. The same hazardous event on a heavy commercial vehicle, where the achievable acceleration is lower and the driver has time to react, might land at S3 + E4 + C1 = ASIL B

Step 5: Safety Goals

Each hazardous event yields a top-level safety requirement called a safety goal. For the Cruise Control case, the safety goal might read: "The cruise control system shall not cause unintended longitudinal acceleration exceeding [X] m/s²."

That goal, together with its assigned ASIL propagates into functional safety requirements, technical safety requirements, hardware architectural metrics, and software requirements. HARA's output is the seed from which the entire safety case grows.

Challenges with the HARA

For all its leverage, HARA is easy to do badly. A few common failure modes:

• Vague item definition. Analyze what you haven't precisely defined, and you get hazards that don't map cleanly to anything real.

• Skipped operating scenarios. Teams jump straight to listing hazards without thinking through the operating context. Severity and exposure end up disconnected from reality.

• Consistency in HARA ratings - While rating severity and controllability across multiple operating scenarios, it is hard for engineers to maintain consistency across ratings

• Time and effort - Performing a HARA for multiple hazards, multiple operating scenarios is a labor-intensive process

• Optimistic controllability. Rating against expert drivers rather than the average driver the standard actually specifies. C ratings drift downward, ASILs drop, and rigor quietly evaporates.

Conclusion: The Most Leveraged Decision in the Program

The HARA is the foundation on which every downstream safety requirement is built, making it essential to get right from the outset. By rigorously identifying hazards and assigning the appropriate ASIL ratings early, teams can design safer systems while avoiding costly rework later in development.