Aufbau einer Tests für HIL in Elektrifizierungsteams

Wichtigste Erkenntnisse

• Tests nur dann zuverlässig, wenn die Prüfstandseinrichtung und die Eingaben wiederholbar und versioniert sind.
• Die Testautomatisierung funktioniert, wenn jeder Test den Ausgangszustand, den Stimulus und eine numerische Regel für das Bestehen oder Nichtbestehen kontrolliert.
• CI-Gates bleiben schnell, wenn knappe Bench-Zeit für kleine stabile Suiten geschützt wird, während längere Läufe weiterhin geplant und zeitlich begrenzt bleiben.

Automatisierte Tests Ihr Elektrifizierungsprogramm am Laufen. Elektroautos machten fast 20 % der weltweiten Autoverkäufe im Jahr 2023. Mehr Varianten und schnellere software zwingen HIL-Labore zur Triage. Eine wiederholbare Regressions-Pipeline verwandelt jede Änderung in eine Überprüfung, der Sie vertrauen können.

HIL-Automatisierung funktioniert nur, wenn der Prüfstand wie ein Build-System und nicht wie ein Experiment funktioniert. Versionierte Eingaben, deterministisches Timing und Pass-/Fail-Regeln sind besser als „auf dem Oszilloskop sah es gut aus“. Die Nachweise müssen Schicht- und Standortwechsel überstehen. Jeder Durchlauf muss mit der Firmware, dem Modell, der Kalibrierung und dem Verdrahtungsstatus verknüpft sein.

Was HIL Tests für elektrifizierte Antriebsstränge leisten Tests

Tests nachweisen, dass das Steuerungsverhalten nach jeder Änderung sicher bleibt. Sie müssen Timing-Fehler, Sättigung und Fehler in der Schutzlogik frühzeitig erkennen. Bei jedem Durchlauf müssen I/O , Anlagenmodell und Solver-Schritt konstant bleiben. Die Ergebnisse müssen mit „bestanden“ oder „nicht bestanden“ enden, sodass Sie den Test ohne Diskussion wiederholen können.

Ein Traktionswechselrichter-Update kann Unit-Tests bestehen und dennoch bei HIL fehlschlagen. Ein neuer Stromschleifenverstärkungssatz kann auf einem Desktop-Modell stabil erscheinen, dann aber bei einem Regenerationsdrehmoment-Schritt eine Überstromabschaltung auslösen. Die Fehlerlogik kann sich verschlechtern, beispielsweise durch einen Latch, der zu früh gelöscht wird und einen DC-Link-Sag maskiert. HIL-Regression deckt diese Probleme auf, da Timing, Schnittstellen und Grenzwerte in einem Durchlauf zusammenkommen.

Starke Suiten konzentrieren sich auf Invarianten, die nicht verändert werden dürfen. Sicherheit und Schutzprüfungen stehen an erster Stelle, dann folgen Leistungsprüfungen auf Akzeptanzniveau. Zehn stabile Tests sind besser als fünfzig fragile. Jedes Gate muss numerisch und nachvollziehbar sein.

„HIL-Automatisierung funktioniert nur, wenn der Prüfstand wie ein Build-System und nicht wie ein Experiment funktioniert.“

Warum manuelle Tests bei der Elektrifizierungsskalierung Tests

Manuelle HIL-Läufe schlagen fehl, sobald die Variantenanzahl und die Zusammenführungskadenz die Benchmark-Zeit übersteigen. Die Einrichtungsschritte führen zu Abweichungen bei der Verkabelung, den Kalibrierungen und den Lastskripten. Die Ergebnisse werden zu Screenshots und Ermessensentscheidungen statt zu Beweisen. Das Team verbringt mehr Zeit mit der Vorbereitung von Tests als damit, aus ihnen zu lernen.

Eine häufige Situation ist, dass zwei Ingenieur:innen denselben Wechselrichtertest auf zwei Prüfständen Ingenieur:innen und unterschiedliche Wellenformen erhalten. Ein Prüfstand verwendet eine andere Sensorskalierungsdatei, der andere hat ein veraltetes Lastprofil. Beide Tests sind erfolgreich, doch niemand kann die Diskrepanz erklären oder reproduzieren. Die Unsicherheit wächst, wenn Zweigstellen geschlossen werden und Prüfstände aufgrund von Wartungsarbeiten rotieren.

Späte Überraschungen sind schmerzhaft, weil die Zeitpläne eng sind und hardware bereits gebucht hardware . Software kosten die US-Wirtschaft immer noch jährlich 59,5 Milliarden Dollar. Eine übersehene Regression in einem Drehmomentsteuerungspfad kann eine erneute Prüfung auf dem Prüfstand, dann eine erneute Fahrzeugprüfung und schließlich einen weiteren Release-Kandidaten auslösen. Durch Automatisierung wird keine Laborzeit mehr für Drift und Wiederholungen verschwendet.

Kernkomponenten einer automatisierten HIL-Regressionspipeline

Eine HIL-Regressionspipeline benötigt einen Testrunner, ein wiederholbares Bench-Profil und einen Ergebnisdienst. Sie muss für jeden Durchlauf die richtigen Modell-, Firmware- und Kalibrierungsversionen abrufen. Sie muss die Bench reservieren, Ziele bereitstellen, Skripte ausführen und Signale automatisch erfassen. Sie muss Ergebnisse veröffentlichen, die sich auf die genauen Eingaben beziehen.

Ein praktischer Durchlauf beginnt mit einer Jobanforderung und endet mit einem signierten Ergebnis. Ein Motorantriebsgehäuse kann eine 12-phasige Permanentmagnet-Synchronmaschine auf FPGA laden, einen Phasenoffenfehler einspeisen und dann Drehmomentrampen ausführen, um die Durchfahrbarkeit zu überprüfen. Teams, die OPAL-RT-Prüfstände betreiben, können Anlagen- und Leistungsstufen auf CPU und FPGA aufteilen, um das Schritt-Timing stabil zu halten. Der Job erfasst Laufmetadaten, sodass ein erneuter Lauf auf einem zweiten Prüfstand vergleichbar bleibt.

Pipelines versagen, wenn die Bench außerhalb software liegt. Die Bench-Konfiguration erfordert Versionskontrolle und Überprüfung. Bench-Zeit ist knapp, daher sind Laufzeitbeschränkungen und strenge Timeouts wichtig. Klein und zuverlässig lässt sich besser skalieren als groß und anfällig.

Wie man Testfälle für wiederholbare HIL-Automatisierung strukturiert

Automatisierbare HIL-Tests beginnen mit einer benannten Anforderung und enden mit einer numerischen Überprüfung. Jeder Test muss die Anfangsbedingungen, Stimuli und Stoppkriterien kontrollieren, damit Wiederholungen übereinstimmen. Tests sollten schnell ablaufen und jeweils nur eine Funktion isolieren. Behandeln Sie Tests wie Code, mit Überprüfungen und Versionshistorie.

Ein Laderegler-Test kann die Batterietemperatur auf -10 °C einstellen, einen Schritt in der Stromanforderung anwenden und überprüfen, ob sich der Strom innerhalb der Grenzwerte einpendelt. Ein Motorsteuerungstest kann eine Drehzahlrampe anweisen und dann überprüfen, ob die Drehmomentwelligkeit nach dem Einschalten der Feldschwächung unter einem Schwellenwert bleibt. Ein Schutz-Test kann einen Sensor-Off-Zustand erzwingen und dann bestätigen, dass der Fallback-Pfad innerhalb einer festgelegten Zeit ausgelöst wird. Diese bleiben stabil, da Stimuli und Überprüfungen explizit sind.

• Jeden Test an eine Prüfstand-Profil-ID und Eingaben binden.
• Zustände und Fehlerkennzeichen vor Stimulus zurücksetzen.
• Fehler und Schritte bei Zeitstempeln auslösen.
• Verwenden Sie Toleranzen und Filter, damit Störsignale keinen Fehler auslösen.
• Protokollieren Sie nur Signale, die zur Erklärung eines Fehlers erforderlich sind.

Eine gute Strukturierung bedeutet, sich gegen „einen Test, der alles überprüft“ zu wehren. Mehrzwecktests verbergen die Ursache und verschwenden Zeit für Wiederholungen. Ein kurzer Test, der aus einem bestimmten Grund fehlschlägt, wird schneller behoben. Eine klare Benennung und Kennzeichnung ist wichtig, da niemand Tests durchführt, die er nicht interpretieren kann.

„Zehn stabile Tests sind besser als fünfzig instabile.“

Datenmanagement und Pass/Fail-Kriterien, denen Ingenieur:innen

Vertrauen entsteht durch Daten, die Sie nachverfolgen, wiedergeben und über verschiedene Durchläufe hinweg vergleichen können. Bei jedem Durchlauf sollten Rohsignale, abgeleitete Metriken und die Eingaben, aus denen sie entstanden sind, gespeichert werden. Die Regeln für „Bestanden“ oder „Nicht bestanden“ müssen über alle Testumgebungen und Releases hinweg konsistent bleiben. Wenn ein Test fehlschlägt, muss der Bericht nicht nur anzeigen, dass er fehlgeschlagen ist, sondern auch, was sich geändert hat.

Eine Regenerationsbremsprüfung kann die Zwischenkreisspannung, Phasenströme, Temperaturschätzungen und Fehlerkennzeichen protokollieren und anschließend den Spitzenwert und die Einschwingzeit berechnen. Der Ausführungskontext sollte den Solver-Schritt, I/O , die Kalibrierungsprüfsumme und den Fehlerplan erfassen. Mit diesem Paket können Sie einen Fehler wiederholen, ihn mit dem letzten Durchlauf vergleichen und die Differenz erklären. Ohne diesen Kontext führen Teams den Vorgang so lange wieder, bis die rote Leuchte erlischt.

Kriterien gewinnen Vertrauen, wenn sie mit den physikalischen und messtechnischen Grenzen übereinstimmen. Eine Regel wie „muss innerhalb von 5 ms auslösen” führt zu Fehlalarmen, wenn Ihre Messkette 2 ms hinzufügt. Daher müssen die Prüfungen mit dem übereinstimmen, was Sie messen können. Baselines erfordern Sorgfalt, da eine mit der Temperatur verschiebende Kurve Fehlalarme auslöst. Führen Sie strenge Prüfungen für Sicherheitspfade und Trendprüfungen für die Leistung durch.

Integration der HIL-Regression in CI-Workflows ohne Verlangsamung der Teams

Die CI-Integration funktioniert, wenn HIL als knappe, gemeinsam genutzte Ressource behandelt wird. Ihr Build-System sollte bei jeder Zusammenführung einen kleinen Smoke-Test und nach einem Zeitplan eine größere Testsuite auslösen. Die Ausführungen müssen in eine Warteschlange gestellt, zeitlich begrenzt und bei Änderungen der Eingaben abgebrochen werden. Die Ergebnisse sollten nur dann zu Zusammenführungen führen, wenn die Tests stabil sind.

Ein praktisches Muster ist eine 10- bis 20-minütige Suite nach jeder Zusammenführung. Die nächtlichen Läufe umfassen längere thermische und Fehlerkampagnen, die eine Stunde dauern. Die Reservierung von Arbeitsplätzen ist wichtig, daher benötigt die Warteschlange Prioritäten und eine klare Zugangsregel. Wenn ein Arbeitsplatz ausfällt, sollte die Pipeline den Lauf als blockiert markieren und fortfahren.

Integration bedeutet auch, zu entscheiden, was blockiert und was informiert wird. Blockierende Gates sollten klein und stabil bleiben, sonst werden sie von den Entwicklern umgangen. Längere Suiten sind wichtig, aber sie funktionieren am besten als Feedback, das die Kriterien verschärft, nachdem Fehler behoben wurden. Ein sauberer Workflow macht HIL zu einem Teil des Arbeitsablaufs und nicht zu einer Last-Minute-Angelegenheit.

Häufige Fehlerquellen bei der HIL-Automatisierung und wie man sie vermeidet

Die meisten HIL-Automatisierungen scheitern aus langweiligen Gründen: instabile Tests, unkontrollierte Bench-Drift und unklare Zuständigkeiten. Unzuverlässige Ergebnisse führen dazu, dass Teams rote Builds komplett ignorieren. Versteckte manuelle Schritte schleichen sich wieder ein, wenn die Tools umständlich sind. Um diese Probleme zu beheben, braucht es Regeln, keine Heldentaten.

Lärm kann Vertrauen schnell zerstören. Ein Team überprüft einen Einzelproben-Spitzenstrom und erhält einmal pro Woche aufgrund einer ADC-Störung eine Fehlermeldung, sodass Ingenieur:innen , bis er bestanden ist. Ein anderes Team aktualisiert die Bench-Firmware, ohne dies zu protokollieren, und wundert sich dann, warum die Zeitreserven schrumpfen und die Schutzprüfungen fehlschlagen. Beides lässt sich vermeiden, wenn Unzuverlässigkeit und Abweichungen als Mängel behandelt werden, für die es Verantwortliche und Lösungen gibt.

Disziplin sorgt dafür, dass die HIL-Regression über Monate hinweg nützlich bleibt, nicht nur über Tage. Änderungen an der Testumgebung erfordern eine Änderungskontrolle, und Teständerungen müssen überprüft und begründet werden. Die Fehlerbehebung erfordert einen klaren Ablauf: Nur bei Fehlern in der Testumgebung erneut ausführen, bei Produktproblemen Fehler melden und unzuverlässige Tests unter Quarantäne stellen. OPAL-RT kann eine deterministische Echtzeitausführung bieten, aber die Ergebnisse bleiben nur dann zuverlässig, wenn Ihr Prozess genauso streng ist wie Ihre hardware.