The problem
Testing a BMS on real cells is slow, hard to repeat and unsafe for fault scenarios such as over-charge or internal short. Hardware-in-the-loop (HIL) testing replaces the cells with a real-time model whose outputs drive the BMS's measurement inputs, so faults and ageing can be emulated repeatably. The research challenge is fidelity: how accurately the emulator reproduces cell behaviour in real time, and whether BMS results on the emulator predict results on real cells.
Objectives
- Build a real-time-capable pack model with Simscape Battery and validate it against public data.
- Deploy it to a real-time target and meet a fixed step deadline.
- Interface emulated cell voltages, current and temperature to a BMS under test.
- Run a test campaign for SOC estimation and protection, including fault injection.
- Quantify emulator fidelity and the effect of I/O errors on BMS results.
What you need
Tools and toolboxes
- Simulink Real-Time — Building and running the model on a real-time target computer, I/O drivers, real-time execution profiling and the test instrument interface.
- Simscape Battery — Cell and pack models with equivalent-circuit parameters, thermal effects and fault parameters.
- Simscape — Fixed-step local solver configuration for real-time execution.
- Simulink Test — Automating the HIL test campaign and reporting results.
- Simulink Desktop Real-Time (optional) — A lower-cost, soft real-time option for early model and interface checks on a desktop computer.
Software
- MATLAB R2023b or later
- Simulink
- Simulink Real-Time
- Simscape Battery
- Simulink Test
- BMS firmware toolchain for the board under test
Extra parts and data
- Real-time target computer with analogue output, analogue input and CAN I/O modules — Simulink Real-Time runs on dedicated real-time target hardware; analogue outputs emulate cell voltages, analogue inputs read BMS balancing or control signals, and CAN carries BMS messages.
- Cell-voltage emulation stage (precision isolated voltage sources or a signal-conditioning board) — Target analogue outputs are usually ground-referenced, while BMS cell inputs are stacked; an isolated emulation stage is needed to present each emulated cell voltage safely.
- BMS board under test — The device being validated, for example a student-built BMS or a development board with a cell-monitoring chip.
- Public battery cycling dataset (for example NASA PCoE or CALCE) — Model parameterisation and fidelity validation against measured cell behaviour.
Key concepts
- Real-time execution
- The model must compute each step within its fixed step time, every time. A missed deadline (overrun) breaks the emulation, so model complexity is limited by worst-case execution time.
- Fixed-step Simscape solving
- Physical models run in real time using a fixed-step local solver such as backward Euler or trapezoidal, with a fixed number of iterations so execution time is bounded.
- Emulator fidelity
- How closely emulated terminal voltage, including I/O errors and delays, matches the real cell under the same current. Low fidelity can make a BMS look better or worse than it is.
- Fault injection
- Changing model parameters or I/O at run time to emulate faults such as a high-resistance cell, sensor drift or open wire, which would be unsafe or destructive with real cells.
Step-by-step guide
- 1
Define the test objectives
Decide what the emulator must validate: for example SOC estimation accuracy within a stated error, over- and under-voltage protection timing, and open-wire detection of an example 4-cell or 16-cell BMS. From these, derive emulator requirements: step time (for example 1 ms), voltage resolution and accuracy at the BMS input (a few millivolts), current-measurement interface and temperature emulation. Include an error budget that splits the allowed error between model, solver and I/O.
Checkpoint: A table of BMS test objectives and the emulator requirements derived from them.
- 2
Parameterise and validate the cell model
Build a cell model in Simscape Battery with a 1RC or 2RC equivalent circuit, OCV against SOC and temperature-dependent parameters, fitted to a public dataset. Validate it offline on held-out profiles from the same dataset, reporting voltage RMS error. This offline accuracy is the upper limit on emulator fidelity. Also check the model across temperatures in the dataset, since BMS tests will include temperature changes. Record the fitted parameters and their uncertainty in a versioned file.
Checkpoint: Offline voltage RMS error on held-out data within a stated bound, for example 15 to 20 mV.
- 3
Build the pack model
Use Simscape Battery's pack-building workflow to create a series pack with cell-to-cell parameter variation (capacity and resistance spread) and a lumped thermal model. Keep cell count and model order within what can run in real time. Expose fault parameters, such as one cell's resistance and capacity, as tunable parameters for run-time changes. Choose parameter spreads from the dataset or literature rather than arbitrary values, and record them, since balancing results depend on them.
Checkpoint: The pack model simulates on the desktop with visible spread in cell voltages under load.
- 4
Make it real-time capable
Switch to a fixed-step solver with the Simscape local solver (backward Euler) and a fixed number of nonlinear iterations. Compare fixed-step results with the variable-step reference and reduce step size or model complexity until the error is acceptable. Estimate execution time on the desktop with profiling to anticipate the target load. Record the chosen step size, solver and iteration count with their justification, since they directly affect both accuracy and the margin to overruns on the target.
Checkpoint: Fixed-step results within a small fraction of a millivolt of the variable-step reference, with a desktop execution estimate.
- 5
Deploy to the real-time target
Add I/O driver blocks for analogue outputs (cell voltages), analogue input or CAN (BMS outputs, such as balancing commands) and a current signal to the BMS current input. Build and deploy with Simulink Real-Time. Monitor task execution time and overruns. Use Simulink Desktop Real-Time first if the target is shared, to debug interfaces at a soft real-time level. Keep the I/O blocks in a separate subsystem from the plant model.
Checkpoint: The model runs on the target for an hour with zero overruns and a recorded maximum task execution time.
- 6
Calibrate the I/O chain
Measure the voltage at each BMS cell input with a calibrated meter for a set of commanded values and fit gain and offset corrections. Measure the delay from model output to BMS input. Apply corrections in the model. Record residual error, which adds to the model error at the BMS input. Repeat the calibration at the start of each test day to detect drift, and log it with the campaign data.
Checkpoint: Residual I/O error per channel within the requirement, for example below 2 mV, and a measured delay.
- 7
Close the loop with the BMS
Connect the BMS through the emulation stage. Feed the pack current profile (for example from an EV model on IDC) into the emulator and drive the BMS current input with the matching signal. Read BMS SOC estimates and fault flags over CAN. Check that balancing commands from the BMS change emulated cell behaviour. Keep all voltages at the low levels of the emulation stage; no real high-voltage pack is used.
Checkpoint: BMS reports cell voltages matching the emulated values within the I/O error, and its SOC estimate follows the emulated SOC.
- 8
Run the test campaign
Automate scenarios with Simulink Test: drive cycles from different initial SOCs, temperature changes, a weak cell, sensor offset, open-wire and over-charge. Record BMS SOC error against emulated true SOC, protection response times and detection outcomes. Repeat each scenario to measure repeatability, which is a key advantage of HIL over real cells. Store each run's data with the scenario settings and model version, so results can be traced and rerun exactly.
Checkpoint: A campaign report with results for every scenario and repeatability across runs.
- 9
Quantify fidelity
If possible, run a subset of safe scenarios with real cells and the same BMS, and compare BMS results on cells with results on the emulator. Otherwise, inject known model and I/O errors (voltage offset, delay, model parameter error) and measure how BMS SOC error and protection timing change. This shows which emulator errors matter for which tests. State clearly which comparison was used.
Checkpoint: A sensitivity table of BMS metrics against emulator error sources, or a cell-versus-emulator comparison.
- 10
Assess real-time margins
Increase model fidelity step by step (more RC branches, more cells, finer thermal model) and record execution time until overruns appear. Plot fidelity against execution time to show what the target can support. Use this to recommend model order for each test objective. Keep a safety margin, for example using no more than 70 per cent of the step time, to allow for I/O jitter and occasional longer steps, and record the margin chosen.
Checkpoint: A fidelity-versus-execution-time plot with the overrun limit marked.
- 11
Write up
Present objectives, model and its validation, real-time deployment, I/O calibration, closed-loop setup, test campaign, fidelity analysis and real-time limits. State the limitations: equivalent-circuit model, emulated rather than real electrochemical faults, and dependence on one dataset. Note that the emulation stage must be designed for isolation and the BMS's input range; real high-voltage packs are out of scope. Release models and scripts.
Checkpoint: A thesis chapter with campaign results and an error budget for the emulator.
Testing & validation
- Offline cell model validated on held-out public data.
- Fixed-step model matches variable-step reference.
- Zero overruns over a long real-time run, with maximum execution time recorded.
- Per-channel I/O calibration and residual error within requirement.
- Repeatability of BMS results across repeated scenarios.
- Sensitivity of BMS metrics to emulator error sources.
Expected results
A real-time battery emulator on Simulink Real-Time with a validated Simscape Battery pack model, calibrated I/O to a BMS under test, an automated HIL test campaign for SOC estimation and protection, and an error budget showing how emulator fidelity affects BMS validation results.
Research angle for your PhD
Research questions: how accurately must a battery emulator reproduce cell behaviour for BMS validation results to transfer to real cells, and which error sources (model order, I/O offset, delay) dominate? Metrics: emulated voltage error at the BMS input, BMS SOC error and protection timing on emulator versus cells, repeatability, and real-time margin. Baselines: offline simulation and real-cell testing for safe scenarios. A quantified emulator error budget, linked to its effect on BMS test outcomes, is a useful and publishable contribution, especially with released models and test scripts.
Take it further
- Add a reduced electrochemical model and compare real-time cost and fidelity.
- Emulate ageing over a campaign by updating capacity and resistance.
- Add a motor and inverter load emulator for a full powertrain HIL.
- Validate a production-style SOC estimator across temperatures.
Viva and review questions
Why use a fixed-step solver with fixed iterations?
Real-time execution needs a bounded computation time every step; variable steps or unbounded iterations could exceed the step deadline and cause overruns.
Why is an isolation stage needed between the target and the BMS?
BMS cell inputs are stacked in series, each referenced to the cell below, while target analogue outputs share one ground, so each emulated cell voltage must be presented by an isolated source.
What can HIL test that real cells cannot?
Repeatable fault scenarios such as over-charge, a weak cell or an open wire, which would be unsafe or destructive on real cells, and exactly repeatable initial conditions.
How do you know the emulator is good enough?
By building an error budget from model, solver and I/O errors and showing how each affects the BMS metrics, ideally confirmed by comparing with real cells on safe scenarios.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.