Eco-Driving Speed Profile for Minimum Energy on a Route

The problem

How a route is driven changes EV energy use as much as the vehicle itself: hard acceleration, high cruise speed and late braking all waste energy that regeneration only partly recovers. Eco-driving assistants suggest speed profiles that save energy without making the trip much slower. Finding such profiles is an optimisation problem with a clear physical meaning, well suited to a B.Tech project.

Objectives

• Model battery energy as a function of a speed profile on a route with stops and gradients.
• Formulate the minimum-energy problem with trip-time, speed-limit and acceleration constraints.
• Solve it with fmincon in the distance domain.
• Compare energy and trip time with baseline driving styles.
• Study the energy-versus-trip-time trade-off.

What you need

Key concepts

Distance-domain formulation

The route is divided into fixed distance steps and the speed at each step is the decision variable. Time per step is Δs / v̄, which makes speed limits and stop positions easy to express.

Energy per segment

Battery energy is the tractive power divided by drivetrain efficiency when motoring, multiplied by regeneration efficiency when braking, integrated over each segment. Asymmetric efficiencies are why coasting often beats braking.

Constrained optimisation

fmincon minimises energy subject to bounds (0 ≤ v ≤ limit), linear inequalities and a non-linear trip-time constraint, using a gradient-based method such as SQP or interior-point.

Pareto front

The set of profiles where energy cannot be reduced without increasing trip time. Sweeping the time limit traces this curve.

Step-by-step guide

1. 1

   Define the route and vehicle

   Create an example 3 km urban route with two stops, a 40 km/h zone and a 5 per cent climb over 300 m. Store distance, speed limit, gradient and stop flags in a table at 10 m resolution. Use example car parameters: 1,200 kg, Cd·A of 0.65 m², Crr of 0.01, 88 per cent drivetrain efficiency and 65 per cent regeneration efficiency. Keep everything in one parameter script.

   Checkpoint: A plot of speed limit and elevation against distance that matches the route description.

2. 2

   Write the energy function

   Write energyOfProfile(v, route, p) that takes the vector of node speeds, computes average speed and acceleration per segment from a = (v₂² − v₁²) / (2Δs), then tractive force from the road-load equation and segment energy F·Δs. Apply motoring or regeneration efficiency depending on the sign. Return total battery energy in Wh and trip time as the sum of Δs / v̄. Guard against zero speed with a small floor.

   Checkpoint: For a constant 30 km/h profile on a flat route, energy matches a hand calculation within 1 per cent.

3. 3

   Build the baselines

   Create two reference profiles. The constant-speed driver accelerates at 1 m/s² to a cruise speed just under each limit and brakes at 2 m/s² for stops. The aggressive driver accelerates at 2.5 m/s², cruises at the limit and brakes late at 3 m/s². Compute energy and trip time for both. These give the comparison points and also a trip time to use as the optimiser's constraint.

   Checkpoint: The aggressive profile uses more energy and takes less time than the constant-speed profile.

4. 4

   Formulate the optimisation

   Decision variables are node speeds. Set bounds from the speed-limit table and force speed to zero at stop nodes by setting both bounds to zero. Add acceleration and deceleration limits as non-linear inequalities from (v₂² − v₁²) / (2Δs). The trip-time limit is a non-linear inequality: total time must not exceed the baseline time plus an allowed margin. Use fmincon with the 'sqp' algorithm.

   Checkpoint: fmincon returns exit flag 1 or 2 with all constraint violations below the tolerance.

5. 5

   Give a good starting point and scale

   Start from the constant-speed baseline so the problem begins feasible. Scale energy to kWh-level numbers and speeds to m/s so the gradients are well conditioned. Supply analytic gradients if convergence is slow, or set FiniteDifferenceType to central. Record iteration count and solve time. Check sensitivity to the starting point by also starting from a slower uniform profile. If the solver stalls, loosen the step tolerance slightly and check that the trip-time constraint is not active from the very first iteration.

   Checkpoint: Both starting points converge to profiles with energy within a fraction of a per cent of each other.

6. 6

   Interpret the optimal profile

   Plot optimal speed against distance with the limits and baselines. Typical features are moderate acceleration, cruising below the limit, early coasting before stops, and slowing slightly on the climb then recovering on the descent. Plot battery power to show where energy is spent and recovered. Explain each feature in terms of aerodynamic loss, regeneration efficiency and the time constraint. Overlay the cumulative energy curves of the optimum and both baselines so the reader can see where along the route the saving is made.

   Checkpoint: A profile plot with each feature annotated and linked to a term in the energy equation.

7. 7

   Cross-check in a time-domain model

   Convert the optimal profile from distance to time with cumulative time per segment and feed it to a Simulink longitudinal model with a driver PI controller following the speed. Compare the Simulink energy with the optimiser's energy. A large gap usually means the distance discretisation is too coarse or the acceleration estimate is inconsistent. Also check that the driver controller tracks the profile closely, because tracking error itself changes energy use and can hide the effect being measured.

   Checkpoint: Simulink energy agrees with the optimiser energy within about 2 per cent.

8. 8

   Sweep the trip-time limit

   Run the optimiser for time margins from 0 to 30 per cent above the aggressive driver's time in a loop, starting each run from the previous solution. Plot energy against trip time to draw the Pareto front and mark the two baselines on the same axes. Note where the curve flattens: beyond that point, extra time gives little extra saving.

   Checkpoint: A smooth Pareto curve with both baselines lying above it.

9. 9

   Test sensitivity to parameters

   Repeat the optimisation with regeneration efficiency at 40 and 80 per cent and with a heavier vehicle. Observe how coasting gives way to regenerative braking as regeneration efficiency rises. Also refine the distance step from 10 m to 5 m to show the result is not an artefact of discretisation. Keep the same route and trip-time margin for every case so the only change between runs is the parameter under study, and record solve time for each case too.

   Checkpoint: A table of energy saved against baseline for each parameter case and both step sizes.

10. 10

    Report

    Present the route, energy model, formulation, solver settings, optimal profile, Pareto front and sensitivity. Quote savings as percentages against each baseline at stated trip times. State the limitations: no traffic, a simplified motor efficiency and a known route. Suggest how the profile could become advice for a driver, for example a target speed shown on a dashboard. Include the parameter script and the optimisation code as appendices so another student can reproduce every figure from the report.

    Checkpoint: A report with the Pareto plot and a savings table for at least three time margins.

Testing & validation

• Energy function matches a hand calculation for constant speed.
• Optimiser converges from two different starting points to the same energy.
• Optimised profile satisfies speed, stop, acceleration and trip-time constraints.
• Time-domain Simulink re-simulation agrees with optimiser energy.
• Results unchanged when the distance step is halved.

Expected results

An optimised minimum-energy speed profile for an example route, with an energy-versus-trip-time Pareto front and quantified savings against constant-speed and aggressive driving baselines.

Take it further

• Replace constant efficiencies with a motor efficiency map.
• Add a traffic-light timing window as a time constraint at a node.
• Solve with dynamic programming and compare with fmincon.
• Implement a receding-horizon version that re-optimises as the vehicle moves.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.