The problem
Fixed charging rules treat a new and an aged battery the same, although an aged cell may need gentler charging and its usable limits shift. Ageing-aware control needs a degradation model that can run on the vehicle, an estimate of the cell's current health and a controller that uses both, all within the limits of embedded hardware.
Objectives
- Build and compare degradation models (empirical calendar and cycle ageing, and a data-driven model) on public datasets
- Estimate state of health online from charge data on the STM32
- Design a charging policy that minimises modelled degradation subject to a charge-time or departure constraint
- Validate the estimator and controller on the kit and quantify the trade-off against a fixed baseline
What you need
From the EV Embedded Development Kit
- Second STM32F103C8T6 as the Smart BMS unit
- 1S battery with connector and T-sense input
- Battery charging unit with its own switch
- Charge/discharge control relay
- Load section: three switchable resistive loads with LEDs
- SPI flash memory
- RTC with CR2032 backup cell
- Serial UART interface
Software
- STM32CubeIDE with HAL drivers
- Embedded C with fixed-point maths
- Python with pandas, NumPy, SciPy, scikit-learn and matplotlib
- TensorFlow Lite for Microcontrollers (optional)
- MATLAB (optional)
Extra parts
- INA219 I2C current and power monitor in the cell path — Throughput, capacity and SOH estimation need measured current in both directions; the kit does not list current measurement.
- Spare cells of the same type (optional) — Separate cells can be cycled under different policies for a small comparison, handled under the same safety rules.
This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.
Key concepts
- State of health
- Usually remaining capacity as a fraction of rated capacity, sometimes also internal resistance growth. It changes slowly and must be estimated from operating data.
- Calendar and cycle ageing
- Cells age when stored, faster at high SOC and temperature, and when cycled, depending on throughput, depth of discharge, C-rate and voltage. Empirical models combine these factors.
- Incremental capacity analysis
- Plotting dQ/dV during slow charging shows peaks whose height and position shift as the cell ages, giving health features from routine charges.
- Constrained optimal charging
- Choosing charge actions to minimise a degradation cost while meeting a charge-time, energy or departure constraint.
Step-by-step guide
- 1
Research design
Write research questions, hypotheses and metrics. Survey ageing models and ageing-aware charging literature. Choose public datasets for offline work, such as NASA PCoE battery data and CALCE cell data, and check their licences and cell chemistries against your cell. Decide what the kit can show in the thesis timeframe: estimator accuracy and controller behaviour, not long-term lifetime gain. Set safety rules: check polarity, never short the cell, never heat it, never leave it charging unattended.
Checkpoint: A research plan with questions, datasets, metrics and an explicit statement of what will and will not be shown on hardware.
- 2
Offline degradation modelling
Fit an empirical model to dataset capacity fade with terms for throughput, depth of discharge, average SOC, temperature and time. Train a data-driven SOH estimator on features such as charge time between two voltages, CV-phase duration and incremental-capacity peak features. Use cell-wise splits so test cells are unseen. Report errors with confidence intervals. Note which dataset conditions differ from the kit cell's use, such as temperature and C-rate.
Checkpoint: Model and estimator errors on held-out cells are tabulated against simple baselines such as linear capacity fade.
- 3
Board setup and logging
Enable the DIP switches for the battery, charger, relay, loads, SPI flash, RTC and UART. Configure the BMS controller at 72 MHz with ADC and DMA for voltage and T-sense, I2C for the INA219 and RTC, SPI for flash and relay and load GPIOs. Calibrate voltage and current against a multimeter. Log every sample with RTC time to flash, with a page header and CRC.
Checkpoint: A full charge and discharge is logged with zero lost pages and calibrated values.
- 4
Cell characterisation
Run reference performance tests: a slow capacity test using a fixed load, a pulse test for resistance and a slow charge for incremental-capacity features. Repeat at set intervals during the project so that any change can be tracked. Compare the kit cell's features with the datasets and note differences in chemistry and format. Use identical procedures each time so that drift reflects the cell, not the test.
Checkpoint: Baseline capacity, resistance and IC features are recorded for the cell.
- 5
Embedded SOH estimator
Port the feature extraction and the chosen estimator to the STM32 in fixed point. Compute features incrementally during each charge to avoid storing the whole curve in 20 KB of RAM. Verify bit-level agreement with Python by replaying dataset charges over UART. Measure flash, RAM and execution time of the estimator, and compare a few quantisation choices so the thesis can show how much accuracy each costs. Make the estimator report a confidence measure alongside the SOH value.
Checkpoint: Replayed dataset charges give on-target SOH within a stated tolerance of the Python estimate.
- 6
Ageing-aware policy
Formulate the charging decision with the levers the kit offers: termination voltage, rest before charge, charge window timing and depth of discharge allowed in use. Minimise modelled degradation subject to a departure or minimum energy constraint, solving a small lookup or grid search on target or a precomputed policy table from the PC. Make the policy depend on estimated SOH. Note that charge current control would need a programmable charger add-on.
Checkpoint: The policy table is generated and loaded, and the controller picks different actions for different SOH and departure inputs.
- 7
Controller integration
Combine the estimator, the policy and the existing protection on the BMS unit. Protection always overrides the policy. Display SOH, chosen termination voltage and expected charge time on the OLED and log each decision with its inputs. Add a manual override and a log flag for runs where protection acted, so that the analysis can separate policy decisions from protection events. Test the integrated firmware with injected faults before starting long campaigns.
Checkpoint: A charge run shows the controller applying the chosen termination and logging the decision trace.
- 8
Simulation study
Simulate months of use in Python with the degradation model, comparing the fixed baseline, a simple heuristic such as always 4.1 V, and the ageing-aware policy. Report modelled capacity fade, energy delivered and charge time. Include sensitivity to model error by perturbing model parameters. Run many simulated vehicles with different usage patterns, and report the distribution of outcomes, not only the average, so the benefit or cost for heavy and light users is clear.
Checkpoint: Simulation plots show the trade-off curves and their sensitivity to model error.
- 9
Hardware validation
On hardware, run repeated cycles under the policy and the baseline, alternating or on separate cells if available. Track feature drift and estimator output, and compare measured capacity at reference tests. Be explicit that short campaigns cannot confirm lifetime differences; use them to validate estimator and controller behaviour. Keep a log of every cycle and its conditions, and stop the campaign if the cell shows unusual heating, swelling or voltage behaviour.
Checkpoint: A validation table with estimator accuracy against reference tests and controller decisions over the campaign.
- 10
Analysis and publication
Present the dataset results, the embedded implementation cost (flash, RAM, CPU), the simulated trade-off and the hardware validation. Discuss limits: chemistry mismatch, short hardware campaign and the levers available. Prepare reproducible scripts and parameter files. State the main claims precisely, linking each to the evidence that supports it, and identify the experiments that would be needed to test the policy's lifetime benefit on real cells over a long campaign.
Checkpoint: A draft paper or chapter with reproducible figures and a clear limitations section.
Testing & validation
- Cell-wise held-out SOH estimation error on public datasets
- On-target versus Python estimator agreement on replayed data
- Simulated capacity fade and charge time for baseline, heuristic and ageing-aware policies
- Hardware reference tests tracking capacity and resistance during the campaign
- Protection overriding the policy in every injected limit case
Expected results
Degradation models and an SOH estimator trained on public data, a fixed-point estimator and ageing-aware policy running on the Smart BMS unit, simulated lifetime trade-offs and hardware validation of the estimator and controller.
Research angle for your PhD
Research questions: how much does feedback from an online SOH estimate improve degradation-aware charging over fixed rules, and how much accuracy is lost when the estimator is quantised for a Cortex-M3? Metrics: SOH error on held-out cells, modelled capacity fade per unit energy delivered, charge-time penalty, sensitivity to model error and embedded cost. Baselines: fixed CC–CV, fixed reduced termination voltage. Datasets: NASA PCoE and CALCE for training and testing. A publishable contribution pairs a rigorous offline evaluation with a working embedded implementation and a frank account of what short hardware tests can and cannot show.
Take it further
- Add a programmable-current charger add-on to include C-rate in the policy
- Use online model updating such as recursive least squares on the degradation parameters
- Compare reinforcement-learning policies trained in simulation
- Report SOH over CAN for fleet-level analytics
Viva and review questions
Why train offline on public datasets?
Ageing takes hundreds of cycles to show; public datasets give that history across many cells, while the kit validates the embedded estimator and controller.
Why does protection override the policy?
The policy is an optimisation layer; limits for voltage, temperature and time must hold whatever the policy or model says.
How do you keep feature extraction within 20 KB RAM?
Features are computed incrementally as samples arrive, such as timing between voltage thresholds and binned dQ/dV, so the whole curve is never stored.
Can you claim the policy extends battery life?
Only in simulation with the stated model. Hardware runs validate behaviour and estimation; a lifetime claim would need long, controlled cycling of many cells.