HaRa
2025-10-07 13 min Season 1 Episode 7
Description & Show Notes
Have you ever been asked to perform a HARA for an ADAS function — and found yourself wondering whether that really makes sense?
In this episode, we’ll start by explaining what a HARA is all about, and then show why HARAs don’t make sense for every type of function.
Transcript
Hello and welcome to another episode of Applied FuSa, a podcast for FuSa pragmatists. Have you ever been asked to perform a HARA for an ADAS function — and found yourself wondering whether that really makes sense? In this episode, we’ll start by explaining what a HARA is all about, and then show why HARAs don’t make sense for every type of function.
It is well known that vehicles can pose a serious threat to life and limb—not only for occupants but also for people outside the vehicle. The goal of functional safety is to develop safety concepts that reduce the risk posed by vehicles to a generally acceptable level. To do this, risks must first be analyzed and assessed. This is meant to help classify risks and ensure a reasonable balance between the business case and the safety case. HARA stands for Hazard Analysis and Risk Assessment and precisely describes these goals. Undesired vehicle behavior—such as unintentional braking—is analyzed, and the resulting risk is assessed. In the first step, the result is the definition of an ASIL and one or more safety goals. ASIL stands for Automotive Safety Integrity Level and can take the values A, B, C, or D, where ASIL A represents a low risk and ASIL D represents a very high, in fact life-threatening, risk. To minimize risk and prevent hazards, safety goals are defined. These are deliberately not formulated as strict requirements but rather describe a general strategy for avoiding specific risks. Typical examples include: “Avoid false braking for more than 100 milliseconds,” or “Avoid unintended deployment of airbags.” These results—ASIL and safety goals—form the foundation for developing functional safety concepts for the relevant vehicle malfunctions. These include the following measurable requirements for the vehicle regarding a specific fault: Fault Tolerant Time Interval (FTTI); Safe State; Maximum Fitrate; Warning and Degradation Concept; and Emergency Operation. ASIL and safety goals are attributes assigned to the safety concept. In this sense, they cannot be implemented directly. For more details on the functional safety concept, please refer to the corresponding episode of this podcast. At this point, it’s important to understand that typically there must be at least one functional safety concept for every vehicle fault. If necessary, multiple concepts may be created—for instance, to differentiate between driving situations. Conversely, a single safety concept may also cover several vehicle faults. Any option is valid as long as all safety-relevant fault cases are ultimately addressed. The HARA is the method that initiates the development of these safety concepts by systematically identifying and analyzing vehicle faults and evaluating the associated risks—so that the ASIL is known and safety goals are defined.
Let’s now look at the actual procedure of a HARA. As already mentioned, the risk of a vehicle fault is analyzed. That means the vehicle does something it’s not supposed to—for example, it performs a full brake application without any reason. A HARA begins with the so-called hazard, i.e., the hazardous fault. In our example, this is the faulty full braking. It’s clear that there is usually a set of possible hazards for each vehicle function. Often, all hazards can be identified using a simple structured approach. Such an approach is presented here. The method is based on the simple question: “In what ways can a function fail?” Six failure cases are immediately obvious: False positive activation – function is triggered mistakenly; False negative activation – function is not triggered when it should be; False positive deactivation – function is stopped mistakenly; False negative deactivation – function is not stopped when it should be; Delayed activation – function starts too late; and Delayed deactivation – function stops too late. For our example: Braking was requested but not triggered (vehicle does not brake); Braking was not requested but still triggered (vehicle brakes without request); Braking stop was requested but not triggered (vehicle keeps braking); Braking stop was not requested but triggered (vehicle stops braking unexpectedly); Braking was requested but started late (vehicle brakes too late); and Braking stop was requested but started late (vehicle stops braking too late). In addition, further fault cases can be found via function output parameters. In the braking example, this would include braking force, which is an analog value. It could be too high or too low—resulting in two more fault cases. Depending on the need, these can be subdivided further, for example into “up to 5 percent too low,” “up to 15 percent too low,” “more than 15 percent too low,” and so on. Tip: It is very helpful to define and consistently use a company-specific list of fault cases for each data type (digital and analog signals, communication, N discrete values, etc.).
Back to the HARA and the example hazard “unintended full braking.” The hazard is then combined with various driving scenarios, since the danger of vehicle faults can vary depending on speed, road surface, weather, etc. Selecting driving scenarios can be an underestimated challenge. When combining all parameter values used to describe a scenario, the number of possible combinations grows very quickly, making a meaningful analysis nearly impossible and the result questionable. Since there are no universally valid criteria for selecting scenarios, expert judgment is essential. An example: One might argue that only high-speed scenarios should be analyzed, as crashes are more dangerous. But is this reasonable? A braking event of a few milliseconds at high speed may have no effect on vehicle dynamics at all. In contrast, several seconds of unintended braking with high braking force at low speeds could be very dangerous—e.g., on icy roads in pedestrian-heavy urban areas. The combination of a hazard and a scenario is called a hazardous event. For each hazardous event, three parameters must be determined: Severity (S), Exposure (E), and Controllability (C). These parameters determine the ASIL for the hazardous event. Let’s look at how the parameters are defined.
Severity S. S0, No injury possible. S1, only minor injuries possible. S2, severe or life-threatening injuries possible, survival likely. And S3, very severe injuries likely, survival nearly impossible. Exposure. E0, the fault cannot occur at all. E1, very low frequency. E2, low frequency. E3, medium frequency. And E4, high frequency. ISO 26262 Part 2, Table B.3 offers guidance: E1, less than once a year. E2, a few times per year. E3, monthly or more often. And E4, nearly every trip. Controllability. C0, controllable in general. C1, simply controllable. C2, normally controllable. And C3, difficult or not controllable. ISO 26262 Part 2, Table B.6 provides clarification: C1, controllable in more than 99 percent of cases. C2, controllable in 90–99 percent of cases. And C3, controllable in less than 90 percent of cases. The source and quality of this data is unclear, so these are generally rough estimates based on expert knowledge.
After determining values for S, E, and C, the ASIL can be derived from their sum: Sum equal to 7 means ASIL A; Sum equal to 8 means ASIL B; Sum equal to 9 means ASIL C; and Sum equal to 10 means ASIL D. Sum below 7 means QM (Quality Management, ISO 26262 does not apply). Example: S equal to S3; E equal to E2; and C equal to C2; results in a sum of 7-means ASIL A. For the case of unintended full braking in the scenario “highway driving at high speed in rain”: S equal to S2; E equal to E4; and C equal to C3; The sum of these is 9-means ASIL C.
Once the ASIL is determined, appropriate safety goals must be defined. For unintended braking, “Avoid unintended braking” is often used. However, this can be problematic. Unintended braking is not inherently dangerous. As already mentioned, very brief braking events (a few milliseconds) might not affect driving dynamics or even be noticeable. Therefore, unintended braking does not always have to be avoided. Why is this important? Because the safety concepts for all braking systems will be aligned with these safety goals, and completely avoiding unintended braking is a very strict requirement. Based on these considerations, a more reasonable safety goal might be:
“Avoid unintended emergency braking for more than 100 milliseconds.” This version includes a time requirement, which brings two major advantages: It relaxes the original demand by allowing very brief unintended braking; and It introduces a clear, measurable requirement, e.g., for diagnostic intervals.
At this point, the safety goal “Avoid unintended emergency braking for more than 100 milliseconds” is sufficient. This safety goal is assigned the previously determined ASIL—ASIL C—and that completes the HARA for this hazardous event. In the same way, all other hazardous events must be analyzed. Each time, an ASIL and one or more safety goals will be derived (or existing ones reused). Once all hazardous events have been evaluated, a Functional Safety Concept for the specific fault—unintended emergency braking—can be developed. But that will be the topic of another episode.
One point remains unresolved, and that is the question: For which functions should a hazard analysis and risk assessment (HaRa) be conducted? Well, HaRAs are often carried out for ADAS functions such as lane change assist or adaptive cruise control, since these functions can accelerate, brake, and steer the vehicle. It therefore seems quite reasonable to perform a HaRa for the respective hazards. Fundamentally, this is not incorrect, but it carries certain risks that can quickly lead to incomplete or contradictory safety concepts, which in turn may increase the overall risk. This can be illustrated with the following simple example. For more details, refer to the episode “Hierarchy of Functions.” If a HaRa has been conducted for unintended braking and a corresponding safety concept has been developed, then a HaRa for adaptive cruise control would also likely analyze faulty braking. An ASIL would be determined, and one or more safety goals would be defined and implemented. The problem is that there is already a safety concept for unintended braking—namely, from the HaRa conducted for unintended braking. If an additional safety concept is now developed for essentially the same fault scenario, not only does this generate redundant work; it must also be ensured that both concepts do not contradict each other. It is much simpler to use the existing safety concept as a requirements document for the development of adaptive cruise control. In other words: ACC should implement the existing concept instead of developing an ACC-specific one.
Applied FuSa – a podcast for Functional Safety pragmatists. Get your new piece of FuSa every other week.
Expert
00:00:23
Moderator
00:12:59