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

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. Nordsys

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

Seite 2 von 41234