Autonome Fahrzeuge nehmen ihre Umwelt über Sensoren wahr. Um die Funktionen der Fahrzeuge frühzeitig und effizient abzusichern, müssen Umwelt, Sensoren und Fahrzeug realitätsnah simuliert und in virtuellen Fahrversuchen getestet werden. dSPACE bietet hierfür eine abgestimmte Werkzeugkette aus leistungsfähiger Hardware und Software.
Bei autonomen Fahrzeugen geht es mittlerweile nicht mehr um die Frage, ob sie im Straßenverkehr Einzug halten werden, sondern nur noch, wann es soweit sein wird. Serienreife Level-4-Fahrzeuge sind bereits für 2020/21 prognostiziert. Um die gewünschten Ziele zu erreichen, ist es entscheidend, die Fahrfunktionen bereits dann abzusichern, wenn sie sich noch in der Entwicklung befinden. Eine Schlüsselkompetenz ist dabei die Fähigkeit, Fahrfunktionen zusammen mit den Sensoren (Kamera, Lidar, Radar etc.) bereits im Labor in quasi realen Verkehrsszenarien zu simulieren. Denn die Alternative, also ausschließlich reale Fahrtests auf der Straße durchzuführen, ist allein schon deswegen nicht praktikabel, weil viele Millionen Kilometer mit echten Fahrzeugen gefahren werden müssten, um alle erforderlichen Szenarien abzudecken.
Rahmenbedingungen für den Absicherungsprozess
Für den Absicherungsprozess der Funktionen für autonomes Fahren haben sich einige Rahmenbedingungen herauskristallisiert:
- Funktionen für autonomes und hochautomatisiertes Fahren sind äußerst komplex, unter anderem weil dabei Messwerte vieler (teilweise über 40) verschiedener Sensoren (Kamera, Lidar, Radar etc.) gleichzeitig berücksichtigt werden müssen.
- Die Vielfalt der zu testenden Verkehrsszenarien (Fahrzeuge, Fußgänger, Verkehrszeichen etc.) ist nahezu unbegrenzt, das heißt, es sind entsprechend aufwendige virtuelle 3D-Szenen für die Tests notwendig.
- Die physikalischen Vorgänge beim Aussenden bzw. Erfassen von Lichtimpulsen, Mikrowellen etc. sind
in Form rechenintensiver physikalischer Umgebungs- und Sensormodelle einzubinden. Hierbei werden auch Effekte der Materialeigenschaften von Objekten berücksichtigt, zum Beispiel Permittivität und Rauigkeit. - Für eine Testabdeckung gemäß ISO-Norm 26262 („Road vehicles –
Functional safety“) müssen viele Millionen Kilometer abgefahren werden, wobei das Augenmerk insbesondere auf kritischen Fahrsituationen liegt – es müssen also auch die „richtigen“ Kilometer gefahren werden.
dSPACE liefert eine leistungsstarke Werkzeugkette aus Hardware und Software, die alle diese Rahmenbedingungen bei der Sensorsimulation entlang des Entwicklungsprozesses berücksichtigt. Dadurch wird es möglich, frühzeitig Fehler zu identifizieren und den gesamten Testprozess sehr effizient zu gestalten.
Simulation ist obligatorisch
Um die Anforderungen an den Absicherungsprozess zu erfüllen, müssen die Fahrfunktionen auf allen unterschiedlichen Stufen des Entwicklungsprozesses verifiziert und validiert werden. Das gelingt mit einer Simulation besonders effizient. Wegen der hohen Komplexität der Funktionen für autonomes Fahren ist es dabei unverzichtbar, dass die zugehörigen Testfälle über verschiedene Stufen des Entwicklungsprozesses hinweg – von Model-in-the-Loop (MIL) über Software-in-the-Loop (SIL) zu Hardware-in-the-Loop (HIL) – und auch plattformübergreifend vergleichbar und wiederverwendbar sind. Voraussetzung hierfür ist eine durchgängige Werkzeugkette.
Die Werkzeugkette von dSPACE unterstützt die hochgenaue Sensorsimulation durchgängig im gesamten Entwicklungsprozess.
Aufbau einer Simulationsumgebung
Der Aufbau einer Simulation im geschlossenen Regelkreis ist für MIL/SIL und HIL identisch (Abbildung 1). Die Simulation besteht im Wesentlichen aus der Simulation von Fahrzeug, Verkehr und Umwelt sowie einer Sensorsimulation, die über eine Schnittstelle mit dem Device under Test (Steuergerät oder Funktionssoftware für autonomes Fahren) verbunden ist. Darüber hinaus benötigt der Anwender eine Möglichkeit, um zum Beispiel Simulationsmodelle zu konfigurieren, Experimente auszuführen und Szenen zu visualisieren. Dabei spielt auch die Unterstützung gängiger Schnittstellen und Standards wie FMI, XIL-API, OpenDrive, OpenCRG, OpenScenario und Open Sensor Interface eine wichtige Rolle. Denn dann lassen sich beispielsweise auch Daten aus der GIDAS (German In-Depth Accident Study)-Unfalldatenbank oder auch Verkehrssimulationswerkzeuge in Form einer Co-Simulation einbinden.
Simulation von Fahrzeug, Verkehr und Umwelt
Grundlegend für die Simulation von Sensoren ist eine Verkehrssimulation, in der unterschiedliche Verkehrsteilnehmer miteinander interagieren. dSPACE bietet dafür die Toolsuite ASM (Automotive Simulation Models), mit der sich virtuelle Testfahrten in virtuellen Umgebungen definieren lassen. Das Modell ASM Traffic berechnet die Bewegungen der Verkehrsteilnehmer und kann damit beispielsweise Überholmanöver, Fahrspurwechsel, Kreuzungsverkehr etc. simulieren. Bei der Interaktion zwischen dem Fahrzeug und der virtuellen Umwelt spielen Sensormodelle eine entscheidende Rolle.
Aufbau und Funktionsweise von Sensoren
Ziel des Einsatzes von Sensoren ist die Erfassung von Objekten. Bei der Objektidentifikation werden aus den Rohdaten des Sensors zunächst Ziele (Targets) ermittelt. Dies kann beispielsweise eine örtliche Häufung erfasster Reflexionspunkte gleicher Relativgeschwindigkeit sein. Aus der charakteristischen Anordnung der Punkte werden im nächsten Schritt klassifizierte Objekte (Auto, Fußgänger, Verkehrszeichen etc.) bestimmt. Kamera-, Radar- und Lidar-Sensoren sind in ihrem grundsätzlichen Aufbau prinzipiell sehr ähnlich: Sie bestehen im Wesentlichen aus einem Front-end, in dem in der Regel noch eine Datenvorverarbeitung durchgeführt wird. Basierend darauf erzeugt eine Datenverarbeitungseinheit einen Rohdatenstrom und gibt eine Target-Liste aus. Anschließend generiert eine andere Einheit die Objektliste und liefert somit die Positionsdaten. Danach folgen die Applikationslogik und das Netzwerkmanagement.
Integrationsoptionen der Sensoren für die Sensorsimulation
Bei der Integration von Sensoren in die Simulation macht man sich die ähnlichen Aufbauten der verschiedenen Sensorarten zunutze und speist je nach Anforderung geeignet aufbereitete Simulationsdaten an den einzelnen Datenverarbeitungseinheiten ein (Abbildung 4). Die Wahl der Integrationsoption ist davon abhängig, wie vollständig und realitätsnah die Eigenschaften des Sensors in die Simulation eingehen sollen und welcher Teil des Sensors getestet werden soll. Die OTA (Over-the-Air)-Stimulation ist ein Ansatz, um beispielsweise eine Umgebungssimulation in ein kamerabasiertes Steuergerät einzuspeisen (Option 4). Hierbei nimmt der Kamerasensor das Bild eines Monitors auf, auf dem die animierte Umgebungsszenerie dargestellt wird. Dabei kann die gesamte Verarbeitungskette inklusive der Kameralinse und dem Imager-Chip getestet werden.
Digitale Sensordaten (Option 3) können in Sensorrohdaten, also Daten direkt nach der Datenvorverarbeitung (Option 3b), sowie Target-Listen (Option 3a) unterschieden werden. Beim Kamerasensor ist dies zum Beispiel der Bilddatenstrom (Rohdaten) bzw. ein erkanntes Ziel (Target-Liste). Die nächste Stufe sind Objektlisten, in denen klassifizierte Ziele samt Bewegungsdaten enthalten sind (Option 2). Die Restbussimulation wird für sensorunabhängige Tests verwendet (Option 1). Die Simulation mittels Objekt- und Target-Listen sowie Rohdaten stellt sowohl für HIL als auch SIL ein Anwendungsszenario dar. Die OTA-Stimulation und die Restbussimulation sind ausschließlich HIL-Anwendungsfälle.
Physikalische/phänomenologische Modelle
dSPACE hat hochgenaue physikalische Sensor-Umfeldmodelle zur Simulation von Kamera-, Radar- und Lidar-Sensoren entwickelt, die in der Regel Rohdaten bzw. Target-Listen liefern. Sie sind für die Berechnung auf Graphics Processing Units (GPUs) ausgelegt.
Kameramodell
Die Absicherung von kamerabasierten Assistenz- und automatisierten Fahrfunktionen setzt grundsätzlich voraus, dass unterschiedliche Linsentypen sowie optische Effekte wie chromatische Aberration oder Vignettierung auf der Linse mit berücksichtigt werden können. Auch eine unterschiedliche Anzahl von Imager-Chips (Mono-/Stereokamera) oder mehrere Kameras für eine Rundumsicht müssen simulierbar sein. Des Weiteren spielen Sensorcharakteristika hinsichtlich der Farbe (monochromatische Darstellung, Bayer-Pattern, HDR etc.), Pixelfehler oder Rauschen in der Validierung eine wichtige Rolle.
Lidar-Modell
Lidar-Systeme senden Laserimpulse aus und messen das an einem Objekt reflektierte Licht. Aus der Laufzeit kann dann der Abstand des Objektes berechnet werden. Neben dem Abstand wird auch die Intensität des reflektierten Lichts bestimmt, die von der Oberflächenbeschaffenheit des Objektes abhängt. Dieses Messprinzip eröffnet die Möglichkeit, die Umgebung in Form einer Punktwolke zu beschreiben, das heißt, die Daten liegen in Form einer Target-Liste mit den Informationen über Abstand und Intensität vor. Des Weiteren ist es beim Lidar-Verfahren wesentlich, dass die spezifischen Betriebsmodi eines Sensors, unter anderem die Winkelauflösung, für die Lichtwellen konfiguriert werden müssen und dass die in der 3D-Szene verwendeten Objekte auch über Oberflächeneigenschaften wie Reflexionsvermögen verfügen. Berücksichtigt man außerdem, dass das Licht durch Regen, Schnee oder Nebel unterschiedlich gestreut wird und dass ein einzelner Lichtstrahl auch mehrere Objekte treffen kann, so ergibt sich eine Amplitudenverteilung über die Fläche des Sensors, die dann wiederum von der Umgebung (bewegliche Objekte, unbewegliche Objekte etc.) bzw. der Zeit abhängt. Das Lidar-Modell unterstützt Ansätze von Punktwolken bis hin zu Rohdaten.
Radarumfeldmodell
Für ADAS/AD-Fahrfunktionen ist Radar wegen seiner Robustheit gegenüber widrigen Wetterbedingungen wie Regen, Schnee, Nebel oder extremen Lichtverhältnissen von großer Bedeutung. Per Radarsensor lässt sich nicht nur die Art von Objekten, also Fahrzeuge, Fußgänger, Radfahrer etc., sondern auch deren Abstand, Höhen und Horizontalwinkel sowie die Relativ- und Absolutgeschwindigkeit bestimmen. Eines der wohl wichtigsten Radar-Verfahren ist das Frequency-Modulated Continuous Wave (FMCW) Radar (Dauerstrichradar), das frequenzmodulierte Signale verwendet. Heutige Radarsysteme senden etwa 128 frequenzmodulierte Signale innerhalb eines Messzyklus aus. Das vom Objekt reflektierte Signal – auch Echosignal genannt – wird detektiert. Unter Verwendung der Frequenzänderung kann dann mit Hilfe des generierten Signals die Entfernung des Objektes gemessen werden. Die Geschwindigkeit des Objektes lässt sich mit Hilfe der Doppler-Frequenz ermitteln. Das Radarmodell von dSPACE gibt das Verhalten der Sensorstrecke realitätsnah wieder. Bei der Modellierung werden zum Beispiel die Mehrwegausbreitung, Reflexionen und die Streuung berücksichtigt.
Arten der Sensormodellierung
Für jede der verschiedenen Integrationsmöglichkeiten des Sensors muss ein Sensormodell verwendet werden, das geeignet aufbereitete Daten zur Verfügung stellt. Im Wesentlichen lassen sich die Modelle für die Sensorsimulation gemäß der Komplexität und der Realitätsnähe einordnen (Abbildung 3). Zwei Modellarten geben Objekt- oder Target-Listen aus: zum einen Ground-Truth-Modelle, die auf realen Referenzdaten basieren, und zum anderen probabilistische Modelle, die auf der Wahrscheinlichkeit von Ereignissen oder Zuständen basieren. Die Rohdaten werden in der Regel von phänomenologischen Modellen geliefert, also solchen, die auf den Kenngrößen von Ereignissen und Zuständen basieren, oder physikalischen Modellen, das heißt auf Basis von mathematisch formulierten Gesetzmäßigkeiten. Je nach Anwendungsfall und Entwicklungszeitpunkt lassen sich die zu entwickelnden Fahrfunktionen durch geeignete Modelle absichern.
Ground-Truth- und probabilistische Modelle
Das Simulationsmodell ASM Traffic beinhaltet eine große Menge von Sensoren, um auf Objektlistenebene Tests im SIL- oder HIL-Fall durchzuführen:
- Radarsensor 3D
- Objektsensor 2-D/3-D
- Kundenspezifischer Sensor
- Verkehrszeichensensor
- Fahrbahnmarkierungssensor
Diese Sensormodelle sind für die CPU-basierte Simulation mit den Plattformen VEOS oder SCALEXIO ausgelegt. Basierend auf einer Objektliste können probabilistische Modelle realistische Effekte wie Umgebungsbedingungen für Nebel und Regen und auch mehrere Ziele pro erkanntem Objekt überlagern. Damit lassen sich beispielsweise Charakteristika eines Radars emulieren und daraus eine Target-Liste berechnen.
Absicherung per Software-in-the-Loop (SIL)-Simulation
Durch den Einsatz einer Software-in-the-Loop-Simulation lässt sich die Software eines sensorbasierten Steuergerätes virtuell mit Hilfe von Standard-PC-Technologie absichern. Damit können die zu testenden Algorithmen frühzeitig auch ohne Verfügbarkeit von Hardware-Prototypen durchgeführt werden. Zusätzlich erlaubt die Verwendung von VEOS (Abbildung 1) und der entsprechenden Modelle eine Berechnung schneller als in Echtzeit. Nutzt man hierbei zusätzlich die Möglichkeit, die Berechnungen auf skalierbaren PC-Clustern auszuführen, lässt sich die Geschwindigkeit noch weiter steigern. Damit wird es möglich, der erheblichen Vielfalt und Anzahl von Testfällen Herr zu werden und auch solche Tests in überschaubarer Zeit durchzuführen, bei denen Millionen von Testkilometern abgefahren werden müssen.
Bei einer SIL-Simulation werden die Fahrzeug-, die Umgebungs- und die Verkehrssimulation sowie ggf. virtuelle Steuergeräte mit Hilfe von VEOS gerechnet. Im Falle einer Simulation basierend auf Ground-Truth- und probabilistischen Modellen werden auch diese in VEOS integriert. Liegen phänomenologische oder physikalische Sensormodelle vor, so läuft auf der Plattform, auf der VEOS installiert ist, ebenfalls eine Applikation zur Sensorsimulation (Kamera, Radar, Lidar), die auf einer GPU gerechnet wird. Die Bewegungsdaten der Umgebungssimulation werden an die Sensorsimulation übergeben, die dann die Modelle für Radar, Lidar oder Kamera berechnet. Das heißt, aus den Bewegungsdaten und der komplexen 3D-Szene mit einer realistischen Umgebung und komplexen Objekten unter Berücksichtigung der physikalischen Charakteristika der Sensoren werden die Rohdaten simuliert. Diese Berechnung erfolgt auf einem Hochleistungsgrafikprozessor, um beispielsweise die Raytracing-Algorithmen für die Umfeldmodellberechnung von Radar und Lidar zu simulieren. Das Ergebnis dieser Sensorsimulation wird dann den virtuellen sensorbasierten Steuergeräten übermittelt. Dies geschieht über Ethernet oder ein virtuelles Ethernet. Außerdem erfolgt so ein Austausch der virtuellen sensorbasierten Steuergeräte mit der Fahrzeugsimulation.
Absicherung per Hardware-in-the-Loop (HIL)-Simulation
Hardware-in-the-Loop-Simulationen ermöglichen den Test von realen Steuergeräten im Labor, indem diese mit aufgezeichneten Daten oder künstlichen Testdaten stimuliert werden. Hierbei ist es im Gegensatz zur SIL-Simulation möglich, das exakte Zeitverhalten der Steuergeräte zu untersuchen. Die HIL-Plattform dSPACE SCALEXIO führt dabei die Verkehrs-, Fahrdynamik- und Umgebungssimulation aus. Die Fahrzeugsimulation ist dann an das Fahrzeugnetzwerk, beispielsweise über CAN oder Ethernet, zur Ausführung einer Restbussimulation angeschlossen. Die Bewegungsdaten des Fahrzeugs und der anderen Objekte werden via Ethernet an einen leistungsstarken PC mit einem Hochleistungsgrafikprozessor gesendet, auf dem die Sensor-Umfeldmodelle für Kamera, Lidar und Radar berechnet werden. Diese Daten (Rohdaten oder Target-Listen) der verschiedenen Sensoren werden zusammengefasst und via Display-Port an die Environment Sensor Interface (ESI) Unit übertragen. Die ESI Unit ist hoch modular aufgebaut, um alle relevanten Protokolle und Schnittstellen unterstützen zu können. Das Hochleistungs-FPGA der ESI Unit wandelt den Datenstrom sämtlicher Sensoren in einzelne Datenströme für die dedizierten Sensoren um und überträgt sie über die unterschiedlichen Schnittstellen an die entsprechenden Kamera-, Lidar- oder Radar-Steuergeräte.
Die physikalischen Sensormodelle von dSPACE simulieren Rohdaten von Kamera, Lidar und Radar mit höchster Genauigkeit.
Absicherung per Over-the-Air-Stimulation
Die Over-the-Air-Stimulation ist ein klassischer Weg für das Testen von Sensoren. Hier befindet sich das komplette sensorbasierte Steuergerät in der Regelschleife (Abbildung 5). Dieser Aufbau ist ideal dafür geeignet, um das Front-end des Sensors mit zu testen, beispielsweise Linse und Imager-Chip einer Kamera. Bei dieser Methode werden wiederum die Fahrzeug-, die Umgebungs- und die Verkehrssimulation mit SCALEXIO berechnet. Soll ein Kamerasensor getestet werden, so wird mit Hilfe eines SCALEXIO-Simulators und MotionDesk eine Verkehrsszene simuliert und auf einem Bildschirm dargestellt. Für die Kamera entspricht diese vorgespielte Szene dann einer realen Straßenszene. Im Falle eines Radarsensors werden korrespondierend zu dem vom SCALEXIO-Simulator berechneten Fahrszenario mit Hilfe des dSPACE Automotive Radar Test Systems (DARTS) Radarechos zur Verfügung gestellt. Auf diese Weise lassen sich beispielsweise Fahrfunktionen wie ACC (Adaptive Cruise Control) oder AEB (Autonomous Emergency Braking) verifizieren.
Zusammenfassung
Damit sich autonome Fahrzeuge sicher im Straßenverkehr bewegen können, müssen ihre ADAS/AD-Funktionen in allen denkbaren Fahrszenarien die richtige Entscheidung treffen. Weil die Zahl an möglichen Fahrszenarien aber quasi grenzenlos ist, führt dies bei den erforderlichen Tests der ADAS/AD-Funktionen im Labor zu einer extremen Komplexität. Mit nur einer einzigen Testmethode lassen sich diese Tests nicht mehr bewältigen. Stattdessen ist eine Reihe verschiedener Testmethoden notwendig. Das Spektrum umfasst unter anderem MIL-, SIL-, HIL-, Open-Loop-, Closed-Loop-Tests und reale Testfahrten. Aufgrund dieser komplexen Test- und Tool-Landschaft liegt der Schlüssel für einen zuverlässigen Validierungsprozess in einer flexiblen und integrierten Werkzeugkette, die vielseitige Schnittstellen und Integrationsmöglichkeiten für Simulationsmodelle und die zu testenden Geräte bietet. Genau hier setzt die dSPACE Werkzeugkette für Sensor- und Umgebungssimulation an, denn sie bietet aufeinander abgestimmte Tools aus einer Hand, die reibungsfrei miteinander agieren und auf diese Weise den Validierungsprozess sehr effizient gestalten.
dSPACE MAGAZINE, PUBLISHED MAY 2019
