Elektroniknet Logo

V2X-/C-V2X-Test im Closed-Loop-Verfahren

Notbremsung – aber sicher!

Warum Closed-Loop-Verfahren für V2X-/C-V2X-Tests von Bedeutung sind.
© Shutterstock.com | elektroniknet

Fahrerassistenzfunktionen, die auf Informationen aus V2X-Systemen zugreifen, stellen hohe Testanforderungen. Wann hierbei Closed-Loop-Testverfahren nötig werden, beschreibt dieser Artikel am Beispiel der Längsführung eines Fahrzeugs.

Auf dem Weg zu den Automatisierungsleveln 3, 4 und 5 nach der Definition im Standard SAE J3016 ergeben sich auch neue Anforderungen an die verbaute Sensorik im Fahrzeug. Neben den »klassischen« bordeigenen Sensoren wie Radar oder bildverarbeitenden Systemen, spielen kommunikative Sensoren bei zunehmendem Automatisierungsgrad eine immer bedeutendere Rolle.

Als solche kommunikativen Sensoren lassen sich auf V2X (Vehicle to X) oder C-V2X (Cellular V2X) basierende Kommunikationssysteme zusammenfassen. Sie erweitern den Erfassungshorizont der bordeigenen Sensorik, indem sie Sensordaten mit anderen Fahrzeugen austauschen oder Informationen aus der Infrastruktur verwerten. Dies führt zwangsläufig auch zu höheren Anforderungen an die in der Serienentwicklung verwendeten Testsysteme.

Bei der V2X-Kommunikation 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 nehmen. So können zum Beispiel Informationen über die Signalphasen einer Ampel dem Fahrer entweder »nur« angezeigt werden, oder aber das Fahrzeug verringert automatisch seine Geschwindigkeit bei Annäherung an eine bevorstehende Rotphase.

Ein weiteres Beispiel ist die Funktion Notbremsassistent: Hierbei wird der Fahrer vor einem stark bremsenden vorausfahrenden Fahrzeug gewarnt, obgleich die Sicht sowohl für den menschlichen Fahrer als auch für die Bordsensorik durch weitere Fahrzeuge verdeckt sein kann. In diesem Fall bringt ein Eingriff in die Längsführung bereits bei einem niedrigen Automatisierungsgrad einen Gewinn an Sicherheit.

Closed oder Open Loop?

Beim Testen einer Funktion, bei der es um eine reine Informationsbereitstellung für den Fahrer geht, 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 – im genannten Beispiel die Längsführung – des eigenen Fahrzeugs hat.  Das Testsystem kann einfacher gehalten werden, da lediglich die Ampelinformationen oder die Informationen über die Verzögerung eines vorausfahrenden Fahrzeuges für das DuT (Device under Test) bereitgestellt werden müssen.

Die Ausgabe auf einem HMI hat keine direkte Auswirkung auf die Längsführung. Das Test-Set-up und das zugrundeliegende Testszenario kann fest definiert werden, da es lediglich von Interesse ist, ob der Fahrer rechtzeitig mit der zum jeweiligen Zeitpunkt definierten richtigen Information auf dem HMI versorgt wurde. Mit einer Open-Loop-Testumgebung lässt sich folglich die entsprechende V2X-Funktion bereits hinreichend abtesten.

Bei aktuell mit V2X-Technik ausgestatteten Serienfahrzeugen wurde dieser Testansatz mithilfe des waveBEEhive, einem Open-Loop-HiL-System, und waveBEEto-go, einem Open-Loop-ViL-System für Realfahrttests, erfolgreich durchgeführt. Die Idee hinter waveBEEhive und waveBEEto-go ist die Simulation von V2X-Netzwerken inklusive der echten Erzeugung der darin versendeten Nachrichten über virtualisierte Netzknoten. Diese Vorgehensweise vereinfacht das Test-Set-up ganz wesentlich, da selbst bei einer Vielzahl von Netzwerkteilnehmern (zum Beispiel Stausituation, stark befahrene Kreuzung oder mehrere Sondereinsatzfahrzeuge) nur wenig reale Kommunikationshardware vorhanden sein muss.

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

Dynamisierung des Testablaufs

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. Aus diesem Umstand wird schnell ersichtlich, dass ein automatisierter Eingriff in die Geschwindigkeit des Ego-Fahrzeuges direkte Auswirkungen auf die Ego-Position im weiteren zeitlichen Verlauf der Testausführung hat.

Testaufbau eines Closed-Loop-HiL-Systems für das Testen von V2X/C-V2X-Funktionen mit den jeweiligen Datenflüssen am Beispiel des Notbremsassistenten.
Testaufbau eines Closed-Loop-HiL-Systems für das Testen von V2X/C-V2X-Funktionen mit den jeweiligen Datenflüssen am Beispiel des Notbremsassistenten.
© Nordsys

Ein fest ablaufendes Testszenario stößt dabei an seine Grenzen. Folglich muss sichergestellt werden, 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 Test-Set-up 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.

In Bild 1 ist ein entsprechender Testaufbau mit den Datenflüssen im Closed Loop dargestellt.  Beim Testen des zuvor erwähnten Notbremsassistenten wird die Position des vorausfahrenden Fahrzeugs sowie dessen Geschwindigkeit und die Geschwindigkeitsänderung in Abhängigkeit von der Zeit in einem Testfall-Editor (waveBEEcreator) fest definiert. Für das Ego-Fahrzeug wird zudem eine Plan-Trajektorie festgelegt, die 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 erfolgen in diesem Set-up auf einer UXM-5G-Wireless-Testplattform von Keysight Technologies, in die die entsprechenden waveBEE-Softwarekomponenten für die GNSS-Ansteuerung sowie das Erzeugen der V2X-Nachrichten als virtuelle Maschine integriert wurden.

Sobald das Testszenario zentral über den C-V2X Director gestartet wurde, »fährt« das vorausfahrende Fahrzeug entlang der festgelegten Wegpunkte mit den jeweils definierten Geschwindigkeiten und überträgt diese Information mittels V2X-Nachrichten over-the-air an das V2X-DuT, das ebenfalls wie geplant »losfährt«. Diese dort decodierten Positionsinformationen können nun entweder über ein reales ADAS-Steuergerät oder eine Restbussimulation weiterverarbeitet werden und das Bremsmanöver wird entsprechend ausgelöst.

Die Verzögerung führt zu einer dynamischen Veränderung der zuvor festgelegten Trajektorie des Ego-Fahrzeuges, was wiederum Einfluss zum Beispiel auf die Stärke der Verzögerung hat. 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 waveBEEtouch in den Testaufbau integriert.

Mit diesem Ansatz lassen sich sehr unterschiedliche Bordnetzarchitekturen abtesten, bei denen beispielsweise die GNSS-Informationen (Position und Zeit) für das Ego-Fahrzeug auch aus einem separaten Steuergerät (GPS-Empfänger) stammen können. Ebenso erlaubt dieses Set-up sowohl die Einbindung weiterer Simulatoren (zum Beispiel 3D-Simulatoren oder Verkehrssimulatoren) als auch zusätzlicher realer Sensorhardware bis hin zu einem kompletten HiL-Set-up, das sämtliche relevanten Sensoren sowie die Sensordatenfusion umfasst.

Szenario kooperative Fahrfunktionen

Das beschriebene Beispiel ist ein recht einfaches Szenario und berücksichtigt damit nur einen Teil zukünftiger Testanforderungen von ADAS-Funktionen unter Einbeziehung von V2X-Systemen. Liegt derzeit der Focus noch auf der reinen Kommunikationsfunktion von V2X/C-V2X, werden in Zukunft kooperative Fahrfunktionen, bei denen sich mehrere Fahrzeuge und die Infrastruktur über V2X abstimmen, mehr und mehr an Bedeutung gewinnen.

Es zeichnet sich also ab, dass SiL-, HiL- und ViL-Systeme zukünftig die gesamte verfügbare Sensorlandschaft berücksichtigen müssen. Letztlich werden jedoch auch immer noch Realfahrtests erforderlich sein. Mit dem waveBEE-Eco-System lassen sich solche kooperativen Funktionen sowohl im Laborprüfstand als auch bei Realfahrttests abbilden.

 

 

 

Manfred Miller ist Gründer, Gesellschafter und Geschäftsführer von Nordsys.
Manfred Miller ist Gründer, Gesellschafter und Geschäftsführer von Nordsys.
© Nordsys

Der Autor

Manfred Miller
ist Gründer, Gesellschafter und Geschäftsführer von Nordsys. Nach seinem Studium der Agrarwissenschaften an der TU München mit Schwerpunkt Landtechnik und Ortungsverfahren arbeitete er 5 Jahre bei einem Fachverlag als Redakteur. Im Jahr 2000 gründete Miller das Unternehmen Nordsys, das Entwicklungsleistungen im Bereich der fahrzeugnahen Software- und Systementwicklung für OEMs und Tier-1s anbietet. Seit 2011 war er maßgeblich an der Entwicklung der waveBEE-Produktfamilie beteiligt. Es handelt sich dabei um ein komplettes Eco-System zur Entwicklung und zum Testen von V2X-Lösungen bis hin zu serienreifen Softwarebausteinen für die V2X-Kommunikation.


Das könnte Sie auch interessieren

Verwandte Artikel

NORDSYS GmbH