The problem
Pure data-driven battery estimators can give physically impossible outputs and generalise poorly outside training conditions, while pure models need careful parameterisation. Physics-informed learning promises better generalisation with less data, but its benefit on embedded BMS hardware is not well established.
Objectives
- Formulate a physics-informed loss combining data error with equivalent-circuit and charge-conservation residuals.
- Train on public datasets and kit data, comparing with a purely data-driven network of the same size.
- Test generalisation to unseen profiles, temperatures and reduced training data.
- Deploy a quantised model on the STM32F103 and measure its cost.
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
- BMS power switch, OLED and six navigation buttons
- Serial UART interface
Software
- STM32CubeIDE
- Embedded C with HAL drivers
- Python with TensorFlow or PyTorch, NumPy, SciPy, pandas
- NASA PCoE and CALCE datasets
- Optional: MATLAB/Simulink
Extra parts
- INA219 I2C current/power monitor module — Measured current is required for the charge-conservation residual, the network inputs and the reference SOC.
This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.
Key concepts
- Physics-informed loss
- The training loss adds penalty terms when the network's outputs break known physics, here coulomb counting between time steps and the Thevenin voltage equation.
- Charge conservation residual
- SOC(t+1) − SOC(t) should equal −I·Δt / capacity. Penalising violations makes predicted SOC trajectories consistent with measured current.
- Generalisation gap
- The difference between error on training-like conditions and on new ones, the main quantity physics-informed methods aim to reduce.
- Deployment constraint
- Physics terms only affect training, so the deployed model can be as small as an ordinary network, but must fit 64 KB flash and 20 KB RAM shared with BMS firmware.
Step-by-step guide
- 1
Frame research questions and baselines
State the hypotheses: physics-informed training reduces error on unseen profiles and temperatures and needs less data than a same-size data-driven network. Choose baselines: EKF on a Thevenin model, a data-driven network and coulomb counting. Define metrics and the data splits before training anything, and decide which public datasets you will use. Write the protocol before collecting results so the comparison cannot be adjusted afterwards to favour the proposed method, and keep it under version control.
Checkpoint: A written protocol with hypotheses, baselines, metrics and splits, agreed with your guide.
- 2
Collect kit data
Fit the INA219 with the cell disconnected, then log voltage, current, temperature and relay and load states at 10 Hz from the Smart BMS STM32 over UART. Run capacity tests, OCV steps, pulse tests and varied load profiles. Follow lithium safety throughout: check polarity, never short, respect voltage limits and supervise charging. Record ambient and cell temperature for every test, and keep a log sheet linking each file to its test conditions and purpose.
Checkpoint: A documented kit dataset with reference SOC from coulomb counting and a measured capacity.
- 3
Prepare public data
Load NASA PCoE and CALCE profiles, resample to a common rate and compute reference SOC consistently. Record each cell's chemistry, capacity and temperature. Keep entire cells or profiles out for testing. Normalise inputs with training statistics only. Check each dataset's current sign convention and units, since they differ between sources and silently break the charge-conservation term. Plot a few profiles from each source after harmonisation to confirm voltage, current and SOC look physically sensible.
Checkpoint: Harmonised training, validation and test sets with a data card describing each source.
- 4
Implement the physics-informed training
Build a network that outputs SOC and polarisation voltage. The loss combines SOC error against reference, a charge-conservation residual using measured current and capacity, and a terminal voltage residual from the Thevenin equation with OCV from a table. Treat R0, R1 and C1 as learnable or identified separately, and weight the terms, studying the weights as a hyperparameter. Log each loss term separately during training so their balance can be inspected.
Checkpoint: Training converges and physics residuals fall alongside data error on validation data.
- 5
Run the generalisation experiments
Compare physics-informed and data-driven networks of identical size on: unseen load profiles, unseen temperatures from the public data, and training sets cut to 50%, 25% and 10%. Repeat with several random seeds and report means and confidence intervals. Include the EKF baseline on the same test data. Use identical architectures, optimisers and training budgets for both networks, so the only difference is the physics terms in the loss, and record the training time of each.
Checkpoint: Tables and plots of error versus data fraction and condition, with seed variation shown.
- 6
Quantise and deploy
Quantise the chosen models to int8 and implement integer inference in C on the Smart BMS STM32, verified bit-exact against a NumPy integer reference. Measure cycles per inference with the DWT counter and flash and RAM from the map file, alongside the existing BMS functions. Check that quantisation does not break the physical consistency of outputs, for example by producing SOC values that jump between steps, and record the flash and RAM left for other BMS tasks.
Checkpoint: Both networks deployed with measured cost and verified outputs.
- 7
Validate on the kit in real time
Run the deployed models live on new kit profiles not used in training, including one from a partially charged start. Log the outputs and compare with reference SOC. Check whether quantisation removes the advantage seen in float. Follow lithium safety during every test: check polarity, never short the cell, respect its voltage limits and never leave it charging unattended. Log the live outputs together with the inputs so any surprising behaviour can be replayed and analysed on the PC afterwards.
Checkpoint: Live error for both networks on unseen kit profiles.
- 8
Analyse physical consistency
Beyond error, measure how often each model gives impossible outputs: SOC outside 0 to 100%, SOC rising during discharge, or voltage residuals beyond sensor noise. Physical consistency is often the strongest argument for this method in a BMS safety context. Count these events on public test data and on live kit runs for every model, including the EKF baseline. Discuss whether any inconsistencies coincide with conditions outside the training range, such as unusual currents or temperatures.
Checkpoint: Counts and rates of physically inconsistent outputs for each model.
- 9
Prepare the thesis contribution
Write the method, experiments and results with statistics, and discuss when physics helps and when it does not. Release code, kit data and the protocol. Identify the next research step, such as adding a thermal model or ageing. Present negative results as well as positive ones, for example conditions where the physics terms did not help or made results worse. Include an ablation table showing the effect of each loss term on its own, which reviewers usually ask for.
Checkpoint: A draft chapter and a reproducibility package.
Testing & validation
- Splits fixed before training; test data never used for tuning.
- Multiple seeds with confidence intervals for every comparison.
- Integer C inference verified against Python.
- Live validation on unseen kit profiles.
Expected results
A physics-informed SOC estimator deployed on a Cortex-M3, with quantified evidence on whether physics terms improve generalisation, data efficiency and physical consistency compared with an equally sized data-driven network and an EKF.
Research angle for your PhD
Research questions: does embedding equivalent-circuit physics and charge conservation in training improve SOC accuracy on unseen conditions and with scarce data, and does the benefit survive int8 deployment on a sub-64 KB MCU? Metrics: RMSE and maximum error, error versus data fraction, physical-consistency violations, inference cycles and memory. Baselines: same-size data-driven network, EKF, coulomb counting. Datasets: NASA PCoE, CALCE and the kit data. Publishable results would be a controlled ablation across data fractions with released code and data showing when physics helps.
Take it further
- Add a lumped thermal model residual using T-sense data.
- Learn ageing parameters jointly to estimate SOH.
- Use the physics residual on the device as a fault or sensor-health indicator.
- Compare with recurrent architectures under the same memory budget.
Viva and review questions
Does the physics add cost on the microcontroller?
No. The physics terms are only in the training loss, so the deployed network is the same size as a plain one. The cost is in training effort and tuning the loss weights.
How do you choose the weights of the loss terms?
We treated them as hyperparameters tuned on validation data and reported sensitivity, because too much physics weight can make the model follow an imperfect model instead of data.
What is the main threat to validity?
One kit cell and public datasets with different chemistries. We addressed this with cell-level splits and several seeds, and state the limits clearly.