Hardware-in-the-Loop und Continuous-Integration

Continuous Integration für Embedded Systeme

Jede kleine Änderung an einem Embedded System kann bösartigste Auswirkungen haben. Findet und behebt man die Probleme zu spät, ist die Behebung zudem sehr teuer. Daher sollte jede Änderung an einem Embedded System innerhalb von Minuten getestet werden können. Nur so kann man sicherstellen, dass man die Probleme schnell entdecken und beheben kann.

Bei reinen Softwareprojekten hilft eine vollständige Automatisierung der Tests über Continuous-Integration (CI). Hierbei löst jede Codeänderung automatisch den Bau und Test der kompletten Software aus. Dadurch kann innerhalb von Minuten ein vollständiger Regressionstest Fehler in bestehendem und neuem Code entdecken. Kann das auch bei Embedded Systemen funktionieren?

Continuous-Integration zur Test-Automatisierung

Sehen wir uns zunächst an, wie Continuous-Integration funktioniert.

Jeder Entwickler aktualisiert seine Softwareänderungen durch einen Committ in ein zentrales Source Code Management System, z.B. GIT
Jeder Committ benachrichtigt die Continuous-Integration Server Applikation (CI-Server).
Der CI-Server checkt die soeben gemachte Änderung aus und baut das Software-Projekt, einschließlich der Tests komplett neu.
Nun werden für den neuen Softwarestand automatisch alle Tests durchgeführt. 4.1 Schlägt ein Test fehl, wird nur der Entwickler benachrichtigt, der die letzte Änderung gemacht hat – z.B. per E-Mail. 4.2 Laufen alle Tests problemlos durch, wird niemand benachrichtigt. Die Testergebnisse werden aber protokolliert.
In vielen Fällen wird auch gleich ein vollständiger Release mit Dokumentation und Release Notes gebaut. So ist immer sichergestellt, dass das Projekt jederzeit und automatisiert lieferfähig ist.

Was ist anders bei Embedded Systemen?

Ziel sollte sein, die Tests möglichst schnell nach jeder Softwareänderung durchzuführen. Bei Unit Tests, die in der Regel reine Software-Tests sind, ist dies einfach. Aber wie kann man das für System- oder Integrationstests bei Embedded Systemen erreichen?

Dafür nötige Hardware-in-the-Loop Tests (HIL-Test) oder manuelle System-Tests sind häufig schwer zu automatisieren. • Echte Hardwareanteile im Testaufbau verhindern die Automatisierung und Wiederholbarkeit • Häufig kann nur der „Happy Path“, nicht aber ein Fehlverhalten getestet werden • Der Teststand ist häufig zu teuer, um für jedes Projekt, jederzeit für Automatisierung verfügbar zu sein

Das Problem am Beispiel einer Ölpumpe

Sehen wir uns ein Beispiel aus einem realen Projekt an. Es handelt sich um den Systemtest für eine sicherheitsrelevante Ölpumpe.

Ziel des Testaufbaus: Test der Temperaturabschaltung für alle relevanten Systemzustände.

Der bisherige Aufbau: Das komplette System läuft in einer großen Klimakammer.

Die Nachteile: • Durch die Trägheit der Klimakammer würde der komplette Test ca. 30 Tage dauern. Dies macht den Test für die Entwicklung praktisch wertlos. • Durch den aufwändigen Systemaufbau sind die Tests nur teilweise zu automatisieren. • Es kann nur der Temperaturfehler getestet werden. Für andere Fehlersituationen müssen Motor, Pumpe oder Hydrauliksystem manuell manipuliert werden. • Die teure Klimakammer steht sehr lange nicht für andere wichtige Systemtests zur Verfügung.

Der neue Aufbau: Wir testen nur den Mikrocontroller, die Treiber und die Applikationssoftware und simulieren die komplette Umgebung. Der Test erfolgt als Black-Box Test über die Signale an den Pins des Mikrocontrollers.

Die Vorteile:

Man testet, was am häufigsten ändert: Die Software
Man kann nicht nur die Temperaturabschaltung, sondern auch alle anderen Fehlersituationen testen.
Neben dem Gutfall (Happy Path) können auch alle Schlechtfälle (Unhappy Path) durch Simulation und Fehlerinjektion getestet werden
Die Testausführung kann vollständig automatisiert werden
Es werden vollständige Regressionstests für JEDE Änderung durchgeführt
Die Durchführung dauert statt 30 Tagen nur noch 50 Minuten.
Der Hardware-Aufbau ist signifikant preiswerter und kleiner.

Der Hardware-Testaufbau

Statt des kompletten Systems wird nur der Microcontroller mit der kompletten unveränderten Software getestet.

Die Pins und somit die benötigten Signale des Systems under Test (SUT, rechte Seite) werden mit dem Testsystem (linke Seite) verbunden. Auf dem Testsystem läuft die Umgebungssimulation (Motorsimulation, Hydrauliksimulation, Temperatursimulation, …) und die automatisierten Testfälle.

Durch die komplette Umgebungssimulation kann das SUT in jeden benötigten Zustand versetzt und damit die Tests komplett automatisiert werden.

Hat man mehr als ein Projekt, oder arbeiten mehrere Entwickler an einem Projekt, so empfiehlt sich ein Aufbau im 19 Zoll Schrank. Im Beispiel sieht man 8 verschiedene Projekte in einem hüfthohen Schrank. Diese sind über USB-Hub mit dem CI-Server verbunden.

Die Software-Entwicklungsumgebung

Um möglichst effizient Umgebungssimulationen und Testfälle erstellen zu können, verwenden wir einen modellgetriebenen Ansatz. Hierbei werden mit der Sprache ROOM und dem Open Source Tool eTrice die Softwarestruktur des Testsystems und die Umgebungssimulationen entwickelt. Die Testfälle werden ebenfalls modellgetrieben mit der Sprache CeGe (Case Generator) entwickelt. Aus den Modellen wird C-Code generiert, compiliert und auf das Testsystem übertragen. Die bei der Testdurchführung protokollierten Ergebnisse werden in verschiedene Diagramme und Standardformate transformiert. Dies macht es Entwicklern, Projektleitern und Reviewern einfacher die Ergebnisse zu interpretieren, zu lernen und die nächste Iteration zu starten.

Fazit

Durch die Reduktion des Hardware-in-the-Loop Tests auf den Mikrocontroller mit der kompletten Software, kann eine vollständige Automatisierbarkeit des Testaufbaus erreicht werden. Die Reaktionszeiten für die Testdurchführung liegen Dank der Verwendung von Continuous-Integration im Bereich von Minuten statt Tagen, Wochen oder gar Monaten. Die Entwickler können so extrem schnell und ohne Abhängigkeiten zu anderen Änderungen auftretende Fehler beseitigen. Dies ist eine wichtige Voraussetzung für eine schnelle, iterative Projektentwicklung.

Links:

Open Source Modellierungstool und Codegenerator eTrice: https://www.eclipse.org/etrice/
miniHIL Hardware und Software: https://www.protos.de/produkte/minihil/