Anwendungsentwicklung V2X: Jenseits des eigenen Bordnetzes

Autor/Redakteur: Manfred Miller, geschäftsführender Gesellschafter und Gründer der NORDSYS GmbH/gg

Die Vernetzung von Fahrzeugen untereinander und mit der Infrastruktur mittels V2X-Kommunikation bringt ganz neue Herausforderungen für die Anwendungsentwicklung mit sich. 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 vier und fünf autonom fahrender Fahrzeuge. Kooperative Systeme wie etwa Platooning oder die Kooperation zwischen autonom fahrenden Fahrzeugen ist ohne V2X kaum denkbar.

Heutige Bordnetze bestehen aus einer Vielzahl von Sensoren und den dazugehörigen Steuergeräten, in denen die Daten aus den Sensoren verarbeitet werden. 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 entsprechende 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 Entwicklungsingenieur 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:

  1. Die Anzahl der Ursprungsdatenquellen (sprich: V2X-Sender) ist variabel
  2. Die Art der Datenquellen kann unterschiedlich sein: Andere Fahrzeuge oder Infrastrukturkomponenten
  3. Unterschiedliche Zielmärkte mit verschiedenen V2X Standards
  4. Konkurrierende oder sich ergänzende Funktechnologien (ITS-G5, LTE-V, 5G)
Eine Kreuzungssituation wie diese stellte den Entwickler von V2X Anwendungen vor das Problem, dass zum Testen seiner Anwendung sowohl die erforderlichen Infrastrukturkomponenten als auch die anderen Verkehrsteilnehmer nicht verfügbar sind. Smarte Testsysteme mit simulierten V2X-Daten helfen ihm bei Labortests wie auch bei Tests auf einem Prüfgelände. (Bild: Nordsys)

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