Software testen mit SIL

Hand in Hand zu einem besseren Ergebnis

2. September 2020, 13:30 Uhr | Von Andreas Hippelein
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Das SIL-Framework »eSIL«

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.

passend zum Thema

Softwarearchitektur des „eSIL Software in the Loop Frameworks“ von Mixed Mode
Bild 3. Softwarearchitektur des »eSIL Software in the Loop Frameworks« von Mixed Mode.
© Andreas Hippelein

Vorteile des Einsatzes von SIL

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.

Grenzen des Einsatzes von SIL

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.

Andreas-Hippelein von Mixed-Mode
Andreas-Hippelein von Mixed-Mode.
© Mixed-Mode

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

 


  1. Hand in Hand zu einem besseren Ergebnis
  2. Das SIL-Framework »eSIL«

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Mixed Mode GmbH

Weitere Artikel zu Industrie-Computer / Embedded PC

Weitere Artikel zu Rechnergestützte Messtechnik