Anwendungsentwicklung V2X: Jenseits des eigenen Bordnetzes
Das oben beschriebene Szenario erfordert für die funktionalen Tests 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 muss vielmehr eine Restverkehrssimulation bereit gestellt werden, 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 sich 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 beziehungsweise 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, gleichzusetzen mit 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 können die Systemgrenzen für die Tests um beliebige Teilnehmer erweitert werden, 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.
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 eins bis fünf. In Wirklichkeit geht die erforderliche Standardisierung jedoch noch weiter und umfasst neben allen sieben OSI-Schichten noch zusätzlich die auf Schicht sieben aufsetzende ITS-Anwendungsebene (ITS = Intelligent Transportation Systems). Voriges gilt zumindest für den Fall, dass ereignisgetriggerte Daten erzeugt und ausgesendet werden sollen. Auf Seite des Empfängers ist die ITS Anwendungsebene dagegen nicht näher standardisiert. Das heißt, der Empfänger kann weitgehend selbst entscheiden, ob und wie er die empfangenen Daten verarbeitet.
Ein vereinfachtes Beispiel soll den beschriebenen Sachverhalt verdeutlichen: Die ITS-Anwendung „Slow or Stationary Vehicle Warning (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 (Decentralized Enviromental Notification Message) erzeugt und gesendet werden darf, sind entsprechend standardisiert. Die DENM selbst muss als Nachricht natürlich auch standardisiert sein.
