Validating inverter software in the loop: why lookup-table models are not enough

Published September 25, 2026 · Persystems GmbH, Regensburg, Germany

Three test stages, one goal

Model-in-the-loop, software-in-the-loop and hardware-in-the-loop build on each other. In MiL the control algorithm is computed as a model against a model of the plant: does the concept work? In SiL the actual firmware – the same code that later runs on the microcontroller – runs against a model of motor, power stage and load: does the software do what the controller design promises? In HiL, finally, a real-time simulator computes the plant and the real control unit is connected to it.

SiL is the stage with the greatest leverage: it needs no hardware, runs on the development PC, can be automated and repeated – and finds bugs before test-bench time and sample hardware are tied up. The prerequisite is a plant model you can trust.

Why lookup-table models are not enough for firmware

In driving simulations and system models the electric drive is usually represented as a lookup table: torque over speed and current, efficiency as a table. That is fast and perfectly right for range or vehicle-dynamics questions. For inverter software it is the wrong tool. A current controller reacts to the current ripple of every single switching event; protection functions trip on current peaks a lookup table does not even know; saturation changes the inductance and with it the controller dynamics; at the voltage limit the modulation decides the behavior.

Testing firmware against a lookup table means testing against a fiction: the test passes, and on the test bench the current controller oscillates because the inductance at 100 A is not the one at 10 A. A plant model for SiL must therefore contain the switching events, the ripple and the saturation – it has to compute physics, not look up tables.

Physically exact and still fast

That is where the conflict used to lie: conventional simulation tools achieve accuracy through tiny time steps, and those make the SiL loop slow. A validation loop of eight hours cannot be built into everyday development, let alone run automatically after every commit.

OverDrive resolves the conflict with structure-preserving integrators from geometric mechanics: they stay stable even with large time steps and conserve energy, momentum and charge over the entire simulation. Motor, inverter and control are computed as piecewise linear models with switching events – every switching event is a kink in the curve, not an averaged-out effect. In the benchmark the results agree with LTspice, PLECS and Simulink down to the switching ripple of ±0.2 A; computing time is up to 32 times shorter. Validation of the inverter software runs twice as fast as real time – on the development PC, without a compute cluster. Eight hours become 15 minutes.

What a SiL validation with OverDrive looks like

1. Reuse your model. Motor and inverter parameters from your existing simulations are reused – no rebuild, no duplicate model maintenance.

2. Connect the firmware. OverDrive comes as an FMU according to the FMI standard and runs in Simulink, CarMaker or another co-simulation environment. The inverter firmware runs software-in-the-loop against the model of your own inverter.

3. Run maneuvers and evaluate. Load steps, run-up, recuperation, voltage dips, overtemperature, sensor failure: the test cases run as scripts, results are checked against references. Controllers are tuned on the model, protection functions are provoked deliberately.

The same model basis then carries through HiL and test bench – what is right in the model, the measurement confirms. At Persystems that is daily practice: the same models that OverDrive computes with also describe the inverters we build and measure on our own test bench.

What changes

Bugs in control and protection functions are found before hardware exists. Validation becomes reproducible and automatable. Test-bench time is used for what only the test bench can do – no longer for hunting bugs a model would have shown long ago. And when the drive is needed in the driving simulation, the same model runs as an FMU in CarMaker – physically, not as a lookup table.