Los2: Standards

Zur Bestandsanalyse gehört auch die Untersuchung des aktuellen Stands und der Relevanz von Standards aus dem Verkehrsbereich wie DATEX II, TPEG, OTS/OCIT, TLS und aus dem IT-Bereich z.B. W3C/WS-* für allgemeine und Webtechnologien sowie OGC im GIS-Bereich.

Im folgenden Kapitel wird eine Übersicht über eine Auswahl an wichtigen, zum Teil standardisierten Datenformaten gegeben, die für diese Referenzarchitektur von Bedeutung sind. Die Quelle für dieses Kapitel ist der UR:BAN Leitfaden.

Die folgenden Datenformate werden nachfolgend kurz erläutert:

OCA und ODG-Standards

OTS 1 (OCIT-I)

Kurzbeschreibung

OTS 1 (OCIT-I) ist entstanden als Industriestandard in Zusammenarbeit mehrerer Softwarehersteller (zusammengeschlossen im Konsortium OTEC im Rahmen der OCIT-Initiative, unterstützt durch die Städteorganisation OCA (Open Traffic System City Association: Verband öffentlicher Baulastträger mit ca. 40 angeschlossenen deutschen, österreichischen und schweizerischen Städten)).

OTS 1 umfasst eine Schnittstelle basierende auf dem Netzwerkprotokoll „Simple Object Access Protocol“ (SOAP) zum Austausch von dynamischen Verkehrsdaten und Steuerungsbefehlen sowie ein durch XML-Schemata definiertes Datenmodell. Der Anwendungsschwerpunkt liegt in der Kommunikation innerstädtischer Zentralen und Subsystemen inklusive Ansteuerung von LSA- und Variotafelsystemen mit entsprechenden Schaltbefehlen.

Ein direkter Datenverkehr mit Feldgeräten ist nicht vorgesehen, hierfür wird für LSA auf OCIT-O verwiesen. Auch ein Austausch von Versorgungsdaten ist nicht enthalten, es können allerdings verfügbare Datenpunkte über Identifikationsnummern und Datentypen abgefragt werden, um dann entsprechende Datenbestellungen aufzugeben. Für die Übermittlung von LSA-Versorgungsdaten wird auf OCIT-I VD verweisen.

Es ist eine zyklische oder ereignisorientierte kontinuierliche Datenübermittlung möglich. Server- und Client-Funktionalitäten sind klar getrennt, Daten werden vom Server zum Client übertragen, Schaltbefehle in die umgekehrte Richtung. Klassischer Anwendungsfall ist die Anbindung eines Verkehrsrechners (Server) an ein Verkehrsmanagementsystem (Client).

OTS 1 wurde im Jahr 2009 auf dem Stand OTS 1.1 verabschiedet, der nach wie vor gültig ist. Eine Weiterentwicklung des Protokolls findet nicht mehr statt, es gibt mittlerweile den Nachfolger OTS 2. Das Datenmodell von OTS 1 ist weiterhin gültig und wird auch in OTS 2 (neben dem DATEX II-Datenmodell) eingesetzt. Das Datenmodell ist frei erweiterbar.

OTS 1 wird auch unter dem Namen OCIT-I (Instations) referenziert, das genau genommen nur eine Teilmenge davon ist (es fehlen Befehle und Betriebsmeldungen sowie einige Datenarten).

Betriebskosten

Betriebskosten speziell auf OTS 1 bezogen fallen nicht an, es gibt keine Lizenzgebühren oder andere direkte Kosten.

Unterstützung (Support)

OTS 1 wird inzwischen nicht mehr weiterentwickelt. Ein allgemeiner Support existiert deswegen nicht. Allerdings ist die komplette Dokumentation mit Schemadateien frei verfügbar (auf http://www.ocit.org/downloadOCIT-I.htm).

Es gibt keine fertigen Softwarebausteine, so dass auch eine Pflege bzw. ein Support für solche Komponenten nicht notwendig ist. Bei einzelnen Fragen ist evtl. eine Hilfestellung über die OCA und die bei der Entwicklung von OTS 1 beteiligten Firmen zu bekommen.

OTS 2

Kurzbeschreibung

OTS 2 ist als Nachfolger von OTS 1 konzipiert und ist Anfang 2011 als Spezifikation DIN-SPEC 91213-1/-2 beim DIN veröffentlicht worden. Dies entspricht einer Vornorm (keiner Norm).

Als Nachfolger von OTS 1 war das wesentliche Ziel, durch Einführung einer standardisierten Schichtentrennung flexible Adaptierbarkeit, erleichterte Erweiterbarkeit, Integration neuer Funktionalitä-ten und verbesserte Testbarkeit sowie Zertifizierbarkeit zu erreichen.

OTS 2 umfasst eine Schnittstelle zum Austausch von Verkehrsdaten aller Art, die basierend auf SOAP, Socket/XML oder (projektspezifisch) anderer Transportmechanismen realisiert werden kann. Ein eigenes Datenmodell ist nicht enthalten, standardmäßig werden das OTS 1-Datenmodell und das DATEX II-Datenmodell integriert. Anders als OTS 1, ist OTS 2 voll bidirektional und sowohl für den Datenaustausch von Zentralenapplikationen als auch mit Feldgeräten geeignet.

Es ist eine zyklische oder ereignisorientierte kontinuierliche oder auch eine einmalige Datenübermittlung möglich. Die Kommunikationspartner können in verschiedenen Rollen agieren, z.B. Publisher, Subscriber oder Distributor. Es gibt Methoden zur Abfrage der verfügbaren (versionierten) Protokollfunktionen und Methoden zur Abfrage der verfügbaren Datenpunkte. Wie in OTS 1 ist auch eine Befehlsübertragung z.B. zur Steuerung von LSA oder Variotafeln vorgesehen.

Betriebskosten

Falls die Dokumentation in der DIN-Version vom Beuth Verlag gekauft wird, kostet sie ca. 200€. Betriebskosten speziell auf OTS 2 bezogen fallen nicht an, es gibt ansonsten keine Lizenzgebühren oder andere direkte Kosten für die Verwendung von OTS 2.

Unterstützung (Support)

OTS 2 (http://www.opentrafficsystems.org) wird von der Städteorganisation OCA (http://www.oca-ev.info) unterstützt. Im Bedarfsfall kann hierüber Support von den an der Entwicklung beteiligten Firmen und Institutionen vermittelt werden. Eine aktive Nutzer- oder Betreiberorganisation speziell für OTS 2 existiert im Moment aber nicht.

OCIT-C (SZVD)

Kurzbeschreibung

OCIT-C umfasst eine SOAP-basierte Schnittstelle zum Austausch von dynamischen Verkehrsdaten und Steuerungsbefehlen sowie ein durch XML-Schemata definiertes Datenmodell. Mit OCIT-C werden die Funktionen zur Kommunikation zwischen zentralen Verkehrssteuerungs- und Verkehrslenkungssystemen abgedeckt. Ein direkter Datenverkehr mit Feldgeräten ist nicht vorgesehen, hierfür wird für LSA auf OCIT-O verwiesen. Die Datenübermittlung erfolgt immer per (zyklischer) Abfrage (Polling). Server- und Client-Funktionalitäten sind klar getrennt.

OCIT-C entstand als inoffizieller Nachfolger von OTS 1 sowie den Siemens-Protokollen Concert/OCPI, ist zu diesen aber nicht direkt kompatibel.

Die Schnittstelle wurde beim DKE als Vornorm (nicht als Norm) DIN VDE V 0832-601/-602 eingebracht und dort unter dem Namen SZVD veröffentlicht werden. Momentan sind keine Aktivitäten zu einer weiteren Standardisierung im Gange und aufgrund der Überschneidungen mit den früher dagewesenen Vornormen und Standards von OTS 2 und DATEX II auch unwahrscheinlich.

Die Version OCIT-C 2.0 erweitert die Schnittstelle um die Übermittlung von Fahrzeugdaten. Das Datenmodell orientiert sich dabei an den ETSI Spezifikationen (CAM, DENM, MAP, SPAT). Diese Version ist (Stand Mai 2016) noch in Arbeit und noch nicht veröffentlicht.

Betriebskosten

Falls die Dokumentation in der DKE-Version gekauft wird, fallen Kosten von ca. 250 Euro an. Betriebskosten speziell auf OCIT-C bezogen fallen nicht an, es gibt ansonsten keine Lizenzgebühren oder andere direkte Kosten für die Verwendung von OCIT-C.

Unterstützung (Support)

OCIT-C (http://www.ocit.org/OCIT-C.htm) wird von der Herstellerorganisation ODG&Partner (http://www.ocit.org/odg.htm) unterstützt. Im Bedarfsfall kann hierüber Support von den an der Entwicklung beteiligten Firmen vermittelt werden.

OCIT-O

Kurzbeschreibung

OCIT-O ist ein geschützter „Firmenstandard“, der den gemischten Einsatz von Steuergeräten und Zentralen-Software unterschiedlicher Hersteller ermöglicht. Getragen wird er von den Firmen Siemens, AVT Stoye, Stührenberg und Swarco Traffic Systems.

Das spezialisierte, lizenzpflichtige Protokoll zur herstellerunabhängigen Anbindung von LSA-Steuergeräten an Zentralen-Software („Verkehrsrechner“ und Testtools) bietet ein objektorientiertes Datenmodell aus Objekten und Methoden sowie ein auf TCP aufsetzendes binäres Protokoll (BTPPL) zum Aufruf von Methoden auf den definierten Objekten.

Mit OCIT-O können Daten von der LSA an die Zentrale übermittelt und umgekehrt Steuerungsdaten und seit V2.0 auch Versorgungsdaten an die LSA übertragen werden. Daten können zyklisch oder ereignisorientiert übermittelt werden.

Die Datenmodelle von OTS 1/2 und von OCIT-C sind auf das OCIT-O Datenmodell abgestimmt, um von OCIT-O-Steuergeräten übertragene Daten oder dorthin zu übertragende Befehle auch im Datenaustausch zwischen Zentralen-Komponenten verlustfrei weitergeben zu können.

Die Version OCIT-O 3.0 erweitert die Schnittstelle um die Übermittlung von Fahrzeugdaten. Das Datenmodell orientiert sich dabei an den ETSI Spezifikationen (CAM, DENM, MAP, SPAT). Diese Version ist (Stand Ende 2015) noch in Arbeit und noch nicht veröffentlicht.

Betriebskosten

OCIT-O muss von jedem Hersteller, der es verwenden will, lizenziert werden, was einmalige Kosten in Höhe von ca. 40.000€ verursacht. Im Falle eines größeren Updates (wie z.B. von OCIT-O 1 auf 2) ist mit weiteren Lizenzkosten für das Upgrade zu rechnen.

Unterstützung (Support)

OCIT-O (http://www.ocit.org/OCIT-O.htm) wird von der Herstellerorganisation ODG (http://www.ocit.org/odg.htm) unterstützt. Im Bedarfsfall wird hierüber Support geleistet. Als Lizenznehmer erhält man Unterstützung durch eine BTPPL-Bibliothek und (z.T. ebenfalls kostenpflichtige) Testtools. Betriebskosten speziell auf OCIT-O bezogen fallen ansonsten nicht an, es gibt keine Lizenzgebühren für einzelne Installationen o.ä.

Standards im Radio Broadcast

Traffic Message Channel – TMC

Kurzbeschreibung

Der Traffic Message Channel (TMC) kann als erstes Telematiksystem verstanden werden, das europaweit genutzt wird. In Deutschland wurde es 1997 eingeführt und ab 2000 auch in Navigationsgeräte integriert. Mit TMC lassen sich Verkehrsmeldungen in kodierter Form im Radio Data System (RDS), das über den UKW-Rundfunk übertragen wird, versenden. Vom Empfänger sind die Meldungen wieder zu dekodieren, um diese entsprechend interpretieren zu können. Das Kodieren erfolgt mit Hilfe von festvorgeschriebenen Listen; d.h. jedem Event bzw. jeder Location ist ein Kode zugeordnet. Der Empfänger muss über die gleiche Kodeliste verfügen wie der Ersteller der Meldung.

Spezifiziert ist TMC in der ISO Reihe ISO 14819 Traffic and Traveller Information (TTI) — TTI messages via traffic message coding: Die Organisation Traveller Information Services Association (TISA) mit ihren Mitgliedern und Arbeitsgruppen pflegt die Spezifikationen und schreibt sie nach Bedarf fort.

Da TMC ein Service des RDS ist, geht damit auch die Kopplung an den UKW-Rundfunk einher. Die Standardisierung kann als abgeschlossen bezeichnet werden. Verantwortliches Gremium ist die TISA, welche die CEN/ISO Standardisierungsorganisation unterstützt.

Unter http://www.tisa.org/technologies/tmc/tmc-world-map/ gibt die TISA Auskunft über die aktuelle Verbreitung und die geplante Einführung von TMC in den Ländern der Welt. Es ist deutlich zu sehen, dass TMC einen hohen Durchdringungsgrad nicht nur in Europa hat. In den USA aber auch in Russland, China, Australien und Brasilien ist TMC etabliert. Argentinien und Indien planen die Einführung von TMC.

Transport Protocol Experts Group (TPEG)

Kurzbeschreibung

TPEG umfasst einen umfangreichen Werkzeugkasten aus technischen Spezifikationen (zum großen Teil CEN/ISO Standards). Alle dienen zur Übermittlung von Verkehrsinformationen für Dienste. Ob Verkehrsmeldungen, flächige Verkehrslage und –prognose, Anzeige der dynamischen Geschwindigkeitsbegrenzungen, Benzinpreise oder Wetter – für jede Anwendung wird ein eigener Teilstandard im Gesamtrahmenwerk erstellt.

Aktualisierte oder neue TPEG Spezifikationen werden seitens der TISA Organisation der CEN/ISO Standardisierung zugeführt. Sind existierende Standards von CEN/ISO zu überprüfen und neu aufzulegen, erfolgt dies ebenso durch die Nutzerorganisation TISA. Jede Institution kann Mitglied in TISA werden und sich dabei aktiv an den Prozessen beteiligen.

Anfang 2012 waren knapp mehr als 20 Dienste-Anbieter mit einer ID zur Verwendung registriert (darunter öffentliche Rundfunksender und namhafte kommerzielle Dienstanbieter im Bereich Fahrzeugnavigation). Verfügbar sind 11 Standards der TPEG-1 Serie sowie 21 Spezifikationen/Standards der TPEG-2 Serie.

TPEG nutzt etablierte Standardkommunikationstechnologie. Die IP-basierter Kommunikation per HTTP ist sehr einfach gehalten. Sie erfordert keine speziellen weiteren Rahmenwerke und ist damit auch von deren Entwicklung nicht abhängig. Die binären Datenströme lassen sich in die Standards des digitalen Rundfunks (DAB/DVB) integrieren und können auch in zukünftige binärstrom-übertragende Technologien integriert werden.

Betriebskosten

Versteht man TPEG Standards als Ein- oder Ausgangsschnittstellen eines ohnehin vorhandenen Gesamtsystems, so können für diese keine speziellen Betriebs- oder Pflegekosten identifiziert werden. Tritt man als Serviceprovider auf, so sind die Kosten für den Kommunikationskanal (z.B. gemietete DAB Bandbreite) zu berücksichtigen. Werden nutzungsabhängige lizensierte Bausteine eingesetzt, ist mit den Lizenzinhabern ein entsprechender Vertrag zu schließen (z.B. mit Via Licencing bei der Nutzung von DLR1/AGORA-C).

Unterstützung (Support)

Über die TISA Organisation verfügt ein TPEG-Implementierer über eine sehr starke und aktive Nutzer-Organisation. Guidelines, Hilfestellungen oder Kontakte werden durch die Mitgliedschaft in der TISA ebenso verfügbar wie die aktuellsten Fassungen der technischen Spezifikationen. http://www.tisa.org

Weitere

OpenLR™

Kurzbeschreibung

OpenLR™ ist ein sich derzeit etablierender Standard zur dynamischen Georeferenzierung (der englische Begriff Location Referencing ist ebenso gebräuchlich). Unter der geographischen Referenz eines Ortes sind Angaben zu verstehen, die diesen Ort und dessen Bezug zu einer Karte oder auch zur realen Umgebung beschreiben und es einem Dritten ermöglichen durch die Referenz den Ort eindeutig zu indentifizieren. Klassisches Beispiel ist die Adresse zur Beschreibung des Wohnortes einer Person beim Versenden eines Briefs. Die Verwendung von geografischen Koordinaten z. B. im UMTS-Format, die auch eine Referenzierung darstellen, wäre auch möglich, aber Sender und Übermittler der Nachricht hätten durchaus Probleme mit dieser Referenz effizient umzugehen.

Unter einer dynamischen Georeferenzierung ist zu verstehen, dass nicht mit festen und vordefinieren Referenzen gearbeitet wird, wie es im Beispiel der Postanschrift oder bei TMC-Locations der Fall ist. Bei dieser Methode wird jedem Ort, wie z. B. dem Streckenabschnitt einer Straße, eine feste ID zugewiesen. Sender und Empfänger sind über die Zuordnung ID und Ort informiert. Der Nachteil dieser Methode ist das zeit- und kostenintensive Erstellen der TMC-Locations und die damit einhergehende Beschränkung auf eine bestimmte Anzahl an Locations. AGORA-C stellt eine dynamische Variante der Georeferenzierung dar. Hierbei fallen aber hohe Lizenzgebühren für die Verwendung des Standards an, so dass AGORA-C Probleme bei der Marktdurchdringung hat. Aus diesem Grund wird im Nachfolgenden nur auf OpenLR™ eingegangen.

Das Ziel einer Methode zur Georeferenzierung wie OpenLR™ ist, dass die Referenzierung von Sender und Empfänger leicht zu encodieren und decodieren ist. Im Falle von OpenLR™ soll dies erreicht werden, indem der nötige Algorithmus als OpenSource verfügbar ist, die zu übertragende Datenmenge möglichst klein ist, die Georeferenzen nicht vordefiniert sind, sondern dynamisch vergeben werden und elektronische Karten unterschiedlicher Hersteller einbezogen werden können. Das OpenLR™-Konzept beinhaltet daher die Möglichkeit einen Ort in ein bestimmtes Datenformat zu kodieren, um die Informationen zu verteilen und die Möglichkeit, das Datenformat auf der Empfängerseite zu dekodieren. Die Karte auf deren Basis kodiert wird und die Karte, welche die Grundlage zur Dekodierung bildet, müssen nicht identisch sein. Der OpenLR™-Standard bietet die Möglichkeit, den gleichen Ort eindeutig oder zumindest mit einer sehr hohen Wahrscheinlichkeit in zwei unterschiedlichen Karten zu referenzieren. OpenLR™ kann innerhalb von DATEX II genutzt werden. Es besteht aber die Abhängigkeit von der Kommunikationstechnik, die dem eigentlichen OpenLR™-Datum zugrunde liegt.

Betriebskosten

Es entstehen neben Kosten für den Betrieb von Servern, deren Größe und Anzahl vom zu unterstützenden Service abhängt, keine weiteren Betriebskosten.

Unterstützung (Support)

Unter http://www.openlr.org/ sind entsprechende nützliche Hinweise zu finden, wie z. B. FAG, Dokumentationen, Beispieldatensätze. Grundsätzlich ist aber Eigeninitiative gefordert.

DATEX II

Kurzbeschreibung

DATEX II ist eine Spezifikation einer Maschine-Maschine-Schnittstelle für den Austausch dynamischer Verkehrs- und Reisedaten zwischen unabhängigen, verkehrstelematischen Systemen. DATEX II enthält ein in UML ausgedrücktes, umfassendes Datenmodell für straßenverkehrsbezogene Daten, welches in einem zweiten Schritt durch ein Software-Werkzeug in ein XML-Schema basiertes Austauschformat umgesetzt wird. Für den Austausch dieser XML-kodierten Daten stehen dann in einer zweiten, unabhängigen Säule der Spezifikation verschiedene, auf Internet-Standards wie HTTP und Web Services (SOAP, WSDL) aufbauende, sogenannte Austauschprofile zur Verfügung. DATEX II ist damit technisch in die aktuellen Standardtechnologien zur Diensterbringung auf dem Internet eingebettet.

Als Ortsreferenz verwendet DATEX II, im Gegensatz zum Vorgänger DATEX, welcher auf Alert C Ortsreferenzen festgelegt war, ein Container-Konzept, welches der Quelle ermöglicht verschiedene Methoden zur Erzeugung von Ortsreferenzen zu nutzen, durchaus auch parallel. Es stehen Ortsreferenzen nach dem Alert C Standard (oft auch als Location Codes bezeichnet), eine auf den Straßenverkehr zugeschnittene Variante des mit TPEG eingeführten TPEG-Loc-Verfahrens (siehe unten), Kilometrierung/Stationierung oder geografische Koordinaten als zur Auswahl zur Verfügung.

Ein besonderes Kennzeichen von DATEX II ist die Erweiterbarkeit des Datenmodells. Obwohl das vorhandene Datenmodell sehr umfangreich ist und den Anspruch erhebt, viele Anwendungsbereiche von dynamischen Daten in der straßenbezogenen Verkehrstelematik abzudecken, besteht die Möglichkeit, das Modell noch durch anwendungsbezogene oder regionale/nationale Spezifika anzureichern. Solche Erweiterungen (sogenanntes Level B) bleiben mit Standardsoftware Plug&Play kompatibel, wenn sie einen in der Spezifikation vorgegebenen Satz von Modellierungsrichtlinien einhalten. Wenn komplett neue innovative Inhalte die Einhaltung dieser Regeln nicht erlauben, besteht immer noch die Möglichkeit der Benutzung der DATEX II Methodik und Werkzeuge (UML-Profil, XML-Schema-Generator, Austauschprotokolle), wobei man dann von Level C spricht. In diesem Fall sind Meldungen allerdings nur noch mit generischer (d.h. inhaltsunabhängiger) DATEX II-Software kompatibel.

DATEX II ist ein mehrteiliger Standard des CEN Technical Committee 278, CEN/TC278, (Road Transport and Traffic Telematics). Weitere Informationen auch unter http://www.datex2.eu/datex-node.

Betriebskosten

Für DATEX II fallen keine Lizenzkosten an. Pflegeaufwand entsteht ggf. durch die Anpassung an neue Versionen. Spezielle Tools oder professionelle Unterstützung werden aktuell nicht angeboten.

Unterstützung (Support)

Unterstützung zu DATEX II wird über die Webseite http://www.datex2.eu/ organisiert. Es stehen ein Forum und ein Issue Tracker zur Verfügung.

Fahrzeug-zu-X Kommunikation

Kurzbeschreibung

Die Fahrzeug-zu-X Kommunikation (im Folgenden kurz: V2X) bezeichnet nicht ein Protokoll im allgemeinen Sinne sondern einerseits eine Familie von Protokollen sowohl für die Kommunikation aus Zentralen heraus als auch zwischen Fahrzeugen und andererseits auch die dazugehörige Architektur. Der Begriff Fahrzeug-zu-X umfasst im Kontext dieses Abschnitts aber auch die Backend-Kommunikation.

Es gibt hierfür eine große Anzahl von Standards (zum Teil noch in der Entstehung) für die verschiedenen Kommunikationsarten. Konkrete Standards gibt es zurzeit für die Kommunikation auf der Fahrzeugseite. Die Kommunikation zur Zentralenseite befindet sich noch in der Standardisierung.

Es ist anzunehmen, dass die Einführung der Technologie zur Kommunikation über die Luftschnittstelle in der Anfangsphase mit größeren Aufwendungen verbunden ist, da es sich um eine neue Technologie handelt. Dies wird sich im Laufe der Jahre ändern, wenn mehr Erfahrung im Umgang mit der Technologie vorhanden sein wird und mehr Anbieter am Markt sein werden.

Es werden vermutlich von verschiedenen Anbietern fertige System zu erstehen sein, so dass die gesamte Komplexität der Luftschnittstellenkommunikation (ähnlich beim Kauf eine Access-Points heute) durch diese Produkte bereits abgedeckt wird. Die Implementierung von Anwendungen wird aufgrund der standardisierten Schnittstellen und dem anzunehmenden Einsatz weit verbreiteter Ausführungsumgebungen nur eine geringe Einarbeitungszeit erfordern. Bei Einsatz der dienstorientierten OSGi Technologie kann der Einsatz eines entsprechenden Rahmenwerkes zu Lizenzgebühren führen. Es sind hier aber auch kostenfrei Open-Source Implementierungen verfügbar.

Der Einsatz von ASN.1 erfordert für kommunikationserfahrene Programmierer nur eine geringe Ei-narbeitungszeit. Es können allerdings Kosten für einen ASN.1 Compiler anfallen, obgleich auch hier Open-Source-Alternativen existieren.

Für die Backendkommunikation sind die Protokolle und Schnittstellen noch nicht ausreichend defi-niert um eine spezielle Aussage tätigen zu können. Allgemein lässt sich aber sagen, dass höchstwahrscheinlich zumeist bereits vorhandene und etablierte Protokolle und Mechanismen eingesetzt werden, sodass sich der Aufwand auf die Implementierung der Funktionalität an und für sich beschränken wird.

V2X nutzt auf der Luftschnittstelle eine Kommunikation, die auf dem weit verbreiteten Standard IEEE 802.11 beruht und dort als IEEE 802.11p standardisiert ist. Die darauf aufbauenden Protokolle sind alle neu spezifiziert worden.

Auf der Backendseite kommen Protokolle auf Basis von IP (IPv4: RFC 791, IPv6: RFC 2460) bzw. Pa-cket Data Convergence Protocol (PDCP: ETSI TS 125 323; im Mobilfunkbereich) zum Einsatz. Die ge-nau eingesetzten Protokolle sind momentan noch offen.

Im Folgenden werden vier wichtige Nachrichtentypen für den Datenaustausch von Fahrzeugen mit Infrastruktureinrichtungen beschrieben:

CAM:

CAMs (Cooperative Awareness Message) enthalten aktuelle Zustandsdaten einer ITS Station (Fahr-zeug / Infrastruktur). Die Nachricht informiert über die Präsenz der ITS-Station, die Position, grundlegende Eigenschaften und Zustandswerte. Alle ITS-Stationen, d.h. sowohl fahrzeugseitig als auch infrastrukturseitig, senden diese Daten periodisch aus. Die Nachrichteninhalte sind zum Teil einheitlich festgelegt und zu einem anderen Teil je nach Stationstyp unterschiedlich. Jede Station sendet ihre aktuelle Position und ihren Stationstyp. Ein Fahrzeug sendet beispielsweise zusätzlich Informationen über den Fahrzeugtyp, seine aktuelle Geschwindigkeit und Bewegungsrichtung. CAM Nachrichten sind standardisiert nach TS 102 637-2 V1.2.1 (ETSI 2011).

DENM:

DENMs (Decentralized Environmental Notification Message) sind Nachrichten, die Information zu genau einem ortsgebundenen Ereignis enthalten, z.B. über eine Baustelle, ein Stauende oder Einsatz- bzw. Gefahrenstellen. Die DENM Nachrichten sind durch standardisiert nach EN 302 637-3 V1.2.1 (ETSI 2014) und werden nur unter der Voraussetzung eines eintretenden Ereignisses generiert und versendet,

MAP/TOPO:

Dieser Nachrichtentyp enthält Informationen zur Topologie einer Kreuzung wie Haltelinien und Fahrstreifen. Dieser Nachrichtentyp ist nach J2735 standardisiert (SAE 2007). Inhaltlich mit den MAP Nachrichten vergleichbar sind die zum Teil auch synonym genannten TOPO Nachrichten, die vom ETSI beschrieben werden.

SPaT:

Die SPaT (Signal Phase and Timing) enthält Daten zum aktuellen Signalbild einer LSA sowie den er-warteten Umschaltzeitpunkt zur nächsten Phase. Dieser Nachrichtentyp ist nach J2735 standardisiert (ebd.).

Betriebskosten

Für die Nutzung der Standards entstehen keine Lizenzgebühren. Die ETSI Standards sind unentgeltlich zugänglich. Die IEEE, SAE und OSI Standards sind zumeist nur entgeltlich zugänglich. Die Nutzung von Funktechnologien erfordert die einmalige Anschaffung von dedizierter Hardware. Es können betreiberabhängige Kosten bei der Nutzung von mobilfunkbasierenden Systemen anfallen.

Die Luftschnittstellenkommunikation über IEEE802.11p erfolgt in Europa im lizenzfreien ISM-Band (ISM = Industrial, Scientific and Medical Band). Für weitere Informationen hierzu wird auf die Stan-dards ETSI EN 302 665 und ETSI ES 202 663 verwiesen.

Unterstützung (Support)

Hierzu lässt sich zum momentanen Zeitpunkt, da die Technologie noch nicht produktiv eingesetzt wird, noch keine Aussage machen. Die Standards in diesem Bereich werden hauptsächlich von vier verschiedenen Organisationen durchgeführt:

• ETSI (European Telecommunications Standards Institute) ITS Standards lassen sich in folgende Bereiche unterteilen: EN = European Norm, ES = ETSI Standard, TS = Technical Specification (Für die einzelnen Bereiche wurde nur beispielhaft ein Standard zur Verdeutlichung ausgewählt.)
• CEN (Comité Européen de Normalisation) / TC (Technical committee) 278 und ISO (International Organization for Standardization) / TC 204
• SAE (Society of Automotive Engineers)
• IEEE (Institute of Electrical and Electronics Engineers)

---

<< Zurück zur Hauptseite