Thermomanagement bei E-Autos testen

Thermomanagement-Software in Elektrofahrzeugen steuert das Heizen und Kühlen von Batterie, Innenraum und weiteren Komponenten so, dass Energie effizient genutzt wird und die Reichweite erhalten bleibt. Getestet wird dabei nicht im Fahrzeug, sondern zunehmend am Hardware-in-the-Loop-System und an einer virtuellen Steuergeräteumgebung, die nur die Thermomanagement-Komponenten isoliert abbildet und damit frühere Fehlerfunde ermöglicht.

Das Wichtigste in Kürze

• Thermomanagement-Software in Elektrofahrzeugen regelt bis zu 200 verschiedene Systemverschaltungen, weil Batterie, Innenraum und verfügbare Leistung gleichzeitig berücksichtigt werden müssen.
• Der Shift vom Fahrzeugtest zum Hardware-in-the-Loop-System senkt Kosten direkt, weil Extremtemperaturen wie minus 20 Grad im Labor simuliert werden, statt das Team nach Skandinavien zu schicken.
• Eine virtuelle Steuergeräteumgebung erlaubt es, ausschließlich die Thermomanagement-Komponenten ohne Basissoftware-Quereinflüsse zu testen, was Fehler noch früher im Release-Zyklus sichtbar macht.
• Automatisierte Testläufe für Thermomanagement-Funktionen dauern zwei bis drei Tage, weil Temperaturregelung und Timer-basierte Vorkonditionierungsabläufe physikalisch träge sind und nicht beliebig beschleunigt werden können.
• Bevor ein Large-Language-Modell Testspezifikationen erzeugen kann, müssen die Eingangsanforderungen in einer strukturierten, maschinenlesbaren Form vorliegen, was den eigentlichen Aufwand darstellt.

Was Thermomanagement in Elektrofahrzeugen leisten muss

Das Thermomanagement regelt alles, was in einem Elektroauto geheizt und gekühlt wird. Die Software dafür liegt auf einem eigenen Steuergerät, das die Temperaturen von Batterie und Innenraum steuert und dabei mit anderen Steuergeräten kommuniziert.

Der Anspruch ist nicht nur, dass es nicht zu warm und nicht zu kalt wird. Das System soll möglichst energieeffizient arbeiten. Das Kühlen eines Batteriesystems oder das Heizen des Innenraums braucht viel Energie, und jede verschwendete Kilowattstunde geht zu Lasten der Reichweite.

Die Komplexität entsteht durch die Kombinatorik. Geschwindigkeit, Außentemperatur, der Kühlbedarf der Batterie, der Wärmebedarf des Innenraums und die verfügbare Leistung greifen ineinander. In Summe ergeben sich rund 200 verschiedene Verschaltungen, in denen das System betrieben werden kann.

Warum Tests am Fahrzeug allein nicht reichen

Tests am realen Fahrzeug sind teuer und langsam. Wer minus 20 Grad prüfen will, während es draußen 20 Grad hat, muss mit dem Auto und einem Tester an einen kalten Ort fahren. Wer die Kühlung bei Hitze prüfen will, fährt nach Afrika.

Genau hier setzt der Shift-Left-Ansatz an: möglichst früh testen, bevor das Fahrzeug überhaupt auf die Straße muss. Der Grundgedanke ist einfach. Je früher ein Fehler gefunden wird, desto günstiger lässt er sich beheben.

Bestimmte Eigenschaften lassen sich trotzdem nur am Fahrzeug beurteilen. Wie sich eine Klimaanlage anfühlt, ob Ventile thermodynamisch korrekt verschalten, ob die Buskommunikation zwischen den Steuergeräten sauber läuft: Solche Dinge gehören ans echte Auto. Die Frühphase entlastet diese Fahrzeugtests, sie ersetzt sie nicht.

Wie ein Hardware-in-the-Loop-System das Fahrzeug simuliert

Ein Hardware-in-the-Loop-System (HiL) simuliert das Fahrzeug, während das echte Steuergerät angeschlossen ist. Physisch ist das ein etwa zwei Meter hoher und drei Meter breiter Schrank voller Technik.

Das Steuergerät selbst ist ein kleiner Kasten mit der gesamten Intelligenz. Im HiL wird ein Teil der Sensorik und Aktorik real verbaut, etwa Widerstandswerte für die Temperatursensoren, ein Großteil wird simuliert. Das System läuft echtzeitfähig, sodass sich das Steuergerät verhält, als wäre es im Auto.

Damit lassen sich Szenarien einstellen, die am Fahrzeug aufwendig wären. 40 Grad Außentemperatur, eine Bergauffahrt: Das System beginnt zu regeln und zu kühlen. Steht später die Fahrzeugerprobung an, ist die grundsätzliche Funktion abgesichert, und vor Ort bleibt nur die Feinjustierung.

Die virtuelle ECU als nächster Shift-Left-Schritt

Die virtuelle ECU verschiebt den Test noch weiter nach vorne, weil sie ganz ohne Hardware auskommt. Statt des gesamten Steuergeräts wird nur die Thermomanagement-Software abstrahiert und virtuell betrieben.

Der Vorteil liegt in der Isolation. Auf einem echten Steuergerät liegen Basissoftware und andere Funktionen, die Quereinflüsse erzeugen. Die virtuelle ECU testet ausschließlich die Thermomanagement-Komponenten und blendet diese Störungen aus.

Hinzu kommt der Zeitvorteil. Die Basissoftware trifft erst Wochen später ein, doch bei kurzen Release-Zyklen lässt sich die Funktionalität schon vorher prüfen. Fehler werden früher sichtbar, und der HiL wird frei für anderes, etwa explorativeres Testen.

Die Manipulation der Signale geschieht hier an einer anderen Stelle. Statt Bussignale zu verändern, greifen die Tests an der äußersten Schnittstelle der virtuellen ECU an, dem Real-Time Environment (RTE). Dort wird beispielsweise die Batterietemperatur gesetzt, und über dieselbe Schnittstelle gibt das Steuergerät seine Ansteuerung für Ventile oder Lüfter zurück.

Ein Testfall, zwei Umgebungen

Dieselbe Testlogik soll auf HiL und virtueller ECU laufen. Auf oberster Ebene bleibt der Testfall gleich, nur die Anbindung ändert sich.

Am Beispiel Batteriekühlen heißt das: Der Testfall lässt sich am HiL verwenden und ebenso an der virtuellen ECU. Für die VECU passt man das Mapping an und initialisiert andere Tools, doch der eigentliche Testfall bleibt derselbe. So entsteht kein doppelter Pflegeaufwand für zwei getrennte Testsuiten.

Der Großteil der Tests ist automatisiert. Reine Testlaufzeiten von zwei bis drei Tagen sind keine Seltenheit, weil manche Funktionen schlicht Zeit brauchen.

Warum Temperatur das Testdesign verlangsamt

Temperatur ist ein träges Phänomen, und diese Trägheit steckt in jedem Testfall. Ein Sprung von 0 auf 30 Grad existiert in der Realität nicht, es gibt nur Anstiege und Abfälle über Zeit.

Die Software berücksichtigt das mit Filterfunktionen. Fährt ein Auto im Sommer aus der Garage, steigt die Außentemperatur schlagartig um 10 bis 15 Grad. Auf der Autobahn gibt es Luftlöcher, in denen es kurz 5 Grad kälter ist. Reagierte die Regelung sofort auf jeden Sprung, würde sie sinnlos zwischen Heizen und Kühlen wechseln.

Im Vergleich zu einem Airbag-Steuergerät, das auf Millisekunden reagieren muss, ist das Thermomanagement deutlich träger. Das prägt auch die Testfälle.

Ein gutes Beispiel ist die Vorkonditionierung. Der Fahrer stellt am Handy ein, dass er um sieben Uhr ein temperiertes Auto will. Das Auto registriert den Termin, alle Steuergeräte schlafen ein, fahren später wieder hoch, prüfen Außentemperatur und Ladezustand der Batterie und berechnen, wann sie mit Heizen oder Kühlen beginnen müssen, um pünktlich 21 Grad im Innenraum zu erreichen. Im Test werden die Timer heruntersimuliert, damit niemand fünf Stunden auf die Abfahrt warten muss. Manche Abläufe wie das Einschlafen der Steuergeräte brauchen trotzdem ihre Zeit.

Funktion testen, nicht Reglergüte

Die Tests prüfen, ob eine Funktion grundsätzlich arbeitet, nicht wie präzise der Regler abstimmt. Diese Trennung hält die Tests stabil und unabhängig von ständigen Datenstand-Änderungen.

Am Fahrzeug wird viel umbedatet, um die Regelung zu optimieren. Für die Funktionstests interessiert diese Bedatung im Detail nicht. Eigene Datensätze am HiL minimieren die Quereinflüsse aus solchen Änderungen.

Konkret heißt das: Geprüft wird, ob die Batterie gekühlt wird und das einigermaßen gut funktioniert. Ob der Regler dabei Über- und Unterschwinger zeigt, schaut man sich am Fahrzeug an, weil sich solche Feinheiten nicht leicht simulieren lassen.

Mit zunehmender Reife des Projekts sind die Testfälle stabiler geworden. Anfangs musste viel angepasst werden, heute ist die Verlinkung enger. Ändert sich eine Funktion, sieht man das nicht nur im Funktionslastenheft, sondern auch an der Systemanforderung. Daraus ergibt sich gezielt, welche Testfälle zu prüfen oder anzupassen sind. Hat eine Änderung keine Auswirkung, läuft der Testfall einfach erneut grün durch.

Wohin die Automatisierung als Nächstes geht

Drei Baustellen prägen die Weiterentwicklung der Teststrategie. Sie zielen alle darauf, früher und mit weniger Handarbeit zu testen.

• Virtuelle ECU ausbauen. Der Aufbau steht am Anfang, erste Tests laufen bereits. Weitere Testfälle sollen vom HiL auf die VECU wandern.
• Continuous Integration. Heute muss man die Software noch manuell aufs Steuergerät flashen, den Testlauf starten und die Ergebnisse hochladen. Künftig soll das vollautomatisiert passieren, sobald eine zu testende Software abgelegt wird.
• Testspezifikation mit LLM. Aus den Anforderungen sollen über ein Large-Language-Modell fertige Testspezifikationen entstehen, statt sie manuell zu schreiben.

Beim LLM-Ansatz liegt die eigentliche Arbeit am Eingang. Bevor ein Modell sinnvolle Testspezifikationen erzeugen kann, müssen die Anforderungen in einer geeigneten, strukturierten Form vorliegen. Erst dieser erste Schritt macht alles Weitere möglich.

In einem regulierten Umfeld kann nicht beliebiger Output akzeptiert werden. Der erzeugte Output muss prüfbar sein, und die Qualität der Eingangsanforderungen entscheidet darüber, ob die generierten Tests überhaupt taugen.