Schnellere Tests von Radar- und anderen Sensoren für ADAS

ADAS benötigt Sensoren, um die Umgebung eines Autos und die aktuelle Fahrsituation wahrzunehmen und die richtigen Entscheidungen zu treffen. Heute kommen softwarebasierte Simulationssysteme zum Einsatz, um ADAS-Funktionen zu entwickeln und zu testen. Herkömmliche Tests auf Integrations- und Systemebene können jedoch nicht den ordnungsgemäßen Betrieb von ADAS unter realen Bedingungen sicherstellen. Darüber hinaus werden diese Tests in der Regel erst spät im Entwicklungsprozess durchgeführt, was Design-Änderungen kostspielig und zeitaufwendig macht und den Produktionsstart (Start of Production, SOP) verzögert.

Um das angestrebte SOP-Datum einhalten zu können, müssen Entwickler bereits zu Beginn des Entwicklungsprozesses übergeordnete Szenarien testen. Die detaillierte Emulation realer Bedingungen ermöglicht eine gründliche Fehlersuche und -behebung für komplette Subsysteme, lange bevor die Fahrzeuge auf die Straße gehen.

Das Ziel von ADAS ist es, den Fahrer nicht nur zu unterstützen, sondern letztendlich vollautomatisiertes oder autonomes Fahren zu ermöglichen. Die Society of Automotive Engineers (SAE) hat in der SAE J3016 (gilt als weltweit führend im technischen Lernen für die Mobilitätsindustrie) fünf Level der Fahrautomatisierung definiert. Bild 1 gibt einen kurzen Überblick über die fünf Level der Fahrautomatisierung von SAE International (Society of Automotive Engineers).

Ein adaptives Abstandsregelsystem wird als Level-1-Betrieb angesehen, und das Autopilot-System von Tesla wird als Level-2-Betrieb angesehen. Mercedes hat gerade angekündigt, dass sie ihre kürzlich erschienene S-Klasse 2021 unter bestimmten Bedingungen mit einer Version von AUTOPILOT für einen Level-3-Betrieb ausstatten werden.

Tabelle 1: Bei höheren Levels werden auch mehr Sensoren benötigt. (Quelle: Keysight)

Tabelle 1 gibt die Anzahl der Sensoren an, die für die Umsetzung jedes Levels der Fahrautomatisierung erforderlich sind. Da die Entwicklung noch im Gange ist, enthalten die Levels 4 und 5 Schätzungen. Es ist offensichtlich, dass mit steigender Automatisierung immer mehr Sensoren notwendig sind, insbesondere Radar-Sensoren.

Die American Automobile Association (AAA) testete die Leistung von verfügbaren ADAS für fünf verschiedene Autos unterschiedlicher Marken. Die Testergebnisse waren eher ernüchternd, wenn man die Hauptaussagen betrachtet:

• Bei Bewertungen auf kontrollierten, abgesperrten Strecken entspricht das ADAS-System des jeweiligen Testfahrzeugs in der Regel den Vorgaben der Gebrauchsanweisung.
• Während einer Testfahrt über rund 6500 km auf öffentlichen Straßen, die hauptsächlich Autobahnen umfassten, wurden 521 Ereignisse registriert, bei denen der Fahrer eingreifen musste. Das entspricht ungefähr einem Ereignis alle 12 km. Besonders bemerkenswert ist, dass 73 Prozent der Ereignisse mit der Spurhaltefunktion des Systems zusammenhingen.

Zusammengefasst kam die AAA zu dem Schluss, dass ADAS mehr stört als hilft. Dieses ziemlich harte Urteil übergeht die Testergebnisse, die zeigen, dass ADAS in der kontrollierten Umgebung wie erwartet funktioniert hat. Die Ergebnisse der AAA-Testfahrt zeigen aber auch, wie schwierig es ist, ADAS für all die verschiedenen Fahrszenarien zu testen, denen man auf öffentlichen Straßen begegnen kann.

Dies weist auf einige zentrale Herausforderungen hin, denen sich die Entwickler bei der Validierung ihrer ADAS-Designs gegenübersehen:

• Es ist schwierig, eine ausreichend hohe Testabdeckung zu erreichen, die die scheinbar unüberschaubare Anzahl möglicher Szenarien in der realen Welt vollständig abdeckt.
• Das Einrichten eines vollständig autonomen Betriebs (Level 5) wird in Zukunft eine deutlich höhere Anzahl von On-Board-Sensoren erfordern. Folglich wird die Verifikation von vollständig autonomen Systemen immer kompliziertere Testaufbauten erfordern.

Um diese Herausforderungen anzugehen, lohnt sich ein genauerer Blick auf den Entwicklungszyklus im Automotive-Bereich mit Schwerpunkt auf der Verifikation. Das Diagramm in Bild 2 stammt aus dem ISO 26262 Framework. Es wird als V-Modell bezeichnet und stellt einen Entwicklungszyklus dar, der sich auf die Gewährleistung der funktionalen Sicherheit konzentriert.

Oben links beginnt das Modell mit der Definition des Gesamtsystems und bewegt sich dann abwärts durch das Design auf System- und Komponentenebene sowohl der Hardware als auch der Software. Unten werden Prototypen gebaut und dann die endgültige Implementierung erstellt. Der rechte Schenkel des V deckt die Verifikation ab und bewegt sich aufwärts durch das Testen einzelner Komponenten, der resultierenden Subsysteme und dann des Gesamtsystems.

Wenn Testingenieure von Modultests zur Systemvalidierung übergehen, beginnen sie möglicherweise mit reinen Simulationen, insbesondere wenn es um den Test von Software geht. Wenn sie jedoch im V-Modell zu Submodulen und schließlich zum kompletten System vorstoßen, muss die Software mit der realen Hardware interagieren, wodurch sich die Komplexität und die Kosten erhöhen.

Eine Möglichkeit, diesen potenziellen Kosten entgegenzuwirken, ist das Auffinden von Design-Fehlern zu einem früheren Zeitpunkt im Verifikationszyklus, wie es durch das V-Modell veranschaulicht wird. Dies hilft, die Kosten für Verifikationstests zu minimieren, und es hilft auch, Fehler zu vermeiden, deren Behebung sehr kostspielig sein kann, wenn sie später im Verifikationsprozess gefunden werden.

Dennoch erfordert die Validierung des Gesamtsystems Straßentests mit einem vollständig integrierten Fahrzeug. Dieser Ansatz hat zwei bemerkenswerte Nachteile: Er ist teuer und die unter zufälligen, realen Umgebungsbedingungen erzielten Ergebnisse sind nicht leicht reproduzierbar. Die Reproduzierbarkeit wird wichtig, wenn das zu testende System zeitweise ein fehlerhaftes Verhalten zeigt.

Software und Hardware in the Loop einbeziehen

Betrachten wir als Beispiel ein adaptives Abstandsregelsystem. Basierend auf den Daten eines Radarsensors soll das System die Brems- und Beschleunigungssysteme so steuern, dass entweder die gewünschte Fahrgeschwindigkeit erreicht oder ein sicherer Abstand zu einem direkt vorausfahrenden Fahrzeug eingehalten wird. Die Verifizierung des Regelalgorithmus beginnt mit einem Simulationssystem, das die Straßenumgebung, den Radarsensor und das physikalische Verhalten des Fahrzeugs nachbildet. Mit diesem Ansatz kann das Verhalten des Algorithmus in verschiedenen Szenarien verifiziert werden. Diese Art von Testaufbau wird als „Software in the Loop“ (SiL) bezeichnet.

Mit der Zeit können Hardware-Elemente zum System hinzugefügt werden. Ein Testaufbau könnte zum Beispiel ein Mikroprozessorsystem wie ein elektronisches Steuergerät (ECU), das später in das Fahrzeug integriert wird, und zum Beispiel einen Radarsensor enthalten. Diese Art des Testaufbaus wird als „Hardware in the Loop“ (HiL) bezeichnet.

Um solche Anwendungen zu adressieren, hat Keysight ein HiL-basiertes System mit der Bezeichnung „Autonomous Drive Emulation (ADE) Platform“ eingeführt. Es unterstützt den Test von ADAS auf der Komponenten- und Systemebene. Das Blockdiagramm in Bild 3 skizziert die High-Level-Architektur der ADE-Plattform.

Die ADE-Plattform baut das Testszenario mit einer simulierten Umgebung auf, die eine reale Situation rund um das Fahrzeug implementiert. Diese Simulation extrahiert die erforderlichen Informationen, um Sensoren wie Kameras oder Radarsensoren zu stimulieren und eine Verbindung zu verfügbaren Kommunikationskanälen wie etwa Vehicle-to-Everything (V2X) herzustellen.

Um die benötigten Informationen für Sensoren wie Radar oder Kameras während des Tests zu extrahieren, lässt sich auch die Ray-Tracing-Technologie verwenden. Bild 4 veranschaulicht das grundlegende Prinzip.

Das Ziel ist es, zu bestimmen, wie ein Objekt auf einer Betrachtungsebene dargestellt werden muss, um das nachzubilden, was ein menschlicher Anwender in der realen Welt beobachten würde. Damit ein Objekt sichtbar ist, muss es beleuchtet werden. In Bild 4 ist die Lichtquelle als Taschenlampe dargestellt.

Ein Drahtgittermodell stellt das Objekt dar, bei dem die Oberfläche des Objekts in kleine dreieckige Kacheln mit einer ebenen Oberfläche aufgeteilt ist. Für jedes Pixel in der Betrachtungsebene kann der Algorithmus eine gerade Linie, d. h. einen Strahl, von einem bestimmten Blickpunkt wie etwa dem Fahrersitz durch das Pixel zum Objekt zeichnen. Dieser Strahl trifft auf eine Kachel des Drahtmodells des Objekts, und ein weiterer Strahl lässt sich von dieser Kachel zur Lichtquelle verfolgen.

Derselbe Algorithmus kann auch in Radaranwendungen Verwendung finden. Die Lichtquelle ist der Radarsender, die relevanten Materialeigenschaften werden einbezogen, und die räumliche Geschwindigkeit wird zur Berechnung der Dopplereffekte berücksichtigt. Trotzdem gelten die gleichen Prinzipien.

Moderne Grafikprozessoren (GPUs) bieten Hardware-Beschleunigung für Raytracing-Algorithmen. Somit sind sie großartige Tools, um die für diesen Ansatz erforderliche Rechenleistung zu erreichen. Doch egal, wie schnell die GPUs auch sein mögen, es wird immer eine Verarbeitungsverzögerung geben, die zu einem Problem werden kann.

Angenommen der Raytracing-Algorithmus hat beispielsweise eine Verarbeitungsverzögerung von 100 ms, um seine Daten an einen Radar-Zielsimulator zu liefern. Dies ist die Zeit, die der Algorithmus benötigt, um einen Schnappschuss der Szene zu machen, seine Berechnung durchzuführen und die Daten an das Radar zu übergeben.

Nähern sich beispielsweise im Stadtverkehr zwei Autos einander und fahren beide mit einer Geschwindigkeit von 50 km/h (Bild 5), dann liegt die Relativgeschwindigkeit bei etwa 28 m/s. Innerhalb des 100-ms-Intervalls haben sie den Abstand um 2,8 m verringert.

Dieses Szenario ist für ein Open-Loop-System einfach zu handhaben. Entwickler können es mit dem Anschauen eines Films vergleichen – es macht nichts, wenn die Daten etwas später wahrgenommen werden. Wenn aber andere Sensoren beteiligt sind, ist es wichtig alle konsistent zu stimulieren. Mit anderen Worten: Die Verarbeitungsverzögerung muss für alle Sensoren gleich sein, um insgesamt eine synchrone Messung zu erreichen.

Wenn man auch die ADAS-Reaktion in den Test einbeziehen möchte, erfordert dies den Closed-Loop-Ansatz. Dieser Ansatz bezieht die Reaktion des Fahrzeugs in die Simulation ein. Wenn das ADAS zum Beispiel beschließt, im Notfall auf die Bremse zu treten, verlangsamt dies das Fahrzeug und beeinflusst folglich die an das Radar gesendeten Daten.

Bezugnehmend auf Bild 3 wird der Loop mit einem HiL-System geschlossen, das auch die Emulation anderer Komponenten innerhalb des Fahrzeugs implementiert, die nicht direkt mit dem ADAS zusammenhängen. Um das Latenzproblem zu überwinden, ist ein Nowcasting-Algorithmus notwendig. Zum Vergleich ist das Forecasting ein bekanntes Konzept aus der Meteorologie: Wettervorhersagen verwenden aktuelle Daten, um vorherzusagen, was in der Zukunft passieren wird. Nowcasting ist die Verwendung von veralteten Informationen – in diesem Fall Daten, die 100 ms alt sind – um die aktuelle Situation vorherzusagen. Mit diesem Ansatz lässt sich die Kombination aus einem Steuergerät, seiner Software und den realen Sensoren testen.

Wenn diese Anforderungen erfüllt sind, ermöglicht die ADE-Plattform das Testen eines ADAS, beginnend mit der Komponentenebene und fortschreitend bis zur Subsystemebene, lange bevor ein Fahrzeug auf der Straße getestet wird. Das Ziel ist es, die Gesamtkosten für den Test zu senken und gleichzeitig die Testabdeckung in einem frühen Stadium der Verifikation zu verbessern. Letztendlich hilft dies, die Leistung von ADAS zu verbessern, wenn sie auf öffentlichen Straßen zum Einsatz kommen.

(prm)