{"id":15271,"date":"2019-11-12T11:22:51","date_gmt":"2019-11-12T10:22:51","guid":{"rendered":"https:\/\/www.sysbus.eu\/?p=15271"},"modified":"2019-11-06T12:39:46","modified_gmt":"2019-11-06T11:39:46","slug":"anwendungsentwicklung-v2x-jenseits-des-eigenen-bordnetzes","status":"publish","type":"post","link":"https:\/\/www.sysbus.eu\/?p=15271","title":{"rendered":"Anwendungsentwicklung V2X: Jenseits des eigenen Bordnetzes"},"content":{"rendered":"\n

Autor\/Redakteur: Manfred Miller, gesch\u00e4ftsf\u00fchrender Gesellschafter und Gr\u00fcnder der NORDSYS GmbH<\/a>\/gg<\/p>\n\n\n\n

Die Vernetzung von Fahrzeugen untereinander und mit der Infrastruktur mittels V2X-Kommunikation bringt ganz neue Herausforderungen f\u00fcr die Anwendungsentwicklung mit sich. Lag der Fokus bei der Anwendungsentwicklung in der Vergangenheit ausschlie\u00dflich 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\u00fcsseltechnologien \u2013 wenn nicht gar als Voraussetzung \u2013 f\u00fcr die Autonomiestufen vier und f\u00fcnf autonom fahrender Fahrzeuge. Kooperative Systeme wie etwa Platooning oder die Kooperation zwischen autonom fahrenden Fahrzeugen ist ohne V2X kaum denkbar. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n\n\n\n\n

Heutige\nBordnetze bestehen aus einer Vielzahl von Sensoren und den dazugeh\u00f6rigen\nSteuerger\u00e4ten, in denen die Daten aus den Sensoren verarbeitet werden. Die\nEntwicklung von funktionalen Softwarekomponenten, die auf diese Sensordaten\nzur\u00fcckgreifen, war somit in einem in sich abgeschlossenen System m\u00f6glich. Das\nbedeutet, dass die Systemgrenzen des Bordnetzes klar definiert waren und sich\nder Entwicklungsingenieur in einer ihm bekannten Umgebung bewegen konnte. Software-in-the-Loop-\n(SiL), Hardware-in-the-Loop-Systeme (HiL) mit entsprechenden\nRestbussimulationen bis hin zu entsprechende Brettaufbauten mit realen\nSteuerger\u00e4ten oder Vehicle-in-the-Loop-Umgebungen geh\u00f6ren heute zum\nStandardrepertoire bei der Funktionsentwicklung und den funktionalen Tests im\nLabor.<\/p>\n\n\n\n

Weiche\nSystemgrenzen und agile Standards<\/strong><\/p>\n\n\n\n

Die\nSystemgrenzen, die der Entwicklungsingenieur bei der Entwicklung von V2X-Funktionen\nzu ber\u00fccksichtigen hat, sind dagegen nicht mehr so eindeutig definiert wie\nbisher. Aus Sicht des bordeigenen Sensornetzes handelt es sich bei der V2X-Kommunikation\nlediglich um einen weiteren Sensor, der Daten f\u00fcr die verarbeitenden Steuerger\u00e4te\nliefert. Zumindest gilt dies beim Empfang von V2X-Nachrichten. Unter diesem\nAspekt betrachtet, \u00e4ndert sich bez\u00fcglich der Vorgehensweise f\u00fcr den Entwickler\nzun\u00e4chst nichts. Es gibt im Vergleich zum herk\u00f6mmlichen, in sich\nabgeschlossenen Bordnetz, jedoch mehrere ganz entscheidende Unterschiede:<\/p>\n\n\n\n

  1. Die Anzahl der Ursprungsdatenquellen (sprich: V2X-Sender) ist variabel<\/li>
  2. Die Art der Datenquellen kann unterschiedlich sein: Andere Fahrzeuge oder Infrastrukturkomponenten<\/li>
  3. Unterschiedliche Zielm\u00e4rkte mit verschiedenen V2X Standards<\/li>
  4. Konkurrierende oder sich erg\u00e4nzende Funktechnologien (ITS-G5, LTE-V, 5G)<\/li><\/ol>\n\n\n\n
    \"\"
    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\u00fcgbar sind. Smarte Testsysteme mit simulierten V2X-Daten helfen ihm bei Labortests wie auch bei Tests auf einem Pr\u00fcfgel\u00e4nde. (Bild: Nordsys)<\/figcaption><\/figure>\n\n\n\n

    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\u00fcr ein im Einsatz befindliches Sonderfahrzeug wird dies schnell deutlich. In einem gro\u00dfen 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\u00dfnahmen n\u00f6tig sind. Platziert man dieses Szenario auf eine mehrspurige Kreuzung in Kombination mit den V2X-Nachrichten der Infrastruktur und anderen Fahrzeugen, ben\u00f6tigt der Entwickler Verfahren f\u00fcr komplexe Umgebungstests, bei denen das eigene Fahrzeug nur eine der vielen Komponenten dieses Netzwerks darstellt.<\/p>\n\n\n\n\n\n\n\n

    Das oben beschriebene Szenario erfordert f\u00fcr die funktionalen Tests eine andere Vorgehensweise, als dies bei herk\u00f6mmlichen, 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\u00f6glichst realit\u00e4tsnah abbildet. Eine n\u00e4hergehende Betrachtung des umgebenden Verkehrs ist meist nicht n\u00f6tig, denn letztlich sich nur die ausgesendeten Nachrichten f\u00fcr den Test entscheidend. Idealerweise k\u00f6nnen Testsysteme \u00fcber 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\u00f6sungen bereits zur Verf\u00fcgung. Der Fokus liegt hierbei auf der Erzeugung von synthetischen, aber immer validen V2X-Nachrichten f\u00fcr Tests im Labor und auf der Versuchsstrecke. Eine Besonderheit des Systems ist die M\u00f6glichkeit, auch eine gro\u00dfe Anzahl von Fahrzeugen oder Infrastrukturknoten simulativ abbilden zu k\u00f6nnen, ohne dass hierf\u00fcr f\u00fcr jedes Fahrzeug ein separates V2X-Modem installiert sein muss. Die Testszenarien, gleichzusetzen mit Test-Cases, sind zu jeder Zeit exakt reproduzierbar, unabh\u00e4ngig in welcher Testumgebung sie ausgef\u00fchrt werden. Somit sind vom SiL-Test, \u00fcber den HiL-Test bis hin zur Realfahrt die Testbedingungen aus der Restverkehrssimulation identisch. Mit derartigen Testl\u00f6sungen k\u00f6nnen die Systemgrenzen f\u00fcr die Tests um beliebige Teilnehmer erweitert werden, ohne das generelle Test-Setup ver\u00e4ndern zu m\u00fcssen. Mehr Teilnehmer im V2X-Netz oder neue Teilnehmer werden einfach per Mausklick erzeugt und die Software sorgt daf\u00fcr, dass diese virtuellen V2X-Stationen auch real senden k\u00f6nnen.<\/p>\n\n\n\n

    \"\"
    Screenshot: Nordsys<\/figcaption><\/figure>\n\n\n\n

    Selbstredend ist f\u00fcr eine funktionierende V2X-Kommunikation die Standardisierung der Kommunikation unerl\u00e4sslich. Naheliegend ist die Standardisierung nach dem OSI-Referenzmodell auf den Schichten eins bis f\u00fcnf. In Wirklichkeit geht die erforderliche Standardisierung jedoch noch weiter und umfasst neben allen sieben OSI-Schichten noch zus\u00e4tzlich die auf Schicht sieben aufsetzende ITS-Anwendungsebene (ITS = Intelligent Transportation Systems). Voriges gilt zumindest f\u00fcr den Fall, dass ereignisgetriggerte Daten erzeugt und ausgesendet werden sollen. Auf Seite des Empf\u00e4ngers ist die ITS Anwendungsebene dagegen nicht n\u00e4her standardisiert. Das hei\u00dft, der Empf\u00e4nger kann weitgehend selbst entscheiden, ob und wie er die empfangenen Daten verarbeitet.<\/p>\n\n\n\n

    \"\"
    Beim funktionalen Testen von V2X Seriensystemen erweitern sich die Systemgrenzen erheblich. Nicht nur das Bordnetz des Ego-Fahrzeugs muss der Versuchsingenieur betrachten, sondern das gesamte verkehrliche Umfeld mit vielen verschiedenen V2X Teilnehmern ist elementarer Teil der Testl\u00f6sung. Mittels geeigneter Editoren f\u00fcr das Erstellen von V2X Szenarien lassen sich Testf\u00e4lle schnell erzeugen und die Nachrichten auf der Luftschnittstelle reproduzierbar generieren. (Grafik: Nordsys)<\/figcaption><\/figure>\n\n\n\n

    Ein vereinfachtes Beispiel soll den beschriebenen Sachverhalt verdeutlichen: Die ITS-Anwendung \u201eSlow or Stationary Vehicle Warning (SSVW)\u201c 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 \u201elangsam\u201c 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\u00fcrlich auch standardisiert sein.<\/p>\n\n\n\n\n\n\n\n

    Standards,\nStandards, Standards<\/strong><\/p>\n\n\n\n

    Die Standardisierung\nauf Applikationsebene, sprich die Beschreibung der Ausl\u00f6sebedingungen und die\ndaraus resultierenden zu sendenden Nachrichteninhalte (Payload) ist beim\nCar-to-Car-Communication Consortium (C2C-CC) angesiedelt. Da die oben\nbeschriebene SSVW-Nachricht auch von Infrastrukturkomponenten ausgesendet\nwerden kann, etwa durch die Ausl\u00f6sung aus einer Verkehrsleitzentrale, erfordert\ndie Standardisierung eine enge Abstimmung zwischen der Fahrzeugseite (also dem\nC2C-CC) und der Infrastrukturseite. Letztere wird durch die europ\u00e4ische ITS-Plattform\nC-ROADS repr\u00e4sentiert, welche sich die Harmonisierung von ITS-Diensten und das\nDeployment in den Mitgliedsstaaten der EU (und dar\u00fcber hinaus) zum Ziel gemacht\nhat.<\/p>\n\n\n\n

    Bei der Standardisierung der Nachrichtentypen und des Routings nimmt das ETSI, das European Telecommunications Standards Institute, die f\u00fchrende Rolle ein. Der Anwendungsentwickler sieht sich somit mit dem Problem konfrontiert, dass er im schlimmsten Fall mehrere Spezifikationsquellen f\u00fcr seine Applikation beachten muss. Erschwerend kommt hinzu, dass zahlreiche Spezifikationsdokumente nach wie vor \u00c4nderungen unterliegen. So ist mit dem erst k\u00fcrzlich ver\u00f6ffentlichten 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\u00fcr das Jahr 2019 abzusehen. Auch hinsichtlich der Spezifikationen f\u00fcr die essentiellen Nachrichtentypen CAM (Cooperative Awarness Message) und DENM sind im Jahr 2019 \u00c4nderungen und Fehlerbereinigungen absehbar. Noch umfangreichere \u00c4nderungen 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\u00dfen \u2013 insbesondere hinsichtlich der derzeit heftig diskutierten LTE-basierten L\u00f6sungen und Erweiterungen.<\/p>\n\n\n\n

    \"\"
    Screenshot: Nordsys<\/figcaption><\/figure>\n\n\n\n

    Die\noben angef\u00fchrten Beispiele betrachten nur die rein europ\u00e4ische Situation. Im\nglobalen Kontext hat der Anwendungsentwickler eine noch weitergehende F\u00fclle von\nNormen zu beachten, um Anwendungen zu programmieren, die den jeweiligen Standards\nentsprechen. Die Diskussion um hybride V2X-Kommunikation, wie etwa bei LTE-V,\nf\u00fchrt zu noch mehr Dokumentationen, die der Entwickler beachten muss.<\/p>\n\n\n\n

    Auf\ndie richtige Softwarearchitektur kommt es an<\/strong><\/p>\n\n\n\n

    Der\nEntwickler von V2X-Anwendungen sieht sich derzeit einem sich dynamisch\n\u00e4ndernden Umfeld aus Standards und Spezifikationen gegen\u00fcber. Auf der reinen\nApplikationsebene haben Spezifikations\u00e4nderungen, wie durch das C2C-CC, direkte\nAuswirkungen. \u00c4nderungen der technischen Standards und Normen in den darunter\nliegenden Schichten (beispielsweise Facilities, Networking bis hin zum Physical\nLayer), k\u00f6nnen den Anwendungsentwickler ebenfalls betreffen. Inwieweit die\n\u00c4nderungen zum Beispiel der CAM, der DENM oder des Geo-Networking Einfluss auf\nseine bereits entwickelten Applikationen haben, h\u00e4ngt in erster Linie von der\nverwendeten Software-Architektur ab. Idealerweise sind alle Schichten strikt\nvoneinander getrennt und \u00fcber Services miteinander verbunden. <\/p>\n\n\n\n

    In Anbetracht der genannten Problemstellungen wird deutlich, wie wichtig die Wahl der richtigen V2X-Softwarearchitektur ist. Eine stabile serviceorientierte Architektur ist hierbei das Mittel der Wahl. Ein Beispiel f\u00fcr eine strikt serviceorientierte Softwarearchitektur ist der waveBEE V2X-Stack. Dem Anwendungsentwickler pr\u00e4sentiert sich eine einheitliche Schnittstelle (WDS) zu allen essentiellen V2X Funktionen, unabh\u00e4ngig vom lokalen Markt oder der verwendeten \u00dcbertragungstechnik. Die vorausschauend geplante, stabile API erm\u00f6glicht eine nachhaltige Entwicklung von Anwendungen im sonst so unruhigen Fahrwasser der neuen Kerntechnologie V2X-Kommunikation. \u00c4nderungen 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\u00e4gt zudem durch eine sinnvolle Kapselung der unter der Anwendungsschicht liegenden V2X-Funktionen ma\u00dfgeblich dazu bei, Fehler bei der Implementierung der Funktion zu vermeiden, indem sich der Anwendungsentwickler beispielsweise nicht mit den Details der Spezifikation der unterschiedlichen Nachrichtentypen besch\u00e4ftigen muss.<\/p>\n\n\n\n

    \"\"
    Bild: Nordsys<\/figcaption><\/figure>\n\n\n\n

    Fazit<\/strong><\/p>\n\n\n\n

    Mit der V2X-Kommunikation verl\u00e4sst der Anwendungsentwickler seine abgeschlossene Bordnetzwelt und hat sich mit einer Vielzahl von Standards auseinander zu setzen. Erschwerend kommt f\u00fcr ihn hinzu, dass sich die Standards in einem stetigen Wandel befinden und neue Spezifikation hinzukommen. Die Wahl einer gut durchdachten V2X-Softwarearchitektur hilft dem Funktionsentwickler, sich auf die funktionalen Aspekte seiner Implementierung zu konzentrieren, unabh\u00e4ngig von Region oder \u00dcbertragungstechnik. Im Zusammenspiel mit gut durchdachten und flexiblen Testl\u00f6sungen steht einer strukturierten Serienentwicklung nichts mehr entgegen.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Die Vernetzung von Fahrzeugen untereinander und mit der Infrastruktur mittels V2X-Kommunikation bringt ganz neue Herausforderungen f\u00fcr die Anwendungsentwicklung mit sich. Lag der Fokus bei der Anwendungsentwicklung in der Vergangenheit ausschlie\u00dflich 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\u00fcsseltechnologien \u2013 wenn nicht gar als Voraussetzung \u2013 f\u00fcr die Autonomiestufen vier und f\u00fcnf autonom fahrender Fahrzeuge. Kooperative Systeme wie etwa Platooning oder die Kooperation zwischen autonom fahrenden Fahrzeugen ist ohne V2X kaum denkbar.<\/p>\n","protected":false},"author":1,"featured_media":15272,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[8,197],"tags":[7115,5290,4185,9962,5872,13093,13095,13102,13101,13103,13100,13105,10602,3923,13104,10608,10603,111,7354,3340,10600,6467,13094,13098,10607,10606,13099,690,13092,13096,13097,10599,13106],"class_list":["post-15271","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-artikel","category-entwicklung","tag-5g","tag-anwendungsentwicklung","tag-api","tag-autonomes-fahren","tag-autonomie","tag-bordnetz","tag-bus","tag-c-roads","tag-c2c-cc","tag-cam","tag-denm","tag-en-302-636-4-1","tag-etsi","tag-eu","tag-geo-networking","tag-hil","tag-its","tag-lte","tag-map","tag-mobilitaet","tag-nordsys","tag-osi","tag-platooning","tag-realfahrt","tag-sil","tag-spat","tag-ssvw","tag-test-2","tag-v2x","tag-vehicle-in-the-loop","tag-vil","tag-wavebee","tag-wds"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/15271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=15271"}],"version-history":[{"count":1,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/15271\/revisions"}],"predecessor-version":[{"id":15278,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/posts\/15271\/revisions\/15278"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=\/wp\/v2\/media\/15272"}],"wp:attachment":[{"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=15271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=15271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sysbus.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=15271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}