Zum Testen seiner V2X-Anwendung in solch einer Kreuzungssituation fehlen dem Entwickler die erforderlichen Infrastrukturkomponenten wie auch andere Verkehrsteilnehmer. Smarte Testsysteme mit simulierten V2X-Daten helfen ihm bei Labortests wie auch bei Tests auf einem Prüfgelände.

Zum Testen seiner V2X-Anwendung in solch einer Kreuzungssituation fehlen dem Entwickler die erforderlichen Infrastrukturkomponenten wie auch andere Verkehrsteilnehmer. Smarte Testsysteme mit simulierten V2X-Daten helfen ihm bei Labortests wie auch bei Tests auf einem Prüfgelände. (Bild: Nordsys)

Die Vernetzung von Fahrzeugen untereinander und mit der Infrastruktur mittels V2X-Kommunikation bringt ganz neue Herausforderungen für die Anwendungsentwicklung mit sich und stellt auch besondere Anforderungen an die Simulation. Lag der Fokus bei der Anwendungsentwicklung in der Vergangenheit ausschließlich auf den Gegebenheiten im fahrzeugeigenen Bordnetz, kommen mit der V2X-Kommunikation auch solche funktionalen Komponenten hinzu, auf die der Entwickler der Funktionen keinen Einfluss hat. Dabei gilt die V2X-Kommunikation als eine der Schlüsseltechnologien – wenn nicht gar als Voraussetzung – für die Autonomiestufen 4 und 5 autonom fahrender Fahrzeuge. Kooperative Systeme wie etwa Platooning oder die Kooperation zwischen autonom fahrenden Fahrzeugen ist ohne V2X kaum denkbar.

Eckdaten

Mit dem Aufkommen der V2X-Kommunikation, die auch für autonomes Fahren unverzichtbar ist, werden die Testbedingungen komplexer. Über die Restbussimulation fürs fahrzeugeigene Bordnetz hinaus muss eine umfangreiche Restverkehrssimulation hinzukommen und ins Fahrzeug eingehende Nachrichten auf der Luftschnittstelle realitätsnah abbilden. Die Testumgebung WaveBEE von Nordsys unterstützt den Funktionsentwickler und erzeugt synthetische, aber immer valide V2X-Nachrichten für Tests im Labor und auf der Versuchsstrecke.

Heutige Bordnetze bestehen aus einer Vielzahl von Sensoren und den dazugehörigen Steuergeräten, welche die Daten verarbeiten. Die Entwicklung von funktionalen Softwarekomponenten, die auf diese Sensordaten zurückgreifen, war somit in einem in sich abgeschlossenen System möglich. Das bedeutet, dass die Systemgrenzen des Bordnetzes klar definiert waren und sich der Entwicklungsingenieur in einer ihm bekannten Umgebung bewegen konnte. Software-in-the-Loop (SiL), Hardware-in-the-Loop-Systeme (HiL) mit entsprechenden Restbussimulationen bis hin zu entsprechenden Brettaufbauten mit realen Steuergeräten oder Vehicle-in-the-Loop-Umgebungen gehören heute zum Standardrepertoire bei der Funktionsentwicklung und den funktionalen Tests im Labor.

Weiche Systemgrenzen und agile Standards

Die Systemgrenzen, die der Ingenieur bei der Entwicklung von V2X-Funktionen zu berücksichtigen hat, sind dagegen nicht mehr so eindeutig definiert wie bisher. Aus Sicht des bordeigenen Sensornetzes handelt es sich bei der V2X-Kommunikation lediglich um einen weiteren Sensor, der Daten für die verarbeitenden Steuergeräte liefert. Zumindest gilt dies beim Empfang von V2X-Nachrichten. Unter diesem Aspekt betrachtet, ändert sich bezüglich der Vorgehensweise für den Entwickler zunächst nichts. Es gibt im Vergleich zum herkömmlichen, in sich abgeschlossenen Bordnetz, jedoch mehrere ganz entscheidende Unterschiede:

Es gibt im Vergleich zum herkömmlichen, in sich abgeschlossenen Bordnetz, jedoch mehrere ganz entscheidende Unterschiede:

  • Die Anzahl der Ursprungsdatenquellen (sprich: V2X-Sender) ist variabel
  • Die Art der Datenquellen kann unterschiedlich sein: andere Fahrzeuge oder Infrastrukturkomponenten
  • Unterschiedliche Zielmärkte mit verschiedenen V2X Standards
  • Konkurrierende oder sich ergänzende Funktechnologien (ITS-G5, LTE-V, 5G)

Die oben genannten Unterschiede haben einen wesentlichen Einfluss auf die Funktionsentwicklung, da der Entwicklungskontext eben nicht mehr klar abgegrenzt werden kann. Dieser Umstand wird insbesondere beim Testen der Funktionen sichtbar. Am Beispiel einer Warnfunktion für ein im Einsatz befindliches Sonderfahrzeug wird dies schnell deutlich. In einem großen Ad-hoc-Netzwerk mit beliebig vielen Teilnehmern muss durch die entsprechende V2X-Anwendung auf Basis der V2X-Nachrichten analysiert werden, ob das eigene Fahrzeug von der Einsatzfahrt beeinflusst wird und ob möglicherweise weitere Maßnahmen nötig sind. Platziert man dieses Szenario auf eine mehrspurige Kreuzung in Kombination mit den V2X-Nachrichten der Infrastruktur und anderen Fahrzeugen, benötigt der Entwickler Verfahren für komplexe Umgebungstests, bei denen das eigene Fahrzeug nur eine der vielen Komponenten dieses Netzwerks darstellt.

Simulation von V2X-Nachrichten auf der Luftschnittstelle

Das beschriebene Szenario erfordert für funktionale Test eine andere Vorgehensweise, als dies bei herkömmlichen, in sich abgeschlossenen Bordnetzen der Fall war: Bestandteil des Testszenarios ist dann nicht mehr die Restbussimulation wie im fahrzeugeignen Bordnetz, sondern es ist vielmehr eine Restverkehrssimulation erforderlich, die zumindest die Nachrichten auf der Luftschnittstelle möglichst realitätsnah abbildet. Eine nähergehende Betrachtung des umgebenden Verkehrs ist meist nicht nötig, denn letztlich sind nur die ausgesendeten Nachrichten für den Test entscheidend. Idealerweise können Testsysteme über die verschiedenen Testzyklen hinweg (SiL, HiL, gegebenenfalls ViL und Realfahrt) identische und reproduzierbare Testszenarien oder Test-Cases generieren. Eine solche Testumgebung steht mit den WaveBEE-Testlösungen bereits zur Verfügung. Der Fokus liegt hierbei auf der Erzeugung von synthetischen, aber immer validen V2X-Nachrichten für Tests im Labor und auf der Versuchsstrecke.

Eine Besonderheit des Systems ist die Möglichkeit, auch eine große Anzahl von Fahrzeugen oder Infrastrukturknoten simulativ abbilden zu können, ohne dass hierfür für jedes Fahrzeug ein separates V2X-Modem installiert sein muss. Die Testszenarien oder Test-Cases sind zu jeder Zeit exakt reproduzierbar, unabhängig in welcher Testumgebung sie ausgeführt werden. Somit sind vom SiL-Test, über den HiL-Test bis hin zur Realfahrt die Testbedingungen aus der Restverkehrssimulation identisch. Mit derartigen Testlösungen lassen sich die Systemgrenzen für die Tests um beliebige Teilnehmer erweitern, ohne das generelle Test-Setup verändern zu müssen. Mehr Teilnehmer im V2X-Netz oder neue Teilnehmer werden einfach per Mausklick erzeugt und die Software sorgt dafür, dass diese virtuellen V2X-Stationen auch real senden können.

Die V2X-Kommunikation standardisieren

Selbstredend ist für eine funktionierende V2X-Kommunikation die Standardisierung der Kommunikation unerlässlich. Naheliegend ist die Standardisierung nach dem OSI-Referenzmodell auf den Schichten 1-5. In Wirklichkeit geht die erforderliche Standardisierung jedoch noch weiter und umfasst neben allen sieben OSI-Schichten noch zusätzlich die auf Schicht 7 aufsetzende ITS-Anwendungsebene (Intelligent Transportation Systems). Voriges gilt zumindest für den Fall, ereignisgetriggerte Daten zu erzeugen und auszusenden. Auf Seite des Empfängers ist die ITS-Anwendungsebene dagegen nicht näher standardisiert. Somit kann der Empfänger weitgehend selbst entscheiden, ob und wie er die empfangenen Daten verarbeitet.

Ein vereinfachtes Beispiel soll den beschriebenen Sachverhalt verdeutlichen: Die ITS-Anwendung SSVW soll vor langsam fahrenden oder stehenden Fahrzeugen warnen. Hierzu muss unter anderem definiert sein, ab wann ein Fahrzeug als stehendes Hindernis zu betrachten ist und bis zu welcher Geschwindigkeit es als langsam gilt. Die Bedingungen, unter denen dann die entsprechende Warnnachricht in Form einer DENM erzeugt und gesendet werden darf, sind entsprechend standardisiert. Die DENM selbst muss als Nachricht natürlich auch standardisiert sein.

Noch mehr Standards

Die Standardisierung auf Applikationsebene, sprich die Beschreibung der Auslösebedingungen und die daraus resultierenden zu sendenden Nachrichteninhalte (Payload) ist beim Car-to-Car-Communication-Consortium (C2C-CC) angesiedelt. Da die oben beschriebene SSVW-Nachricht auch von Infrastrukturkomponenten ausgesendet werden kann, etwa durch die Auslösung aus einer Verkehrsleitzentrale, erfordert die Standardisierung eine enge Abstimmung zwischen der Fahrzeugseite (also dem C2C-CC) und der Infrastrukturseite. Letztere wird durch die europäische ITS-Plattform C-ROADS repräsentiert, welche sich die Harmonisierung von ITS-Diensten und das Deployment in den Mitgliedsstaaten der EU (und darüber hinaus) zum Ziel gemacht hat.

Bei der Standardisierung der Nachrichtentypen und des Routings nimmt ETSI, das European Telecommunications Standards Institute, die führende Rolle ein. Der Anwendungsentwickler sieht sich somit mit dem Problem konfrontiert, dass er im schlimmsten Fall mehrere Spezifikationsquellen für seine Applikation beachten muss. Erschwerend kommt hinzu, dass zahlreiche Spezifikationsdokumente nach wie vor Änderungen unterliegen. So ist mit dem erst kürzlich veröffentlichten Basic System Profile (BSP) in der Version 1.3.0 des C2C-CC lediglich eine weitere Etappe in der Spezifikation erreicht worden. Das BSP in der Version 1.4.0 ist für das Jahr 2019 bereits abzusehen.

Anwendungsentwickler müssen Unzähliges beachten

Auch hinsichtlich der Spezifikationen für die essenziellen Nachrichtentypen CAM (Cooperative Awarness Message) und DENM sind im Jahr 2019 Änderungen und Fehlerbereinigungen bereits absehbar. Noch umfangreichere Änderungen sind in den Nachrichtentypen SPAT (Signal Phase and Timing) und MAP zu erwarten. Die letzten Aktualisierungen des Geo-Networking (EN 302 636-4-1) sind erst im Jahr 2018 erfolgt, weitere sind nicht auszuschließen – insbesondere hinsichtlich der derzeit heftig diskutierten LTE-basierten Lösungen und Erweiterungen.

Die oben angeführten Beispiele betrachten nur die rein europäische Situation. Im globalen Kontext hat der Anwendungsentwickler eine noch weitergehende Fülle von Normen zu beachten, um Anwendungen zu programmieren, die den jeweiligen Standards entsprechen. Die Diskussion um hybride V2X-Kommunikation, wie etwa bei LTE-V, führt zu noch mehr Dokumentationen, die der Entwickler beachten muss.

Auf die richtige Softwarearchitektur kommt es an

Der Entwickler von V2X-Anwendungen sieht sich derzeit einem dynamisch ändernden Umfeld aus Standards und Spezifikationen gegenüber. Auf der reinen Applikationsebene haben Spezifikationsänderungen, wie durch das C2C-CC, direkte Auswirkungen. Änderungen der technischen Standards und Normen in den darunter liegenden Schichten – angefangen von Facilities über Networking bis hin zum Physical Layer – können den Anwendungsentwickler ebenfalls betreffen. Inwieweit beispielsweise Änderungen der CAM, der DENM oder des Geo-Networking Einfluss auf seine bereits entwickelten Applikationen haben, hängt in erster Linie von der verwendeten Software-Architektur ab. Idealerweise sind alle Schichten strikt voneinander getrennt und über Services miteinander verbunden.

Die aufgezeigte Problemstellung macht deutlich, wie wichtig die Wahl der richtigen V2X-Softwarearchitektur ist. Eine stabile serviceorientierte Architektur ist hierbei das Mittel der Wahl. Ein Beispiel für eine strikt serviceorientierte Softwarearchitektur ist der V2X-Stack von WaveBEE. Dem Anwendungsentwickler präsentiert sich eine einheitliche Schnittstelle (WDS, Wireless Distribution System) zu allen essenziellen V2X-Funktionen, unabhängig vom lokalen Markt oder der verwendeten Übertragungstechnik. Die vorausschauend geplante, stabile API ermöglicht eine nachhaltige Entwicklung von Anwendungen im sonst so unruhigen Fahrwasser der neuen Kerntechnologie V2X-Kommunikation. Änderungen der Spezifikationen unterhalb der Applikationsebene im Schichtenmodell werden vom V2X-Stack komplett abstrahiert. Somit kann sich der Funktionsentwickler voll und ganz auf seine Kernaufgabe fokussieren: die funktionalen Aspekte seiner Anwendung. Die richtige Software-Architektur trägt zudem durch eine sinnvolle Kapselung der unter der Anwendungsschicht liegenden V2X-Funktionen maßgeblich dazu bei, Fehler bei der Implementierung der Funktion zu vermeiden, indem sich der Anwendungsentwickler nicht mit den Details der Spezifikation der unterschiedlichen Nachrichtentypen beschäftigen muss.

Funktionale Aspekte im Fokus behalten

Mit der V2X-Kommunikation verlässt der Anwendungsentwickler seine abgeschlossene Bordnetzwelt und hat sich mit einer Vielzahl von Standards auseinander zu setzen. Erschwerend kommt für ihn hinzu, dass sich die Standards in einem stetigen Wandel befinden und neue Spezifikation hinzukommen. Die Wahl einer gut durchdachten V2X-Softwarearchitektur hilft dem Entwickler, sich auf die funktionalen Aspekte seiner Implementierung zu konzentrieren, unabhängig von Region oder Übertragungstechnik. Im Zusammenspiel mit gut durchdachten und flexiblen Testlösungen steht einer strukturierten Serienentwicklung nichts mehr entgegen.

Manfred Miller

Geschäftsführender Gesellschafter und Gründer von Nordsys

(jwa)

Sie möchten gerne weiterlesen?

Unternehmen

Nordsys GmbH

Mittelweg 7 A
38106 Braunschweig
Germany