The problem
Rear-end collisions are among the most frequent crash types, often caused by distraction or following too closely. Forward collision warning alerts the driver early enough to brake. Warning too late is useless and warning too often makes drivers ignore or disable the system. Getting the timing right with simple, explainable logic based on time-to-collision is the first step towards automatic emergency braking.
Objectives
- Define warning requirements in terms of driver reaction time and achievable braking.
- Compute TTC, enhanced TTC and required deceleration from range, range-rate and acceleration.
- Design staged caution and warning logic with hysteresis.
- Build rear-end test scenarios covering stationary, slower and braking lead vehicles.
- Measure warning lead time, missed warnings and nuisance warnings.
What you need
Tools and toolboxes
- MATLAB — Scenario scripts, TTC calculations, batch simulation and metric analysis.
- Simulink — The closed-loop model of ego and lead vehicles, sensor model, FCW logic and a driver reaction model.
- Stateflow (optional) — The staged alert logic with latching and hysteresis.
- Automated Driving Toolbox (optional) — Driving Scenario Designer scenarios and its prebuilt Euro NCAP rear-end scenarios as reference test cases.
Software
- MATLAB R2023b or later
- Simulink
- Stateflow (optional)
- Automated Driving Toolbox (optional)
Extra parts and data
None beyond the software above.
Key concepts
- Time-to-collision
- TTC = range / closing speed, the time to impact if both vehicles keep their current speeds. It is undefined when the gap is opening.
- Enhanced TTC
- Includes relative acceleration, solving the quadratic for time to zero range. It warns earlier when the lead vehicle is braking, the case where plain TTC is most optimistic.
- Required deceleration
- The constant deceleration the ego must apply now to avoid contact. Comparing it with what a driver can reasonably achieve is another way to set warning thresholds.
- Nuisance warning
- A warning in a situation the driver judges safe, such as passing a slower car in the next lane. Too many cause drivers to lose trust in the system.
Step-by-step guide
- 1
Set the warning requirements
Define the operating range (for example ego speed 20 to 120 km/h) and state the timing target in physical terms: a warning should come early enough that a driver with a reaction time of about 1.2 to 1.5 s, braking at a firm but not extreme level, can avoid the collision. Set limits on missed warnings and nuisance warnings per hour. Write down your assumed reaction time and braking level and justify them from published human-factors literature.
Checkpoint: A requirement sheet with stated reaction time, braking assumptions, operating range and targets.
- 2
Build the vehicle and scenario model
In Simulink, model ego and lead vehicles as point masses with speed profiles from MATLAB scripts. Compute true range, range-rate and relative acceleration. Add a sensor block with a maximum range of about 150 m, a 50 ms update, Gaussian noise on range and range-rate, and a target-present flag. Keep the scenario parameters (speeds, decelerations, initial gaps) in a structure so batch runs are easy to set up.
Checkpoint: Plots of true and measured range and range-rate for a lead vehicle braking at 4 m/s².
- 3
Compute TTC and enhanced TTC
Implement TTC = range / closing speed, set to infinity when the gap is opening or closing speed is below a small threshold. Implement enhanced TTC by solving 0 = r + ṙ·t + ½·a_rel·t² for the smallest positive root, handling the cases of no real root and a lead vehicle that stops before impact. Filter range-rate with a simple low-pass or Kalman filter to avoid noisy TTC values.
Checkpoint: TTC and enhanced TTC traces where enhanced TTC drops earlier when the lead vehicle brakes.
- 4
Compute required deceleration
Derive the deceleration the ego needs, starting after a driver reaction delay, to stop its approach before the gap reaches a safety margin, including the case where the lead vehicle stops first. Implement it in a MATLAB Function block. Use it as a second warning criterion and compare its timing with TTC thresholds on the same scenarios, since the two react differently at high and low speed.
Checkpoint: Required-deceleration traces for slow, braking and stationary lead-vehicle scenarios.
- 5
Design the staged alert logic
Implement two alert levels: a caution when enhanced TTC falls below a first threshold, and an imminent warning below a second threshold or when required deceleration exceeds a set value. Latch each alert for a minimum time and release it only when TTC rises above the threshold plus a hysteresis margin. Suppress alerts when the driver is already braking hard, since the warning adds nothing then.
Checkpoint: Alert timelines that rise cleanly without flicker in noisy measurement conditions.
- 6
Add a driver reaction model
To test whether warnings are early enough, add a simple driver model that starts braking a fixed reaction time after the imminent warning, ramping up to a chosen deceleration. Run each scenario with this driver and record whether a collision occurs and the minimum gap. This turns warning timing into a clear outcome: collision avoided or not, under stated driver assumptions.
Checkpoint: Collision and minimum-gap results for each scenario with the modelled driver response.
- 7
Build the scenario set
Create rear-end scenarios similar to the Euro NCAP car-to-car rear cases: approaching a stationary car, approaching a slower moving car and following a car that brakes. Vary ego speed in 10 km/h steps, lead deceleration from 2 to 7 m/s² and initial gap. Add nuisance scenarios such as a car in the adjacent lane, a lead car turning off and a slow car the ego is already braking for.
Checkpoint: A scenario table of at least 100 combinations, including nuisance cases, ready for batch runs.
- 8
Run the batch evaluation
Run every scenario with sim() in a loop, logging alert times, TTC at warning, required deceleration and outcome with the driver model. Compute warning lead time relative to the last point at which the modelled driver could still avoid the collision, plus counts of missed warnings and nuisance warnings. Repeat with plain TTC only, enhanced TTC only and the combined logic to compare the three versions.
Checkpoint: A results table of lead time, missed and nuisance warnings for the three logic versions.
- 9
Tune the thresholds
Sweep the caution and warning thresholds and plot missed warnings against nuisance warnings for each version, like a trade-off curve. Choose thresholds that meet the requirement targets and explain the trade-off. Check sensitivity to the assumed driver reaction time by repeating the evaluation at 1.0 and 2.0 s, since real drivers vary widely, especially when distracted. Tune on half of the scenarios and report final figures on the other half, so the thresholds are not fitted to the test data.
Checkpoint: Trade-off curves with the chosen thresholds marked and a reaction-time sensitivity table.
- 10
Report
Document the requirements, TTC and enhanced TTC derivations, required-deceleration logic, alert design, driver model, scenarios and results. Discuss where plain TTC fails and how enhanced TTC and required deceleration help. State the limits: ideal lane assignment, a single lead target and a simple driver model. Note that FCW testing beyond simulation uses closed test tracks with soft targets, never public roads.
Checkpoint: A report with derivations, trade-off curves and a reproducible scenario and results package.
Testing & validation
- TTC and enhanced TTC checked against hand calculations on simple cases.
- Warning lead time across ego speeds and lead decelerations.
- Collision avoidance with the modelled driver response.
- Missed and nuisance warning counts for plain TTC, enhanced TTC and combined logic.
- Sensitivity of results to driver reaction time.
Expected results
A tuned forward collision warning function with staged alerts, evaluated across a large set of rear-end and nuisance scenarios, with a clear trade-off between missed and nuisance warnings.
Take it further
- Add automatic emergency braking after the warning stage.
- Replace the ideal sensor with fused camera and radar tracks from a tracker.
- Add lane assignment so vehicles on curves in adjacent lanes are handled.
- Make thresholds adapt to measured driver attention from a cabin camera.
Viva and review questions
Why is plain TTC optimistic when the lead vehicle brakes?
It assumes the closing speed stays constant, but braking increases the closing speed, so the real time to impact is shorter.
How did you choose the warning threshold?
From the driver reaction time and braking assumptions, then tuned on a trade-off curve between missed warnings and nuisance warnings.
Why suppress the warning when the driver is already braking hard?
The driver has already responded, so the warning adds distraction without improving safety, and it would count as a nuisance warning.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.
