Die virtuelle Prüfung und Validierung von Radarsensoren

Für zuverlässige automatisierte Fahrfunktionen müssen Sensoren die Fahrzeugumgebung präzise wahrnehmen. In der Realität ist es nur bedingt und unter enormen Aufwand möglich, automatisierte Fahrfunktionen zu entwickeln und zu testen. Der virtuelle Fahrversuch hingegen ermöglicht den Test und die Validierung der Sensorperzeption in nahezu unbegrenzt vielen Szenarien. Dieser Artikel beschreibt den Test von Radarsensoren, die für automatisierte Fahrfunktionen unverzichtbar geworden sind.

Technologie zum Test des Radarsensors

Im Automobilbereich bietet die Radartechnologie Vorteile wie eine sehr gute Mess- und Trennfähigkeit von Relativgeschwindigkeiten. Sie ermöglicht es, die Abstände zu anderen Verkehrsteilnehmern − den Targets − präzise zu bestimmen und ihre Bewegungen nachzuverfolgen. Durch eine realitätsnahe Emulation der Umgebung bildet die Simulation die Grundlage für Test und Validierung des Radarsensors.

Ausschlaggebend ist es dabei, den Sensor an sich sowie die Fahrzeugintegration auf unterschiedlichen Ebenen zu testen. In der Simulation wird die vom Radarsensor wahrgenommene Umgebung in einer Form nachgebildet, die den Test der gesamten Wirkkette ermöglicht und so die Anzahl der nötigen realen Fahrversuche reduziert. Eine dafür geeignete Testmethode stellt die Radar-Target-Simulation dar, deren Umsetzung mithilfe des Radar-Target-Simulators (RTS) auf Basis synthetischer Datenquellen erfolgt. Mit dieser Methode können Radarsensoren in die Validierung mit einbezogen werden, ohne dass dabei ein Eingriff in den hochfrequenten Teil der Radareinheit notwendig ist.

Bild 1 veranschaulicht die typische Prozessierungskette eines Radarsteuergeräts im Automobilbereich. Für die hochfrequente Signalverarbeitung sowie für die Prozessierung verfügt das Steuergerät über verschiedene Komponenten.

Ein Test des Sensors ist auf unterschiedlichen Abstraktionslevels möglich. Für Level 1 ist der RTS notwendig, während Level 2 und 3 auf der Verwendung der Raw-Signal-Injection basieren. Die Umsetzung von Level 4 und 5 erfolgt über die Restbussimulation, also der Emulation auf Basis der Echtzeit-Hardware. Der Fokus dieses Artikels liegt auf Level 1, für den das Radar-in-the-Loop-Interface entwickelt wurde.

Basierend auf den Sensormodellen der Simulationsplattform CarMaker von IPG Automotive erfolgt die Sensoremulation auf der Autonomous-Drive-Emulation-Architektur (ADE) von Keysight Technologies. Ausgeführt wird sie auf der Echtzeit-Hardware-Plattform Xpack4, die Kameraemulation wiederum erfolgt mithilfe der Video Interface Box X. Zusätzliche Eingangssignale werden für bestimmte Fahrzeugregler benötigt, etwa Geschwindigkeit, Nicken oder Gieren. Die Echtzeithardware überträgt dafür die Aktuatorsignale an die entsprechenden Subsysteme im Fahrzeugmodell, wobei sämtliche notwendigen Technologien wie FlexRay, CAN-FD oder SOME/IP unterstützt werden.

Der Radarsensor wird dabei als Blackbox betrachtet. Es werden also keine Annahmen im Hinblick auf das Steuergerät vorausgesetzt, die in der Modellierung zu einer Verfälschung führen könnten. Da keine Schnittstelle im Steuergerät notwendig ist, ist die Integration der Sensoren in das Testsystem verhältnismäßig einfach umzusetzen. Durch eine direkte Verknüpfung der Keysight-Hardware mit der Umfeldsimulation CarMaker ist eine Darstellung beliebig vieler Targets und Objekte erzielbar, ohne auf einen mechanischen Ansatz zurückgreifen zu müssen.

Die Entwicklung des Radar-in-the-Loop-Interface erfolgte mit dem Ziel, dem RTS aufbereitete Zieldaten mit mehreren Antennenelementen bereitzustellen. Die Generierung dieser Daten erfolgt entweder auf Basis eines virtuellen Objektsensors oder eines Raytracing-basierten Radarsensormodells, das von CarMaker bereitgestellt wird. Das Radar-in-the-Loop-Interface stellt die Auswahl, Verteilung und Übertragung von Zieldaten in einem segmentbasierten Format dar (Bild 2). Die Anzahl und Winkel der Segmente lassen sich gemeinsam mit der Zielauswahl und weiteren radarspezifischen Variablen parametrieren.

Die Komponenten einer RTS-Testumgebung sind in Bild 3 dargestellt. Die Hauptsimulation seitens CarMaker läuft auf einem Echtzeitsystem. Dieses System garantiert eine konstante Zykluszeit und stellt die Hardware für die RUT-Restbussimulation bereit, die für Closed-Loop-Anwendungen benötigt wird.

Die Bedienung der Simulation und die Erstellung der Testszenarien erfolgen über die CarMaker/HIL-GUI auf einem Front-End-PC. Ein GPU-Sensorframework ermöglicht die Nutzung der Rechenleistung für komplexe Radarsensorberechnungen. Die vom Radar-in-the-Loop-Interface verarbeiteten Zieldaten werden durch UDP/IP-Pakete über eine Gigabit-Ethernet-Verbindung an den RTS übertragen.

Einen geeigneten Ausgangspunkt für eine reproduzierbare und verständliche Simulation stellen objektbasierte Zieldaten dar, die durch den CarMaker-Objektsensor Ground Truth generiert werden. Die Aufgabe des Objektsensors ist, Objekte im Sensor-Sichtfeld zu detektieren und als Objektliste bereitzustellen. Mit diesem Ansatz wird ein Ziel pro Verkehrsobjekt generiert. Alle detektierten Objekte verfügen über die Attribute Reichweite (R), Geschwindigkeit (v), Azimutwinkel (j) und Elevation (θ) – entweder am Referenzpunkt oder am nächstgelegenen Punkt der Verkehrsobjekte.

Das Sensormodell Raw Signal Interface (RSI) generiert die auf Raytracing basierenden Zieldaten. Raytracing ermöglicht die Simulation der polarimetrischen Ausbreitung der elektromagnetischen Welle. Die Parametrisierung des RSI-Sensormodells erfolgt auf Basis der gleichen Randbedingungen wie beim Radar under Test (RUT). Ergänzend erfolgt entsprechend der RUT-Spezifikation die Parametrierung von Sendeleistung, Mittenfrequenz, Antennencharakteristiken sowie Auflösung und Genauigkeit in Bezug auf Reichweite, Geschwindigkeit und Winkel des Radarmodells. Als Ausgabe stellt das RSI-Sensormodell eine Radarpunktwolke mit den Attributen Reichweite (R), Geschwindigkeit (v), Azimutwinkel (j) und Empfangsleistung (P)/RCS bereit. Auf die Punktwolke wird ein adaptiver Segmentierungs- und Clustering-Algorithmus angewendet, mit dem die Ziele auf Basis der Segmente, in denen sie sich befinden, sortiert werden. Die Segmentanzahl lässt sich frei parametrieren, wenn der RTS den Ankunftswinkel (Angle of Arrival, AoA) durch Manipulation der Phase des IF-Signals simuliert, oder sie ergibt sich aus der Anzahl der auf der RTS-Hardware vorhandenen Front-Ends.

Jedes Segment deckt einen Bereich von Azimutwinkeln innerhalb des Field of View (FoV) des Radars ab. Auf der Grundlage der Azimutwinkel erfolgt die Identifizierung der Segmente, zu denen die Ziele gehören. Sobald in einer Stichprobe die Zielanzahl pro Segment das parametrisierte Maximum überschreitet, werden nur die Ziele mit signifikanter Radar Cross Section (RCS) ausgewählt. Nach erfolgter segmentweiser Sortierung der Ziele werden sie zu Clustern zusammengefasst. Anschließend erfolgt eine Aufzeichnung der Ziele mit der größten oder durchschnittlichen Leistung in jedem Cluster, gefolgt von einer Übertragung an den RTS. Dieser erzeugt dann das Radar-Echo auf der Grundlage der Radar-Signatur des virtuellen Ziels.

Um die Beispiele im Versuchslabor nachzubilden, müssen OEMs die Ausgabe der Simulation in reale Signale umsetzen, um die Radarmodule zu stimulieren. Die folgenden Konzepte erklären, wie sich die Szenen für Labortests nachbilden lassen.

3D-Laserscanner, Lidar- und Radartechnologien erzeugen häufig Punktwolken und Referenzpunkte. Punktwolken beschreiben einen Datensatz von Punkten, die Objekte oder Objektgruppen abbilden. Die Punkte, als Koordinaten der x-, y- und z-Achse dargestellt, ermöglichen die Zusammenfassung zahlreicher räumlicher Informationen in einem Datensatz. Punktwolken fügen der Szene Details hinzu und gewährleisten, dass der zu testende Algorithmus zwischen zwei nahe beieinanderliegenden Objekten unterscheiden kann. Während ein herkömmlicher RTS eine einzige Reflexion unabhängig von der Entfernung liefert, erhöht die Radarszenenemulation die Anzahl der Reflexionen, wenn die Entfernung zum Ziel abnimmt. Diese Art der dynamischen Auflösung variiert die Anzahl der Punkte, die ein Objekt darstellen, in Abhängigkeit von der Entfernung.

Um die Punktwolken anzuzeigen, muss das Setup zwei Hardware-Aspekte erfüllen: Die für die Darstellung erforderlichen Informationen müssen aus dem Szenariosimulator extrahiert werden, etwa mithilfe von Raytracing. Darüber hinaus muss der Radarszenenemulator eine solche Punktwolke darstellen können. Dazu wird eine Rixelmatrix erstellt, die eine ausreichend hohe Auflösung bietet. Jedes Rixel emuliert individuell den radialen Abstand, die radiale Geschwindigkeit (Doppler) und die Signalamplitude. Rixel sind RF-Transceiver, die klein genug sind, um in eine chipgroße Einheit zu passen. Jedes Rixel ist vergleichbar mit einem Pixel auf einem Fernsehbildschirm. Wenn acht von ihnen auf einer Platine platziert sind und mehrere Platinen nebeneinander gestapelt werden, entsteht durch die Matrix der Rixel eine hochauflösende Wand. Dies ist vergleichbar mit einem Bildschirm, dessen Pixel unterschiedliche Farben und Helligkeiten darstellen − nach einem vergleichbaren Prinzip visualisieren die Rixel Entfernung, Geschwindigkeit und Objektgröße.

Raytracing extrahiert die erforderlichen Informationen für Sensoren während des Tests. Das Konzept geht zurück auf die Computergrafik und die Möglichkeit, digitale 3D-Objekte auf 2D-Bildschirmen darzustellen, indem das physikalische Verhalten von Licht simuliert wird. Durch die Einbindung von Objekten in ein Stimulus-Response-System werden sie sichtbar. In dem Diagramm beleuchtet die Lichtquelle das Objekt, wobei die Lichtstrahlen in mehrere Richtungen reflektiert und gestreut werden. Lediglich die Strahlen, die im Blickfeld des Benutzers zusammenlaufen, werden auf der Betrachtungsebene abgebildet.

Obwohl sich dieses Prinzip auf das sichtbare Lichtspektrum bezieht, ist es für jeden auf LOS-Strahlung basierenden Stimulus-Response-Rendering-Algorithmus gültig – etwa für die Radarvision. Die Lichtquelle bildet der Radarsender und die relevanten Materialeigenschaften betreffen das Reflexionsvermögen der Radarstrahlung. Allerdings müssen auch radarspezifische Parameter extrahiert werden. Zum einen ist dies die radiale Geschwindigkeit, die der Radarsensor über den Doppler-Effekt erkennen kann, als auch die Entfernung zwischen Radar und Objekt. Dies gilt auch für reflektierte Strahlen (Multipath-Propagation).

Um die mithilfe von Raytracing gewonnenen Informationen in eine für den Radarsensor verständliche Form zu übersetzen, wurde jedes Fahrzeug als Objekt erstellt und in der Simulation eine Richtung und Geschwindigkeit zugewiesen. Das RSE-Testarray enthält eine Wand aus RF-Frontends oder Rixels, die das mit den Parametern modulierte Signal zurücksenden. Diese werden vom System under Test benötigt, um Szenenelemente zu erkennen. Ein Array aus 64 × 8 Rixels erzeugt eine dynamische Radarumgebung, die mehr Fälle in kürzerer Zeit abdeckt als Systeme, die auf mechanisch bewegliche Teile angewiesen sind. Darüber hinaus ist es stabiler, vorhersehbarer, wiederholbarer und zuverlässiger.