The problem
Fleet operators want a virtual copy of each battery that predicts its behaviour and ageing, but twins are usually built from lab-grade data. In a real vehicle the twin is fed by limited, quantised, delayed and sometimes missing embedded telemetry. How much model fidelity survives those constraints is not well understood.
Objectives
- Design the embedded telemetry: signals, rates, quantisation, timestamps and transport over UART and CAN.
- Build a PC-side twin combining a second-order Thevenin model and a lumped thermal model.
- Adapt twin parameters online with recursive least squares or a Kalman filter.
- Quantify how sampling rate, quantisation, latency and packet loss affect prediction error.
- Validate on kit data and on public datasets such as NASA PCoE and CALCE.
What you need
From the EV Embedded Development Kit
- Smart BMS unit STM32F103C8T6
- 1S battery with connector and T-sense input
- Load section: three switchable resistive loads with LEDs
- Battery charging unit with its own switch
- Charge/discharge control relay
- CAN bus interface with screw terminal
- Serial UART interface
- I2C and SPI buses to the onboard devices
- RTC with CR2032 backup cell
Software
- STM32CubeIDE with HAL drivers
- Embedded C
- Python 3 with NumPy, SciPy, pandas, python-can and matplotlib
- MATLAB/Simulink (optional) for model comparison
Extra parts
- INA219 I2C current and power monitor module — The kit does not list current measurement; the twin needs measured current as its input. It is wired in series with the battery or load path through the I2C bus.
- USB-CAN adapter — The board has one CAN node; the adapter lets the PC twin receive telemetry over CAN as a vehicle-side consumer would.
- Digital multimeter (lab equipment) — To calibrate voltage and current readings.
This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.
Key concepts
- Digital twin
- A model that runs alongside a physical asset, is continuously updated from its measurements and is used to estimate hidden states or predict future behaviour.
- Second-order Thevenin model
- An open-circuit voltage source in series with an ohmic resistance and two RC pairs, which captures fast and slow polarisation of a Li-ion cell.
- Recursive least squares (RLS)
- An online estimator that updates model parameters with each new sample; a forgetting factor lets it track slowly changing parameters such as resistance growth.
- Telemetry degradation
- Quantisation, limited sample rate, transport delay and lost packets all reduce the information reaching the twin; each can be emulated and its effect measured.
- Prediction horizon
- How far ahead the twin forecasts, for example terminal voltage 60 s ahead under a known load step.
Step-by-step guide
- 1
Define research questions and the twin's purpose
Decide what the twin must do: track terminal voltage, estimate SOC and internal resistance, and forecast voltage and temperature under planned loads. Write the research questions, for example how prediction error grows as telemetry rate falls from 10 Hz to 0.1 Hz, or with 8-bit versus 16-bit quantisation. Set safety rules for the cell: polarity, never short, supervised charging, protection limits enforced by the BMS firmware.
Checkpoint: A research plan with questions, metrics, baselines, safety rules and a list of experiments.
- 2
Integrate current measurement
Wire the INA219 in the current path as the kit's connectors allow, with the cell disconnected while wiring. Configure its calibration register for the shunt value and expected current range, and read bus voltage and current over I2C with HAL_I2C_Mem_Read. Calibrate against a multimeter at several loads. Document the sign convention for charge and discharge. Measure the INA219 noise floor with no load to know the smallest current it resolves reliably.
Checkpoint: Measured current matches the multimeter within a stated tolerance for each load combination.
- 3
Design the telemetry firmware
On the Smart BMS unit, sample voltage, current and temperature with a timer-paced loop at 100 Hz, filter and downsample to the configured telemetry rate, quantise to the configured resolution, and timestamp with a millisecond tick aligned to the RTC. Send frames over UART (rich, full rate) and over CAN as packed 8-byte frames at lower rate. Include sequence numbers to measure loss.
Checkpoint: Both streams arrive on the PC with correct scaling and continuous sequence numbers.
- 4
Run characterisation tests
Use the switchable loads and the relay to run pulse tests (load on and off at several SOC levels with rests), constant-load discharges and supervised charges. Keep the BMS protection active. Record high-rate data over UART as the reference dataset for model identification. Repeat key tests to measure repeatability, and record ambient temperature for every test. Keep protection limits conservative and stop any test if the cell warms unexpectedly. Document the test schedule so it can be repeated later to look for parameter drift.
Checkpoint: A reference dataset covering the SOC range with pulse responses, stored with a description of each test.
- 5
Identify the offline model
From rest periods build the OCV–SOC curve. Fit R0 from the instantaneous voltage step at load changes and the two RC pairs from the relaxation curves with nonlinear least squares in SciPy. Fit a lumped thermal model (heat from I²R, heat loss to ambient) to the temperature trace. Report parameters with confidence intervals. Check whether parameters depend on SOC and, if so, store them as lookup tables.
Checkpoint: The fitted model reproduces a held-out pulse test with voltage RMSE recorded in mV.
- 6
Build the online twin
Write a PC service that receives telemetry from UART or CAN, runs the model in step with the data, estimates SOC with an extended Kalman filter, and updates R0 and the RC parameters with RLS using a forgetting factor. Handle missing packets by propagating the model forward without correction. Log twin states and residuals. Track parameter estimates over time and check they converge and stay physically plausible.
Checkpoint: The twin tracks a live discharge with bounded voltage residuals and plausible SOC.
- 7
Add prediction
Given a planned load profile, propagate the twin forward 30, 60 and 300 s and compare the forecast voltage and temperature with what the cell actually does. Use this to predict time to the cut-off voltage under each load. Report forecast error as RMSE and maximum error for voltage and temperature at each horizon, and the error in predicted time to cut-off. Compare forecasts made with adapted parameters and with fixed offline parameters to show what online adaptation adds.
Checkpoint: Forecast error at each horizon recorded for several load profiles.
- 8
Degrade telemetry systematically
Use the firmware's settings (and replay of the high-rate reference data) to vary sample rate, quantisation step, transport delay and random packet loss. For each setting run the twin and measure tracking and forecast error. Compare UART and CAN transport. Change one factor at a time first, then combine factors in a small factorial design to see interactions. Use replay so every setting uses exactly the same underlying data, and keep the random seeds for packet loss in the results.
Checkpoint: Error-versus-degradation curves for each factor, with repeated runs to show variance.
- 9
Validate on public datasets
Apply the same twin and degradation study to public data such as NASA PCoE or CALCE cell tests, which cover wider current ranges and ageing. Check that trends seen on the 1S kit cell hold on those cells, and note where they do not. Apply the same degradation settings to the public data so results are directly comparable, and describe any preprocessing such as resampling.
Checkpoint: A comparison table of twin error on kit data and on at least one public dataset.
- 10
Compare against baselines
Compare the adaptive twin with a fixed-parameter model and with a simple OCV-plus-R model. Report RMSE, maximum error, forecast error and computational cost per update. Use the same telemetry settings for every method so the comparison is fair, and include a data-driven baseline such as a small regression model trained on the reference dataset. Report computation per update in microseconds on the PC, and estimate what it would cost on the STM32 if moved to the edge.
Checkpoint: A baseline comparison table with all methods tested on identical data.
- 11
Write up for publication
Document the testbed, telemetry design, models, degradation study, results and limitations (single small cell, laboratory temperature, low current range). Release code and kit datasets where possible. Structure the paper around the research questions, with a clear description of the testbed, the degradation method and the statistics used. Discuss how the findings could guide telemetry design in real vehicles and what further tests, such as multi-cell packs or temperature chambers, would be needed to confirm them.
Checkpoint: A paper-style draft with figures reproducible from the released scripts.
Testing & validation
- Current calibration verified against a multimeter at each load level.
- Model RMSE reported on held-out tests, not on training data.
- Degradation curves repeated with several random seeds for packet loss.
- Results checked on at least one public dataset.
Expected results
An embedded-fed battery digital twin with online parameter adaptation and quantified sensitivity of tracking and forecast accuracy to telemetry rate, resolution, delay and loss.
Research angle for your PhD
Research questions: what minimum telemetry rate and resolution keep a battery twin within a given error bound, and how should embedded telemetry be designed (event-driven versus periodic, which signals at which rate) for twin fidelity? Metrics: voltage RMSE, SOC error, forecast error at several horizons, parameter convergence time, bytes per hour. Baselines: fixed-parameter models and full-rate telemetry. Datasets: kit-generated data plus NASA PCoE and CALCE. A publishable contribution would give a quantified telemetry-design guideline validated on both the testbed and public data.
Take it further
- Move SOC estimation onto the STM32 in fixed-point and send only states and residuals.
- Add ageing models trained on public datasets to forecast capacity fade.
- Use residual monitoring for fault detection.
Viva and review questions
Why add an INA219?
The kit does not list current sensing, and the twin's model is driven by current, so a measured input was needed.
Why a forgetting factor in RLS?
It gives more weight to recent data so the parameters can track slow changes such as temperature effects or ageing.
How do you handle lost packets?
The model propagates forward on the last known input without measurement correction, and the uncertainty is allowed to grow until data returns.
Why validate on public datasets?
The kit cell covers a narrow range; public datasets test whether the findings hold for wider currents and ageing.