Inverter-Software im Software-in-the-Loop validieren: Warum Kennfeldmodelle nicht reichen

Veröffentlicht am 25. September 2026 · Persystems GmbH, Regensburg

Drei Teststufen, ein Ziel

Model-in-the-Loop, Software-in-the-Loop und Hardware-in-the-Loop bauen aufeinander auf. Bei MiL wird der Regelalgorithmus als Modell gegen ein Modell der Strecke gerechnet: Passt das Konzept? Bei SiL läuft die tatsächliche Firmware – derselbe Code, der später auf dem Mikrocontroller arbeitet – gegen ein Modell von Motor, Leistungsstufe und Last: Tut die Software, was der Regler-Entwurf verspricht? Bei HiL schließlich rechnet ein Echtzeitsimulator die Strecke, und das reale Steuergerät hängt daran.

SiL ist die Stufe mit dem größten Hebel: Sie braucht keine Hardware, läuft auf dem Entwicklungsrechner, lässt sich automatisieren und wiederholen – und findet Fehler, bevor Prüfstandszeit und Musterhardware gebunden sind. Voraussetzung ist ein Streckenmodell, dem man trauen kann.

Warum Kennfeldmodelle für die Firmware nicht reichen

In Fahrsimulationen und Systemmodellen wird der elektrische Antrieb meist als Kennfeld abgebildet: Drehmoment über Drehzahl und Strom, Wirkungsgrad als Tabelle. Das ist schnell und für Reichweiten- oder Fahrdynamikfragen völlig richtig. Für die Inverter-Software ist es das falsche Werkzeug. Eine Stromregelung reagiert auf den Stromrippel jedes einzelnen Schaltvorgangs; Schutzfunktionen lösen an Stromspitzen aus, die ein Kennfeld gar nicht kennt; Sättigung verändert die Induktivität und damit die Reglerdynamik; an der Spannungsgrenze entscheidet die Modulation über das Verhalten.

Wer Firmware gegen ein Kennfeld testet, testet gegen eine Fiktion: Der Test läuft grün, und am Prüfstand schwingt der Stromregler, weil die Induktivität bei 100 A eine andere ist als bei 10 A. Ein Streckenmodell für SiL muss deshalb die Schaltvorgänge, den Rippel und die Sättigung enthalten – es muss Physik rechnen, nicht Tabellen nachschlagen.

Physikalisch exakt und trotzdem schnell

Genau hier lag bisher der Zielkonflikt: Herkömmliche Simulationswerkzeuge erreichen Genauigkeit durch winzige Zeitschritte, und die machen die SiL-Schleife langsam. Eine Validierungsschleife von acht Stunden lässt sich nicht in den Entwicklungsalltag einbauen, geschweige denn automatisiert nach jedem Commit ausführen.

OverDrive löst den Konflikt mit strukturerhaltenden Integratoren aus der geometrischen Mechanik: Sie bleiben auch bei großen Zeitschritten stabil und erhalten Energie, Impuls und Ladung über die gesamte Simulation. Motor, Inverter und Regelung werden als stückweise lineare Modelle mit Schaltereignissen gerechnet – jeder Schaltvorgang ist ein Knick in der Kurve, kein weggemittelter Effekt. Im Benchmark stimmen die Ergebnisse mit LTspice, PLECS und Simulink überein, bis in den Schaltrippel von ±0,2 A; die Rechenzeit ist bis zu 32-mal kürzer. Die Validierung der Inverter-Software läuft doppelt so schnell wie Echtzeit – auf dem Entwicklungsrechner, ohne Rechencluster. Aus acht Stunden werden 15 Minuten.

So sieht eine SiL-Validierung mit OverDrive aus

1. Modell übernehmen. Motor- und Inverterparameter aus den bisherigen Simulationen werden weiterverwendet – kein Neuaufbau, keine doppelte Modellpflege.

2. Firmware anschließen. OverDrive kommt als FMU nach FMI-Standard und läuft in Simulink, CarMaker oder einer anderen Co-Simulationsumgebung. Die Inverter-Firmware rechnet Software-in-the-Loop gegen das Modell des eigenen Inverters.

3. Manöver fahren und bewerten. Lastsprünge, Hochlauf, Rekuperation, Spannungseinbrüche, Übertemperatur, Sensorausfall: Die Testfälle laufen als Skript, die Ergebnisse werden gegen Referenzen geprüft. Regler werden am Modell abgestimmt, Schutzfunktionen gezielt provoziert.

Dieselbe Modellbasis trägt anschließend durch HiL und Prüfstand – was im Modell stimmt, bestätigt die Messung. Bei Persystems ist das Alltag: Dieselben Modelle, mit denen OverDrive rechnet, beschreiben die Inverter, die wir bauen und am eigenen Prüfstand vermessen.

Was sich damit ändert

Fehler in der Regelung und in den Schutzfunktionen werden gefunden, bevor Hardware existiert. Die Validierung wird reproduzierbar und automatisierbar. Prüfstandszeit wird für das genutzt, was nur der Prüfstand kann – und nicht mehr für die Suche nach Fehlern, die ein Modell längst gezeigt hätte. Und wenn der Antrieb in der Fahrsimulation gebraucht wird, läuft dasselbe Modell als FMU in CarMaker – physikalisch, nicht als Kennfeld.