Wozu dient Hardware-in-the-Loop-Testing?
Beim Hardware-in-the-Loop-Testing wird Software auf echter Zielhardware getestet, während ein HiL-Prüfstand die Umgebung über simulierte Signale in Echtzeit nachbildet. So lassen sich Integrationsprobleme finden, die in reinen Software-Simulationen nicht auftauchen. Das ist besonders bei sicherheitskritischen Systemen im Automotive- und Industriebereich wichtig.
Auch bekannt als: HiL · HiL-Test · HiL-Prüfstand · Hardware in the Loop · HiL-Simulation · Hardware-in-the-Loop-Simulation
Ist Hardware-in-the-Loop (HiL) bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Auf einem HiL-Prüfstand ist das echte Steuergerät oder die echte SPS mit einem Echtzeitsimulator verkabelt, der die Anlage ersetzt. Der Simulator rechnet ein Streckenmodell, also ein mathematisches Modell von Motor, Fahrzeug oder Maschine, und gibt die Ergebnisse als elektrische Signale auf die Eingänge des Prüflings. Der Prüfling reagiert mit seinen Ausgängen, der Simulator liest sie zurück und rechnet den nächsten Schritt. So entsteht ein geschlossener Regelkreis, die „Loop“ im Namen. Der Simulator muss dabei im Takt des Prüflings rechnen, häufig im Millisekundentakt. Kommt er nicht hinterher, sieht die Steuerung ein Verhalten, das keine echte Anlage zeigen würde, und das Testergebnis ist wertlos.
HiL ist die letzte Stufe einer Kette, die Schritt für Schritt mehr echte Technik in die Schleife holt. Beim Model-in-the-Loop (MiL) läuft nur ein Modell der Regelung, etwa in Simulink, gegen das Streckenmodell, beides rein am PC. Beim Software-in-the-Loop (SiL) läuft der daraus erzeugte oder von Hand geschriebene Code kompiliert auf dem PC gegen dasselbe Modell. Processor-in-the-Loop (PiL) führt den Code auf dem Zielprozessor oder einem Evaluierungsboard aus und deckt Fehler auf, die erst der echte Compiler und die echte Recheneinheit verursachen, etwa Rundungsfehler in Festkomma-Arithmetik. HiL betreibt schließlich das komplette Steuergerät mit echten Treibern, Ein- und Ausgängen. Erst hier werden Timing-, Treiber- und I/O-Fehler sichtbar. Jede Stufe ist langsamer und teurer als die vorherige. Deshalb prüft ein gutes Team in MiL und SiL so viel wie möglich und bringt nur auf den Prüfstand, was nur dort sichtbar wird.
Gegenüber dem Test an der realen Anlage hat HiL zwei Vorteile. Jeder Testlauf ist exakt wiederholbar, und Fehler lassen sich gezielt einstreuen. Ein Kabelbruch, ein ausgefallener Sensor oder ein Wert jenseits der Grenze wäre am Fahrzeug oder an der laufenden Maschine zu gefährlich oder zu teuer. Am Prüfstand ist er ein Testfall unter vielen. So weist ein Team nach, dass ein Steuergerät bei Sensorausfall in den sicheren Zustand wechselt, ohne dafür einen echten Fehler in der Anlage zu provozieren. Simulatoren und Testautomatisierung für solche Prüfstände liefern etwa dSPACE, NI mit VeriStand und Speedgoat.
Für Industrial DevOps holt HiL das kontinuierliche Testen bis an die Hardware, weil der Prüfstand als automatisierte Stage in der CI/CD-Pipeline laufen kann. Zwei Dinge begrenzen das in der Praxis. Prüfstände sind teuer, und ihre Zahl ist schnell kleiner als die Zahl der Builds, die getestet werden wollen. Und das Streckenmodell braucht Pflege. Ist es zu grob, besteht die Steuerung am Prüfstand Tests, an denen sie in der Anlage scheitern würde.
Sensorausfall am Prüfstand statt auf der Teststrecke
Ein Automotive-Team muss nachweisen, dass ein Steuergerät bei einem ausgefallenen Raddrehzahlsensor in den sicheren Zustand wechselt. Auf der Teststrecke wäre dieser Versuch gefährlich und kaum zweimal gleich zu wiederholen. Am HiL-Prüfstand trennt die Fehlerinjektions-Hardware das Sensorsignal auf Befehl der Testautomatisierung, der Simulator rechnet die Fahrdynamik weiter, und das Protokoll zeigt, nach wie vielen Millisekunden das Steuergerät reagiert hat. Derselbe Test läuft danach bei jedem Release wieder, Signal für Signal identisch.
Regelungsfehler vor der Inbetriebnahme finden
Ein Maschinenbauer hat Fehler in der Regelung bisher bei der Inbetriebnahme an der Kundenmaschine gefunden, mit dem Kunden daneben. Heute koppelt er seine SPS-Builds an einen HiL-Prüfstand mit einem Anlagenmodell, und jeder Nightly-Stand läuft automatisch gegen die Testfälle. Morgens liegt ein Report vor, und eine Regression fällt auf, bevor neue Firmware an eine reale Maschine geht.
Wo lohnt sich Automatisierung Ihrer HiL-Tests?
Hardware-in-the-Loop-Tests entfalten ihren Wert erst automatisiert in der Pipeline — der beste Einstieg hängt an Stand und Branche. Zwei Klicks ordnen ein.
In welchem Umfeld testen Sie?
- Was ist ein HiL-Prüfstand?
- Ein HiL-Prüfstand (auch Hardware-in-the-Loop-Prüfstand oder Test-Bench) ist der physische Aufbau, auf dem Hardware-in-the-Loop-Tests laufen. Er besteht aus dem Prüfling, also Steuergerät oder SPS, einem Echtzeitsimulator mit dem Streckenmodell, der Signalkonditionierung samt Fehlerinjektions-Hardware und der Testautomatisierung, die Testfälle ausführt und Ergebnisse protokolliert. Häufig kommt eine Restbussimulation hinzu, die fehlende Kommunikationsteilnehmer etwa am CAN-Bus nachbildet. Für die Steuerung sieht der Prüfstand aus wie eine echte Anlage, einschließlich gezielt provozierter Fehler wie Kabelbruch oder Sensorausfall.
- Was ist der Unterschied zwischen MiL, SiL, PiL und HiL?
- Die vier Verfahren unterscheiden sich darin, wie viel echte Technik in der Testschleife steckt. MiL (Model-in-the-Loop) testet ein Modell der Regelung gegen ein Streckenmodell, rein virtuell. SiL (Software-in-the-Loop) testet den kompilierten Code auf dem PC ohne Zielhardware. PiL (Processor-in-the-Loop) lässt den Code auf dem Zielprozessor laufen und findet Compiler- und Rechengenauigkeitsfehler. HiL (Hardware-in-the-Loop) betreibt das komplette Steuergerät gegen eine Echtzeitsimulation und deckt zusätzlich Treiber-, I/O- und Timing-Fehler auf. Dafür ist HiL die langsamste und teuerste Stufe.
- Was ist Software in the Loop (SiL)?
- Software-in-the-Loop (SiL) ist ein Testverfahren, bei dem der kompilierte Steuerungscode ohne Zielhardware auf einem PC gegen ein simuliertes Streckenmodell läuft. Weil dafür kein Prüfstand nötig ist, laufen SiL-Tests bei jedem Commit und beliebig oft parallel. Sie finden Logik- und Integrationsfehler früh, sehen aber keine Timing-, Treiber- oder I/O-Probleme der echten Hardware. Dafür braucht es danach PiL oder HiL.
- Wofür werden HiL-Tests eingesetzt?
- Vor allem für sicherheitskritische Funktionen, die am realen System zu gefährlich oder zu teuer zu testen wären: gezielte Fehlerinjektion wie Sensorausfall oder Kabelbruch, Grenzwertprüfungen und Regressionstests neuer Firmware-Stände. Typische Einsatzfelder sind Automotive-Steuergeräte, Embedded-Systeme und SPS-gesteuerte Maschinen. HiL fängt einen Großteil der Fehler früher und gefahrlos ab, den abschließenden Test an der realen Anlage ersetzt es aber nicht.
- Wie integriert man HiL-Tests in eine CI/CD-Pipeline?
- Als eigene Stage, die meist nicht bei jedem Commit läuft, sondern nächtlich oder vor einem Release, weil Prüfstände knapp sind. Die Pipeline reserviert einen freien Prüfstand, flasht den Build, fährt die Testfälle und legt die Ergebnisse als Artefakt ab. Wer vorher SiL-Tests bei jedem Commit laufen lässt, hält den Prüfstand frei für die Fehler, die nur dort auftauchen.
- Wofür steht die Abkürzung HiL?
- HiL steht für Hardware-in-the-Loop, wörtlich „Hardware in der Schleife“. Gemeint ist, dass die reale Hardware, also das Steuergerät oder die SPS, in einen geschlossenen Regelkreis mit einer Echtzeitsimulation eingebunden ist. Die verwandten Abkürzungen MiL, SiL und PiL bezeichnen dieselbe Idee mit einem Modell, der Software oder dem Prozessor statt des kompletten Steuergeräts in der Schleife.
Wo steht Ihr Team bei Hardware-in-the-Loop (HiL)?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Hardware-in-the-Loop (HiL): Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01dSPACEHIL Testing(externe Seite, öffnet in neuem Tab)
Herstellerdarstellung des Prüfaufbaus mit Echtzeitsimulation und Restbussimulation.
- /02NIHardware-in-the-Loop(externe Seite, öffnet in neuem Tab)
Deutschsprachige Übersicht zu HiL-Prüfständen, Signalkonditionierung und Testautomatisierung.
- /03MathWorksHardware-in-the-Loop (HIL) Simulation(externe Seite, öffnet in neuem Tab)
Ordnet HiL gegenüber MiL und SiL ein und zeigt den Übergang vom Modell zum Prüfstand.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance