Skip to main content
emobility.academy
PhDThermal managementResearch About 16 weeksMATLAB & Simulink

Predictive Battery Thermal Control Using Route Information

Design a model predictive controller that uses route information, such as upcoming grades, speed and a planned fast-charge stop, to pre-cool or pre-heat an EV battery. Compare its energy use and temperature compliance with reactive thermostat and PI control in closed-loop simulation.

Tools: Simulink · Model Predictive Control Toolbox

Predictive Battery Thermal Control Using Route Information: DIYguru EV lab with charging and electrical trainers
Representative photo from DIYguru's EV lab, not of this specific project.

The problem

Reactive battery thermal control responds only after temperature rises, so it often runs the chiller hard during hill climbs or just before fast charging, when cooling is most expensive and least effective. Navigation already knows the route, elevation and charging stops. Predictive control can use that preview to move cooling earlier and cheaper, but it needs a reliable control-oriented model and a way to handle forecast errors.

Objectives

  • Build a control-oriented battery thermal model and a higher-fidelity plant model.
  • Formulate an MPC problem using a preview of predicted heat generation and charging events.
  • Implement linear or adaptive MPC in Simulink and tune horizon, weights and constraints.
  • Compare energy and temperature metrics with thermostat and PI baselines on realistic routes.
  • Study robustness to forecast errors in speed, grade and ambient temperature.

What you need

Tools and toolboxes

  • Model Predictive Control Toolbox — MPC Controller or Adaptive MPC Controller blocks with measured-disturbance preview, constraints and weight tuning in the MPC Designer app.
  • Simulink — Closed-loop simulation of plant, controller and route preview signals.
  • Simscape — Higher-fidelity plant model of pack, coolant loop and chiller, so the controller is tested on a model different from its internal one.
  • MATLAB — Route generation, model identification, scripted scenario studies and statistics.
  • Optimization Toolbox — Optional: offline dynamic-programming or fmincon benchmark giving the best achievable result with perfect preview.

Software

  • MATLAB R2023b or later
  • Simulink
  • Model Predictive Control Toolbox
  • Simscape and Simscape Fluids (for the plant)
  • CSV route data with speed, elevation and charging stops

Extra parts and data

None beyond the software above.

Key concepts

Model predictive control
At each step the controller solves an optimisation over a future horizon using a model and forecasts, applies only the first move and repeats. It handles constraints such as maximum chiller power directly.
Measured disturbance preview
Known future inputs, such as predicted heat generation from the route, are fed to the MPC as a previewed disturbance so it can act before they arrive.
Control-oriented model
A low-order model, for example two thermal states for battery and coolant, that is accurate enough for prediction yet fast enough to optimise in real time.
Forecast error
Real speed, traffic and ambient differ from predictions, so a predictive controller must stay safe and reasonably efficient when its preview is wrong.

Step-by-step guide

  1. 1

    Define scenarios and metrics

    Define example routes: an intercity drive with a long climb, followed by a fast-charge stop, at 40 °C ambient, and an urban route with frequent stops. Fix the battery temperature window, for example 20–35 °C during driving and below a stated value at charge start, and define metrics: chiller and pump energy, time outside the window, peak temperature and temperature at charge start. Write the baselines: thermostat with hysteresis and a PI controller on battery temperature.

    Checkpoint: A scenario list, metric definitions and baseline descriptions agreed before any controller is built.

  2. 2

    Build the plant model

    Build a Simscape plant with a lumped pack thermal mass, a coolant loop with pump and cold plate, and a chiller modelled as a heat-removal element with an electrical power that depends on COP and ambient. Drive it with heat generation computed from a vehicle and electrical pack model on each route. Use ode23t and check energy balances in steady state.

    Checkpoint: The plant closes its energy balance within two per cent and produces plausible temperature traces under thermostat control.

  3. 3

    Identify the control-oriented model

    Derive a two-state linear model with battery and coolant temperatures, chiller cooling power as input and battery heat generation and ambient as disturbances. Fit its parameters to plant simulation data with a least-squares fit, or linearise the plant at an operating point. Validate prediction accuracy on a different route over the intended horizon length. Keep the model order low so the MPC solves quickly.

    Checkpoint: Open-loop prediction error over a 10-minute horizon below a stated bound, for example 1 °C RMS on held-out data.

  4. 4

    Generate the preview signal

    From the route's speed and elevation, compute expected heat generation ahead using the same vehicle and pack models but nominal parameters, and mark the charging stop as a large future heat input. Feed this as a measured disturbance with preview to the MPC block. Create versions of the preview with added errors in speed, grade and ambient for robustness tests.

    Checkpoint: Preview signals that match the true heat generation for the nominal case and deviate by known amounts in the error cases.

  5. 5

    Formulate and implement the MPC

    Configure an MPC object in MATLAB with the identified model, a sample time such as 10 s, a prediction horizon of several minutes and constraints on cooling power and its rate of change. Penalise battery temperature outside the window with soft output constraints and penalise cooling power to save energy. Place the MPC Controller block in the closed loop with the Simscape plant.

    Checkpoint: The MPC runs in closed loop without infeasibility warnings and keeps temperature within the window on the nominal route.

  6. 6

    Tune horizon and weights

    Sweep prediction horizon and the weight ratio between temperature violation and energy, scripting runs with sim(). Plot energy against time outside the window to show the trade-off front. Choose a setting and justify it. Check computation time per step to confirm it is compatible with an automotive controller sample time. Keep the same scenario set for every tuning so points on the trade-off front are comparable, and avoid tuning on the routes used for final evaluation.

    Checkpoint: A trade-off plot and a chosen tuning with measured solve time per step.

  7. 7

    Compare with baselines

    Run thermostat, PI and MPC on all routes and ambient cases. Record every metric. Show time traces for the climb-then-charge route, highlighting how MPC pre-cools before the climb and before arrival at the charger while baselines react late. Explain where the energy saving comes from, for example running the chiller at a higher COP when ambient is cooler or load is lower.

    Checkpoint: A results table across scenarios with MPC compared with both baselines on every metric.

  8. 8

    Compute a perfect-preview benchmark

    Solve the whole-route problem offline with dynamic programming or fmincon using perfect knowledge of the disturbances, to obtain a lower bound on energy for the same constraints. Report how close MPC gets to the bound, which tells you whether a longer horizon or better model would be worth the effort. Use the same constraints, sample time and initial conditions as the MPC runs so the comparison is fair, and use the control-oriented model so the gap reflects horizon effects.

    Checkpoint: Benchmark energy reported with MPC's gap to it as a percentage.

  9. 9

    Robustness to forecast errors

    Run MPC with the erroneous previews, including a delayed charge stop, underestimated grade and wrong ambient. Record constraint violations and energy. If violations grow, add feedback through the MPC's state estimator or tighten soft constraints. Compare the degradation with the baseline controllers, which do not use preview. Run each error case at several magnitudes to show how performance degrades, and include a case where the charge stop is cancelled to check the controller does not over-cool unnecessarily.

    Checkpoint: Robustness table showing MPC performance under each forecast error, with any safety-relevant violation explained.

  10. 10

    Report and publishable findings

    Present the plant, control model, MPC design, comparisons, benchmark gap and robustness results. State the limitations: one plant structure, simulated routes and a simplified chiller. Discuss the steps towards a vehicle implementation, such as code generation for the MPC and integration with navigation data. Release the scripts, route data and controller settings so the results can be reproduced, and present energy savings with the scenarios they depend on rather than as a single figure. Discuss what would change with a measured chiller map.

    Checkpoint: A thesis chapter with reproducible scripts and a clear statement of the energy saving and its conditions.

Testing & validation

  • Plant energy balance and plausible baseline behaviour.
  • Control-model prediction error on held-out data.
  • MPC feasibility and solve time per step.
  • Metric comparison against thermostat and PI baselines on all routes.
  • Gap to the perfect-preview benchmark and robustness under forecast errors.

Expected results

A route-aware MPC for battery thermal management, evaluated against standard baselines and an offline optimum, with its robustness to forecast errors quantified.

Research angle for your PhD

Research questions: how much auxiliary energy and battery temperature exceedance can route preview save in hot climates, how much of the offline optimum does MPC recover, and how quickly do the gains vanish as forecast error grows? Metrics: thermal energy per trip, time outside the window, temperature at charge start and gap to the dynamic-programming bound. Baselines: thermostat, PI and MPC without preview. Validation: test on a plant model distinct from the controller model and across many routes, including Indian highway and ghat profiles. A rigorous robustness analysis with forecast error, which many published studies omit, is what makes the work publishable.

Take it further

  • Use nonlinear MPC with a COP map dependent on ambient and load.
  • Add cabin cooling to the same optimisation with shared compressor capacity.
  • Generate code from the MPC with Embedded Coder and measure execution time on a target processor.
  • Learn the preview error model from recorded trips.

Viva and review questions

Why does pre-cooling save energy rather than just moving it earlier?

Cooling earlier can happen at lower power and higher COP, and avoids running the chiller at maximum during peak load or charging when efficiency is lowest, so total electrical energy can fall.

Why test the MPC on a different plant model?

Testing on its own internal model hides model mismatch; a higher-fidelity plant shows whether the controller is robust to the differences it will meet in reality.

What does the dynamic-programming benchmark tell you?

It gives the best result achievable with perfect information, so the MPC's gap to it shows how much is lost to horizon length, model error and real-time constraints.

How do soft constraints help?

They let the optimiser exceed the temperature window slightly with a heavy penalty instead of becoming infeasible, which keeps the controller running when disturbances are larger than expected.

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.

Related EV projects

All 100 MATLAB & Simulink EV projects