Mittlerweile sind die neuen Generationen von Fahrerassistenzsystemen soweit fortgeschritten, dass der Übergang zum vollautomatisierten, fahrerlosen Fahren keine größere Herausforderung mehr darstellt. Damit autonome Fahrzeuge in Zukunft ebenfalls zu unserem öffentlichen Straßenverkehr gehören, müssen deren sensorgestützte elektronischen Systeme umfassend getestet und abgesichert werden, um Risiken im öffentlichen Verkehr auf ein Minimum zu reduzieren. Dies rückt das Thema Test unter ein besonderes Licht. Hierbei müssen die verschiedensten Soft- und Hardwaresysteme auf unterschiedlichste Weise in kürzester Zeit und im Rahmen eines festgelegten Budgets getestet werden, um Fehler bzw. Schwachstellen des Systems zu finden und zu beseitigen.

Um dennoch Herr dieser Aufgabe zu werden, sind intelligente Teststrategien und Ansätze nötig. Hierbei gilt es, Testmethoden über den gesamten Entwicklungszyklus der eingesetzten Soft- und Hardwaresysteme zu positionieren. Somit würde man das Testen als entwicklungsbegleitend in eine frühe Entwicklungsphase einbinden, anstatt wie gewohnt am Ende der Entwicklung. Jedoch besteht das Problem bei diesem Ansatz darin, dass die verschiedenen Entwicklungsphasen unterschiedliche Testmethoden benötigen. Dadurch besitzt jede Entwicklungsphase eigene Testwerkzeuge mit unterschiedlichen Dateiformaten, die wiederum nur in dieser einen Phase eingesetzt werden können.

Mit dem Beginn einer neuen Phase werden neue Tests mit anderem Werkzeug entwickelt. Die Wiederverwendbarkeit der zurvor entwickelten Testfälle wäre so nicht möglich. Um dennoch die Wiederverwendung von Tests während der unterschiedlichen Entwicklungsphasen zu unterstützen, muss eine Virtualisierung der Testumgebung (Test-Software und -Hardware) mit standardisierten Kommunikationsschnittstellen geschaffen werden. Die Standardisierungsorganisation ASAM (Association for Standardization of Automation and Measuring Systems) verfolgt diese Philosophie mit der XIL API (X-in-the-Loop). Die XIL API sorgt für eine Entkopplung der Testsoftware und -Hardware und ermöglicht über standardisierte Kommunikationsschnittstellen (z.B. der Model Access Port – kurz MA-Port) die Wiederverwendung von Testfällen unterschiedlicher Testsysteme in unterschiedlichen Entwicklungsphasen.

Abbildung 1: XIL Test Systemarchitektur

Mittels testgetriebener Entwicklung kann die XIL API bereits in einer frühen Entwicklungsphase für die Spezifizierung bzw. Auslegung der Systemfunktionen und -Architektur mit dem Model-in-the-Loop (MiL) Ansatz über SiL-Verfahren (Software-in-the-Loop) eingesetzt werden, bevor die eigentliche Serienhardware zum Einsatz kommt. Später lassen sich dieselben SiL-Tests dank der standardisierten Schnittstellen ebenfalls in einer HiL (Hardware-in-the-Loop) Umgebung mit echter Hardware erneut ausführen. Die Standardisierung ist eine Voraussetzung dafür, dass die neuen, komplexeren Systemarchitekturen beherrschbar bleiben. Als komparative Philosophie zur XIL könnte man AUTOSAR nennen. AUTOSAR hat sich inzwischen durchgesetzt und in der Automobilindustrie etabliert, so dass es mittlerweile die Regel ist, Software von neuen ECUs nach dem AUTOSAR-Prinzip zu entwickeln. Auch bei den Testthemen ist es den Entwicklern klar, dass eine Standardisierung der Datenformate und Schnittstellen ein MUSS ist. In diesem Fall würde die XIL API eine Abhilfe schaffen, da der Schwerpunkt von XIL ausschließlich bei den Testthemen liegt.

Auf dem Markt existieren jetzt bereits die ersten XIL-Lösungen. Allerdings, damit diese XIL-Lösungen sich ebenfalls bei den Entwicklern durchsetzen können, muss eine reibungslose Integration in gewohnte Arbeitsabläufe gewährleistet sein. Wenn dies nicht möglich ist, dann wird das Interesse an diesen Lösungen stark nachlassen. Ob die XIL API sich beim Thema Test (wie AUTOSAR in der Softwareentwicklung) etablieren wird, ist abzuwarten, da der XIL-Standard recht jung und noch unbekannt bzw. nicht weit verbreitet ist.

Quelle
Abbildung 1: https://www.asam.net/standards/detail/xil/wiki/