Hazard Analysis and Risk Assessment (HARA) for Lane Keeping Assist

The problem

Every safety-related automotive function starts with a HARA, because it decides which hazards matter and how much rigour the rest of development needs. Lane Keeping Assist steers the vehicle, so wrong or missing torque can cause lane departure or collision. Students often learn the ASIL table without applying it. This project produces a complete, reviewable HARA for a realistic function.

Objectives

• Write an item definition for Lane Keeping Assist with boundaries, interfaces and assumptions.
• Identify malfunctioning behaviours using a structured method.
• Combine malfunctions with operating situations to form hazardous events.
• Rate severity, exposure and controllability with justified arguments and determine ASILs.
• Derive safety goals with safe states and fault-tolerant time intervals.

What you need

Key concepts

Item

The system or combination of systems implementing a function at vehicle level, here Lane Keeping Assist with its camera, controller and steering actuator interface.

Hazardous event

A combination of a hazard caused by malfunctioning behaviour and an operating situation, such as unintended steering torque while driving on a motorway at high speed.

Severity, exposure and controllability

S rates the possible harm, E how often the operating situation occurs, and C how likely the driver or others can avoid harm. Together they determine the ASIL.

Safety goal

A top-level safety requirement derived from the HARA, stating what must be avoided, with its ASIL, safe state and timing.

Step-by-step guide

1. 1

   Write the item definition

   Describe Lane Keeping Assist at vehicle level: it detects lane markings with a front camera and applies corrective steering torque through the electric power steering when the vehicle drifts without indication, within a speed range such as 60 to 130 km/h. Define boundaries, interfaces (camera, steering, turn indicators, driver torque sensor, HMI), driver interaction, legal assumptions and what is outside scope. List known limitations such as poor markings.

   Checkpoint: An item definition with a boundary diagram, interface list and stated assumptions.

2. 2

   Identify functions and malfunctions

   List the item's functions: detect lanes, decide intervention, command torque, warn and hand back to the driver. Apply guide words to each function, such as no function, unintended function, too much, too little, wrong direction, too early and too late. For example: unintended torque, excessive torque, torque in wrong direction, missing intervention. Keep only malfunctions that are possible at vehicle level.

   Checkpoint: A malfunction table with an ID, the function and the guide word for each entry.

3. 3

   Define operating situations

   Build a list of operating situations relevant to lane keeping: road type (motorway, rural road, urban), speed band, traffic density, weather and road condition, curve or straight, and adjacent objects such as oncoming traffic or barriers. Combine them carefully so the list covers realistic cases without exploding into thousands. Note exposure reasoning for each, based on driving time or frequency.

   Checkpoint: An operating situation catalogue with an exposure argument for each entry.

4. 4

   Form hazardous events

   Combine each malfunction with the relevant operating situations to form hazardous events, describing the hazard and its possible consequence, such as unintended steering torque towards oncoming traffic on a two-lane rural road at 80 km/h causing a head-on collision. Remove combinations that cannot lead to harm and record why. Keep each event short, specific and traceable to its malfunction and situation IDs.

   Checkpoint: A hazardous event list with traceable IDs and consequence descriptions.

5. 5

   Illustrate key events in simulation

   For three or four of the most important events, build scenarios in Driving Scenario Designer: an ego vehicle on a curved two-lane road with oncoming traffic, and inject an unintended lateral deviation. Observe how quickly the vehicle leaves the lane for different torque levels and speeds. This supports controllability arguments with time-to-line-crossing estimates instead of opinion alone. Save the scenarios so reviewers can rerun them when they question a rating.

   Checkpoint: Scenario plots of lateral offset over time with estimated time to lane departure for each event.

6. 6

   Rate S, E and C

   For each hazardous event, rate severity from S0 to S3, exposure from E0 to E4 and controllability from C0 to C3, and write a one- or two-sentence justification for every rating. Use the scenario results for controllability: a slow drift with driver hands on the wheel is easier to control than sudden strong torque. Mark uncertain ratings for review. Where two team members disagree on a rating, record both views and the agreed outcome.

   Checkpoint: Every hazardous event has S, E and C ratings with written justifications.

7. 7

   Determine ASILs

   Look up the ASIL for each event from the S, E and C combination using the ISO 26262 risk graph table implemented as a formula in the spreadsheet, and check a few by hand. Record QM where no ASIL applies. Review the distribution: the highest ASILs should come from high-speed situations with severe outcomes and low controllability, which matches intuition.

   Checkpoint: ASIL column filled for every event, with hand checks of at least five entries.

8. 8

   Derive safety goals

   Group hazardous events with similar hazards and write safety goals, such as avoid unintended steering torque that leads to lane departure, with the highest ASIL among its events. For each goal define a safe state, for example LKA deactivated with driver warning and no torque, and an estimated fault-tolerant time interval from the scenario results. Ensure every hazardous event rated above QM is covered.

   Checkpoint: A safety goal list with ASIL, safe state and fault-tolerant time interval, and full coverage of events.

9. 9

   Review the HARA

   Hold a structured review with classmates or a supervisor acting as independent reviewers. Use a checklist: completeness of malfunctions, realistic situations, justified ratings, correct ASIL lookup and complete safety goal coverage. Record review findings, decisions and changes in a log. Ratings often change after review; that is expected and shows the method working. Bring the scenario plots to the review so controllability arguments can be checked against evidence.

   Checkpoint: A review log with findings, resolutions and the updated HARA version.

10. 10

    Report

    Present the item definition, method, malfunction list, situations, hazardous events, ratings, ASILs, safety goals and review log. Explain the reasoning behind the highest-ASIL events in detail. State limits: student assumptions on exposure, no field data and a single variant. Note the next steps in the safety lifecycle: functional safety concept and technical safety requirements. Attach the spreadsheet and scenario files so the analysis can be checked and reused.

    Checkpoint: A complete HARA report with traceable tables and a clear next-steps section.

Testing & validation

• Every malfunction traced to at least one hazardous event or justified as harmless.
• Every rating has a written justification.
• ASILs checked against the standard's table by hand for a sample.
• Every hazardous event above QM covered by a safety goal.
• Independent review completed and logged.

Expected results

A complete, reviewed HARA for Lane Keeping Assist with traceable hazardous events, justified ratings, ASILs and safety goals with safe states and time intervals.

Take it further

• Continue to a functional safety concept with safety requirements per goal.
• Extend to a lane centring function and compare ASILs.
• Add SOTIF triggering conditions for poor lane markings under ISO 21448.
• Run a driver-in-the-loop simulator study to support controllability ratings.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.