Software-in-the-Loop (SIL) Testing ist aus der Entwicklung nicht mehr wegzudenken. Gleichzeitig umfasst die kleine Abkürzung SIL ein sehr weites Themengebiet. Dieser Blogartikel beschreibt, was SIL-Simulation bedeutet und welche Voraussetzungen und Anforderungen dazugehören.

Software-in-the-Loop Testing bedeutet zunächst einmal nichts anderes, als dass Software – egal in welchem Zustand – in einer simulierten Umgebung zum Einsatz kommt, um sie auf Herz und Nieren, d. h. Bits und Bytes, zu testen. Und genau da fangen schon die Feinheiten an: Ein Stück C-Code oder eine einzelne Software-Funktion zu testen, erfordert eine andere Testumgebung und andere Testszenarien als ein komplettes Steuergeräte-Netzwerk. Auch muss man unterscheiden zwischen dem Testen der Software mit einer reinen Stimulation der Schnittstellen (open-loop) und der Integration mit zum Beispiel einem Streckenmodell im geschlossenen Regelkreis (closed-loop).

Allgemeiner Aufbau einer SIL-Umgebung

Unabhängig vom Einsatzszenario besteht eine SIL-Testumgebung aus vier Elementen, und zwar

• der zu testenden Software, d. h. dem System-under-Test (SuT),
• den Simulationsmodellen für die Umgebungssimulation,
• der Simulations- und Integrationsplattform, also dem System, auf dem das System under Test und die Simulationsmodelle zusammengebracht und ausgeführt werden,
• der Validationsumgebung, also der Steuerungs-, Konfigurations-, Auswerte- und Bediensoftware.

Der Umfang und die Anforderungen an diese vier Elemente sind abhängig von der zu testenden Software. Die folgenden Abschnitte verdeutlichen dies am Beispiel einer neu entwickelten Software-Funktion für ein Fahrerassistenzsystem, die im Gesamtverbund getestet werden soll. Bevor es damit losgeht, müssen aber zwei grundlegende Fragen geklärt werden: Wie bekomme ich meine Software überhaupt in die virtuelle Welt und welche Umgebungsmodelle benötige ich als Gegenspieler dafür?

System under Test – Von der Software zum virtuellen Steuergerät

Das System under Test (SuT) steht im Mittelpunkt jeden Tests, denn es ist genau die Software, die sich später auf einem Steuergerät im realen Einsatz bewähren muss. Die SIL-Tests laufen komplett ohne Steuergeräte-Hardware ab, wodurch sich viele Vorteile ergeben, zum Beispiel geringere Kosten, einfache Skalierbarkeit in der Cloud etc. Aber können realistische Einsatzbedingungen ohne Hardware überhaupt dargestellt werden?

Im Gegensatz zu Soft-ECUs, die mit vereinfachten Simulink®/Stateflow®-Modellen arbeiten, werden dazu beim SIL-Testing „virtuelle Steuergeräte“ (V-ECUs) genutzt. Ganz allgemein kann ein virtuelles Steuergerät jede Steuergeräte-Software sein – von einer einfachen Funktion bis hin zu der kompletten hardwareunabhängigen Software eines Steuergeräts. Der große Unterschied zu einfachen Modellen besteht darin, dass V-ECUs auf dem realen Seriencode basieren. V-ECUs können zudem unterschiedliche Abstraktionsebenen besitzen, je nachdem, wo sie zum Einsatz kommen. In der Industrie hat sich zur Charakterisierung die Einteilung in fünf Level etabliert, die im Folgenden kurz skizziert werden:

Fünf etablierte Abstraktionsebenen für V-ECUs

Level 0

Im einfachsten Fall liegt ein Modell vor, zum Beispiel in MATLAB/Simulink oder als Functional Mock-up Unit (FMU). Damit sind nur Tests des Regelalgorithmus des Steuergeräts möglich, da zum Beispiel die Basis-Software oder der Seriencode der Regelapplikation fehlen.

Level 1

In diesem Fall enthält die V-ECU den Original-Seriencode von einzelnen Applikationen bis hin zu der ganzen Applikationsschicht einer echten ECU. Weitere Komponenten wie Funktionen der Basis-Software (BSW) müssen durch die Simulationsumgebung bereitgestellt werden bzw. vereinfachte BSW für die Simulation in die V-ECU integriert werden.

Level-1-V-ECUs arbeiten auf Signalebene und ermöglichen zum Beispiel den Test von Funktionen, die auf verschiedene Komponenten verteilt sind.

Level 2

Durch Erweiterung der V-ECU um Teile der Basis-Software, die zum Zweck der Simulation erstellt wird, werden Tests aufs Bus- und Netzwerkebene ermöglicht. Der Test zielt immer noch auf die Funktion der Applikationssoftware ab, wird allerdings um Funktionen wie Bus Monitoring, Diagnoseschnittstellen oder Restbusmodelle erweitert.

Level 3

Eine Level-3-V-ECU enthält auch Seriencode der Basis-Software. Sie kann zum Beispiel zum Test der Software-Integration einer ECU oder auch zum Verbundtest mehrerer ECUs genutzt werden.

Level 4

Wenn der Seriencode für die Steuergeräte-Hardware kompiliert wurde oder Hardware-Abhängigkeiten enthält, ist die Integration einer Instruction Set Simulation notwendig.

Wie erstelle ich eine V-ECU?

Je nach Projektkontext liegen SUTs bzw. V-ECUs schon vor und müssen nur auf der Simulations- und Integrationsplattform ausgeführt oder an sie gekoppelt werden, zum Beispiel als FMU, ROS-Algorithmus oder auch als V-ECU-Artefakt im dSPACE Format. Dann muss keine eigene V-ECU erstellt werden. Liegt aber nur der Code vor, muss dieser an die Simulatorschnittstellen angebunden und evtl. um Funktionen für die Simulation ergänzt werden. dSPACE bietet Möglichkeiten, genau das zu tun, hier sprechen wir von V-ECU-Erstellung.

Abhängig von Einsatzbereich, Projektanforderungen und davon, ob die Entwicklung auf AUTOSAR basiert, gibt es verschiedene Möglichkeiten, eine V-ECU in der dSPACE Toolkette zu erstellen. Funktions- und Software-Entwickler, die nur mit Einzelkomponenten arbeiten, können eine V-ECU direkt mit Simulink oder TargetLink erstellen. Das Ergebnis ist eine einfache V-ECU (Level 1), die nur aus einem bestimmten Teil der Applikationsschicht der Steuergeräte-Software besteht. Damit sind grundlegende Funktionstests möglich. Ähnlich können mit dem V-ECU-SDK C- oder C++-Funktionen direkt aus einer IDE heraus an Schnittstellen des Simulators VEOS angebunden und dann während der Simulation auch in der IDE debuggt werden.

Für unser Beispiel, in dem die Software im Gesamtverbund getestet werden soll, reicht das nicht aus. Hierfür brauchen wir eine V-ECU, die möglichst viel der realen ECU enthält. Dafür müssen Software-Komponenten, Funktionen, Basis-Software und nicht-AUTOSAR-Code aus unterschiedlichen Quellen kombiniert werden. Dies geschieht alles zentral mit der Software SystemDesk. Die so erzeugte Gesamt-V-ECU enthält neben der Applikationsschicht die Laufzeitumgebung (RTE) und Teile der Basis-Software (Level 2 bis 3). Diese werden von SystemDesk an VEOS-Schnittstellen angebunden. Mit einer solchen V-ECU sind umfangreiche Tests möglich, die zum Beispiel auch Bus Monitoring und Diagnoseschnittstellen einschließen.

Die Erzeugung von V-ECUs aus Seriencode für Bestands-ECUs kann bei der Einführung von SIL Testing eine Herausforderung sein. Wir haben mehrere Jahre Erfahrung aus vielen Kundenprojekten mit allen Arten von V-ECUs. Um SIL erfolgreich einzuführen, bieten wir Unterstützung darin, wie an die V-ECU-Erzeugung in konkreten Fällen am besten herangegangen werden kann.

Simulationsmodelle für eine geschlossene Schleife

Simulationsmodelle stellen den notwendigen Gegenpart zum SUT dar. So werden sowohl realistische Eingangsgrößen zur Verfügung gestellt, als auch entsprechende Ausgangsgrößen vom SUT sinnvoll verarbeitet, um eine gesamte virtuelle Testfahrt zu ermöglichen. Daraus ergeben sich vielfältige Anforderungen an die Simulationsmodelle – von der Abbildung einer realistischen Fahrdynamik und unterschiedlichen Antriebsstrangvarianten über komplette Verkehrssimulationen mit zahlreichen Teilnehmern bis hin zu realistischen 3D-Umgebungen mit verschiedenen Wetterphänomenen und entsprechenden physikbasierten Sensormodellen. Je nachdem, was für eine Funktion getestet werden soll, sind zudem unterschiedliche Abstraktionsgrade gefordert. Beispiele für passende Simulationsmodelle mannigfaltiger Detaillierung für Fahrzeug- und Antriebsstrangvarianten sind bei den dSPACE Automotive Simulation Models (ASM) zu finden. Mit dSPACE AURELION liegen detaillierte 3D-Umgebungs- und Sensormodelle vor. So können sämtliche automotiven Domänen, insbesondere ADAS/AD-Anwendungen und E-Mobilität, adressiert und in einer geschlossenen Schleife entwickelt und abgesichert werden.

Ein typisches Beispiel für eine Interaktion des SuTs mit dem Streckenmodell ist in Abbildung 3 dargestellt. Das SuT erwartet neben dem Fahrzeugzustand die Daten der Umfeldsensorik und spielt das Ergebnis der Trajektorienplanung an die Aktorik zurück. Um das SuT unter realistischen Bedingungen testen zu können, sind also mehrere Steuergeräte beteiligt, die wiederum ihre eigenen Ansprüche an die Fahrzeug- und Umweltmodelle stellen. Die Sensorsimulation spielt eine besonders wichtige Rolle in diesem Zusammenhang und kann von einfachen Objektlisten bis hin zu realistischen Daten wie Lidar-Punktewolken flexibel konfiguriert werden.

Nachdem nun das SuT als V-ECU vorliegt und die Modelle ausgewählt wurden, bleibt noch eine zentrale Frage offen: Wie lassen sich die unterschiedlichen Komponenten miteinander zur Gesamtsimulation verbinden?

Simulations- und Integrationsplattform

Zur Integration und Simulation der verschiedenen Simulationsbestandteile wird VEOS als zentrale Plattform genutzt. Dort können die V-ECUs und Simulationsmodelle sowie alles Weitere, was zur Simulation benötigt wird, zusammengeführt werden. Dabei beschränkt sich VEOS nicht nur auf dSPACE Artefakte und Tools, sondern unterstützt alle relevanten Standards. Ist eine Integration über Standards nicht möglich, kann eine Co-Simulation verwendet werden. So können vielseitige Komponenten von 3rd-Party-Modellen über andere Middlewares (ROS etc.) und POSIX-basierte Steuergeräte bis hin zu Level-4-V-ECUs (Instruction Set Simulation) integriert werden.

Als zentrale Plattform ist VEOS auch für die Simulation selbst verantwortlich. VEOS übernimmt die Zeitsynchronisierung und Kommunikation zwischen den verschiedenen Simulationsbestandteilen. Die Zeitsynchronisierung macht die Simulation von Echtzeitbedingungen unabhängig. Die Simulation kommt daher nicht nur ohne Hardware aus, sondern läuft in vielen Fällen auch schneller als am HIL. Dabei ist sie – wenn das alle angebundenen Artefakte ermöglichen – deterministisch und dadurch reproduzierbar. Gleichzeitig ermöglicht die Zeitsynchronisierung eine exakte Darstellung der Kommunikation. VEOS ermöglicht sowohl signalbasierte Kommunikation zwischen den Simulationsteilnehmern also auch den Austausch von Busnachrichten. Dabei simuliert VEOS die realen Busse, indem auch das Zeitverhalten der Buskommunikation berücksichtigt wird. Ähnlich wie am HIL kann auch auf die Buskommunikation in VEOS zum Beobachten der Busnachrichten und zur Fehlereinspeisung zugegriffen werden.

Trotz der zentralen Rolle und des großen Funktionsumfangs ist VEOS eine leichtgewichtige Plattform, die sich vom Desktop-PC bis zur Cloud skalieren lässt. Somit sind Tests vom einzelnen Steuergerät bis hin zum virtuellen Fahrzeug möglich.

Nachdem im SIL Testing ein ausreichender Reifegrad der Software nachgewiesen wurde, erfolgt der Wechsel auf den HIL-Simulator mühelos, da sich alle Komponenten und Experimente aus dem SIL wiederverwenden lassen.

Automatische Absicherung

Um bei umfangreichen Testkampagnen den Überblick zu behalten, fehlt nur noch eine zentrale Validierungsumgebung. An diese werden hohe Ansprüche gestellt: Zunächst muss die Simulation konfiguriert, gesteuert und später automatisiert werden. Die Tests sollen zentral geplant und durchgeführt werden und dabei verschiedene Testmethodiken berücksichtigen, zum Beispiel anforderungs-  oder szenariobasiertes Testen. Daraus resultiert ein entscheidender Vorteil: Tests können 24/7 durchgeführt werden und erlauben eine standortübergreifende Zusammenarbeit. Ebenfalls ist eine direkte Rückverfolgbarkeit von Anforderungen, Testfällen und Testberichten, wie von ISO 26262 empfohlen, möglich.

dSPACE bietet mit dem Test Solution Package (AutomationDesk in Verbindung mit SYNECT) und SIMPHERA zwei Lösungen an, die zwei unterschiedliche Anwendungsschwerpunkte adressieren und sich beide nahtlos in die Werkzeugkette einfügen.

Beide Lösungen bieten Unterstützung bei den drei wesentlichen Teilschritten, die für erfolgreiches Testen wichtig sind: Die Testerstellung, die Ausführung der erstellen Tests und das Management aller für die Tests relevanten Artefakte inklusive der Ergebnisse.

Für die Testerstellung ist für den Nutzer eine einfache, aber dennoch mächtige Oberfläche zur Konfiguration der Testfälle wichtig. Dies ist mit AutomationDesk für typische requirements-basierte Tests in allen Domänen möglich. Für spezielle ADAS/AD-orientierte Tests wie szenariobasiertes Testen bietet SIMPHERA eine intuitive Oberfläche zur Konfiguration solcher Tests an. Die in AutomationDesk erstellten Tests werden dann typischerweise in SYNECT gemanaged, von wo aus sie auch beispielsweise auf weltweit verteilten HIL-Plattformen zur Ausführung gebracht werden können. Die Ergebnisse werden in einer zentralen Datenbank gespeichert und sind somit zentral verfügbar, was Kollaboration fördert. Außerdem werden die Ergebnisse auch mit Hilfe sogenannter ALM-Tools (Tools, in denen Anforderungen an die Software beschrieben und nachvollzogen werden) mit den vom Test abgedeckten Anforderungen in Verbindung gebracht. SIMPHERA bietet als cloud-native Lösung Vorteile beim skalierten Ausführen von szenariobasierten Tests, die durch eine große Menge an Parametern und großen Parameterbereichen zu einer enormen Menge an konkreten Testfällen führen. Die skalierte Ausführung in massiv paralleler Form in der Cloud reduziert hier die Zeit enorm, die benötigt wird, um die nötigen Testergebnisse zu erzeugen. Auch hier werden die Ergebnisse zentral in einer Datenbank gespeichert, wo sie für weitere Analysen zur Verfügung stehen.