The problem
Long highway drives and dense traffic tire drivers, and inconsistent following distances are a common cause of rear-end collisions. Adaptive cruise control holds a set speed when the road is clear and a safe time gap behind a slower vehicle. Building it from scratch teaches the core of longitudinal ADAS: mode logic, a spacing policy, controller tuning and comfort limits, all on a vehicle model the student understands.
Objectives
- Write ACC requirements for set speed, time gap, comfort limits and operating speed range.
- Model the longitudinal dynamics of an EV with an actuator lag for drive and brake torque.
- Design speed and spacing controllers with a constant time-gap policy.
- Implement mode switching, driver set-speed and time-gap selection in Stateflow.
- Verify the function on lead-vehicle scenarios against spacing, comfort and safety metrics.
What you need
Tools and toolboxes
- Simulink — The vehicle model, controllers and closed-loop test bench built from base blocks such as Integrator, Gain, PID Controller and Saturation.
- Stateflow — The ACC mode logic: off, standby, speed control, spacing control and driver override.
- MATLAB — Parameter scripts, scenario definitions, batch runs with sim() and metric calculation.
- Simulink Test (optional) — Test harnesses and a test manager suite that checks each requirement automatically.
- Model Predictive Control Toolbox (optional) — The Adaptive Cruise Control System block as a reference controller to compare with your own design.
Software
- MATLAB R2023b or later
- Simulink
- Stateflow
- Simulink Test (optional)
- Model Predictive Control Toolbox (optional)
Extra parts and data
None beyond the software above.
Key concepts
- Constant time-gap policy
- The desired distance to the lead vehicle is a standstill distance plus the ego speed times a time gap, for example 1.8 s. The gap grows with speed, as a careful driver's would.
- Speed and spacing modes
- With no relevant lead vehicle, ACC tracks the driver's set speed. When a slower vehicle is ahead, it controls spacing instead. The controller uses the smaller of the two acceleration demands.
- Comfort limits
- Limits on acceleration, deceleration and jerk keep ACC smooth. ACC is not an emergency brake: if more deceleration is needed, it warns the driver.
- Actuator lag
- Drive and brake torque do not change instantly. A first-order lag in the model makes the controller design realistic and shows why aggressive gains cause oscillation.
Step-by-step guide
- 1
Write the requirements
Write numbered requirements in plain language: ACC operates between 30 and 120 km/h, the driver can select set speed and one of three time gaps (for example 1.2, 1.8 and 2.4 s), deceleration is limited to a comfort value and jerk is limited, brake pedal input switches ACC to standby, and a takeover warning is raised when more braking is needed than ACC may apply. Add measurable acceptance criteria to every requirement so that each can be tested later.
Checkpoint: A numbered requirement list where every item has a measurable acceptance criterion.
- 2
Build the vehicle model
In Simulink, model a compact EV's longitudinal dynamics with mass, rolling resistance, aerodynamic drag and road grade, driven by a wheel torque command. Add a first-order lag of about 0.3 to 0.5 s between the commanded and actual acceleration to represent motor and brake response, and saturate the available drive and brake torque. Check the model by applying step commands and comparing top speed and coast-down against hand calculations.
Checkpoint: Step responses and a coast-down test that match hand-calculated values within a few per cent.
- 3
Model the lead vehicle and sensor
Create a lead vehicle whose speed follows a profile from a MATLAB script, and compute relative distance and relative speed. Add a simple sensor model with a maximum range, a small amount of noise and a 50 ms update interval, plus a flag that says whether a lead vehicle is detected in the ego lane. Keep the scenario definitions in one script so new profiles can be added without editing the model.
Checkpoint: Plots of relative distance and speed for a braking lead vehicle with sensor noise visible.
- 4
Design the speed controller
Design a PI controller that turns speed error into an acceleration demand. Tune it on the vehicle model so a 20 km/h step in set speed is reached without overshoot beyond about 1 km/h, while respecting the acceleration and jerk limits through a rate limiter and saturation. Add anti-windup so the integrator does not wind up while the demand is saturated, for example on a long climb.
Checkpoint: A set-speed step response with small overshoot and acceleration and jerk inside the limits.
- 5
Design the spacing controller
Compute desired distance d_des = d0 + t_gap × v_ego and the spacing error e = d − d_des. Design the acceleration demand as a feedback law on spacing error and relative speed, a_cmd = k1·e + k2·Δv, and tune k1 and k2 for a well-damped response. Linearise the loop with the actuator lag and check the closed-loop poles or step response. Saturate the demand to the comfort limits.
Checkpoint: A response to a lead vehicle slowing from 80 to 60 km/h with settled spacing and no oscillation.
- 6
Implement the mode logic in Stateflow
Build a Stateflow chart with states Off, Standby, SpeedControl, SpacingControl and Override. Use transitions for the main switch, set and resume buttons, brake pedal, accelerator pedal and the lead-vehicle detected flag. Add a time-gap selection substate. Arbitrate the final demand as the minimum of the speed and spacing demands when a lead vehicle is present, so the ACC never accelerates towards a slower car.
Checkpoint: Stateflow animation showing correct transitions for every button and pedal input in a scripted test.
- 7
Add the takeover warning
Compute the deceleration required to avoid closing below the minimum safe gap, from relative speed and distance. If it exceeds the ACC deceleration limit, raise a takeover warning to the driver. Make the warning latch for a minimum time and clear only when the required deceleration falls back below the limit. This shows clearly where ACC ends and forward collision warning or AEB must take over.
Checkpoint: A hard-braking lead-vehicle scenario where the takeover warning appears before the time gap drops below the minimum.
- 8
Build the test scenarios
Script at least eight scenarios: approach to a slower car, lead car braking gently and firmly, cut-in at short range, cut-out revealing a slower car, lead car accelerating away, set-speed changes and driver brake override. Run them with sim() in a loop at several ego speeds and time-gap settings. Store time histories of speed, distance, time gap, acceleration, jerk and mode for every run.
Checkpoint: A batch script that runs every scenario and setting and saves results to a single table.
- 9
Verify against the requirements
Write MATLAB functions that check each requirement automatically: steady-state time gap within tolerance, maximum deceleration and jerk inside limits, minimum time gap never below a safety threshold, correct override behaviour and takeover warning timing. Report pass or fail per requirement and scenario. If Simulink Test is available, put these checks into a test manager file so they run on every model change.
Checkpoint: A requirement-by-scenario pass/fail matrix with every failure explained or fixed.
- 10
Compare with a reference and report
Optionally run the same scenarios with the Adaptive Cruise Control System block from the Model Predictive Control Toolbox and compare spacing error, comfort and minimum time gap with your PI-based design. Write up the requirements, model, controller design, Stateflow logic, test scenarios and verification results. State clearly that ACC is a comfort function and that testing beyond simulation needs a closed test area under supervision.
Checkpoint: A report with requirement traceability, comparison results and the full model and scripts.
Testing & validation
- Vehicle model checked against hand calculations.
- Steady-state time gap error for each time-gap setting.
- Maximum deceleration and jerk inside comfort limits in all scenarios.
- Minimum time gap and takeover warning timing in hard-braking and cut-in scenarios.
- Requirement-by-scenario pass/fail matrix.
Expected results
A working Simulink and Stateflow ACC with a constant time-gap policy, verified automatically against written requirements on a library of lead-vehicle scenarios.
Take it further
- Add stop-and-go operation down to standstill.
- Replace the spacing controller with an MPC and compare comfort.
- Use detections from a Driving Scenario Designer scenario and a tracker in place of the ideal sensor.
- Generate C code with Embedded Coder and run the controller as software-in-the-loop.
Viva and review questions
Why use a time-gap policy instead of a fixed distance?
Stopping distance grows with speed, so a fixed distance is too large in slow traffic and too small at highway speed; a time gap scales naturally.
Why take the minimum of the speed and spacing demands?
It guarantees the car never accelerates towards a slower lead vehicle just because the set speed is higher.
What happens if more braking is needed than ACC allows?
ACC applies its maximum comfort deceleration and warns the driver to take over; emergency braking belongs to FCW and AEB functions.
Why did you add actuator lag to the model?
Real drive and brake torque respond with delay, and a controller tuned without lag can oscillate or overshoot on the real vehicle.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.