Die Planung eines Hardware in the Loop (HiL)-Testsystems wird in vielen Embedded Projekten zu spät in den Projektalltag integriert. Anforderungen ändern sich ständig und Schnittstellen müssen angepasst werden. Das Testsystem muss alle Schnittstellen und Umgebungsbedingungen des Prüflings bedienen und gleichzeitig die Echtzeitbedingungen einhalten.
In vielen Fällen empfiehlt sich dann ein Middleware-basierter Ansatz, um die Testsysteme einfach, effektiv und schnell ändern zu können, wobei die Echtzeitfähigkeit, Portabilität und Flexibilität eine große Rolle spielen.

Zielpublikum: Testautomatisierungsanwender und -experten, Testmanager, Projektleiter, Entscheidungsträger, Interessierte
Voraussetzungen: Grundlegende Kenntnisse im Bereich Entwicklung von Embedded Systems und Softwaretest
Schwierigkeitsgrad: Advanced

Extended Abstract:
In den letzten Jahren hat der Funktionsumfang von eingebetteten Systemen, speziell auch im Industrie- und Automobilbereich, stark zugenommen. Es wird erwartet, dass dieser Trend sich auch in Zukunft fortsetzt und neben der bloßen Funktionsvielfalt auch die Interaktion mit der Umwelt immer weiter zunimmt. Zum Projektstartzeitpunkt eines Embedded Systems wird dabei häufig das Testen in den Hintergrund gestellt. Im Projektverlauf werden Anforderungen definiert, welche den verschiedenen Stakeholdern gerecht werden sollen. Meist wird dabei jedoch der Tester als Stakeholder vergessen.
In jedem Industriebereich kommt dann schließlich doch der Zeitpunkt, an dem die Frage nach dem Test in den Vordergrund rückt. Welche Tests soll es geben? Wie soll getestet werden? Genügen Modultests oder müssen über den normalen Softwaretests hinaus auch Integrations- oder gar Systemtests durchgeführt werden? Eines trifft aber in allen Varianten zu: Je später das Testteam involviert wird, desto umständlicher und aufwendiger wird das Testen.
Die Anforderungen sind längst fixiert und doch ändern sich diese mit jedem neuen Build. Der Safety- and Security-Beauftragte fordert für die Freigabe jedoch auch noch funktionale Sicherheitstests und das Projektbudget ist begrenzt. Dafür muss nun eine Testumgebung geschaffen werden, um den Prüfling hinreichend testen zu können. Hierzu müssen HiL-System-Hersteller angefragt werden, und diese Testsysteme sollen am besten alle Schnittstellen des Prüflings direkt bedienen können. In der Realität ist dies allerdings ohne weiteres meist nicht out-of-the-box möglich.
Der Einsatz einer Middleware kann hier Abhilfe schaffen, über die zum Beispiel Hardwareschnittstellen verschiedener Hersteller (DIO-/AIO-Karten, FPGA, CAN) aber auch Softwareschnittstellen verschiedener Komponenten / Applikationen (Umgebungsmodell, physikalische Simulation) an die Echtzeitsimulation angebunden werden können.
Im Vordergrund steht jedoch auch die Echtzeitfähigkeit des Testsystems. Immerhin muss sich der Prüfling in seiner simulierten Umgebung wohlfühlen und diese vom Verhalten her hinreichend nahe der realen Umgebung sein. Es gilt auch, die verschiedenen Messzykluszeiten (vom Messsystem, vom DeviceUnderTest (DUT), etc.) auf eine gemeinsame Basis zu bringen.
Verschiedene Hersteller bieten Middleware- oder Hardware Abstraction Layer (HAL)-Lösungen an, welche unterschiedliche Ausrichtungen des Datenflusses wie den Zugriff über eine Cloud bieten. Es stellt sich die Frage: Welche Lösung bietet nun eine Middleware basierter Ansatz für den Embedded-Test?