Wenn die Schnittstellen für Soft- und Hardware abgefangen sind, muss der Entwickler sie lediglich mit Ein- und Ausgaben versorgen. Hierbei hängt die konkrete Umsetzung der Simulation von der verwendeten Software ab. Hierzu wurde von Mixed Mode das Embedded-Software-in-the-Loop-Framework »eSIL« entwickelt (Bild 3).
Die Simulation wird über eine Python-API bereitgestellt, um mit möglichst wenig Aufwand und flexibel die Hardwarekomponenten nachzubilden. Alternativ kann der Entwickler aus Leistungsgründen in C++ oder C implementieren. Hiermit sind der Simulation keine Grenzen gesetzt. Ebenso kann der Prüfer komplexe Modelle mit Matlab/Simulink oder einer anderen Modellierungssoftware erstellen. In den meisten Fällen ist jedoch eine komplexe physikalische Simulation nicht nötig, da lediglich ein klarer »Input/Output«-Test auszuführen ist.
Mit dem Einsatz eines PCs als Host-Plattform ist es leicht möglich, PC-Komponenten zu verwenden, um manuelle oder erweiterte automatisierte Tests auszuführen. So kann zum Beispiel die Netzwerkkarte des PCs genutzt werden, um etwa die Server-Kommunikation einer noch nicht fertigen IoT-Hardware oder das Anbinden eines Fernbedienungsmoduls über Bluetooth zu testen. Dank des PCs und seiner vielen Schnittstellen sind die Möglichkeiten nahezu unbegrenzt und es gibt einen kosteneffizienteren Übergangsbereich zu HIL.
Jeder Softwareentwickler kennt das Problem: Er erbt ein historisches Projekt, das durch etliche Programmiererhände und -generationen gegangen ist, nie richtig dokumentiert wurde, bei dem die ursprünglichen Designer schon lange die Firma verlassen haben oder nie ein Softwarearchitekt beteiligt wurde. Es wurden nie Unit-Tests ausgeführt, geschweige denn das Programm so entworfen, dass es überhaupt aus separierbaren Modulen besteht, die der Entwickler testen könnte. Im Falle von meist undokumentiertem und wenig systematisch getestetem Legacy Code kann SIL beim Test der Außenschnittstellen unterstützen. Hiermit können Entwickler Re-Factoring sowie einen systematischen, automatisierten Test vorbereiten.
Software in the Loop ermöglicht die Tests, welche das Entwickeln der Außenschnittstellen des Programms begleiten und Legacy-Code testbar machen – ohne ihn vollständig neu strukturieren zu müssen. Die Tests nutzen Entwickler ihrerseits als Basis für Regressionstests zum Re-Factoring und ziehen das alte Projekt auf eine neue, stabile Architektur um.
Embedded-Systeme sind häufig in einer Echtzeitumgebung mit speziellen Echtzeit-Betriebssystemen eingebunden. Weil das Host-System der Simulation auf einem PC nicht echtzeitfähig ist, lässt sich das exakte Zeitverhalten in der Simulation nicht umsetzen. Normalerweise ist das keine Schwierigkeit, da funktionale Tests keine Zeitabhängigkeit im Blick haben. Dafür sind Leistungs- und Lasttests vorgesehen, die sich in einer simulierten Umgebung nicht mit sinnvollem Aufwand ausführen lassen: Die beim Zusammenspiel der echten Hardware entstehenden Timing-Verhältnisse sind so gut wie nie so real simulierbar, dass der Test gegen die reale Zielhardware ganz ersetzbar ist.
Je nach Komplexität der zu simulierenden Hardware, kann der Aufwand für das erste Erstellen und die Pflege der HS beim Weiterentwickeln der Hardware sehr hoch sein. Gerade in Release-Phasen kann das mit hohem Zeitdruck zu Engpässen führen. Häufig wird übersehen, dass die HS selbst ein Stück Software ist, die ihrerseits zu prüfen ist. Immerhin müssen Entwickler, basierend auf dem Verhalten der HS, Qualitätsaussagen zu der später auszuliefernden Software machen. Selbst wenn sie teilweise vorläufig sind. Fast zwangsläufig durchläuft ein Test-Framework – welcher Art auch immer – eine Phase von »Kinderkrankheiten«, bei denen die gefundenen Fehler zunächst mehrheitlich dem Framework und nicht dem Testobjekt selbst zuzurechnen sind. Und schließlich sind in jedem Falle die anhand der SIL gewonnenen Testergebnisse genau auf ihre Aussagereichweite zu prüfen. Nichtsdestotrotz bietet der SIL-Ansatz bei den eingangs erwähnten Umständen ein praxisbewährtes Verfahren zum Softwaretest, selbst bei noch fehlender Zielhardware.
Der Autor
Andreas Hippelein ist M.Eng in Mechatronik und seit 2019 Systementwickler bei Mixed Mode in Gräfelfing. Zuvor er war er in der Drone Group bei Intel in Forschung und Entwicklung von UAVs tätig sowie für die Automatisierung von Produktionslinientests verantwortlich. Bei Mixed Mode ist er in diversen Projekten als Technical Lead, Softwarearchitekt und Entwickler tätig.
sales@mixed-mode.de