Powertrain Design-Space Exploration for Cost, Range and Performance

The problem

Powertrain choices interact: a bigger pack adds range but also mass, which costs energy and acceleration; a bigger motor improves acceleration but may run less efficiently in city driving. Concept engineers explore thousands of combinations to find the best trade-offs. This project builds a reproducible exploration workflow with honest models and constraints.

Objectives

• Define design variables, constraints and objectives for an example car.
• Build fast parametrised models of the pack, motor (scalable map) and vehicle.
• Verify the model and its scaling laws against reference cases.
• Run a multi-objective genetic search and extract Pareto fronts.
• Analyse which variables drive each objective and how robust the chosen design is.

What you need

Key concepts

Design variables

Here: series cell count, parallel cell count, motor torque scale factor and gear ratio. Some are integers, so the optimiser must respect integer constraints.

Motor scaling

A reference efficiency map is scaled in torque (and losses) to represent bigger or smaller motors of the same family. It is an approximation that must be stated.

Multi-objective optimisation

Searching for designs where no objective can be improved without worsening another. The result is a Pareto front, not a single best design.

Cost proxy

A simple relative cost from pack energy and motor peak power using stated per-unit assumptions. It ranks designs but is not a price estimate.

Step-by-step guide

1. 1

   Define the problem

   For an example C-segment car, define variables: series cells Ns (for example 90–110), parallel cells Np (2–6, with a stated cylindrical cell), motor torque scale (0.7–1.4 of a 250 N·m reference) and gear ratio (7–11). Objectives: maximise WLTP range, minimise 0–100 km/h time and minimise the cost proxy. Constraints: top speed at least 150 km/h, peak C-rate within the cell rating, pack voltage within the motor's range.

   Checkpoint: A problem definition table with variable bounds, objectives, constraints and the cost-proxy formula with its assumptions.

2. 2

   Build the pack model

   Write a MATLAB function that, from Ns, Np and cell data (capacity, nominal voltage, resistance, mass), returns pack energy, voltage, internal resistance, mass (cells times a packaging factor, for example 1.4) and maximum power at a C-rate limit. Keep it vectorised so a whole population can be evaluated quickly. Write unit tests for the function with matlab.unittest so later changes cannot silently break it, and include a case at each bound of Ns and Np.

   Checkpoint: For a known configuration, the pack function returns energy, voltage and mass matching a hand calculation.

3. 3

   Build the scalable motor model

   Load a reference motor efficiency map and scale its torque axis by the scale factor, scaling motor mass and inertia proportionally (state this assumption). Express losses as a function of normalised torque and speed so scaled maps stay physically plausible. Plot reference and scaled maps side by side. Check that the scaled map still covers the speed and torque range the vehicle tests need, and log any lookups that fall outside it during evaluation.

   Checkpoint: Scaled maps for 0.7 and 1.4 with peak efficiency unchanged and torque axes scaled as intended.

4. 4

   Build the fast vehicle model

   Use a backward or forward Simulink model with the road-load equation, the scaled motor map as a 2-D Lookup Table, the gear ratio and the pack model. Use a fixed-step solver with a 0.1 s step for speed, after confirming that energy changes by less than 1 per cent compared with 0.01 s. Wrap it in a MATLAB function evaluateDesign(x) that returns objectives and constraint values.

   Checkpoint: One call to evaluateDesign runs in seconds and returns range, 0–100 time and cost proxy.

5. 5

   Verify the model

   Check three reference designs by hand or against a separate detailed model: range from energy and Wh/km, acceleration from a simple constant-torque/constant-power integration, and top speed from the power balance. Also confirm that infeasible designs (for example C-rate too high) are reported as constraint violations, not silently clipped. Keep these reference cases as regression tests that run before every optimisation, so model edits cannot quietly change results.

   Checkpoint: Reference-design results within a few per cent of independent calculations, and constraint violations correctly flagged.

6. 6

   Run the multi-objective search

   Call gamultiobj with integer constraints on Ns and Np, nonlinear constraints from evaluateDesign, a population of about 100 and a stated number of generations. Cache results by design vector to avoid repeated simulations. Use parallel evaluation if available. Save the full history so the analysis can be repeated without rerunning. Log the number of evaluations and the wall-clock time, because these matter when comparing with other search methods.

   Checkpoint: A converged Pareto set whose front changes little over the last generations.

7. 7

   Analyse the Pareto front

   Plot range against 0–100 time, coloured by cost proxy, and a three-objective parallel-coordinates plot. Identify knee points where a small loss in one objective gives a large gain in another. Plot each design variable along the front to show which variables change and which stay at a bound. Discuss whether the variables sitting at bounds suggest the bounds themselves should be widened in a follow-up study.

   Checkpoint: Pareto plots with two or three highlighted knee designs and their variable values.

8. 8

   Sensitivity and robustness

   For the knee designs, perturb mass, CdA, cell capacity and motor efficiency by stated amounts with a Monte Carlo of a few hundred samples and report spread in range and acceleration. Repeat the search with a different cost-proxy assumption and compare fronts. This shows which conclusions depend on uncertain assumptions. Report which knee design keeps its constraint margins best under uncertainty, as this is often more useful than the nominal optimum.

   Checkpoint: Spread of range and acceleration for each knee design and a comparison of fronts under two cost assumptions.

9. 9

   Validate the search

   Run a coarse full-factorial grid over the same space (or a Latin hypercube sample of many points) and check that the genetic search front dominates or matches the grid's non-dominated set. Repeat the search with different random seeds and compare the fronts using the hypervolume indicator. If the sample set finds non-dominated points that the search missed, increase the population or generations and repeat until the fronts agree.

   Checkpoint: Hypervolume values across seeds within a small spread, and no grid point dominating the search front.

10. 10

    Report

    Document the problem, models, scaling assumptions, verification, search settings, Pareto results, sensitivity and validation. Make clear that the cost proxy ranks designs under stated assumptions and is not a price. Provide the code and cached results so readers can rerun the analysis with their own cell or motor data. Add a short guide explaining how to swap in another cell datasheet or motor map and rerun the full exploration.

    Checkpoint: A report with reproducible Pareto fronts, stated assumptions and recommended knee designs.

Testing & validation

• Pack and vehicle functions agree with hand calculations for reference designs.
• Solver step size has less than 1 per cent effect on energy.
• Search front matches or dominates a grid or sampled reference set.
• Hypervolume is consistent across random seeds.

Expected results

A reproducible design-space exploration workflow with Pareto fronts of range, acceleration and a cost proxy for an example car, knee-point designs, robustness results and validation against a sampled reference.

Take it further

• Add a second motor (dual-motor AWD) as a discrete design choice.
• Include cell chemistry as a categorical variable.
• Replace the Simulink model with a trained surrogate for faster search.
• Add a battery thermal constraint on repeated acceleration.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.