V2X für autonomes Fahren mit Closed-Loop-Verfahren testen

Bei der Vehicle-to-X-Kommunikation (V2X) geht es im Wesentlichen um den Austausch von Informationen, die entweder reinen Informationscharakter für den Fahrer haben oder aber als zusätzliche Datenquelle für eine Sensordatenfusion Einfluss auf die Manöverentscheidung des automatisiert bzw. autonom fahrenden Fahrzeuges haben. So lassen sich zum Beispiel Informationen über die Signalphasen einer Ampel dem Fahrer „nur“ anzeigen, allerdings ist auch möglich, dass das Fahrzeug automatisch seine Geschwindigkeit bei Annäherung an eine bevorstehende Rotphase verringert. Ein weiteres Beispiel ist die Funktion des Notbremsassistenten: Hierbei warnt das Fahrsystem den Fahrer im Voraus vor einem stark bremsenden Fahrzeug, obgleich die Sicht sowohl für den menschlichen Fahrer als auch für die Bordsensorik durch weitere Fahrzeuge verdeckt sein kann. In diesem Beispiel bringt ein Eingriff in die Längsführung bereits bei einem niedrigen Automatisierungsgrad einen Gewinn an Sicherheit.

Beim Testen der ersten Variante, also bei der reinen Informationsbereitstellung für den Fahrer, ist eine Closed-Loop-Betrachtung beim Testen in einem Hardware-in-the-Loop-Prüfstand (HiL) nicht zwingend erforderlich, da die empfangene Information zunächst keinen Einfluss auf das Fahrmanöver des eigenen Fahrzeugs hat. Das Testsystem kann einfacher gehalten werden, da lediglich die Ampelinformationen bzw. die Informationen über die Verzögerung eines vorausfahrenden Fahrzeuges für das Device under Test (DuT) notwendig sind. Die Ausgabe auf einem HMI hat keine direkte Auswirkung auf die Längsführung. Das Testsetup und das zugrundeliegende Testszenario können Entwickler daher fest definieren, da es lediglich von Interesse ist, ob der Fahrer rechtzeitig die zum jeweiligen Zeitpunkt definierte richtige Information auf dem HMI erhalten hat. Mit einer Open-Loop-Testumgebung lässt sich die V2X-Funktion hinreichend testen.

Bei aktuell mit V2X ausgestatteten Serienfahrzeugen wurde dieser Testansatz mithilfe des WaveBee Hive – einem Open-Loop-HiL-System – und WaveBee to-go – einem Open-Loop ViL-System für Realfahrttests – erfolgreich durchgeführt. Die Idee hinter WaveBee Hive und to-go ist die Simulation von V2X-Netzwerken inklusive der echten Erzeugung von den darin versendeten Nachrichten über virtualisierte Netzknoten. Diese Vorgehensweise vereinfacht das Test-Setup ganz wesentlich, da selbst bei einer Vielzahl von Netzwerkteilnehmern nur wenig reale Kommuni-kationshardware vorhanden sein muss.

Bei einem aktiven Eingriff in das Fahrmanöver ist ein fest definiertes Testszenario nicht zielführend. Am Beispiel des Notbremsassistenten zeigt sich das: Das automatische Abbremsen des eigenen Fahrzeugs führt im Idealfall zu einer Entschärfung der Gefahrensituation, sodass die Bremsleistung reduziert werden kann. Somit hat die automatische Längsführung einen direkten Einfluss auf die Geschwindigkeit des Ego-Fahrzeugs (Fahrzeug, in dem das DuT später verbaut werden soll) und damit auf dessen Position im zeitlichen Ablauf des Testszenarios.

Beim Testen von Anwendungen, die auf V2X-Informationen aufbauen, sind zwei Informationen in den ausgetauschten Nachrichteninhalten elementar: Position und Zeit. Diese beiden Informationen sind als Minimalanforderung definiert, um verwertbare Nachrichten in einem V2X-Netzwerk überhaupt auszutauschen. Dieser Umstand zeigt, dass ein automatisierter Eingriff in die Geschwindigkeit des Ego-Fahrzeuges direkte Auswirkungen auf die Ego-Position im weiteren zeitlichen Verlauf der Testausführung hat. Ein fest ablaufendes Testszenario stößt hier an seine Grenzen und es muss folglich sichergestellt sein, dass sich die Ortsinformation des Ego-Fahrzeuges zu jedem Zeitpunkt dynamisch verhalten kann. Die Frage ist hierbei, wie sich diese variable Ortsinformation bei einem feststehenden HiL-Aufbau in einer Laborumgebung realisieren lässt. Zusätzlich erfordert das Testsetup eine einheitliche und synchronisierte Zeitbasis für alle Netzknoten im V2X-Netzwerk – unabhängig davon, ob sie aus der Simulation kommen oder reale Hardware in Form des DuTs im HiL-Aufbau integriert ist.

Bild 1 zeigt einen entsprechenden Testaufbau mit den Datenflüssen im Closed Loop. Beim Testen des Notbremsassistenten definiert der Entwickler die Position sowie die Geschwindigkeit und deren Veränderung über die Zeit des vorausfahrenden Fahrzeugs in einem Testfalleditor. Für das Ego-Fahrzeug muss er zusätzlich eine Plantrajektorie festlegen, welche ohne einen automatisierten Eingriff in die Längsführung des Ego-Fahrzeuges zu einem Auffahrunfall führen würde. Die Ausführung des Testszenarios, die zentrale Ablaufsteuerung sowie die Erzeugung der V2X-Nachrichten erfolgt in diesem Setup auf einer UXM-5G-Wireless-Test-Plattform von Keysight Technologies, in welche die entsprechenden WaveBee-Softwarekomponenten für die GNSS-Ansteuerung sowie das Erzeugen der V2X-Nachrichten als virtuellen Maschine integriert wurden. Sobald der Entwickler das Testszenario zentral über den C-V2X-Director startet, fährt das vorausfahrende Fahrzeug entlang der festgelegten Wegpunkte mit den jeweils definierten Geschwindigkeiten und überträgt diese Information mittels V2X-Nachrichten an das V2X-DuT, welches ebenfalls wie geplant losfährt. Diese dort decodierten Positionsinformationen lassen sich nun entweder über ein reales ADAS-Steuergerät oder eine Restbussimulation weiterverarbeiten, welche dann das Bremsmanöver entsprechend auslösen. Die Verzögerung führt zu einer dynamischen Veränderung der zuvor festgelegten Trajektorie des Ego-Fahrzeuges. Die Dynamik bei Ort und Geschwindigkeit des Ego-Fahrzeuges wird hierbei über eine Steuerung der GNSS-Signale im GNSS-Simulator erreicht und der Loop ist damit geschlossen. Für das Monitoring der V2X-Kommunikation sowie das Logging der V2X-Nachrichten ist eine WaveBee Touch in den Testaufbau integriert.

Mit diesem Ansatz lassen sich unterschiedliche Bordnetzarchitekturen abtesten, bei denen etwa die GNSS-Informationen für das Ego-Fahrzeug auch aus einem separaten Steuergerät stammen können. Ebenso erlaubt dieses Setup sowohl die Einbindung weiterer Simulatoren als auch zusätzlicher realer Sensorhardware bis hin zu einem kompletten HiL-Setup, das sämtliche relevanten Sensoren sowie die Sensordatenfusion umfasst.