Hardware-in-the-Loop: Kernel-Test am echten Gerät - Markus Napierkowski

Wer die Testmaschine reserviert hat, dem funkt kein Kollege mehr dazwischen Ob ein Kernel auf jeder CPU-Generation läuft, zeigt erst die echte Hardware. Genau dafür hat Markus Napierkowski mit seinem Team ein Hardware-in-the-Loop-Framework gebaut, das seit zwei Monaten Open Source auf GitHub liegt, und darüber spreche ich mit ihm auf der TACON in Leipzig. Entwickler und CI reservieren sich dieselben Testmaschinen über eine REST API, sauber initialisiert, als stünden sie neben dem Schreibtisch. An jeder Maschine hängt ein Raspberry Pi für USB, HDMI und serielle Konsole, eine neue Hardware ist auf der Softwareseite fünf Zeilen Code im Nix-Repository. Mich hat vor allem gefreut, dass hier jemand ein über Jahre gewachsenes Werkzeug zurück an die Community gibt. „Ich kann mir als Entwickler jetzt eine Hardware reservieren und sie benutzen, als würde sie neben meinem Tisch stehen.“ - Markus Napierkowski Markus Napierkowski hat Informatik in Dresden studiert und ist seit neun Jahren bei Cyberus Technology tätig. Angefangen hat er als Software Engineer mit der Entwicklung von Produkten auf Basis von Microkernels. Seitdem hat er an unterschiedlichsten Themen gearbeitet, von Virtualisierungstechnologie in Rust und Performance-Benchmarks über den Aufbau der internen Testautomatisierungs-Infrastruktur bis hin zur Beratung rund um Nix, NixOS und moderne Entwicklungsprozesse. Heute ist Markus Head of Test Automation and CI bei Cyberus. Sein Fokus liegt auf Entwicklungsmethodik und Testautomatisierung sowie darauf, Partner bei der Verbesserung und Automatisierung ihres Software Development Lifecycles zu unterstützen. Highlights: 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. Weitere Links zur Episode: Cyberus Technology Announcing HWaaS: Open-Source Hardware-in-the-Loop Test Automation HWaaS on GitHub 📘 Tool-Migration geplant? Teamscale-Playbook: nur 20 % der Tests migrieren, fast volle Fehlererkennung. Kostenlos herunterladen Danke an die Community-Partner des Podcasts: