Unterwegs zum autonomen Fahren: Mit V2X-Kommunikation simulationsbasiert testen

Seite 3: Grüne Welle mit GLOSA

Inhaltsverzeichnis

Ein Beispiel für einen zukünftigen Service ist die Anzeige der prognostizierten Ampelphase bei Erreichen der Haltelinie im Display, wie in Abbildung 2 zu sehen. Eine Erweiterung dazu ist die sogenannte "Green Light Optimal Speed Advisory", kurz GLOSA. Mit GLOSA erhalten Fahrende eine Geschwindigkeitsempfehlung für das Erreichen der nächsten Grünphase einer kommenden Ampel. Für eine Priorisierung von Fahrzeugen wie dem öffentlichen Personennahverkehr in BiDiMoVe oder Einsatzfahrzeugen im Projekt SIRENE sieht der Standard die Nachrichtentypen Signal Request Message (SREM) und Signal Status Message (SSEM) vor. Mit einer SREM fordert ein Fahrzeug eine Bevorrechtigung an einer Kreuzung an (Signal Request). Solch eine Nachricht enthält die für die Priorisierung benötigten Informationen wie den StationType, der die Art der ITS-Station beschreibt. Der StationType unterscheidet zwischen Fußgängern (Codierung = 1), Fahrradfahrern (2), Straßen- und Schienenfahrzeugen (3-11) und Roadside-Units (RSUs) (15). Die Infrastructure-to-Vehicle-Information (IVI) bildet unter anderem physische Verkehrsschilder ab, dabei können die Schilder sowohl statisch als auch dynamisch veränderbar sein.

Das Display zeigt die prognostizierte Ampelphase bei Erreichen der Haltelinie an (Abb. 2).

(Bild: © DLR Institut für Verkehrssystemtechnik)

In der Entwicklung von V2X-Kommunikationssystemen gehört das Testen zum Alltag. Wie Softwareentwickelnde wissen, setzt sich der Testprozess im Allgemeinen aus sogenannten Komponententests, anschließenden Integrationstests und zuletzt den Systemtests zusammen. Das Deutsche Zentrum für Luft- und Raumfahrt legt seinen Fokus auf Systemtests, die Wissenschaftler meist auf der Basis von Systemspezifikationen oder Use Cases erstellen. Die Durchführung der Systemtests erfolgt entweder in Laborumgebungen oder im realen Umfeld, in dem das zu testende System am Ende zum Einsatz kommen soll. Während im Feldversuch insbesondere in frühen Entwicklungsstadien das Risiko und die Kosten eines Tests sehr hoch sind, können Labortests vergleichsweise günstig durchgeführt werden.

Zur Nachbildung des Verkehrsgeschehens rund um das System-Under-Test (SUT) benötigen Tester eine Simulationsumgebung, in die das SUT sich einbinden lässt. Solche Tests bezeichnen Wissenschaftler und Wissenschaftlerinnen als In-the-Loop-Tests. Vor der Simulation einzelner Use Cases im Verkehr müssen Entwickelnde die Verkehrsszenarien erst definieren und erstellen. Deshalb geht es hier im Artikel zunächst um die Frage, wie Entwicklerinnen und Wissenschaftler Verkehrsszenarien definieren.

In der szenariobasierten Verkehrssimulation stellt ein Verkehrsszenario eine temporäre Verkehrssituation dar, die aus den folgenden Kernelementen besteht:

  1. Topologie der Straße
  2. logische Verknüpfungen und Leitinfrastruktur
  3. temporäre Modifikationen wie eine Baustelle (optional)
  4. Dynamik der Verkehrsteilnehmenden
  5. Umweltbedingungen
  6. digitale Informationen (optional)

Als (Quasi-)Standard für die Definition von Verkehrsszenarien gilt das Dateiformat OpenSCENARIO in Verbindung mit OpenDRIVE, das der logischen Beschreibung von Straßennetzen und der Infrastruktur dient. OpenDRIVE bildet demnach die ersten drei Elemente einer temporären Verkehrssituation ab. Der OpenSCENARIO-Standard existiert seit 2018 und ergänzt die OpenDRIVE-Daten um dynamische Informationen. Beide Datenformate basieren auf dem XML-Format.

In der nachfolgenden Tabelle sind einige zurzeit relevante Simulationsumgebungen für Verkehrsszenarien aufgeführt. Für jede Simulationsumgebung zeigt die Tabelle das primäre Ziel der Simulation. Zudem ist aufgeführt, ob der OpenSCENARIO-Standard unterstützt wird und ob V2X-Kommunikation simuliert wird.

Eine Auswahl zurzeit relevanter Simulationsumgebungen für Verkehrsszenarien, Stand: November 2021.

Zu sehen ist, dass die meisten Simulationsumgebungen sich jeweils bisher auf ein Thema fokussiert haben, nämlich auf die Simulation von V2X-Nachrichten oder auf die Integration von Verkehrsszenarien im OpenSCENARIO Format. Bei einigen Simulationsumgebungen wie VTD oder SUMO ist die Integration des OpenSCENARIO Standards jedoch für die Zukunft geplant.

Ziel ist es nun, das OpenSCENARIO-Format mit der Simulation von V2X-Kommunikation zu verbinden. Genauer gesagt geht es um das Generieren von V2X-Nachrichten der Fahrzeuge, die in einem gemäß OpenSCENARIO definierten Verkehrsszenario enthalten sind. V2X-Nachrichten lassen sich beispielsweise generieren mit dem Open-Source-V2X-Stack Vanetza, der auf GitHub zu finden ist. Simuliert werden die Nachrichtenformate CAM und DENM.

Ego-Fahrzeug

Als Ego-Fahrzeug bezeichnen Forschende das Fahrzeug, das in einer Simulation untersucht wird. Das Ego-Fahrzeug wird in Fahrsimulationen meist aus der Ich-Perspektive dargestellt, sodass Versuchsfahrenden eine Simulation ähnlich zum echten Fahrerlebnis ermöglicht wird.

Der Ablauf der Simulation nach dem Erstellen eines Verkehrsszenarios ist in Abbildung 3 zu sehen. Zunächst ermittelt ein Skript sämtliche im Szenario enthaltenen Fahrzeuge. Als zusätzliche Information wird gespeichert, ob es sich um ein Ego-Fahrzeug oder ein Non-Ego-Fahrzeug handelt. In OpenSCENARIO sind die Routen der Fahrzeuge meist nicht als durchgängige Bewegungspfade (Trajektorien), sondern als Aktionen in Abhängigkeit zur Position oder Geschwindigkeit anderer Fahrzeuge definiert. Eine Abhängigkeit könnte beispielsweise sein: "Ego-Fahrzeug verringert Geschwindigkeit auf 50 km/h, wenn der Abstand zu Fahrzeug X geringer ist als 10 Meter". Ein weiteres Skript ermittelt im Anschluss aus den gegebenen Abhängigkeiten konkrete Bewegungstrajektorien für die enthaltenen Fahrzeuge. Die Speicherung der Trajektorien erfolgt als Wegpunktliste in einer Datenbank. In der Wegpunktliste sind für jede Sekunde im Szenario die Positionen der Fahrzeuge enthalten.

Zur Simulation von DENMs, also Gefahrenwarnungen, existiert im OpenSCENARIO-Standard noch kein XML-Element. Zur Beschreibung des sendenden Fahrzeugs und der DENM-Inhalte können Entwickelnde jedoch unter anderem die im Standard mitgelieferten frei konfigurierbaren Aktionen (CustomCommandActions) verwenden. Die Informationen zu Aussendungszeitpunkt, Sender und Inhalt ermittelt ein Python-Skript und speichert sie in einer für diesen Zweck erstellten Datenbank.

Vom Verkehrsszenario zur V2X-Nachricht (Abb. 3)

Im zweiten Schritt, der zeitlich unabhängig vom Erstellen der Datenbank ist, generiert eine Simulationsumgebung im Zusammenspiel mit dem V2X-Stack Vanetza die zugehörigen V2X-Nachrichten. Das verwendete Simulationsframework ist das Simulation Environment for ERTMS Verification (SEFEV), das im Regelfall im Hardware-in-the-Loop-Labor im DLR zur Erprobung von Eisenbahn-Leit- und -Sicherungssystemen dient. ERTMS steht dabei für das European Rail Traffic Management System. Die Simulationsumgebung liest zunächst die Wegpunktliste und die DENMs aus der Datenbank ein. Anschließend startet die Simulation des Szenarios.

Hierfür simuliert das Framework das Ego-Fahrzeug auf einer Trajektorie – die Strecke wird quasi abgefahren. Abhängig von der Position des Ego-Fahrzeuges stößt das Simulationsframework die Generierung der CAMs der umliegenden Fahrzeuge an. Das Simulationsframework sendet nun sekündlich pro Non-Ego-Fahrzeug einen Trigger mit Informationen zum sendenden Fahrzeug und zur Position aus. Getriggert wird der Vanetza-V2X-Stack, der daraufhin mit Hilfe der erhaltenen Informationen eine CAM generiert. Das Erzeugen von DENMs läuft analog dazu ab: Ist in der Datenbank die Aussendung einer DENM von einem Non-Ego-Fahrzeug zum aktuellen Zeitpunkt enthalten, triggert das Simulationsframework mit der Information den Vanetza-V2X-Stack, der daraufhin eine DENM erstellt.

Zur tatsächlichen Aussendung der V2X-Nachrichten über den 802.11p-Funkstandard ist der Vanetza-V2X-Stack in ein On-Board Unit integriert. Die OBU (MK5 von Cohda Wireless) ist bereits mit Antennen und einem GPS-Modul ausgestattet.

Zusammenfassend lässt sich mit dem beschriebenen Ablauf die V2X-Kommunikation mehrerer Fahrzeuge in einem Verkehrsszenario simulieren. Mit einer weiteren OBU eines anderen Herstellers konnte die Korrektheit und Kompatibilität der erstellten Nachrichten durch den Vanetza-V2X-Stack validiert werden.