Zusammenfassung: Software-in-the-Loop (SIL)-Tests in der Automobilindustrie

Software-in-the-Loop (SIL)-Tests sind zu einem festen Bestandteil der Software-Entwicklung in der Automobilindustrie geworden. Gleichzeitig deckt die Abkürzung SIL ein sehr breites Spektrum an Themen ab. Dieser Blog-Artikel beschreibt, was SIL-Simulation bedeutet und welche Anforderungen und Herausforderungen sie mit sich bringt.

Zunächst einmal bedeutet SIL-Testing nichts anderes, als dass Software – egal in welchem Zustand – in einer simulierten Umgebung eingesetzt wird, um sie auf Herz und Nieren zu prüfen, um die Bits und Bytes zu kontrollieren. Und genau hier beginnen die Feinheiten: Das Testen eines Stücks C-Code oder einer einzelnen Software-Funktion erfordert eine andere Testumgebung und andere Testszenarien als ein komplettes Steuergerätenetzwerk. Es ist auch zu unterscheiden zwischen dem Testen der Software mit einer reinen Stimulation der Schnittstellen (open-loop) und der Integration mit beispielsweise einem geschlossenen Streckenmodell (closed-loop).

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

Das zu testende System (SUT) steht im Mittelpunkt eines 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, was zu vielen Vorteilen führt, z. B. geringere Kosten, einfache Skalierbarkeit in der Cloud, etc. Aber können realistische Betriebsbedingungen überhaupt ohne Hardware abgebildet werden?

Im Gegensatz zu Soft-ECUs, die mit vereinfachten Simulink®/Stateflow®-Modellen arbeiten, kommen bei SIL-Tests virtuelle Steuergeräte (V-ECUs) zum Einsatz. Im Allgemeinen kann ein virtuelles Steuergerät jede Art von Steuergeräte-Software sein – von einer einfachen Funktion bis hin zur kompletten, hardwareunabhängigen Software eines Steuergeräts. Der große Unterschied zu einfachen Modellen besteht darin, dass die V-ECUs auf echtem Seriencode basieren. V-ECUs können auch verschiedene Abstraktionsebenen haben, je nachdem, wo sie eingesetzt werden. In der Industrie hat sich zur Charakterisierung die Einteilung in fünf Stufen durchgesetzt, die im Folgenden kurz skizziert werden:

Fünf etablierte Abstraktionslevel für V-ECUs

Level 0

Im einfachsten Fall liegt ein Modell vor, z. B. in MATLAB®/Simulink oder als Functional Mock-up Unit (FMU). Das bedeutet, dass nur Tests des Regelalgorithmus des Steuergeräts möglich sind, da z. B. die Basissoftware oder der Seriencode der Regelanwendung fehlen.

Level 1

In diesem Fall enthält die V-ECU den Original-Seriencode von einzelnen Applikationen bis hin zur gesamten Applikationsschicht eines echten Steuergeräts. Weitere Komponenten, z. B. Funktionen der Basissoftware (BSW), müssen von der Simulationsumgebung bereitgestellt werden oder es muss eine vereinfachte BSW für die Simulation in die V-ECU integriert werden.

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

Level 2

Durch die Erweiterung der V-ECU um Teile der Basissoftware, die zu Simulationszwecken erstellt wird, werden Tests auf Bus- und Netzwerkebene ermöglicht. Der Test zielt weiterhin auf die Funktion der Anwendungssoftware ab, wird aber um Funktionen wie Busüberwachung, Diagnoseschnittstellen oder Restbusmodelle erweitert.

Level 3

Eine Level-3-V-ECU enthält auch den Seriencode der Basissoftware. Sie kann z. B. für den Test der Software-Integration eines Steuergeräts oder auch für den Integrationstest mehrerer Steuergeräte verwendet werden.

Level 4

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

Wie erstelle ich eine V-ECU?

Je nach Projektkontext sind SUT oder V-ECUs bereits vorhanden und müssen nur noch auf der Simulations- und Integrationsplattform ausgeführt oder an diese gekoppelt werden, zum Beispiel als FMU, ROS-Algorithmus oder sogar als V-ECU-Artefakt im dSPACE Format. Dann ist es nicht nötig, eine eigene V-ECU zu erstellen. Steht jedoch nur der Code zur Verfügung, muss dieser mit den Simulatorschnittstellen verknüpft und eventuell um Funktionen für die Simulation ergänzt werden. dSPACE bietet genau hierfür Möglichkeiten – für die V-ECU-Erstellung.

Es gibt verschiedene Optionen, eine V-ECU in der dSPACE Werkzeugkette zu erstellen, abhängig vom Anwendungsbereich, den Projektanforderungen und davon, ob die Entwicklung auf AUTOSAR basiert. 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 ausgewählten Teil der Anwendungsschicht der Steuergeräte-Software besteht. Damit sind grundlegende Funktionstests möglich. Ebenso können mit dem V-ECU SDK C- oder C++-Funktionen direkt aus einer IDE an Schnittstellen des VEOS-Simulators angebunden und dann während der Simulation, ebenfalls in der IDE, gedebugged werden.

Für unser Beispiel, bei dem die Software im Gesamtnetz getestet werden soll, ist dies nicht ausreichend. Wir brauchen eine V-ECU, die so viel wie möglich von der echten ECU enthält. Dazu müssen Software-Komponenten, Funktionen, Basissoftware und Nicht-AUTOSAR-Code aus verschiedenen Quellen kombiniert werden. Dies alles erfolgt zentral mit der SystemDesk-Software. Die so erzeugte Gesamt-V-ECU enthält neben der Anwendungsschicht die Laufzeitumgebung (RTE) und Teile der Basissoftware (Level 2 bis 3). Die Laufzeitumgebung und die Software-Teile sind über SystemDesk mit den VEOS-Schnittstellen verbunden. Mit einer solchen V-ECU sind umfangreiche Tests möglich, zum Beispiel mit Busüberwachung und Diagnoseschnittstellen.

Die Generierung von V-ECUs aus dem Seriencode bestehender Steuergeräte kann bei der Durchführung von SIL-Tests eine Herausforderung darstellen. Wir verfügen über mehrjährige Erfahrung aus vielen Kundenprojekten mit allen Typen von V-ECUs. Um SIL erfolgreich zu implementieren, bieten wir Unterstützung an, wie die V-ECU-Generierung in bestimmten Fällen am besten angegangen werden kann.

Simulationsmodelle für einen geschlossenen Regelkreis

Simulationsmodelle stellen das notwendige Gegenstück zum SUT dar. So werden realistische Eingangsgrößen bereitgestellt und entsprechende Ausgangsgrößen vom SUT sinnvoll verarbeitet, um eine vollständige virtuelle Testfahrt zu ermöglichen. Daraus ergeben sich vielfältige Anforderungen an die Simulationsmodelle – von der Simulation realistischer Fahrzeugdynamik und verschiedener Antriebsstrangvarianten bis hin zu kompletten Verkehrssimulationen mit zahlreichen Teilnehmern und realistischen 3D-Umgebungen mit unterschiedlichen Wetterphänomenen und entsprechenden physikalisch basierten Sensormodellen. Je nach der zu testenden Funktion sind auch unterschiedliche Abstraktionsebenen erforderlich. Beispiele für geeignete Simulationsmodelle mit einer Vielzahl von Details für Fahrzeug- und Antriebsstrangvarianten liefern die dSPACE Automotive Simulation Models (ASM). Mit dSPACE AURELION sind detaillierte 3D-Umgebungs- und Sensormodelle verfügbar. Dadurch können alle Bereiche des Fahrzeugs, insbesondere ADAS/AD-Anwendungen und E-Mobilität, angesprochen und in einem geschlossenen Regelkreis entwickelt und validiert werden.

Ein typisches Beispiel für eine Interaktion des SUT mit dem Streckenmodell ist in Abbildung 3 dargestellt. Neben dem Fahrzeugstatus erwartet das SUT die Daten der Umgebungssensoren und gibt das Ergebnis der Trajektorienplanung an das Aktorsystem zurück. Um das SUT unter realistischen Bedingungen testen zu können, sind also mehrere Steuergeräte beteiligt, die wiederum ihre eigenen Anforderungen an die Fahrzeug- und Umgebungsmodelle haben. Eine besondere Rolle spielt dabei die Sensorsimulation, die von einfachen Objektlisten bis hin zu realistischen Daten wie Lidar-Punktwolken flexibel konfiguriert werden kann.

Jetzt, da das SUT als V-ECU verfügbar ist und die Modelle ausgewählt wurden, bleibt eine wichtige Frage offen: Wie können die verschiedenen Komponenten für eine vollständige Simulation miteinander verbunden werden?

Simulations- und Integrationsplattform

VEOS wird als zentrale Plattform für die Simulation und Integration der verschiedenen Simulationskomponenten eingesetzt. Dort können die V-ECUs und Simulationsmodelle sowie alles andere, was für die Simulation benötigt wird, zusammengeführt werden. VEOS ist nicht auf dSPACE Artefakte und Werkzeuge beschränkt, sondern unterstützt alle relevanten Standards. Wenn eine Integration über Normen nicht möglich ist, kann die Co-Simulation eingesetzt werden. Dies ermöglicht die Integration vielseitiger Komponenten, die von Modellen von Drittanbietern bis hin zu anderer Middleware (ROS usw.), POSIX-basierten Steuergeräten und Level-4-V-ECUs (Befehlssatzsimulation) reichen.

Als zentrale Plattform ist VEOS auch für die Simulation selbst zuständig. VEOS übernimmt die Zeitsynchronisation und die Kommunikation zwischen den verschiedenen Simulationskomponenten. Die Zeitsynchronisation macht die Simulation unabhängig von Echtzeitbedingungen. Die Simulation benötigt daher nicht nur keine Hardware, sondern läuft in vielen Fällen auch schneller als bei HIL. Sie ist deterministisch und daher reproduzierbar – wenn alle angeschlossenen Artefakte dies zulassen. Gleichzeitig ermöglicht die Zeitsynchronisation eine exakte Darstellung der Kommunikation. VEOS ermöglicht sowohl die signalbasierte Kommunikation zwischen den Simulationsteilnehmern als auch den Austausch von Busnachrichten. VEOS simuliert die realen Busse, wobei auch das Zeitverhalten der Buskommunikation berücksichtigt wird. Ähnlich wie bei HIL kann auf die Buskommunikation in VEOS zugegriffen werden, um Busnachrichten zu überwachen und Fehler zu injizieren.

Trotz der zentralen Rolle und des großen Funktionsumfangs ist VEOS eine leichtgewichtige Plattform, die vom Desktop-PC bis zur Cloud skaliert werden kann. Damit sind Tests von einem einzelnen Steuergerät bis hin zu einem virtuellen Fahrzeug möglich.

Sobald ein ausreichender Reifegrad der Software im SIL-Test nachgewiesen wurde, ist der Wechsel zum HIL-Simulator mühelos möglich, da Komponenten und Experimente aus SIL wiederverwendet werden können.

Automatische Validierung

Um den Überblick über umfangreiche Testkampagnen zu behalten, fehlt nur noch eine zentrale Validierungsumgebung. An diese werden hohe Anforderungen gestellt: Zunächst muss die Simulation konfiguriert, gesteuert und später automatisiert werden. Die Tests sollten zentral geplant und durchgeführt werden, wobei verschiedene Testmethoden, z. B. anforderungs- oder szenariobasierte Tests, zu berücksichtigen sind. Dies führt zu einem entscheidenden Vorteil: Die Tests können rund um die Uhr durchgeführt werden und ermöglichen eine standortübergreifende Zusammenarbeit. Gleichzeitig ist eine direkte Rückverfolgbarkeit von Anforderungen, Testfällen und Testberichten möglich, wie von ISO 26262 empfohlen.

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

Beide Lösungen bieten Unterstützung in den drei wesentlichen Phasen, die für erfolgreiches Testen wichtig sind: Die Testerstellung, die Durchführung des erstellten Tests und die Verwaltung aller Artefakte einschließlich der Ergebnisse, die für die Tests relevant sind.

Für die Testerstellung ist es wichtig, dass der Benutzer eine einfache, aber leistungsfähige Schnittstelle für die Konfiguration von Testfällen hat. Dies ist in allen Bereichen möglich, in denen AutomationDesk für typische anforderungsbasierte Tests eingesetzt wird. Für spezielle ADAS/AD-orientierte Tests, z. B. szenariobasierte Tests, bietet SIMPHERA eine intuitive Schnittstelle zur Konfiguration solcher Tests. Die in AutomationDesk erstellten Tests werden dann typischerweise in SYNECT verwaltet, von wo aus sie beispielsweise auch auf global 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 die Zusammenarbeit fördert. Darüber hinaus werden die Ergebnisse mit Hilfe von ALM-Tools (Tools, in denen die Anforderungen an die Software beschrieben und nachvollzogen werden) mit den vom Test abgedeckten Anforderungen verknüpft. Als Cloud-native Lösung bietet SIMPHERA Vorteile bei der skalierten Durchführung von szenariobasierten Tests, die aufgrund einer großen Menge an Parametern und großen Parameterbereichen zu einer enormen Menge an spezifischen Testfällen führen. Die massiv parallele, skalierte Ausführung in der Cloud verkürzt die Zeit für die Erstellung der erforderlichen Testergebnisse erheblich. Auch hier werden die Ergebnisse zentral in einer Datenbank gespeichert und stehen dort für weitere Analysen zur Verfügung.