Fahrzeug mit verschiedenen Sensor-Sichtfeldern

Radar- und andere Sensoren zur Erfassung der Umgebung gelten als Schlüsseltechnologien für das autonome Fahren. (Quelle: Keysight)

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.

Wozu braucht es HiL-Tests für Sensoren?

Die Termine für den Produktionsstart sind häufig knapp gesetzt, aber dennoch müssen Anwendungen getestet werden, manche mehr, manche weniger. Gerade bei Fahrerassistenzsystemen sind ausgiebige Tests nötig, um idealerweise sämtliche Fahrszenarien zu validieren. Allerdings sind solche Tests mit dem Zeitplan nur schwer vereinbar. Mit Hardware- und Software-in-the-Loop-Systemen lassen sich solche Test beschleunigen. Keysight hat dafür ein HiL-basiertes System entwickelt, welches den Test von ADAS auf Komponenten- und Systemebene unterstützt. Mit der Autonomous Drive Emulation Platform (ADE) lassen sich Umgebungen simulieren mit denen sich Sensoren stimulieren. Weiterhin können Kommunikationskanäle getestet werden.

Entwicklung für höhere Level an Autonomie

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)

Sensor L0 L1 L2 L3 L4/5
Radar N/A 0-3 0-5 3-6 6-20
Kameras N/A 0-1 3-5 3-6 3-6
Ultraschall N/A 4-8 8-12 Radar Radar
Lidar N/A 0 1 2-3 3+
Sicheres V2X Nein Nein Wenig Ja Ja

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.
Tabelle veranschaulicht Automatisierung m Fahrzeug mit Händen und Lenkrädern
Bild 1: Überblick über die fünf Level der Fahrautomatisierung: Der Bedarf an menschlicher Interaktion und Aufmerksamkeit nimmt bei höheren Leveln der Fahrautomatisierung ab. (Quelle: Keysight)

Die Herausforderungen bei der ADAS-Validierung verstehen

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.

V-Modell mit verschiedenen Entwicklungszyklen
Bild 2: Das V-Modell aus dem ISO 26262 Framework stellt einen Entwicklungszyklus dar. (Quelle: Keysight)

Kontrolle der kumulativen Kosten des Testens

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.

Schematischer Aufbau einer Testumgebung
Bild 3: Durch die Integration zeitlich synchronisierter Tests von wichtigen Subsystemen spart ADE Zeit und Geld und bietet eine bessere Testabdeckung im Vergleich zu Tests mit einzelnen Einheiten. (Quelle: Keysight)

Erstellen der simulierten Umgebung

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.

Auto wird von Lichtquelle bestrahlt
Bild 4: Innerhalb einer computergestützten Simulation erzeugt das Raytracing sehr realistische Ansichten der modellierten Objekte. (Quelle: Keysight)

Handhabung inhärenter Verarbeitungsverzögerungen

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.

Zwei Autos fahren aneinander vorbei.
Bild 5: Zwei Fahrzeuge, die sich aus entgegengesetzten Richtungen nähern, sind ein häufiges Szenario im Stadtverkehr, das simuliert werden kann. (Quelle: Keysight)

Closed Loop für hochrealistische Tests

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)

Autor

Bernhard Holzinger, Keysight

Bernhard Holzinger

arbeitet als Technical Architect fr die Automotive Energy Solutions von Keysight.

Kostenlose Registrierung

Bleiben Sie stets zu allen wichtigen Themen und Trends informiert.
Das Passwort muss mindestens acht Zeichen lang sein.
*

Ich habe die AGB, die Hinweise zum Widerrufsrecht und zum Datenschutz gelesen und akzeptiere diese.

*) Pflichtfeld

Sie sind bereits registriert?