Hardware-in-the-Loop: Kernel-Tests auf echter Hardware mit Markus Napierkowski

Ob ein Kernel auf jeder CPU-Generation läuft, zeigt erst die echte Hardware. Markus Napierkowski hat dafür ein Hardware-in-the-Loop-Framework gebaut und Open Source gestellt. In dieser Folge des Podcasts Software Testing & Qualität spricht Host Richard Seidl auf der TACON in Leipzig mit seinem Gast Markus Napierkowski über die Herausforderungen beim Testen systemnaher Software. Sie beleuchten, wie sein Team ein über Jahre gewachsenes Framework entwickelt hat, um automatisierte Tests auf echten Geräten zuverlässig und effizient zu gestalten. Das Gespräch dreht sich um die Kernfrage: Wie kann man Entwicklern und CI/CD-Pipelines einen sauberen, exklusiven und dynamischen Zugriff auf physische Testmaschinen ermöglichen, als stünden sie direkt neben dem Schreibtisch?

Das Wichtigste auf einen Blick

• Warum Hardware-in-the-Loop? Für systemnahe Software wie Linux-Kernel ist das Testen auf echter Hardware unerlässlich, da Virtualisierung nicht alle Eigenheiten verschiedener CPU-Generationen oder plattformspezifischer Images abbilden kann.
• Die Lösung: Ein Open-Source-Framework: Markus und sein Team haben ein Framework entwickelt, das die Reservierung, Initialisierung und Steuerung von Test-Hardware über eine REST-API automatisiert. Es wurde kürzlich auf GitHub als Open Source veröffentlicht.
• Die Architektur: Ein Raspberry Pi pro Testmaschine: Jedes Testgerät wird durch einen dedizierten Raspberry Pi gesteuert. Dieser übernimmt die Kontrolle über USB, das Auslesen des HDMI-Signals und den Zugriff auf die serielle Konsole.
• Nahtlose Integration: Entwickler können Hardware für manuelle Tests reservieren und so den langsamen Zyklus aus Code-Push und Warten auf die Pipeline umgehen. Gleichzeitig nutzt die CI/CD-Pipeline dieselbe Infrastruktur für automatisierte Tests.
• Infrastructure as Code mit Nix: Die Konfiguration neuer Hardware ist dank Nix und NixOS stark vereinfacht. Eine neue Maschine auf der Softwareseite hinzuzufügen, erfordert laut Markus nur etwa fünf Zeilen Code im Repository.
• Aufruf an die Community: Das Projekt ist seit Kurzem Open Source und das Team sucht aktiv nach Feedback und neuen Anwendungsfällen, um die zukünftige Entwicklung an den Bedürfnissen der Community auszurichten.

Warum reicht Virtualisierung für den Kernel-Test nicht aus?

Die Reise des Frameworks begann vor über zehn Jahren mit einem fundamentalen Problem: Wie stellt man sicher, dass ein neu entwickelter Linux-Kernel oder Mikrokernel auf einer Vielzahl von CPU-Architekturen und -Generationen fehlerfrei läuft? Markus erklärt, dass virtuelle Umgebungen hier an ihre Grenzen stoßen. Während Unit-Tests und virtualisierte Tests schnelle Feedback-Zyklen ermöglichen, lassen sich bestimmte hardwarenahe Fehler und Inkompatibilitäten nur auf dem echten Gerät aufdecken. Ein finaler Abnahmetest für ein Image, das speziell auf eine Hardware-Plattform zugeschnitten ist, kann nur auf dieser Plattform selbst stattfinden. Dieser Bedarf an zuverlässigen und wiederholbaren Tests auf physischer Hardware war der Auslöser für die langjährige Investition in ein eigenes Hardware-in-the-Loop-Testlabor.

Das HIL-Framework im Detail: Ein Raspberry Pi pro Testmaschine

Das Herzstück der Lösung ist ein System, das die häufigsten Schmerzpunkte bei der manuellen Verwaltung von Test-Hardware adressiert. Das Framework stellt sicher, dass jede Testumgebung sauber initialisiert und für die Dauer eines Tests exklusiv reserviert ist. Dadurch werden Konflikte vermieden, die entstehen, wenn mehrere Entwickler oder eine CI-Pipeline gleichzeitig auf dieselbe Maschine zugreifen. Die technische Umsetzung ist ebenso pragmatisch wie clever: An jeder Testmaschine hängt ein Raspberry Pi. Dieser kleine Computer agiert als universelle Schnittstelle und ermöglicht die Fernsteuerung kritischer Funktionen. Er kann USB-Geräte wie einen Boot-Stick simulieren, den Bildschirminhalt über HDMI auslesen und über die serielle Konsole direkt mit dem System kommunizieren. Die gesamte Orchestrierung läuft über eine zentrale REST-API, die von einem Web-UI, einem Kommandozeilen-Tool oder direkt von Testskripten angesprochen werden kann.

Wie die Integration in Entwicklungsworkflows gelingt

Ein zentrales Ziel des Frameworks ist es, den Entwicklungsprozess zu beschleunigen. Markus beschreibt den ineffizienten Standard-Workflow: Ein Entwickler macht eine Änderung, pusht sie, holt sich einen Kaffee und wartet auf das Ergebnis der CI-Pipeline. Mit dem neuen System kann sich derselbe Entwickler die benötigte Hardware per API-Aufruf reservieren und sie nutzen, als stünde sie direkt auf seinem Schreibtisch. Er kann Fehler interaktiv untersuchen und Korrekturen testen, ohne auf die Pipeline angewiesen zu sein. Gleichzeitig kann die CI/CD-Pipeline, etwa GitLab CI, die exakt gleiche Infrastruktur für vollautomatisierte Tests nutzen. Das Tooling unterstützt die Erstellung von strukturierten Testberichten im JUnit-XML-Format, die sich nahtlos in die Benutzeroberfläche von CI-Systemen integrieren. Das System eignet sich laut Markus auch für Performance-Benchmarks, die auf echter Hardware stabile und verlässliche Messergebnisse liefern - etwa um sicherzustellen, dass die Boot-Zeit eines Routers ein bestimmtes Limit nicht überschreitet.

Der Schritt zu Open Source und der Ruf nach der Community

Nachdem das Framework über Jahre intern mit einer Partnerorganisation entwickelt wurde, hat das Team es vor zwei Monaten als Open-Source-Projekt veröffentlicht. Markus betont, dass dieser Schritt eine bewusste Entscheidung war, um der Community etwas zurückzugeben. Schließlich, so argumentiert er, basiert fast die gesamte moderne IT-Infrastruktur auf Open-Source-Software. Aktuell wird das Tool hauptsächlich intern genutzt, doch das Team ist sehr daran interessiert, zu erfahren, ob und wie es für andere nützlich sein könnte. Auf der TACON und durch den Podcast suchen sie gezielt den Austausch, um neue Anwendungsfälle zu entdecken und die Weiterentwicklung zu priorisieren. Eine konkrete Roadmap gibt es noch nicht, aber mögliche Erweiterungen, wie eine standardisierte Schnittstelle zum Flashen von Firmware, werden bereits diskutiert. Derzeit liegt der Fokus darauf, Feedback zu sammeln und zu verstehen, welche Funktionen für eine breitere Adaption notwendig wären.

Praktische Schritte zur Evaluierung des Frameworks

1. Anwendungsfall prüfen: Analysiere, ob deine Testanforderungen - sei es bei Embedded-Systemen, Kernel-Entwicklung oder hardwareabhängigen Performance-Messungen - die Grenzen der Virtualisierung überschreiten. Wenn du physische Geräte wiederholt in einem definierten Zustand benötigst, könnte das Framework passen.
2. Projekt erkunden: Besuche das GitHub-Repository des Projekts. Mache dich dort mit der Architektur, der Dokumentation und den grundlegenden Konzepten vertraut. Der Link dazu wird in den Shownotes des Podcasts geteilt.
3. Konzept verstehen: Verinnerliche die Kernidee. Du benötigst eine zentrale Steuerungseinheit und pro Testgerät einen Raspberry Pi, der als Brücke zwischen der Management-API und der Hardware dient. Das Booten erfolgt standardmäßig von einem simulierten USB-Stick.
4. Feedback geben und mitwirken: Da das Projekt noch jung ist, ist dein Feedback besonders wertvoll. Nimm Kontakt mit Markus und dem Team auf, diskutiere deine Anforderungen und trage dazu bei, die Zukunft des Frameworks zu gestalten.