HARA by ISO 26262 Standard: Why Understanding Hazards and Risks is a Stepping Stone of your Functional Safety Journey
ISO 26262 is a Globally Recognized standard for the design and development of automotive E/E systems. It is a framework that makes Functional Safety, a part of the automotive product development life-cycle.
ISO 26262 standard deals with different aspects of the functional safety in Automotive. It is designed to eliminate any unacceptable risk to the human life.
This journey of eliminating the risk starts with identification and analysis of the hazards and assessment of the risks associated with the hazards.
This particular step or process of identification and analysis is known as HARA (Hazard Analysis and Risk Assessment).
We will begin by understanding what is HARA? And proceed to Why is HARA necessary? And finally understand this process from the value-chain point-of-view (Automotive OEM and suppliers). Sit tight! There’s a lot coming your way!
What is HARA and Why is it Required?
Hazard Analysis and Risk Assessment is mentioned in the Part-3 of ISO 26262 standard document. The purpose behind HARA is to identify the malfunctions that could possibly lead to E/E system hazards and assess the risk associated with them.
The findings are then used to formulate the safety goals that are required to be met, in order to achieve the coveted “safe state”.
This example will bring some clarity. A Lane Departure Warning Assistant (LDW) in a car is responsible for warning the driver, in case the vehicle attempts to switch the lanes, without the turn-indicator on in the same direction.
In order to make this feature fail-safe, a Functional Safety Consultant is required to identify the hazards associated with the Lane Departure Warning Assiatant. Hence, there is a need for HARA
The following examples of the possible hazardous events, will help us understand the importance of identifying these hazards:
- The LDW gets activated automatically, even when the car is not changing lanes. This may cause the driver to lose control of the car.
- Required Alert from the LDW system is not displayed on the dashboard (Driver may assume that LDW is working and may react late)
- LDW warns the driver, but the warning lights do not get activated. An accident may occur.
Who Should Shoulder the Responsibility for HARA: The OEM or the Supplier?
Simply put, any automotive software/hardware manufacturer that wants its product to conform to ISO 26262 functional safety, must perform HARA.
An OEM may aim for its Electronic Power Steering to be ASIL-A compliant. It may then ask its EPS supplier to go for HARA and other methods such as FMEA and FMEDA etc. to ensure the conformance to the required ASIL.
In other scenario, the OEM may decide to build their own ASIL-A compliant EPS. HARA, in such case, will be performed by the OEM themselves.
Now, let’s find out where HARA appears, in the functional safety journey.
As is clear from the process flowchart, HARA is preceded by Item Definition and followed by functional safety concept.
So, to understand HARA in a better manner, we will first talk about Item definition and initiation of the safety Lifecycle. In the process, we will also introduce you to the inputs that are needed for HARA.
Step-1: Item Definition
HARA essentially deals with the malfunctions, at the vehicle-level. Hence, having a clear understanding of how the vehicle and the associated sub-systems work, is very important for the functional safety experts.
This understanding is captured in the form of Item Definition. Hence, to effectively perform HARA, a solid Item-definition is very important
What is an Item? – An Item, by definition, is system or array of systems, that are required to implement a function at the vehicle level. For instance, Anti-lock Braking System can be an item.
The Item Definition Constitutes of the following:
- Name of item and the descriptions
- Core Technology on which the item works (Electronic/Electrical/Mechanic etc.)
- Interfaces to other functions (both external and internal)
- Safety requirements and known failure-modes
- Functional dependency of one item on others
An item definition may have more details, which will only make HARA easier. Once, the item definition is identified, the safety-lifecycle kick-starts.
Step-2: Safety Lifecycle Initiation
This is more of a transitionary step. At this stage, this it is ascertained that whether a new item is being developed or modifications are being made to an existing item.
Another objective is to define the safety lifecycle activities that will be carried out in the next steps.
Step-3: Hazard Analysis and Risk Assessment
At this stage, the functional safety engineers are aware of the items and their functions. The next step is to identify the malfunction for every item under consideration and specify certain factors such as operational scenarios, operation modes etc. All these factors are considered as the inputs for HARA.
The identification of malfunctions is best performed with the help of HAZOP. It stands for Hazard and Operability Analysis. It is an exploratory analysis that takes into account the deviation from the system design or operating intentions.
In simpler terms, HAZOP theory assumes that any potential hazard will emanate whenever there is a deviation from the intended operation of a system.
It uses certain guide words to denote such deviations. For instance, the acceleration system in the car leading to reverse acceleration, i.e. when throttle pedal is pressed, the car decelerates (a malfunction). A guideword denoting such a scenario may be “reverse”.
- Once the malfunction is identified, it is described using a hazard description in order to elaborate the issue.
- The scenario in which such malfunction occurs is described under Operational Scenario. The scenarios can be Idle, Acceleration, Braking etc.
- Similarly, the Operational Mode is also specified for the malfunctions. The modes can be Vehicle Parked, Vehicle Idle, Vehicle moving at low-speed/high speed, and son on and so forth.
The capability of identifying all these inputs comes from domain expertise of the Functional Safety Consultant and the Automotive Engineers.
Also, the knowledge of the known malfunctions of the items under consideration, and data sheet of the components, also help in identifying the inputs.
Post the identification of hazards, comes their classification. This classification is required to derive the ASILs (Automotive Safety and Integrity Level) and then the safety goals.
ASIL determination, along with Safety Goals, can be considered as the Output of HARA. We recommend reading of our blog on ASIL determination, to understand this classification in detail.
However, for the sake of continuity and understanding of the safety goals formulation, we will give a brief idea about this classification.
The Hazards derived during HARA are classified under three categories:
- Exposure (E): The measure of possibility of a system to fail or be in a hazardous situation.
- Controllability (C): Determines the extent to which the driver of the vehicle can control the vehicle, if a safety goal is breached due to failure or malfunctioning of any automotive component.
- Severity (S): The extent of harm that may be caused to the driver and other occupants, in the instance of occurrence of a hazard.
Now, let’s understand what are safety goals w.r.t functional safety.
Understanding Safety Goals in terms of Automotive Functional Safety
According to ISO 26262 standard, Safety Goals are the top-level safety requirements for each item. These goals go on to formulate the functional safety requirements, needed to avoid any unreasonable risk for each of the hazardous events.
Safety Goals are derived by understanding all the potential hazards that may contribute to the failure of a component. Each safety goal also has an ASIL attribute as well as the requirement specified to bring the vehicle to safe-state.
The process of finding the safety goals can be summarized in the following steps:
- Identification of all the relevant hazards
- Identification of operational scenarios, modes, and environmental conditions etc.
- Combine Situations and the Hazardous Events
- Perform classification of Hazardous Events
- Identify Safety Goals that cover all Hazardous Events
The system engineer analyzes the hazardous events and also analyze the severity, exposure and controllability of the hazards.
Based on these deductions, safety goals are formulated. During the process of HARA, several hazards for an item are derived. And each hazard may have different ASIL values depending on its severity, exposure and controllability.
As one safety goal covers several hazardous events, the highest ASIL value among the hazards is assigned to that safety goal.
Let’s understand safety goals better with an example of Lane Departure Warning Assistant.
|Hazard Desc||ASIL||Safety Goal|
|The LDW function activates in a condition which is in valid. It suppresses intentional steering manouvers.||ASIL-D||Driver should be able to cancel the LDW by moving steering in counteractive way.|
How is HARA performed?
HARA as a process, is a culmination of both the ISO 26262 prescribed framework and the team’s understanding of functional safety and automotive functions.
This is the reason why HARA can be performed either by using tools or by using Excel sheets.
One of the most widely used tool for HARA is is ENCO SOX. It is a versatile tool that aids the automotive engineers in end-to-end Model based E/E system development.
Hazard Analysis and Risk Assessment is one of the various ISO 26262 functional safety activities that this tool can perform.
Alternatively, HARA and safety goals derivation can be performed on Excel Sheet. The experts need to create a template (prescribed by ISO 26262) and put in place certain calculation to get things rolling.
HARA sets the tone for your ISO 26262 functional safety journey. HARA is a necessary first step, as it helps to derive ASIL values and safety goals for the system.
The subsequent steps in the safety lifecycle, such as functional safety concepts and actual product development & testing, are achieved based on these safety goals and ASIL values.
ASK OUR EXPERTS
Car HUD (Heads-up Display)
Go-to-market in 6 months with our automotive grade hardware and software design
Automotive Control Units
Electronic Control Units (ECU) development services for Body Control Modules (BCM), Powertrain, Chassis and Infotainment
AUTOSAR Software Services
AUTOSAR MCAL development, RTE and BSW integration, Application Layer development, Tools configuration and code generation
CUSTOMER SUCCESS STORIES
Find out how J1939 stack resolved on-chip memory issue for an Automotive Tier-I supplier
Modular architecture re-design across fleet management product lines - GPS fleet security, vehicle and trailer tracking
Design and development – Sensor Networks, Custom IoT gateway, Cloud and Mobile App