Autonomous Emergency Braking with Staged Warnings and Braking

The problem

Even attentive drivers sometimes brake too late or not hard enough. AEB brakes automatically when a collision is imminent and the driver has not reacted. It is now required or rated in many markets and is spreading to Indian cars. Designing it means balancing early intervention, which prevents more crashes, against false braking, which is itself dangerous. This project builds a staged AEB and measures that balance.

Objectives

• Write AEB requirements covering warning, partial braking, full braking and driver override.
• Set up rear-end test scenarios with sensors and a tracker producing the most important object.
• Design staged AEB logic based on TTC and stopping-time calculations.
• Integrate the logic with a longitudinal vehicle model and brake actuator lag.
• Measure collision avoidance, impact speed reduction and false activations.

What you need

Key concepts

Staged intervention

AEB first warns the driver, then applies partial braking, then full braking as the collision becomes more imminent. Each stage gives the driver a chance to act first.

Stopping time

The time needed to stop from the current speed at a given deceleration, plus brake build-up time. Comparing it with TTC tells the logic when braking must begin.

Impact speed reduction

When a collision cannot be avoided, braking still lowers the impact speed and so the injury risk. It is an important AEB metric alongside full avoidance.

False activation

Braking when there is no real threat, for example for a car turning away or a roadside object. It risks rear-end crashes from following traffic and must be very rare.

Step-by-step guide

1. 1

   Write the AEB requirements

   Write numbered requirements: AEB operates between 10 and 80 km/h for vehicle targets in the ego lane; it gives a warning, then partial braking at a set deceleration, then full braking; the driver can override by strong accelerator input or steering; and false activations must be extremely rare. Set targets such as full avoidance up to a stated speed for a stationary target and impact speed reduction above that speed. Make every requirement testable.

   Checkpoint: A numbered, testable requirement list with avoidance and false-activation targets.

2. 2

   Set up the test scenarios

   Open Driving Scenario Designer and load the prebuilt Euro NCAP rear-end scenarios for a stationary, slower and braking target vehicle. Export each to a MATLAB function and script variations of ego speed, overlap and target deceleration. Add false-activation scenarios: an adjacent-lane car on a curve, a target turning away and a car leaving the lane. Mount a forward camera and radar on the ego vehicle in each scenario.

   Checkpoint: Scenario files that regenerate with any chosen speed and deceleration, including false-activation cases.

3. 3

   Build the perception chain

   In Simulink, use the Scenario Reader block to read actors and lane boundaries, sensor blocks for camera and radar detections, and the Multi-Object Tracker block to fuse them. Write a function that selects the most important object in the ego lane from confirmed tracks and lane boundaries. Output its range, range-rate and relative acceleration to the AEB logic. Check MIO selection on the curve scenario before going further.

   Checkpoint: The MIO is correct in every scenario, including the adjacent-lane car on the curve.

4. 4

   Model the vehicle and brakes

   Model the ego vehicle's longitudinal dynamics with a brake system that builds deceleration with a delay and a first-order rise, for example 0.2 s delay and 0.3 s rise time, limited to a maximum deceleration on dry asphalt. Include the driver's accelerator and brake inputs as signals so override can be tested. Validate stopping distance from 50 km/h against hand calculation with the same delay and deceleration.

   Checkpoint: Simulated stopping distance matches the hand calculation within a small margin.

5. 5

   Compute the decision quantities

   Compute TTC and enhanced TTC from the MIO data. Compute stopping times for the partial and full braking levels, including brake build-up time. Define the activation conditions: warning when TTC is below the warning time, partial braking when TTC is below the partial-braking stopping time plus a margin, and full braking when TTC is below the full-braking stopping time. Keep these as tunable parameters in a script.

   Checkpoint: Plots of TTC against the three stopping-time thresholds for a stationary-target scenario.

6. 6

   Implement the Stateflow logic

   Build a chart with states Default, FCW, PartialBraking1, PartialBraking2 and FullBraking, moving forward as TTC falls and releasing only when the ego has stopped or the threat is gone. Add an Override state entered on strong accelerator or steering input. Output the deceleration demand to the brake model and a warning flag. Animate the chart during a scenario run to check every transition.

   Checkpoint: Animated runs showing the expected state sequence in stationary, slower and braking target scenarios.

7. 7

   Run the avoidance tests

   Run every rear-end scenario variation with no driver braking, so AEB alone acts. Record whether contact occurs, impact speed, minimum gap and the time each stage started. Plot impact speed against initial ego speed for each target type. The curve should show full avoidance up to a certain speed and reduced impact speed above it. Compare against your requirement targets.

   Checkpoint: Impact-speed plots per target type with the full-avoidance speed limit marked.

8. 8

   Run false-activation and override tests

   Run the false-activation scenarios and record any warning or braking. Then rerun selected avoidance scenarios with a driver who steers away or presses the accelerator strongly and check that AEB releases. Add sensor noise and short track dropouts to see whether the logic stays stable. Every false activation must be traced to its cause, either perception or logic, and fixed or documented.

   Checkpoint: A table of false-activation and override results with zero unexplained cases.

9. 9

   Tune and check robustness

   Sweep the threshold margins and partial braking levels, and plot full-avoidance speed against the number of false activations or warnings in the nuisance set. Choose a setting and justify it. Then check robustness to a lower road friction value and a longer brake delay, which reduce avoidance performance. Report how much margin the chosen tuning leaves. Tune on a separate set of scenario variations from those used in the final evaluation, so the reported figures stay fair.

   Checkpoint: A trade-off plot and a robustness table for reduced friction and longer brake delay.

10. 10

    Verify and report

    Check each requirement against the results, automatically with Simulink Test if available, and produce a traceability matrix. Write up the requirements, scenarios, perception chain, decision logic, Stateflow design, results and robustness study. Stress that AEB development uses simulation, then closed test tracks with soft targets under supervision, and never testing on public roads. List each requirement that is not met with its cause and the change that would fix it, and explain how the results relate to the scenario families used in consumer test protocols.

    Checkpoint: A report with a requirement traceability matrix and a reproducible model and scenario set.

Testing & validation

• Stopping distance of the brake model against hand calculation.
• Collision avoidance and impact speed for stationary, slower and braking targets.
• False activations on adjacent-lane, turning and lane-leaving scenarios.
• Override behaviour for steering and accelerator input.
• Robustness to reduced friction and longer brake delay.

Expected results

A staged AEB function in Simulink with sensor fusion input, verified on Euro NCAP-style rear-end scenarios with measured avoidance speeds, impact speed reduction and false-activation results.

Take it further

• Add pedestrian and cyclist targets and crossing scenarios.
• Generate code with Embedded Coder and run software-in-the-loop tests.
• Add a friction estimate to adjust braking thresholds.
• Integrate with ACC so both functions share the same perception and arbitration.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.