Hardware-in-the-Loop bezeichnet das automatisierte Testen von Systemsoftware auf echter Hardware, weil ein Kernel oder ein Embedded-Image am Ende nur dort abgenommen werden kann. Ein Open-Source-Framework reserviert dafür Testmaschinen in einem sauberen Ausgangszustand, bootet das passende Image und gibt die Geräte per REST API an Entwickler wie an die CI-Pipeline aus.
Das Wichtigste in Kürze
- Auf allen CPU-Generationen muss ein Kernel laufen, deshalb besteht ein plattformspezifisches Image seinen finalen Abnahmetest nur mit Hardware-in-the-Loop auf dem echten Gerät.
- Der Knackpunkt beim Hardware-in-the-Loop-Test ist der saubere Ausgangszustand, den das Framework herstellt, indem es jedes reservierte Gerät vom USB-Stick mit dem passenden Image bootet.
- Warten auf die Pipeline nach jedem Push kostet Zeit, darum reservieren Entwickler die Maschine für einen HIL-Test selbst und geben sie danach an die CI zurück.
- Jede Testmaschine hängt an einem Raspberry Pi für USB-Simulation, HDMI-Ausgabe und serielle Konsole; ein weiteres Gerät kostet softwareseitig etwa fünf Zeilen Code.
- HIL Testing läuft in der GitLab CI vor oder nach jedem Pull Request mit und liefert jeden Testfall als JUnit XML Artefakt.
Ein Kernel beweist nur auf echter Hardware, dass er läuft
Wer Systemsoftware baut, kommt um Hardware-in-the-Loop nicht herum: Das Testobjekt läuft auf dem echten Zielgerät, und eine Testumgebung steuert dieses Gerät von außen, startet es, bespielt es und liest aus, was es tut. Markus Napierkowski und sein Team arbeiten auf Linux-Kernel-Ebene und haben früher Mikrokerne gebaut. Ein Kernel soll auf jeder CPU-Generation laufen, also muss er auf jeder dieser Hardware-Generationen auch getestet werden. Virtualisierung hilft bei vielem, beim Beweis für die reale Plattform hilft sie nicht.
Dasselbe gilt eine Ebene höher bei Embedded-PCs. Dort lässt sich ein Großteil virtualisiert prüfen, der finale Abnahmetest aber nur dann, wenn das Image, das für genau diese Plattform zugeschnitten ist, auch auf genau dieser Plattform bootet. Der Wunsch dahinter war von Anfang an derselbe wie bei Unit-Tests: schnelle Feedback-Zyklen, kein manuelles Durchklicken.
Das Labor für HIL Testing, das Kollegen von Markus vor über zehn Jahren aufgebaut haben, war der Anfang. Die Anwendungsfälle und die Lösungen dafür haben sich seither mehrfach verändert. Die aktuelle Fassung ist ein Framework, das über Jahre gemeinsam mit einer Partnerorganisation entstanden ist, lange closed source blieb und seit zwei Monaten auf GitHub liegt.
Warum ist der saubere Ausgangszustand bei Hardware-in-the-Loop-Tests der Knackpunkt?
Weil die Automatisierung auf Softwareebene meistens schon da ist und trotzdem nichts beweist. Skript hochladen, Payload hochladen, ausführen: Das bekommt fast jedes Team hin. Was fehlt, ist Setup und Teardown für die Hardware selbst. Ohne beides weiß nach einem Lauf niemand sicher, in welchem Zustand das Gerät steckt, und der nächste rote Test sagt wenig über die Software.
Eine Testmaschine wird reserviert und ist dann in einem definierten Anfangszustand. Der Test gibt das Boot-Image vor, dazu weitere Geräte im Umfeld, die initialisiert sein müssen, und bei Bedarf ein Netzwerk aus mehreren Maschinen. Dann geht die Hardware an, und der eigentliche Test läuft so, als hätte sich jemand per SSH eingeloggt und ihn von Hand gestartet.
Markus benennt die Grenze offen: Die saubere Initialisierung macht sich das Framework einfach, weil es auf den Fall optimiert ist, in dem Booten vom USB-Stick reicht. Firmware auf ein Gerät zu flashen kann es noch nicht; wer das braucht, muss es selbst anbauen. Das deckt nach seiner Erfahrung trotzdem einen großen Teil der eigenen Fälle und vieler Kundenfälle ab.
Wie teilen sich Entwickler und CI-Pipeline dieselbe Testhardware?
Über Reservierung mit einem Secret. Die Tests laufen in der Pipeline vor oder nach jedem Pull Request, je nach Strategie des Projekts, und dieselbe Infrastruktur steht Entwicklern direkt offen. Wer ein Fehlverhalten untersuchen will, nimmt sich dieselbe Maschine für denselben Test heraus, ohne die CI anzuhalten. Ist die Maschine wieder frei, holt sich die Pipeline sie zurück.
„Ich kann mir als Entwickler jetzt eine Hardware reservieren und sie benutzen, als würde sie neben meinem Tisch stehen.“
(Markus Napierkowski)
Der Anlass dafür war ein Arbeitsrhythmus, den viele kennen: Änderung pushen, auf die Pipeline warten, Kaffee holen, zurückkommen, immer noch warten. Oder die Nachricht im Team-Chat, dass die Maschine jetzt reserviert ist und bitte niemand darauf deployen soll. Was dann trotzdem passiert. Eine Reservierung gehört dagegen einer Person, bis sie die Maschine zurückgibt. Wenn mehrere Exemplare derselben Hardware vorhanden sind, verteilt das System die Anfragen dynamisch zwischen CI und Menschen.
Das Secret lässt sich teilen, und das lohnt sich in einem Fall: Ein Test schlägt fehl, und zwei Leute schauen gemeinsam in die Web-UI, was der Bildschirm-Output der einzelnen Maschinen gerade zeigt und warum.
Ein Raspberry Pi je Testmaschine, fünf Zeilen Nix je neuer Hardware
Neue Hardware einzuhängen kostet auf der Softwareseite etwa fünf Zeilen Code und ein Deployment. Markus und sein Team setzen auf Nix und NixOS und halten die gesamte Testinfrastruktur in einem Infrastructure-as-Code-Repository. Ein neues Gerät ist dort ein dupliziertes Stück Konfiguration, einmal ausgerollt.
Auf der Hardwareseite hängt an jeder Testmaschine ein Raspberry Pi. Er simuliert über USB Geräte wie das Bootmedium, liest den HDMI-Ausgang der Maschine mit und bindet die serielle Konsole an.
Der Pi muss einmal vorbereitet werden. Danach kapselt die Infrastruktur-Beschreibung den Rest der Komplexität weg; wer das Gesamtsystem einmal verstanden hat, erweitert es ohne Herumfummeln an einzelnen Geräten.
Wie schreibt man einen HIL-Test, ohne die API zu kennen?
Indem das Tooling die Umgebung aufbaut, bevor das Testskript startet. Unter allem liegt eine REST API; die Web-UI nutzt sie, das Command-Line-Tooling nutzt sie. Wer eine Maschine reserviert, bekommt ein Secret zurück, das als Kontext für alle reservierten Maschinen gilt. Über denselben Weg lassen sich die Maschinen vernetzen, ein VLAN-Switch gehört zum Aufbau.
Ein Test beschreibt in JSON, welche Maschinen er braucht, in welchem Netzwerk sie hängen und welches Bootmedium sie bekommen. Das Testskript selbst beginnt erst an der Stelle, an der die Maschinen per SSH erreichbar sind. Die Person, die den Test schreibt, muss im besten Fall nie wissen, wie die API dahinter spricht.
Ein großer Anwendungsfall war GitLab CI. Die einzelnen Testfälle eines Durchlaufs fallen im JUnit-XML-Format als Artefakt heraus, damit die CI sie strukturiert anzeigt. Für Performance-Benchmarks ist das Testen auf Hardware ebenfalls relevant: Virtualisierte Messungen sind oft nicht stabil genug, und manchmal steht die Zahl im Requirement. Ein Router, der in höchstens zehn Sekunden hochgefahren sein muss, braucht Messdaten, die das belegen, und die lassen sich aus den Läufen aufnehmen und weiterleiten.
Ein internes Werkzeug, bewusst auf GitHub
Markus nennt das Framework noch ein internes Tool. Es deckt die eigenen Fälle und die des Partners ab; ob es mit wenigen Kniffen auch anderen hilft, ist offen. Es gibt erste Gespräche, aber keinen Beleg und kein externes Investment. Eine Roadmap existiert jenseits von Aufräumarbeiten nach der Veröffentlichung nicht. Der Kandidat, der sich auf der TACON in Gesprächen herausgeschält hat, ist ein Interface, um Firmware auf Geräte zu bekommen statt nur vom USB-Stick zu booten. Für die aktuellen Anwendungsfälle hält Markus den Stand für gut genug.
Open Source wurde das Framework aus zwei Gründen. Hinter der proprietären Fassung stand kein kommerzieller Wert, der das Geheimhalten gerechtfertigt hätte. Und die ganze eigene Infrastruktur baut auf Open-Source-Software auf; Markus beschreibt es als Ehrgefühl, etwas Gebautes auch wieder zurückzugeben, selbst wenn sich zeigen sollte, dass es zu viele Änderungen bräuchte, um über das eigene Haus hinaus zu taugen.
Wenn Du Embedded-Systeme mit wechselnden Hardware-Konfigurationen testest und die Reservierung heute noch über den Team-Chat läuft, lohnt sich ein Blick auf das Projekt. Markus sucht gerade Rückmeldungen dazu, welche Anwendungsfälle dem Framework noch fehlen.
Häufig gestellte Fragen
Was ist Hardware-in-the-Loop?
Hardware-in-the-Loop bedeutet, dass die zu testende Software auf dem echten Zielgerät läuft, während eine Testumgebung dieses Gerät von außen steuert: starten, Boot-Image bereitstellen, Ausgaben mitlesen. Für Kernel und Embedded-Images ist das der einzige Weg, um zu zeigen, dass ein Build auf einer konkreten Plattform tatsächlich funktioniert.
Wie integriert man Hardware-in-the-Loop-Tests in eine CI-Pipeline?
Die Hardware-Tests laufen als normaler Pipeline-Schritt, etwa vor oder nach jedem Pull Request. Das Tooling reserviert dafür eine Maschine, bootet sie mit dem vorgegebenen Image und gibt sie danach wieder frei. Die Ergebnisse der einzelnen Testfälle landen als JUnit-XML-Artefakt in der CI, bei GitLab zum Beispiel direkt in der Oberfläche.
Reicht ein virtualisierter Test, oder braucht es einen HIL-Test auf echter Hardware?
Für den größten Teil der Entwicklung reicht Virtualisierung, für den Abnahmetest nicht. Ein Image, das auf eine bestimmte Plattform zugeschnitten ist, beweist erst auf dieser Plattform, dass es bootet und läuft. Für den Nachweis, dass ein Kernel auf jeder unterstützten CPU-Generation funktioniert, gilt dasselbe.
Eignet sich Hardware-in-the-Loop auch für Performance-Messungen?
Ja, gerade dann, wenn eine Zahl im Requirement steht. Ein Router, der in höchstens zehn Sekunden hochgefahren sein muss, braucht Messdaten vom echten Gerät, weil virtualisierte Messungen oft schwanken. Die Werte aus den Testläufen lassen sich aufzeichnen und an eine Infrastruktur weiterleiten, die sie sammelt und auswertet.
