Simulating NCAP-Style AEB Test Scenarios and Scoring

The problem

Consumer test programmes rate AEB systems with standard scenarios at defined speeds and overlaps, and manufacturers tune their functions against these protocols long before track tests. Reproducing the scenarios and scoring logic in simulation shows a student how a function is judged and where it loses points.

Objectives

• Study the scenario definitions and scoring principles of a published NCAP AEB protocol.
• Recreate car-to-car and pedestrian scenarios in the Driving Scenario Designer.
• Run an AEB controller through each scenario at the protocol's test speeds.
• Score each run by avoidance or speed reduction and aggregate a protocol-style result.
• Identify the scenarios and speeds where the function loses most points.

What you need

Key concepts

Car-to-car rear scenarios

Standard AEB tests where the ego car approaches a stationary, slower-moving or braking target car from behind at set speeds and lateral overlaps.

Vulnerable road user scenarios

Tests with pedestrian or cyclist targets crossing or walking along the road, sometimes emerging from behind parked cars.

Speed reduction

When a collision cannot be avoided, the difference between the initial speed and the impact speed. Protocols award partial credit for reducing impact speed.

Overlap

How much of the ego car's width lines up with the target, expressed as a percentage. Partial overlaps are harder because the target may sit at the edge of the sensor's view.

Step-by-step guide

1. 1

   Study the protocol

   Read the current published AEB test and assessment protocols of a consumer programme such as Euro NCAP, and note the scenario families, test speeds, overlaps, target types and how points are awarded. Record the scoring rules in your own table rather than copying them, and note the protocol version. Since protocols change between versions, state clearly which version you follow and treat your score as an approximation, not an official rating.

   Checkpoint: A table of scenarios, speeds and scoring rules with the protocol version noted.

2. 2

   Load and inspect prebuilt scenarios

   Open the Driving Scenario Designer and load the prebuilt Euro NCAP scenarios that ship with the Automated Driving Toolbox, such as car-to-car rear stationary and pedestrian crossing cases. Check that their speeds, overlaps and target placements match your protocol table, and adjust where your chosen version differs. Export each one to a MATLAB function with speed and overlap as input arguments, so a script can generate every test point.

   Checkpoint: Each scenario family exists as a function that produces the right geometry for any test speed and overlap.

3. 3

   Model sensors and the AEB controller

   Add a front radar and camera to the ego vehicle with realistic ranges and fields of view. Build the AEB in Simulink or MATLAB: select the most important object in the ego path, compute TTC, then apply a forward collision warning followed by staged partial and full braking. You can start from the AEB reference example in the Automated Driving Toolbox and replace parts with your own logic. Model brake actuation with a short delay and a deceleration ramp.

   Checkpoint: The AEB stops the ego car before a stationary target at a low test speed with a logged warning and brake sequence.

4. 4

   Generate the test matrix

   From the protocol table, generate every combination of scenario, test speed and overlap. For car-to-car rear stationary, this means speeds from the lowest to the highest specified in fixed increments and the specified overlaps. For pedestrian scenarios, include far-side and near-side crossings, adult and child targets where the protocol has them, and obstructed cases. Store the matrix as a table with one row per test.

   Checkpoint: A test matrix table covering every protocol test point.

5. 5

   Run the matrix and record outcomes

   Run each test and record whether a collision occurred, the impact speed computed from ego and target speeds at the moment of contact, the time of first warning and of first braking, and peak deceleration. Detect contact from actor bounding boxes using ground-truth poses. Check a sample of runs visually on the bird's-eye plot. Save all results with the scenario parameters so scoring can be repeated without rerunning the simulations.

   Checkpoint: A results table with collision flag and impact speed for every test point.

6. 6

   Implement the scoring

   Write a scoring function that follows the principles in your protocol table: full credit for avoidance, partial credit scaled by speed reduction, and the weighting of scenarios into a total. Make the rules data-driven, read from a table, so a new protocol version can be scored by editing data rather than code. Verify the function with hand-calculated examples: a full avoidance, a partial reduction and a no-reaction case.

   Checkpoint: The scoring function reproduces three hand-calculated example scores exactly.

7. 7

   Analyse where points are lost

   Plot impact speed against test speed for each scenario and overlap, and show the points lost per scenario family. Identify patterns: small overlaps failing because the target is detected late, high speeds failing because braking starts too late, or pedestrian cases failing because of the camera's field of view. Trace each failure to a cause in the logs, such as late object selection or brake delay.

   Checkpoint: A chart of points lost per scenario family with a cause identified for each main loss.

8. 8

   Improve the function and rescore

   Make one targeted change at a time: widen the in-path selection for small overlaps, start partial braking earlier, or improve pedestrian tracking. Rerun the matrix after each change and compare total score and false activations in a set of no-threat scenarios you add for this purpose. Show that an earlier trigger can raise the score but also increase unwanted braking, and choose a balanced setting.

   Checkpoint: Before-and-after scores for at least two changes with their effect on false activations.

9. 9

   Report

   Present the protocol summary with its version, the simulation setup, the test matrix, the scoring method and the results. State clearly that this is a simulation-based estimate with idealised sensors and vehicle dynamics, not an official rating, and that real assessments use instrumented track tests with soft targets. Include all scripts and the protocol data table so the score can be reproduced.

   Checkpoint: A report with reproducible scores and a clear statement of what the score does and does not mean.

Testing & validation

• Scenario geometry checked against the protocol table.
• Scoring function verified with hand calculations.
• Impact speed computed from ground truth at contact.
• False activations measured in added no-threat scenarios.

Expected results

A simulation-based NCAP-style AEB assessment with a data-driven scoring tool, a score for the student's AEB and an analysis of where and why it loses points.

Take it further

• Add cyclist and motorcyclist scenarios.
• Add sensor noise and missed detections and measure score sensitivity.
• Compare two protocol versions and how they rank the same function.
• Model wet road friction and its effect on avoidance.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.