Deliverable D21.4 Kommunikationsprotokolle · 2018. 9. 25. · Deliverable D21.4 Spezifikation der Kommunikationsprotokolle Version 1.0 Verbreitung Öffentlich Projektkoordination

Deliverable D21.4

Spezifikation der Kommunikationsprotokolle

Version 1.0

Verbreitung Öffentlich Projektkoordination Daimler AG

Versionsdatum 29.09.2009

simTD wird gefördert und unterstützt durch

Bundesministerium für Wirtschaft und Technologie Bundesministerium für Bildung und Forschung Bundesministerium für Verkehr, Bau und Stadtentwicklung

Sichere Intelligente Mobilität Testfeld Deutschland

Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite ii

Dieses Dokument wurde erstellt von Firma Ford Forschungszentrum Aachen GmbH

Beiträge wurden verfasst von

Andreas Hiller – Daimler AG

Carsten Neumann – FhG Fokus

Manuel Mattheß – FhG SIT

Dr. Andreas Festag – NEC Europe Ltd.

Hugo Santos – NEC Europe Ltd.

Dr. Wenhui Zhang – NEC Europe Ltd.

Dr. Christoph Sorge – NEC Europe Ltd.

Martin Wiecker – Ford Forschungszentrum

Projektkoordination

Dr. Christian Weiß

Daimler AG

HPC 050 – G021

71059 Sindelfingen

Germany

Telefon +49 7031 4389 550

Fax +49 7031 4389 210

E-mail [email protected]

Das simTD Konsortium übernimmt keinerlei Haftung in Bezug auf die veröffentlichten Deliverables. Änderungen sind ohne Ankündigung möglich. © Copyright 2009 simTD Konsortium

The simTD consortium will not be liable for any use of the published deliverables. Contents are subject to change without notice. © Copyright 2009 simTD consortium

Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite iii

Inhaltsverzeichnis Zusammenfassung...................................................................................................................1 Summary ..................................................................................................................................2 1. Nachrichtenformate auf Anwendungsebene .....................................................................3

1.1 Allgemein .................................................................................................................3 1.1.1 Kommunikationsbeziehungen ....................................................................3 1.1.2 Existierende Standards ..............................................................................5 1.1.3 Nomenklatur...............................................................................................8 1.1.4 Positionskodierung.....................................................................................8 1.1.5 Zeitdaten ....................................................................................................9

1.2 C2X Nachrichtenformate........................................................................................10 1.2.1 Einsatzgebiet der C2X-Nachrichtenformate.............................................10 1.2.2 Informationen einer Nachricht ..................................................................10 1.2.3 C2X Application Payload: Allgemeiner Rahmen auf

Anwendungssschicht ...............................................................................11 1.2.4 Unformatierte Daten - AppSpecificData ...................................................12 1.2.5 Aktuelle Zustandsdaten - CoopAwareness ..............................................12 1.2.6 Ereignisdaten - DecEnvNotification (DEN)...............................................16 1.2.7 Fahrhistorie - ProbeVehicleData ..............................................................19 1.2.8 Fahrtziel – Destination .............................................................................20 1.2.9 Kreuzungstopologie - Intersection............................................................21 1.2.10 Verkehrsregeln – TrafficRegulation..........................................................23 1.2.11 Ampelphaseninformation – SignalState ...................................................24 1.2.12 Dezentrale Verkehrslage..........................................................................26 1.2.13 Verkehrslage - TrafficList .........................................................................28 1.2.14 Textnachricht – TextAnnouncement ........................................................28 1.2.15 Differential GPS Korrekturdaten...............................................................29

1.3 IP-basierte Kommunikation ....................................................................................30 1.3.1 Allgemeines..............................................................................................30 1.3.2 Internetbasierte Dienstnutzung ................................................................30 1.3.3 Standortinformationsdienste ....................................................................31

1.4 Infrastrukturinterne Kommunikation .......................................................................31 1.4.1 Allgemeines..............................................................................................31 1.4.2 Lokale Verkehrsabhängige LSA-Steuerung.............................................31 1.4.3 Stadtverkehrslage ....................................................................................35

1.5 IT-Sicherheit...........................................................................................................39 1.5.1 Absicherung der C2X-Nachrichten...........................................................39 1.5.2 Absicherung der IP Basierten Kommunikation.........................................39

2. Testprotokolle..................................................................................................................43

Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite iv

2.1 Versuchssteuerung ................................................................................................43 2.1.1 Dateiübertragung .....................................................................................47

2.2 Livedatenübertragung ............................................................................................48 2.3 IT-Sicherheit...........................................................................................................49

2.3.1 Absicherung der Versuchssteuerung .......................................................50 2.3.2 Absicherung der Livedatenübertragung ...................................................50 2.3.3 Absicherung der Dateiübertragung ..........................................................50

3. Protokolle Netzwerkschicht .............................................................................................52 4. Resultate .........................................................................................................................53 Literaturverzeichnis ................................................................................................................55 Abkürzungen ..........................................................................................................................56 Glossar ...................................................................................................................................58 Anhang 1: Basisdatentypen ASN.1 ........................................................................................59 Anhang 2: Relevante TPEG Tabellen ....................................................................................79 Anhang 3: Funktionale Beschreibung und Basisspezifikation von SIM-NET (Functional Description and Base Specification of SIM-NET)...................................................................81

Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite v

Abbildungen Abbildung 1.1: Kommunikationsbeziehungen. .....................................................................3 Abbildung 1.2: Aufbau einer TPEG Nachricht ......................................................................8 Abbildung 1.3: ASN.1 Definition des allgemeinen Rahmens einer C2X-Nachricht auf

Anwendungsebene.....................................................................................12 Abbildung 1.4: ASN.1 Definition Application Specific Data (ASD)......................................12 Abbildung 1.5: ASN.1 Definition der Cooperative Awareness Message (CAM).................15 Abbildung 1.6: Definition der Decentralized Environmental Notification (DEN)..................18 Abbildung 1.7: Beschreibung eines Events basierend auf dem TPEG-TEC Draft

Standard .....................................................................................................18 Abbildung 1.8: Definition der ProbeVehicleData mit gesammelten Fahrdaten aus

einem Fahrzeug..........................................................................................19 Abbildung 1.9: Beschreibung eines Fahrziels ....................................................................20 Abbildung 1.10: Stadtverkehrslage - Überblick ....................................................................36 Abbildung 1.11: Stadtverkehrslage – TrafficValue ...............................................................37 Abbildung 1.12: Stadtverkehrslage – TrafficElement ...........................................................38 Abbildung 1.13: C-WLAN Absicherung im Ad-Hoc Modus...................................................40 Abbildung 1.14: Sequenzdiagramm: Versand von anwendungsspezifischen

Nachrichten über Ad-Hoc C-WLAN ............................................................41 Abbildung 1.15: Sequenzdiagramm: Empfang von anwendungsspezifischen

Nachrichten über Ad-Hoc C-WLAN ............................................................42 Abbildung 2.16: Sequenzdiagram des Steuerungsprotokolls...............................................44

Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite vi

Tabellen Tabelle 1.1: Kommunikationsbeziehungen in simTD und beispielhafte Daten ..................4 Tabelle 1.2: Unformatierte Daten - AppSpecificData .....................................................12 Tabelle 1.3: Aktuelle Zustandsdaten - CoopAwareness ................................................12 Tabelle 1.4: Ereignisdaten - DecEnvNotification (DEN) .................................................16 Tabelle 1.5: Ereignisdaten - DecEnvNotification (DEN): Lokale Gefahrenwarnung......16 Tabelle 1.6: Ereignisdaten - DecEnvNotification (DEN): Baustelleninformation ............17 Tabelle 1.7: Ereignisdaten - DecEnvNotification (DEN): weitere, proprietär

definierte Ursachenkennziffern...................................................................17 Tabelle 1.8: Fahrhistorie - ProbeVehicleData ................................................................19 Tabelle 1.9: Fahrtziel - Destination.................................................................................20 Tabelle 1.10: Kreuzungstopologie - Intersection ..............................................................21 Tabelle 1.11: Verkehrsregeln - TrafficRegulation.............................................................23 Tabelle 1.12: Ampelphaseninformation - SignalState ......................................................24 Tabelle 1.13: Dezentrale Verkehrslage - Sotis.................................................................26 Tabelle 1.14: Verkehrslage - TrafficList............................................................................28 Tabelle 1.15: Textnachricht - TextAnnouncment..............................................................28 Tabelle 1.16: Differential GPS Korrekturdaten .................................................................29 Tabelle 1.17: Korrektur Daten nach RTCM......................................................................30 Tabelle 1.18: Lokale Verkehrsabhängige LSA-Steuerung ...............................................32 Tabelle 1.19: ManualDirectionType..................................................................................33 Tabelle 1.20: LogischePosition ........................................................................................34 Tabelle 1.21: Verkehrsmodell Knotenpunkt LSA .......................................................35 Tabelle 2.22: Protokolle, in OSI-Anwendungsschichten eingeteilt ...................................43 Tabelle 2.23: Absicherung der Protokolle, in OSI-Anwendungsschichten eingeteilt........50

Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 1

Zusammenfassung Das vorliegende Dokument beschreibt die Kommunikationsprotokolle und -schnittstellen zwi-schen den Fahrzeug- und Infrastrukturkomponenten im Projekt simTD. Das Dokument ist als Grobspezifikation zu verstehen, d.h. alle für das Gesamtsystem notwendigen Funktionen und Schnittstellen sind definiert. Dort wo auf bestehende Systeme und technische Standards zurückgegriffen wird, sind diese referenziert und nur die für simTD relevanten Funktionen und Schnittstellen beschrieben. Die für simTD neu zu entwickelnden Funktionen, speziell die C2X-Nachrichten, sind in der standardisierten Metasprache ASN.1 ausgeführt. Die formale Dar-stellung von Daten- und Nachrichtenformaten sowie von Schnittstellen erfolgt in UML Se-quenzdiagrammen. Kodierung und Programmierung von Funktionen und Schnittstellen sind nicht Bestandteil dieses Dokuments.

Den Kern der simTD Architektur bildet der C2X Core, welcher folgende Funktionen erfüllt: Multiplexing, Weiterleitung sowie ggf. Zwischenspeicherung von Nachrichten, die zwischen Fahrzeugen sowie mit der Infrastruktur ausgetauscht werden. Dies geschieht unter Zuhilfe-nahme zusätzlicher Information, wie z.B. der Position von Netzknoten (Fahrzeuge und IRS). Eine Zwischenspeicherung von Nachrichten ist dann erforderlich, wenn ein Netzknoten nicht erreichbar ist (kein Funkkontakt), oder wenn eine definierte Datenrate nicht überschritten werden darf und Nachrichten deshalb zurückgehalten werden müssen. Die Kommunikation kann sowohl im Unicast (Point-to-Point) als auch im Broadcast (Point-to-Multipoint) erfolgen. Der Nachrichten-Broadcast unterstützt dabei topologie-basierte, geo-basierte und single-hop Verfahren.

Über das simTD Netzwerk (SIM NET) sollen verschiedene Anwendungen mit unterschiedli-chen Anforderungen (z.B. Datenrate, Latenzzeit, Nachrichtenpriorität) kommunizieren. Deshalb wurden Datenverkehrsklassen (Traffic Classes) definiert mithilfe derer der C2X Core die verschiedenen Nachrichten und Datenpakete priorisieren kann. Eine bestimmte Dienstgüte kann damit nicht garantiert werden, weil die Kommunikation drahtlos erfolgt und den physikalischen Gegebenheiten der Wellenausbreitung unterliegt. Zumindest kann jedoch der Datenverkehr entsprechend priorisiert werden.

Ein Wireless Manager ist für die Steuerung der Netzwerk- und Transport-Schicht zuständig. Dieser konfiguriert und überwacht die verschiedenen Systeme zur Funkübertragung und stellt das IP Netzwerk bereit.

Zur Absicherung der Kommunikation gegenüber Angriffen Dritter sind entsprechende Sicher-heitsvorkehrungen getroffen.

Für die Durchführung von Feldversuchen werden weiterhin spezielle Testprotokolle bereitge-stellt.

HINWEIS: Bitte beachten Sie die im Kapitel 4 „Resultate“ gezogenen Schluss-folgerungen!


Summary D21.4 Specification of Communication Protocols

This document describes the communication protocols and interfaces between vehicles and infrastructure components for the simTD project. It should be considered as a general system specification that contains all functionalities and interfaces required for the simTD system to work properly. Existing standards and technical systems are used whenever possible. In this case, details are limited to those parts relevant for the simTD system. All functions that have to be developed specifically for simTD are defined in the standardized meta-language ASN.1. Formal descriptions of data and message formats as well as interfaces are provided as UML sequence diagrams. Detailed encoding and programming of functions and interfaces are beyond the scope of this document.

The foundation of the simTD architecture is the C2X core, which provides multiplexing, for-warding and, if necessary, buffering of all messages that are exchanged between vehicles and sent to the infrastructure. For performing this functionality, the C2X core uses supple-mentary information, such as the position of network nodes (vehicles and roadside stations). Buffering of messages may be necessary if nodes are unreachable (no wireless connectivity) or if a given bandwidth shall not be exceeded and a message transfer therefore need to be postponed. Communication uses unicast (point-to-point) as well as broadcast (point-ot-multi-point). Different broadcast methods are supported: topology-based, geo-based and single-hop.

A range of applications with different requirements concerning data rate, latency and priority will communicate over the simTD network (SIM NET). Therefore, the concept of data traffic classes has been introduced. Based on these traffic classes, the C2X core can prioritize and schedule messages and data packets. This does not guarantee a certain quality of service, since communication is wireless and suffers randomly occurring, propagation-related distur-bances. However, data traffic can at least be adequately prioritised.

A Wireless Manager controls the network and transport layer. It configures and monitors the different wireless communication subsystems and provides the IP connectivity to the layers above.

Sufficient security measures are taken to prevent attacks on the system by third parties.

Specific routines and protocols are defined to facilitate field trials.


1. Nachrichtenformate auf Anwendungsebene

1.1 Allgemein

1.1.1 Kommunikationsbeziehungen

VZH (a ) IC S (b )

IR S Land (h)

IR S Stadt (f)

IVS (g)

IGLZ (c)

LSA-Steuergerä t (e)

Inte rne t

IKR (d)

1 2

3.1

3.25

4

12

9

8

7

6

11

Abbildung 1.1: Kommunikationsbeziehungen. Referenzierung durch Schnittstellennummern (roter Kreis) und Kennbuchstabe der empfangenden Komponente; graue Kästen zeigen Elemente der VZH grüne Kästen Elemente der Stadt Frankfur

Die Kommunikationsbeziehungen 9, 11 und 12 laufen im Wesentlichen über die Funkkom-munikation ITS-G5. Im Rahmen von simTD sind die Kommunikationsmodule der IVS und IRS mit Consumer-WLAN ausgerüstet, die auch eine alternative Kommunikation im Ad-hoc-Modus zulassen.

Die Beziehung 3.1 bezeichnet eine Verbindung über Mobilfunk. Hier werden je nach Ab-deckung die Verfügbaren Datendienste genutzt, z.B. UMTS. Über den Service provider besteht dann ein entsprechender Anschluss 3.2 an die ICS, genauer an die VsZ. Die Ander-en Kommunikationskanäle sind weitestgehend durch bestehende Infrastrukturarchitekturen der HLSV und der Stadt Frankfurt vorgegeben und werden hier nicht näher beschrieben

Die folgenden Kommunikationsbeziehungen und Protokolle sind für die Schnittstellen vorgesehen:


Tabelle 1.1: Kommunikationsbeziehungen in simTD und beispielhafte Daten

Von Nach Daten (Beispielhaft)

VzH ICS Verkehrsdaten (Fernstraßen), Baustellendaten (Land) 1 (b)

1 (a) ICS VzH

2 (b) IGLZ ICS Städt. simTD-Verkehrslage, Baustellenmeldungen, Störungsmeldungen,

2 (c) ICS IGLZ simTD- Gesamtverkehrslage, Hinderniswarnung

ICS IVS Fahreranweisungen 3

IVS ICS

ICS IRS Hinderniswarnung, simTD-Gesamtverkehrslage 4 (h)

4 (b) IRS ICS

IGLZ IRS Städt. simTD-Verkehrslage, Hinderniswarnung 5 (f)

5 (c) IRS IGLZ Fahrzeugposition, Fahrtziel, Abbiegewunsch, Geschwindigkeit

IGLZ IKR Rahmensignalpläne 6 (d)

6 (c) IKR IGLZ Detektorinformationen, Betriebszustandsinformationen, Signalzeiten

IKR LSA Steuergerät Rahmensignalpläne 7 (e)

7 (d) LSA Steuergerät IKR Detektorinformationen, Betriebszustandsinformationen, Signalzeiten

IRS LSA Steuergerät Fahrzeugposition, Fahrtziel, Abbiegewunsch, Geschwindigkeit

8 (e)

8 (f) LSA Steuergerät IRS Daten für Ampelphasenassistent (Betriebszustandsinformationen, Grünzeiten)

IVS IRS Fahrzeugposition, Fahrtziel, Abbiegewunsch, Geschwindigkeit

9 (f)

9 (g) IRS IVS Daten für Ampelphasenassistent (Betriebszustandsinformationen, Grünzeiten), städt. simTD-Verkehrslage, Hinderniswarnung

VsZ IRS 10

IRS VsZ Fahrzeugbewegung/-zustand, aufgezeichnete Bewegungs-/Wetterdaten, Ereignisdaten, Fahrtziel

11 (g) IVS IVS Fahrzeugbewegung/-zustand, Ereignisdaten, Fahrtziel

IVS IRS 12 (h)

12 (g) IRS IVS

Web-Inhalte

Die folgenden Kapitel beschreiben die Inhalte und Formate von Nachrichten im simTD Sys-tem. Dabei sind Nachrichten logisch zusammengefasste Dateneinheiten, die als Einheiten übertragen und verarbeitet werden. Dabei werden einige Nachrichten zum Teil von einem Format in ein anderes Format umgesetzt. Dies geschieht vor allem in den IRS.


Zu den einzelnen Nachrichten wird zunächst die Quelle der Nachricht angegeben. D.h. die Komponente oder Funktion, die die Information in der Nachricht erzeugt und das Aussenden der Nachricht veranlasst.

Weiter sind Informationssenken angegeben. Es handelt sich um Funktionen, die den Inhalt der Nachrichten auswerten.

Zuletzt sind die Schnittstellen aufgelistet, über die die Nachricht gesendet wird. Dabei ist die Nummer der Schnittstelle angegeben und der Kennbuchstabe der empfangenden Kom-ponente.

1.1.2 Existierende Standards

Soweit dies die Arbeit in simTD vereinfacht, werden vorhandene Nachrichtenformate und -protokolle eingesetzt. Dies gilt sowohl für Netzwerkprotokolle, als auch für Datenformate. Einige dieser Standards werden hier vorausgesetzt und nicht weiter erwähnt.

Hierzu gehört z.B. der Zugriff auf die Fahrzeugdaten über die VAPI, aber auch Daten zur LSA-Steuerung.

1.1.2.1 ASN.1 ASN.1 eignet sich zur abstrakten, implementierungsunabhängigen Beschreibung in Kommu-nikationsprotokollen, insbesondere für Protokolle der oberen Schichten des OSI-Referenz-modells. Daher wird die Information der Anwendungsschicht der C2X-Nachrichten, d.h. Nachrichten, die in dem dezentralen Netzwerk zwischen ITS-Stations ausgetauscht werden, in ASN.1 beschrieben. Standardisierungsaktivitäten von ETSI und SAE in diesem Bereich benutzen ASN.1. Daher und um die Komplexität des simTD Systems beherrschbar zu halten werden C2X-Nachrichten ausschließlich in ASN.1 spezifiziert.

Aus den ASN.1 Spezifikationen werden mit dem Tool ASN1C von Objective Systems Inc. Javaklassen generiert und in dem C2X-Message Bundle auf der Application Unit (AU) angeboten, welche die Informationen in dekodierter Form verfügbar machen. Diese Klassen erlauben dann auch das En-/Dekodieren der Information nach dem standardmäßigen Enkodier-Verfahren unaligned PER. Dazu wird eine Runtime Library angesprochen, die auch mit dem C2X-Bundle zur Verfügung gestellt wird. Das C2X-Bundle wird sowohl auf den IVSs, als auch auf den IRSs integriert.

1.1.2.2 OTS2 OTS21 und OTS (OpenTrafficSystems) entstanden auf Initiative der OCA2 (Open Traffic Systems City Association), dem internationalen Verband Öffentlicher Baulastträger und Betreiber. Seine Wurzeln hat OTS in der OCIT®-Initative, die auf die Schaffung von Schnittstellenstandards für Lichtsignalsteuerungsysteme ausgerichtet ist.

Mit dem Begriff OTS (Open Traffic Systems) verbindet die OCA die visionäre, langfristig aus-gerichtete Zielvorstellung von sog. offenen Systemen und Systemlandschaften im Verkehrs-bereich. Unter offen werden solche Systeme verstanden

1 http://www.ots2.org 2 http://www.oca-ev.org

http://www.ocit.org/�http://www.ocit.org/�


• die über eine offene und flexible Systemarchitektur verfügen,

• deren Teilsysteme über Schnittstellen kommunizieren, die konform zum OTS-Kommunikationsstandard sind und

• die darüber dem Anspruch der OCA an Herstellermischbarkeit gerecht werden.

OTS ist eine Marke der OCA und ist aus dem Namen der OCA abgeleitet. Verbunden damit ist die Selbstverpflichtung der OCA, Ergebnisse des OTS-Prozesses für alle Interessierten frei verfügbar zu machen.

OTS ist ursprünglich für die Anwendung in städtischen Systemen konzipiert worden. Durch eine bereits in Angriff genommene Integration mit dem schon international in Standardisierung befindlichen DATEX II-Standard kann OTS 2/DATEX II aber auch für den Verbund von Innerorts- und Außerortssystemen eingesetzt werden, die über den Bereich der Lichtsignalanlagensteuerung hinaus gehen.

Kernpunkte der OTS2-Schnittstellenspezifikation sind:

• Allgemein verwendbares, gut ausgearbeitetes, schichtenbasiertes Kommunikationsprotokoll

• Aufbau – Klar strukturiert, Schichtentrennung – Modularisierung der Funktionalitäten

• Erweiterbarkeit – Modulare Ergänzungen möglich – Konfigurationsaushandlung

• Funktionalität – Erweitertes Rollenmodell – Verbessertes Fehlerverhalten – Bessere Testbarkeit

• Integrationsfähigkeit – OCIT-I – DATEX II

• Verbreitung im Innerorts-Bereich

Einbindung in simTD

OTS2 bringt ein Datenmodell mit, welches jedoch in simTD nicht angewendet wird (d.h. in simTD wird in erster Linie auf die Protokollfunktionalitäten von OTS2 zurückgegriffen).

Als Datenmodell für die OTS2-Übertragung in simTD eignet sich das sehr umfangreichere und in der Verkehrstechnik etablierte Datenmodell von DATEX II (siehe nachfolgendes Kapitel).

Das OTS2-Protokoll wird in simTD auf folgenden Schnittstellen eingesetzt:

• 2 (IGLZ – VsZ)

• 5 (IRS – IGLZ)

• 8 (IRS – LSA; nur im Testfeld)

http://www.datex2.eu/�


1.1.2.3 DATEX II als Datenmodell Datex II ist der Nachfolger des DATEX-Standards und findet bei der Beschreibung verkehrs-technischer Daten auf der Infrastrukturseite im Außerortsbereich Verwendung.

DATEX II bietet ein

• Umfangreiches fachliches Daten- und Referenzierungsmodell

• (plattformunabhängig, Trennung Dateninhalte und Austausch)

• Dreistufiges Erweiterungsmodell

• Starke Verbreitung im Außerortsbereich

DATEX II verfügt auch über minimale Protokollfunktionen, die jedoch in simTD nicht verwen-det werden. Das DATEX II-Datenmodell wird auf dem OTS2-Protokoll angewendet.

Integration in C2X (simTD)

Daten werden dabei in xml-kodiert. Eine entsprechende Schemadatei ist frei verfügbar.3

• DATEX II ist deutlich abstrakter und weniger meldungsorientiert als C2X

• In DATEX II werden Daten in UML (abstrakt) modelliert • DATEX II verwendet hierzu ein eigenes UML-Profil

• Weitere Metadaten, die zu einer Abbildung auf eine Austauschplattform (hier: XML-Schema; Transfersyntax!) notwendig sind, werden ebenfalls in UML Stereotypen & Eigenschaftswerten erfasst

• C2X verwendet ASN.1 zur (abstrakten) Beschreibung der auszutauschenden Meldun-gen (Hinweis: Unterschied zwischen Daten und Meldungen!)

• Transformation in Transfersyntax ist Teil des Standards (Encoding Rules)

• Für DATEX II ⇒ C2X gibt es zwei Möglichkeiten – Generierung einer DATEX II XSD und Transformation nach ASN.1 – Generierung einer neuen Plattformabbildung (PSM) für C2X-ASN.1

• Für C2X ⇒ DATEX II muss auf die Re-Modellierung in UML zurückgegriffen werden

Kombination mit OTS2

Es ist wichtig bei der Entwicklung neuer Nachrichtenformate eine Kompatibilität zu DATEX II herzustellen. Insbesondere für die Kommunikation auf der Infrastrukturseite wird eine Kom-bination von OTS2 und DATEX II angestrebt. Dies bringt u.a. folgende Vorteile:

• Die Protokolloptionen von DATEX II sind offen gestaltet und lassen verschiedene Optionen zu.

• Das Protokoll von OTS2 ist so gestaltet, dass es unabhängig von einem bestimmten Datenmodell verwendbar ist. Zusätzlich ist das OTS Datenmodell flexibel erweiterbar.

• Beides zusammen ermöglicht den Transport auch von DATEX II Daten über das OTS Protokoll.

• Die bisherigen Anwendungsbereiche ergänzen sich gut. Z.B. ist in DATEX II der Be-reich Verkehrsmeldungen sehr gut ausgebaut, der in OTS bisher fehlte.

3 Offizielle DATEX II Web-Seite mit Downloadmöglichkeit: http://www.datex2.eu/


1.1.2.4 TPEG TPEG ist ein Standard für die Kodierung von Telematik-Informationen, die von einer Zentrale verbreitet werden. Er ist in erster Linie als Erweiterung und Verbesserung von TMC entwickelt worden. Hierbei wurden, z.B. auch Kodierverfahren für ÖV-Information mit aufgenommen. TPEG existiert als ISO Standard.

TPEG beinhaltet relevante Tabellen (Enumerations), die auf jeden Fall übernommen werden sollten, z.B. für die Klassifizierung von Ereignissen oder Fahrzeugtypen. Diese gehen in die ASN.1 Spezifikation ein und ermöglichen ein einfaches Zusammenführen von Daten. Einige Beispiele hierfür sind:

• Fahrzeugtyp: ISO/TS 18234-4:2006 Tabelle rtm01 vehicle_type

• Fahrzeuguntertyp: ISO/TS 18234-4:2006 Tabelle rtm02, rtm05, rtm06, rtm07, rtm08, rtm09, rtm11, rtm16, rtm40, rtm48

• Level 1 Event Klassen: ISO/TS 18234-4:2006 Tabelle 1

TPEG definiert dazu sowohl Datenelemente zur Beschreibung relevanter Information als auch die Kodierung für die Übertragung. In den ITS-Stations wird kein TPEG-Encoder zur Verfügung stehen. Nachrichten, die in den ITS-Stations erzeugt werden, sind in ASN.1 spezi-fiziert und werden durch einen ASN.1 Runtime Library en- bzw. dekodiert. Dabei schränken die in ASN.1 definierten Datenfelder aber die Möglichkeiten, Daten zusammenzustellen, gegenüber TPEG deutlich ein. Sie lassen damit nicht so viele Freiheiten, erleichtern aber die Verarbeitung in einem dezentralen System und sind kompakter.

TPEG bietet verschiedene Profile an. TPEG Automotive Profile (TPEG TAP) ist eine speziell für den Einsatz in Navigationsgeräten entwickelte Spezifikation, die die Spezifikation TPEG-TEC (Traffic Event Compact) beinhaltet. Dieses Protokoll wurde für die Übertragung von verkehrsrelevanten Inhalten entwickelt. In der folgenden Abbildung kann man exemplarisch die Struktur einer TPEG-TEC Nachricht sehen.

Abbildung 1.2: Aufbau einer TPEG Nachricht

1.1.3 Nomenklatur

Die Nomenklatur der einzelnen Datenelemente erfolgt durchgehend in Englisch und orientiert sich an dem VAPI Standardprofil, SAE J2735 Standard bzw. C2C-CC/ETSI, DATEX II, TPEG, bzw. anderen referenzierten Standards

1.1.4 Positionskodierung

simTD verwendet Geo-Koordinaten mit Längen- und Breitengrad, Höhe und Richtung, sowie optional Straßennamen. Als Koordinatensystem wird das in der Navigation und Satelliten-Positionierung übliche System WGS84 verwendet. Die teilweise in der deutschen


Infrastruktur verwendeten Gauss-Krüger Koordinaten werden nicht für die Kommunikation mit den Fahrzeugen benutzt.

Die Stützung der Positionierung vor allem auf die Geokoordinaten gewährleistet die Möglichkeit im simTD System auch ohne eine digitale Karte teilzunehmen. Außerdem kann die Positionskodierung in allen Fahrzeugen leicht erzeugt werden. Eine Beschreibung mit WGS84 entspricht einer der vielen Beschreibungsmöglichkeiten, die auch TPEG-LOC anbietet, allerdings mit anderer Granularität der Koordinaten. Auf die Verwendung textueller Repräsentation wird aus Performanzgründen verzichtet.

Auch wenn in simTD ein gemeinsames Kartenmodul in den Fahrzeugen verwendet wird, ist eine Referenzierung auf Kanten-IDs nicht sinnvoll, da diese gemeinsame Datengrundlage in kommerziellen Systemen nicht gegeben sein wird. Allerdings ist durch die gemeinsame Karte in simTD auf jeden Fall gewährleistet, dass Koordinaten, die aus dem Map-Matching dieser Karte aus einer Komponente stammen, auch in einer anderen Komponente dem richtigen Streckenabschnitt zugeordnet werden können. Dies gilt jedoch nicht, wenn die Zentrale andere digitale Karten verwendet.

1.1.5 Zeitdaten

Eine einheitliche Zeitbasis ist wesentlich für die Zusammenarbeit der Anwendungen eines Kooperativen Systems, aber auch für den Vergleich und die Auswertung geloggter Daten der Versuche. Es ist genau zu definieren welche Zeit in simTD verwendet werden soll. Hierbei sollte allgemein ein einheitliches Zeitmodell verwendet werden.

Es gibt prinzipiell zwei Quellen, die eine Zeit zur Verfügung stellen können: die Zeitinforma-tion, die über das GPS-System verteilt wird, oder über Langwellensender. In Deutschland ist letzteres vor allem DCF77. Das GPS System basiert auf einer eigenen GPS-Zeit; DCF77 auf der Internationalen Atomzeit TAI. GPS-Zeit und TAI differieren um einen festen Betrag von 19s. Allerdings überträgt sowohl DCF77 als auch GPS die Korrektur durch Schaltsekunden, sodass im Empfänger die Einheitszeit UTC vorliegt und auch meist standardmäßig ausgegeben werden. Dabei kommt es aber während der Schaltsekunden zu Unstetigkeiten im Zeitstempel.

Die GPS-Receiver werden in den Fahrzeugen als Zeitgeber eingesetzt. Die Rechner der VZH arbeiten auf der Grundlage der UTC-Zeit. Im VZH-System ist ein ntp-Server eingerichtet, der allen Beteiligten die gemeinsam zu verwendete Zeit verbindlich vorgibt. Da die VsZ einerseits mit Zeitstempeln versehene Daten aus dem VZH-System übernimmt und andererseits über LAN (und Firewall) mit dem VZH-Server verbunden ist, bietet es sich an, dass die Server der VsZ ebenfalls ihre Zeit vom ntp-Server beziehen.

Daher soll in allen Stations und für alle Zeitstempel die UTC-Zeit verwendet werden. Da in IVS, IRS und ICS UTC-Zeit vorliegen, ist also keine Korrektur erforderlich.

Für die Übertragung der Zeit wird das POSIX Zeitformat basierend auf der UTC verwendet, dass die Sekunden seit 1.1.1970 0 Uhr an gibt. Das POSIX-Format basiert normalerweise auf UTC, doch sind zum Teil auch abweichende Definitionen gebräuchlich. Im Jahr 2038 wird es im POSIX Zeitformat zu einem Überlauf kommen. Dies ist im Rahmen von simTD nicht relevant und kann durch eine saubere Implementierung abgefangen werden. Ebenso sind die Unstetigkeiten bei Schaltsekunden abzufangen.


1.2 C2X Nachrichtenformate

1.2.1 Einsatzgebiet der C2X-Nachrichtenformate

Das C2X-Netzwerk läuft primär über ITS-G5 (802.11p) Kommunikation zwischen den IVSs und den IRSs, sowie den IVSs untereinander. Daneben wird in simTD auch die Verbreitung dieser Nachrichten über ITS IMT Public (Mobilfunk) und Consumer WLAN (IEEE802.11b/g) getestet. Zudem werden evtl. die C2X-Nachrichten im Infrastrukturnetz auch in der spezifizierten Form zwischen der ITS Central Station und den IRSs weitergeleitet, falls eine Verarbeitung nicht lokal in den IRSs erfolgt.

In dem C2X-Netzwerk in simTD werden standardisierte Nachrichten paketorientiert verteilt. Im Wesentlichen geschieht dies über Broadcast-Mechanismen.

1.2.2 Informationen einer Nachricht

Neben den Nutzdaten (application payload), die über die unten aufgeführten ASN.1 Formate definiert sind ist insbesondere bei C2X-Nachrichten noch Information aus anderen Kommunikationsschichten zur Verfügung zu stellen. Dies sind insbesondere Daten aus der Netzwerkschicht, Transportschicht und aus der IT-Sicherheit.

Netzwerkschicht:

Der Nachrichtenheader der Netzwerkschicht enthält Informationen über den Autor der Nachricht mit dessen ID, Position, Richtung und Geschwindigkeit. Außerdem sind Adress-informationen interessant, die Aufschluss geben, für welches Gebiet die Information adressiert ist und wie lange die Information gültig ist.

Weiterhin ist von Interesse, über welches Medium (ITS 5GA, ITS IMT Public oder Consumer WLAN) die Nachricht kommuniziert wird.

Transportschicht:

Informationen der Transportschicht ermöglichen die Nachrichten schon unterhalb der Anwendungsschicht zu selektieren und entsprechend zu verteilen, ohne die ASN.1 Daten zu dekodieren. Außerdem ermöglichen sie eine grobe Filterung der Daten in der Umfeldtabelle, ohne die spezifischen Nachrichtenformate zu kennen. Der Wert besteht aus drei logischen Elementen:

• 1 Byte: Packet Type, der die in den folgenden Kapiteln beschriebenen Typen unterscheidet;

• 1 Byte: Content Type;

• 1 Byte: Content Subtype.

Content Type und Content Subtype beschreiben die Information der protocolMsg als Enume-ration. Beispielsweise wird bei einer DEN, welche über eine Unfallstelle informiert, diese Information als Enumeration auch in den Content Subtype übertragen (Content Type =Gefahrenwarnung, Content Subtype =Unfallstelle), um eine Vorfilterung zu ermöglichen. Falls für einen Nachrichtentyp keine solche Vorfilterung möglich oder erwünscht ist, werden die Indizes automatisch jeweils mit einer 0 vorbelegt und sollten nicht davon abweichen.

Um eine Eindeutigkeit der Content (Sub)Type-Felder zu gewährleisten, werden für die rele-vanten Nachrichtentypen – beispielsweise für DEN und AppSpecificData – Indexlisten erstellt, die auf Projectplace TP2 AP21 A214 Nachrichtenformate als Excel-Datei abgelegt werden. Neue Indizes sollten dort sparsam und nur bei konkretem Bedarf angelegt


werden. Unnötige Typreservierungen und fehlende Strukturierung können ansonsten zu einer Unübersichtlichkeit der Typen führen.

IT-Sicherheit:

Aus der IT-Sicherheit werden Informationen gegeben, ob Signaturen und evtl. Verschlüsse-lungen erfolgreich verarbeitet wurden. Außerdem sind hier die Ergebnisse der Plausibilitäts-prüfung enthalten. Um den Funktionen eine feste Zuordnung der Fahrzeuge zu bieten wird durch das Tracking der Plausibilitäskomponente eine LocalNodeID der C2X-Nachricht hinzugefügt, die auch bei einem Wechsel der Pseudonyme konstant bleibt.

1.2.3 C2X Application Payload: Allgemeiner Rahmen auf Anwendungssschicht

Nachrichten im C2X-Netzwerk sind auf Anwendungsebene in ASN.1 definiert. Eine Beschrei-bung der allgemein verwendeten Datentypen findet sich im Anhang. Die Nachrichten haben einen allgemeinen Rahmen in dem wesentliche Parameter enthalten sind. Diese Datenele-mente werden in der Umfeldtabelle benutzt, um Nachrichten zu verwalten und zugreifbar zu machen und im Relevanzfilter nach vorgegebenen Kriterien filtern zu können.

Das Element protocolMsg enthält dann den weiteren Dateninhalt in einem entsprechenden Datenformat. Neben den vordefinierten Inhalten gibt es noch einen Nachrichtentyp AppSpe-cificData mit hier unspezifizierten, anwendungsspezifischen Inhalten. Für Definition und Ko-dierung der anwendungsspezifischen Nachrichten sind die Anwendungsentwickler zuständig.

Ausnahme: Nachrichten mit DGPS-Korrekturdaten werden in simTD nicht ASN.1 kodiert und nutzen daher auch nicht den allgemeinen Rahmen C2XAppPayload.

C2XAppPayload::= SEQUENCE { -- protocol version of the protocolMsg element protocolVersion INTEGER (0..255), -- Unique identifier of information about a situation from one originator -- messages with the same ActionID and later generationTime replace the previous message -- a CAM Message shall always hav ActionID==0 actionID ActionID, -- indicates the explicit cancelation of an message -- with the same action IDs from the same originator cancelationFlag BOOLEAN, -- timestamp as reference for message content, e.g. station states, -- or generation time of data, e.g., jam detection generationTime LongTimeStamp, -- time span after generationTime when the message shall be deleted from all databases.. validityDuration ValidityDuration, -- point as reference position for information. The detailed meeaning is defined by the application referencePosition ReferencePosition OPTIONAL, -- type depending content of the message protocolMsg CHOICE { appSpecificData [APPLICATION 1] AppSpecificData, coopAwareness [APPLICATION 2] CoopAwareness, decEnvNotification [APPLICATION 3] DecEnvNotification, probeVehicleData [APPLICATION 4] ProbeVehicleData, destinationData [APPLICATION 5] DestinationData, intersectionData [APPLICATION 6] Intersection, trafficRegulationData [APPLICATION 7] TrafficRegulationData, signalStateData [APPLICATION 8] SignalStateData, sotisData [APPLICATION 9] SotisData, trafficListData [APPLICATION 10] TrafficListData, textAnnounceementData [APPLICATION 11] TextAnnouncementData, ..., -- additional messages to be defined here later on ... }


-- the index APPLICATION will be together -- application dependent description of content used for data filtering on high level. -- e.g. cause code and subcause for decentralized environmental notification }

Abbildung 1.3: ASN.1 Definition des allgemeinen Rahmens einer C2X-Nachricht auf Anwendungsebene

1.2.4 Unformatierte Daten - AppSpecificData

Beschreibung Tabelle 1.2: Unformatierte Daten - AppSpecificData

Packet Type

Content Type

Content Subtype

Quelle Senke Schnittstelle Traffic Class

IT-Sicherheit

1 -- -- -- -- -- -- --

Dieser Nachrichtentyp steht Anwendungen zur Verfügung, damit sie eigene, in Eigenregie kodierte/dekodierte Daten übertragen kann. Er enthält eine Serie von Bytes mit nicht näher spezifizierter Bedeutung. Hierbei muss auf Senderseite und Empfängerseite die genaue Spezifikation des Inhalts und der Kodierung in der Awendung bekannt sein, um die Daten in der Funktion auszuwerten. Die Kodierung muss nicht unbedingt den sonst verwendeten En-coding Rules entsprechen. Hierbei können die Felder Content Type und Content SubType genutzt werden, um der empfangenden Funktion kenntlich zu machen, um welche Daten es sich handelt, d.h. ob Sie für die Funktion relevant sind und wie Sie zu behandeln sind.

Format AppSpecificData ::= OCTET STRING

Abbildung 1.4: ASN.1 Definition Application Specific Data (ASD)

1.2.5 Aktuelle Zustandsdaten - CoopAwareness

Tabelle 1.3: Aktuelle Zustandsdaten - CoopAwareness

Packet Type

Content Type

Content Subtype


IT-Sicherheit

2 0 0 CAM-Dispatcher (F_1.1.2)

F_1.3.3, F_1.3.2, F_2.1.4, F_2.2.4

11g, 9g, 9f, (weiterleitung über 8e, 5c)

02 signiert

Beschreibung Die Nachricht informiert über die Präsenz der ITS-Station, die Position, grundlegende Eigen-schaften und Zustandswerte. Alle ITS-Stations, d.h. IVSs und IRSs senden diese Daten periodisch aus. Diese Nachrichten werden in den umliegenden ITS-Stations gesammelt und in deren Komponente „Umfeldtabelle“ als Nachbarschaftstabelle den Funktionen zur Verfügung gestellt.

Die Nachricht hat einen sehr generellen Aufbau. Für verschiedene Typen der ITS-Stations wird der obligatorische Inhalt in sogenannten Profilen festgelegt. Der Aufbau der CAM ist an den aktuellen Arbeitsstand bei C2C-CC und ETSI angelehnt. Neben der Information, die in


dem Datencontainer der Anwendungsschicht übertragen wird, werden folgende wesentliche Informationen im Netzwerkheader übertragen und auf der Empfängerseite mit genutzt:

• Station ID

• TimeStamp

• Position (Longitude, Latitude)

• Speed, heading

• Accuracy (position, speed, heading)

Außerdem wird es auf Netzwerkebene ein Mechanismus zum Service Announcement geben. Zum Beispiel kommuniziert eine IRS, dass sie Probe Vehicle Date entgegennimmt oder ein IRS Kommuniziert, dass sie Kreuzungstopologie-Daten broadcastet. Zusätzlich enthalten die Daten Infomation zu Übertragungskanälen, die auf der Netzwerkschicht relevnat sind. Informationen des Service Announcements sind nicht Teil der CAM. Für die Anwendungen relevante Informationen werden über eine andere Schnittstelle auf der VAU zur Verfügung gestellt.

Die Datenobjekte in den TaggedValue Listen der einzelnen Profile sind noch nicht vollständig spezifiziert, da eine Harmonisierung mit dem bestehenden Datenglossar noch erfolgen muss. Unten sind beispielhaft ein paar Datenobjekte angefügt.

Profil: basicVehicle Das Profil „basicVehicle“ gilt vor allem für private Fahrzeuge. Von diesem Profil werden wei-tere Profile abgeleitet, z.B. emergencyVehicle. Da der Status PanicBrake von F_2.2.3 aus-gewertet werden soll, muss die Information auch durch eine Heuristik gesetzt werden, wenn sie über den CAN nicht verfügbar ist.

stationCharacteristics: ‘111’B mobil, privat und physikalisch relevant obligatorische TaggedValue: vehicleType, stationLength, stationWidth,

curvature, longitudinalAcceleration, PosConfidenceEllipse, exteriorLights (mit Blinker und Warnblinker), accelerationControl (insbesondere PanicBrake, die evtl. berechnet werden muss)

Situative obligatorische TaggedValue: confidenceStationLength, falls Fahrzeuglänge nicht genau angegeben werden kann, z.B. wegen Anhänger

crashStatus, falls Crash Signal aktiv

Optionale TaggedValue: timeToStopLine oder distanceToStopLine, turnAdvice, occupancy, dooropen, curvatureGradient

Profil: basicIRS Die basicIRS ist eine ITS Roadside Station die prinzipiell alle Aufgaben der Infrastruktur übernehmen kann, von ihr werden speziellere Profile abgeleitet. Die Station ist so montiert, dass sie den Verkehr nicht direkt beeinflusst, d.h. keine Kollisionsgefahr zu anderen Verkehrsteilnehmern besteht.


stationCharacteristics: ‘000’B stationär, nicht privat und nicht physikalisch relevant

obligatorische TaggedValue: -- Situative obligatorische TaggedValue: -- Optionale TaggedValue: im Kontext von simTD nicht verwendet.

Entsprechende Spezifikationen außerhalb von simTD liegen nicht vor.

Profil: emergencyVehicle Emergency Vehicles sind öffentliche Einsatzfahrzeuge, die potentiell mit Blaulicht fahren können. Hierbei ist es prinzipiell möglich, dass die Fahrzeuge ihr Profil zwischen basicVehicle und emergencyVehicle wechseln. Dies ist insbesondere bei zivilen Streifenwagen sinnvoll. Für die Absicherung der Nachrichten von emergencyVehicles ist es wichtig, dass ein Pseudonymwechsel durchgeführt wird, sobald zwischen den Profilen umgeschaltet wird. Einsatzfahrzeuge können mit zivilen Pseudonymen als basicVehicle kommunizieren und als emergencyVehicle mit einem entsprechend signierten Zertifikat.

stationCharacteristics: ‘101’B mobil, nicht privat und physikalisch relevant

obligatorische TaggedValue: wie “basicVehicle” plus EmergencyResponseType

Situative obligatorische TaggedValue: wie “basicVehicle” Optionale TaggedValue: lightBarInUse, sireneInUse

Profil: publicTransportVehicle Public Transport Vehicle sind Fahrzeuge des öffentlichen Nahverkehrs. Ihre Unterscheidung ist z.B. für Vorrangschaltungen relevant (siehe Kapitel 1.4.2)

stationCharacteristics: ‘101’B mobil, nicht privat und physikalisch relevant

obligatorische TaggedValue: wie “basicVehicle” plus PublicVehicleType

Situative obligatorische TaggedValue: wie “basicVehicle” plus "DoorOpen", während Fahrgasttüren geöffnet sind und 30s danach

Optionale TaggedValue: wie “basicVehicle” plus lineRef (Linie), courseOfJourneys (Kurs), routeRef (Route), trafficLightPriority (ÖV-Priorität), scheduleDevaition (Fahrplanabweichung), occupancy (Besetzungsgrad), ÖPNV Fahrzeuge sollten alle verfügbaren optionalen Daten senden


Format -- The root data frame for cooperative awareness messages CoopAwareness ::= SEQUENCE { -- Basic characterization of a node. A more detailed classification can be given by -- VehicleType. stationCharacteristics SEQUENCE { mobile BOOLEAN, private BOOLEAN, physicalRelevant BOOLEAN, ... }, -- tagged list has optional and mandatory entries depending on the profile of the -- ITS station, this is defined in a separate document taggedList SET SIZE(0..32) OF TaggedValue }

Abbildung 1.5: ASN.1 Definition der Cooperative Awareness Message (CAM)

Ablauf Das Sendeintervall wird unter den folgenden Randbedingungen situationsabhängig angepasst:

a) Unter Normalbedingungen sendet jedes Fahrzeug mit einem Sendeintervall: CAM_DT_NORM4 Normalbedingung ist eine gleichförmige, geradlinige Bewegung mit der Geschwindigkeit CAM_V_NORM

b) Für ein deterministisch beherrschbares System läuft der CAM Sendeprozess unabhängig von den Anwendungen. Die Regeln müssen einfach und in jedem Fahrzeug identisch zu berechnen sein

c) Das maximale Sendeintervall ist CAM_DT_MAX. Dies ist das normale Sendeintervall für IRS

d) Das minimale Sendeinterval ist CAM_DT_MIN e) Das System prüft zyklisch alle CAM_DT_CHECK ob auf Grund einer Bedingung eine

CAM gesendet werden soll. Ein Versand wird im Rahmen dieser Randbedingungen getriggert, wenn eine der folgenden Bedingungen erfüllt ist:

(1) Positionsänderung größer als CAM_DT_NORM × CAM_V_NORM (2) HeadingÄnderung > atan(CAM_DS_MAX_LATERAL / (CAM_DT_NORM ×

CAM_V_NORM)) (3) |Positionsänderung – valt * dt| > CAM_DS_MAX_LONGITUDINAL (4) Geschwindigkeitsänderung > größer als CAM_DV_MAX (5) spontanes Senden bei CAN Ereignis:

– Blinker geändert – Warnblinker geändert – Gefahrenbremsung – Türsignal ÖV – Einsatzfahrzeugstatus

Die ITS-Station (IVS und IRS) signiert die Nachrichten.

4 Durch Großbuchstaben gekennzeichnete Parameter werden in dem Funktionsentwicklungsteam

F_1.1.2 festgelegt.


1.2.6 Ereignisdaten - DecEnvNotification (DEN)

Tabelle 1.4: Ereignisdaten - DecEnvNotification (DEN)

Packet Type

Content Type

Content Subtype


IT-Sicherheit

3 causeCode (siehe

Tabelle)

subCauseCode (siehe Tabelle)

F_1.1.3, F_1.1.5, F_1.2.2, F_2.1.x, F_2.2.3

F_1.1.3, F_1.2.2, F_1.3.2, F_2.1.x, F_2.2.3

11g, 9g, 9f, (weiterleitung über 4b, 5c, 3b, 4f, evtl.

3g?,)

01, 10, 11

signiert, verschlüs-

selt

Beschreibung DENs (Decentralized Environmental Notification) sind Nachrichten die Information zu genau einem ortsgebundenen Ereignis enthalten, z.B. über ein Stauende oder Nebelgebiet. Dieses Ereignis kann punktförmig oder ausgedehnt sein. In den IVS wird eine DEN zu den jeweiligen Ereignissen von den Funktionen F_2.1.1 „Hinderniswarnung“, F_2.1.2 „Stauendewarnung“, und F_2.1.3 „Straßenwetterwarnung“ erzeugt. Zusätzlich werden noch DEN auf der Zentrale in der Funktion F_1.1.3 „Ermittlung der Verkehrswetterlage“ erzeugt. Informationen zu Baustellen werden in der Funktion F_1.2.2 erzeugt. Baustelleninformation enthält neben der Art der Baustelle und deren Länge und Spurbeschränkungen auch die lokal erfasste Verkehrslage.

Daten werden in den Fahrzeugen zur Gefahrenwarnung verwendet und auch in den Zentra-len verarbeitet. Dies bedeutet, dass diese Meldungen an der IRS vom C2X-Netzwerk in das Netz der Infrastruktur umgesetzt werden müssen und umgekehrt.

Im Rahmen der Hauptfunktion „Lokale Gefahrenwarnung“ werden die folgenden Ereignisse gemäß des TPEG-TEC Working Document 3.0 verwendet.5 Tabelle 1.5: Ereignisdaten - DecEnvNotification (DEN): Lokale Gefahrenwarnung

Ereignis causeCode subCauseCode TPEG-TEC V3.0:cause/subCause

Liegengebliebenes Fahrzeug 31 0 (unknown) 013/000

Unfall 2 0 (unknown) 002/000

Wanderbaustelle 3 3 003/003

Gegenstände auf der Fahrbahn 27 0 (unknown) 010/000

Tiere auf der Fahrbahn 28 0 (unknown) 011/000

Menschen auf der Fahrbahn 30 0 (unknown) 012/000

Gefährliches Stauende 63 1 027/001

Glätte 11 0 (unknown) 006/000

Niederschlag 45 0 (unknown) 019/000

(Seiten-)Wind 42 1 017/001

Nebel 43 1 018/001

5 Es sei an dieser Stelle darauf hingewiesen, dass momentan an der Version 3 des Standards

gearbeitet wird, dieser aber nicht öffentlich verfügbar ist.


Im Rahmen der Hauptfunktion „Baustelleninformation“ werden die folgenden Ereignisse ge-mäß des TPEG-TEC Working Document 3.0 verwendet.6 Tabelle 1.6: Ereignisdaten - DecEnvNotification (DEN): Baustelleninformation

Ereignis causeCode subCauseCode TPEG-TEC V3.0:cause/subCause

Straßenarbeiten 3 1 (unknown) ??

Markierungsarbeiten 3 2 (unknown) ??

Wanderbaustelle 3 3 (unknown) 003/003

Neben der in der TPEG-TEC definierten Codes werden noch weitere, proprietär definierte causeCodes in simTD benötigt. Tabelle 1.7: Ereignisdaten - DecEnvNotification (DEN): weitere, proprietär definierte Ursachenkennziffern

Ereignis causeCode subCauseCode

Stehendes Einsatzfahrzeug 101 (Allgemeine Gefahr) 1 (Stehendes Einsatzfahrzeug)

Fahrendes Einsatzfahrzeug 101 (Allgemeine Gefahr) 2 (Fahrendes Einsatzfahrzeug)

Notbremsung 102 (gefährliche Fahrweise) 1 (Notbremsung)

Der entsprechende causeCode und subCauseCode werden auch in der Type ID der Nach-richt als Content Type bzw. Content Sub Type gesetzt.

6 Es sei an dieser Stelle darauf hingewiesen, dass momentan an der Version 3 des Standards

gearbeitet wird, dieser aber nicht öffentlich verfügbar ist.


Format DecEnvNotification ::= SEQUENCE { management DecentralizedNotificationManagement, -- container with situation description, incl. type, severity event Event, -- tagged list of additional event parameters describing, e.g. windspeed, heading taggedList SET SIZE(0..32) OF TaggedValue, -- description of event location and dedictaed distribution area location DecentralizedNotificationLocation } DecentralizedNotificationManagement::= SEQUENCE { -- probability of hazard informa-tion to be true at mgt. reliability INTEGER(0..100), -- negates the existence of a situation type at the given location. isNegation BOOLEAN -- link to additional information dataReference DataReference OPTIONAL } DecentralizedNotificationLocation::= SEQUENCE { locationRef CHOICE{ circle [0] CircLocData, rectangle [1] RectLocData, -- list of waypoints leading to the situation position the first trace [2] Trace, ... }, destinationArea CHOICE{ circle [0] CircLocData, rectangle [1] RectLocData, ... } }

Abbildung 1.6: Definition der Decentralized Environmental Notification (DEN)

-- Event description derived from TPEG-TEC Draft Event ::= SEQUENCE { trafficFlowEffect TrafficFlowEffect, causeCode CauseCode, directCause DirectCause } DirectCause ::= SEQUENCE { severity INTEGER (0..255), -- according TPEG table tec003 subCauseCode SubCauseCode OPTIONAL, lengthEffected Range OPTIONAL, laneRestriction INTEGER (0..255) OPTIONAL, -- according to TPEG table tec 004 numberOfLanes INTEGER (0..255) OPTIONAL -- valid together with laneRestrictionType }

Abbildung 1.7: Beschreibung eines Events basierend auf dem TPEG-TEC Draft Standard

Ablauf Die Nachrichten werden innerhalb des C2X-Netzwerkes weitergegeben gemäß der Verbrei-tungsparameter, welche die Anwendung setzt. Hierzu wird auf den IVS und IRS eine Store&Forward-Funktionalität auf Netzwerkebene implementiert.


1.2.7 Fahrhistorie - ProbeVehicleData

Tabelle 1.8: Fahrhistorie - ProbeVehicleData

Packet Type

Content Type

Content Subtype


IT-Sicherheit

4 0 0 F_1.1.2 F_1.1.4, F_1.3.2

9f, 3b (Weiterleitung über 4b, 5c)

12 Signiert per Mobilfunk

Verschlüsselt per IRS

Beschreibung Jede IVS zeichnet ihre eigene Fahrhistorie in aggregierter Form auf. Das heißt, es werden Wegpunkte mit Zeitstempeln zur Berechnung einer Durchschnittsgeschwindigkeit abgelegt. Zusätzlich werden Temperaturdaten und Scheibenwischeraktivität abgelegt.

Die Durchschnittsgeschwindigkeiten werden zur Ermittlung der Verkehrslage in der Zentrale (F_1.1.4) und lokal zur Ermittlung der Verkehrslage in einem Baustellenbereich (F_1.2.2) verwendet. Die wetterrelevanten Daten dienen zur Ermittlung der Verkehrswetterlage in der Zentrale (F_1.1.3).

Diese Daten werden in F_1.1.2 gesammelt und an die Infrastruktur versendet. Die Kommu-nikation erfolgt an IRSs per 802.11p oder an die Zentrale direkt per UMTS.

Format ProbeVehicleData ::= SEQUENCE { -- Data set uses reference position as current position -- and generation time of C2X-Packet as timestamp for this position trace SEQUENCE SIZE (0..32) OF SEQUENCE { -- position relative to the previous (more recent) position offPosition2D OffsetPosition2D, -- time between this position and the previous position in the chain duration Duration, -- milage of the vehicle at the position, used for referencing weather data Milage Milage }, weatherData SEQUENCE SIZE (0..32) OF SEQUENCE { -- milage of the vehicle corresponding to the reported data milage Milage, value TaggedValue } }

Abbildung 1.8: Definition der ProbeVehicleData mit gesammelten Fahrdaten aus einem Fahrzeug

Ablauf Das Fahrzeug sendet die Nachricht per Unicast an eine IRS mit dem ServiceAnnouncement „TrafficDataCollector“, sobald in der Umfeldtabelle eine CAM der ITS-Station erkannt wird.

Alternativ werden die Nachrichten per Mobilfunk an die ICS (VsZ) gesendet, wenn eine komplette Nachricht zusammengestellt wurde.

Die Nachricht wird vom Fahrzeug verschlüsselt und signiert.


1.2.8 Fahrtziel – Destination

Tabelle 1.9: Fahrtziel - Destination

Packet Type

Content Type

Content Subtype


IT-Sicherheit

5 0 0 F_1.1.2 F_1.3.1, F_1.3.2, F_1.3.3

9f, 3b (Weiterleitung über 4b, 5c,

8e)

12 Signiert per Mobilfunk

Verschlüsselt per IRS

Beschreibung Die Nachricht enthält Informationen über das nächste Ziel eines Fahrzeugs. Diese Daten können nur bei aktiver Navigation kommuniziert werden, oder bei einem System, das die festgelegte Route des Fahrzeugs kennt, insbesondere bei ÖPNV Fahrzeugen im Linienverkehr. Sind Zwischenziele in der Navigation gesetzt, so wird nur das nächste Zwischenziel ausgesandt.

Diese Information ebenso wie die eigene Position zum Zeitpunkt der Übermittlung, sind relevant um das Verhalten des Fahrzeuges an Abbiegepunkten auf dem folgenden Streckenabschnitt zu prognostizieren und werden für die LSA-Steuerung (F_1.3.2, F_1.3.3) und für die Prognose der Netzlasten bei der Berechnung von Umleitungsempfehlungen F_1.3.1 verwendet.

Anmerkung: Information des nächsten Abbiegehinweises aus der Navigation werden über die CAM ausgesendet, da die Information auch für andere Fahrzeuge in der Umgebung inte-ressant ist. Ebenso sind alle anderen relevanten Daten der ÖV-Fahrzeuge mit dem CAM-Profil PublicTransport abgedeckt.

Anmerkung: Kann die Information zur aktuellen Position auch bei Mobilfunkübertragung aus unteren Netzwerkebenen ermittelt werden, kann auf die Übertragung der Nutzdaten verzichtet werden.

Format DestinationData ::= SEQUENCE { -- destination currently set at the navigation system destination ReferencePosition, -- description of current position position ReferencePosition }

Abbildung 1.9: Beschreibung eines Fahrziels

Ablauf Wird das Fahrziel in der Navigation oder bei ÖPNV-Fahrzeugen im System gesetzt, dann wird die Nachricht per Mobilfunk an die Versuchszentrale (VsZ) gesendet.

Sobald in der Umfeldtabelle die CAM einer bisher nicht sichtbaren IRS, mit dem ServiceAnnouncement „TrafficDataCollector" oder "TrafficController“ erkannt wird, sendet das Fahrzeug die C2X-Nachricht per Unicast an diese IRS .

Die Nachricht wird vom Fahrzeug verschlüsselt und signiert.


1.2.9 Kreuzungstopologie - Intersection

Tabelle 1.10: Kreuzungstopologie - Intersection

Packet Type

Content Type

Content Subtype


IT-Sicherheit

6 0 0 F_1.1.1

F_1.3.3

F_2.2.2, F_2.2.4

8f, 9g 10 Signiert,

Beschreibung Die Abstimmung zu der Nachricht ist noch nicht final abgeschlossen. Im Gegensatz zu den anderen Nachrichten wurde die Nachricht komplett aus dem SAE J2735 abgeleitet und alle Elemente, die im Rahmen von simTD oder in einer europäischen Adaption des Standards nicht verwendet werden können, in der Definition belassen und als optional mit entsprechen-dem Kommentar markiert.

Intersection ::= SEQUENCE { name DescriptiveName OPTIONAL, -- not to be used in SIM-TD id IntersectionID, refPoint ReferencePosition OPTIONAL,-- the reference from which subsequent data

points are offset until a new point is used. refInterNum IntersectionID OPTIONAL, -- not to be used in SIM-TD orientation [0] Heading OPTIONAL, -- not to be used in SIM-TD laneWidth [1] LaneWidth OPTIONAL, -- reference width used by subsequent lanes until

a new width is given type [2] IntersectionStatusObject OPTIONAL, -- not to be used in SIM-TD approaches [3] SEQUENCE SIZE(1..32) OF ApproachObject, -- data about one or more approaches (lane data

is found here) preemptZones [4] SEQUENCE SIZE(1..32) OF SignalControlZone OPTIONAL, -- not to be used

in SIM-TD priorityZones [5] SEQUENCE SIZE(1..32) OF SignalControlZone OPTIONAL, -- not to be used

in SIM-TD conflictArea [6] SEQUENCE SIZE(0..256) OF Area, ... } -- Beschreibung eines Kruezungsarms mit allen Zufahrts und Abfahrtsspuren -- Link connected to intersection wit all incoming and outgoing lanes ApproachObject ::= SEQUENCE { refPoint [0] ReferencePosition OPTIONAL, -- not to be used in SIM-TD laneWidth [1] LaneWidth OPTIONAL, -- reference width used by subsequent -- lanes until a new width is given approach [2] Approach OPTIONAL, -- list of incoming lanes egress [3] Approach OPTIONAL, -- list of outgoing lanes ... } -- Egress or approach of a link containing all lanes Approach ::= SEQUENCE { name DescriptiveName OPTIONAL, -- not to be used in SIM-TD id RoadSegmentID OPTIONAL, drivingLanes SEQUENCE SIZE(0..32) OF VehicleReferenceLane, computedLanes SEQUENCE SIZE(0..32) OF VehicleComputedLane, trainsAndBuses SEQUENCE SIZE(0..32) OF SpecialLane, -- not to be used in SIM-TD but all

done in drivingLanes and computedLanes, barriers [0] SEQUENCE SIZE(0..32) OF BarrierLane OPTIONAL, -- not to be used in

SIM-TD crosswalks [1] SEQUENCE SIZE(0..32) OF CrosswalkLane OPTIONAL, -- not to be used in

SIM-TD ... } -- lane defined by a point list VehicleReferenceLane ::= SEQUENCE {


laneNumber LaneNumber, laneWidth LaneWidth OPTIONAL, laneAttributes VehicleLaneAttributes, nodeList NodeList, keepOutList [1] NodeList OPTIONAL, -- not to be used in SIM-TD connectsTo [2] ConnectsTo OPTIONAL, -- a list of other lanes and their turning

used by this lane conflictAreaIDs [3] SEQUENCE SIZE(0..256) OF INTEGER, speedLimit INTEGER (0..150), ... } -- lane defined by offset to an reference lane VehicleComputedLane ::= SEQUENCE { laneNumber LaneNumber, laneWidth LaneWidth OPTIONAL, laneAttributes VehicleLaneAttributes, refLaneNumber LaneNumber, lineOffset DrivenLineOffset, keepOutList [1] NodeList OPTIONAL, -- not to be used in SIM-TD connectsTo [2] ConnectsTo OPTIONAL, -- a list of other lanes and their turning

used by this lane conflictAreaIDs [3] SEQUENCE SIZE(0..256) OF INTEGER, speedLimit INTEGER (0..150), ... } -- List of relative positions describing an egress or approach -- Offsets are additive from the last point. -- first point is the the stop line or point at the boarder of the intersection area. NodeList ::= SEQUENCE{ nodes SEQUENCE SIZE (2..64) OF Offsets } -- providing offsets in an karthesian coordinate system in 1cm granularity Offsets ::= SEQUENCE { xOffset INTEGER (-32767..32767), yOffset INTEGER (-32767..32767), zOffset [1] INTEGER (-32767..32767) OPTIONAL, width [2] LaneWidth OPTIONAL } -- perpendicular offset from the center lane of the reference lane to the center line of the

described lane. -- positive values describe a offset to the right in the direction of the NodeList

(clockwise at the intersection) -- granularity 1cm DrivenLineOffset ::= INTEGER (-32767..32767) -- List of possible connection of a lane ConnectsTo ::= SEQUENCE(SIZE(1..48)) OF ConnectionInformation ConnectionInformation ::= SEQUENCE { lane LaneNumber, intersection IntersectionID, maneuver TurnDirection } -- Description of a conflict area by for points which describe not necessarily a rectangle Area ::= SEQUENCE{ id INTEGER (0..255), a Offsets, -- all offset are relative to reference point of

intersection b Offsets, c Offsets, d Offsets } VehicleLaneAttributes ::= BIT STRING { noData (0), egressPath (1), -- a two-way path or an outbound path is described maneuverStraightAllowed (2), maneuverLeftAllowed (3), maneuverRightAllowed (4),


yield (5), maneuverNoUTurn (6), maneuverNoTurnOnRed (7), maneuverNoStop (8), noStop (9), noTurnOnRed (10), hovLane (11), bus (12), -- SAE busOnly does not make sense in a Bit Field taxi (13), -- SAE busAndTaxiOnly does not make sense in a Bit Field maneuverHOVLane (14), maneuverSharedLane (15), -- a "TWLTL" (two way left turn lane) bike (16), -- SAE comment added maneuverBikeLane train (17), -- added from SIM-TD includes train individualTraffic (18), -- added from SIM-TD to distinguish special lanes vehiclesEntering (19), -- for SIM-TD copied from SpecialLaneAttributes vehiclesLeaving (20) -- for SIM-TD copied from SpecialLaneAttributes } SpecialLaneAttributes ::= NotToUseSAEonly -- features set at normal vehicle lane SpecialLane ::= NotToUseSAEonly -- features set at normal vehicle lane BarrierLane ::= NotToUseSAEonly CrosswalkLane ::= NotToUseSAEonly IntersectionStatusObject ::= NotToUseSAEonly CrosswalkLaneAttributes ::= NotToUseSAEonly BarrierAttributes ::= NotToUseSAEonly SignalControlZone ::= NotToUseSAEonly DescriptiveName ::= NotToUseSAEonly

Ablauf Diese Nachricht wird periodisch von der IRS an der LSA als Broadcast versendet (ca. 1Hz)

1.2.10 Verkehrsregeln – TrafficRegulation

Tabelle 1.11: Verkehrsregeln - TrafficRegulation

Packet Type

Content Type

Content Subtype


IT-Sicherheit

7 0 0 F_1.1.1 F_2.2.2, F_2.2.4

9g?? 10 Signiert

Beschreibung Die Nachricht enthält die Information über ein oder mehrere Verkehrszeichen, bzw. Verkehrsregeln. Wenn sich eine Verkehrsregel auf eine Strecke bezieht, ist diese Strecke in der Punktfolge „extension“ des Elementes „Trace“ abgelegt. Wiederholende Verkehrszeichen werden nicht kodiert, auch das Ende der Verkehrsregel wird nicht kodiert, z.B. Aufhebung des Überholverbotes.

Format TrafficRegulationData ::= SET SIZE(1..64) OF TrafficRegulation TrafficRegulation ::= SEQUENCE { trafficSignID INTEGER (0..4294967295), -- Eindeutige ID des VZ Datensatzes intersectionID [1] IntersectionID OPTIONAL, -- Stellt die Referenz zur

Kreuzungstopologie her trafficSignIDCont [2] INTEGER (0..4294967295) OPTIONAL, -- VZ setzt das VZ der ID

trafficSignIDCont fort (Notwendigkeit der Verlinkung über ID ist zu prüfen, kann im Bereich von Abzweigungen notwendig sein).

isStatic BOOLEAN, -- false if variable message sign (VMS) validitySign [3] ValidityPeriod OPTIONAL, -- Gültigkeitsdauer des VZ Datensatzes validityRegulation [4] ValidityPeriod OPTIONAL, -- Gültigkeitsdauer des Inhalts eines WVZ

(VMS)


trafficSign TrafficSign, -- enthält Haupt- und Zusatzzeichen (TrafficSignCode, TrafficSignSubCode, beides sind Tabellenzeiger)

positionRef Trace, -- Reference Position including Direction and Waypointlist

signPosition [5] OffsetPosition2D OPTIONAL,--Aufstellort des VZ relativ zur ReferencePosition

lanes [6] Lanes OPTIONAL, -- VZ gilt für die Fahrspur Nr. recommendedSpeed [7] Speed OPTIONAL -- Empfohlene Fahrgeschwindigkeit, die Ego

an bei Beginn der Gültigkeit des VZ erreicht haben sollte.

}

Ablauf Siehe Ablauf für Textnachricht Jede zu versendende Nachricht wird von der IRS vor dem Versenden signiert.

1.2.11 Ampelphaseninformation – SignalState

Tabelle 1.12: Ampelphaseninformation - SignalState

Packet Type

Content Type

Content Subtype


IT-Sicherheit

8 0 0 F_1.1.1, F_1.3.3

F_2.2.2, F_2.2.1

8f, 9g 11 Signiert

Beschreibung Das LSA-Steuergerät steuert die Signalabfolge der LSA. Um den Zustand des LSA-StG auswerten und darauf aufbauend weitere Prognosen leisten zu können, müssen bestimmte Parameter wie aktuelles Signalbild, Signalbild der nächsten Sekunde, Grünzeitende/ Rotzeitende aller aktuellen und nächsten Signalbilder über eine Schnittstelle (OTS 2./ Proprietär) an die IRS weitergegeben werden.

Die IRS dekodiert die vom LSA-StG erhalten Daten und wertet sie aus, um eine Prognose der kommenden Signalfolge zu erhalten und sendet diese Information über ITS 5GA an die IVS weiter.

Format Die Abstimmung zu der Nachricht ist noch nicht final abgeschlossen. Im Gegensatz zu den anderen Nachrichten wurde die Nachricht komplett aus dem SAE J2735 abgeleitet und alle Elemente, die im Rahmen von simTD oder in einer europäischen Adaption des Standards nicht verwendet werden können, in der Definition belassen und als optional mit entsprechen-dem Kommentar markiert.

SignalPhaseAndTimingData ::= SEQUENCE { msgID [1] DSRCmsgID OPTIONAL, -- not to be used in SIM-TD name [2] DescriptiveName OPTIONAL, -- not to be used in SIM-TD id IntersectionID, -- this provided a unique mapping to the

intersection map in question status IntersectionStatusObject, -- general status of the controller lanesCnt INTEGER(1..255) OPTIONAL, -- not to be used in SIM-TD states SEQUENCE (SIZE(1..255)) OF MovementState, -- each active Movement/lane is given in turn and contains its state, and -- seconds to the next event etc. priority [3] SignalState OPTIONAL, -- not to be used in SIM-TD prempt [4] SignalState OPTIONAL, -- not to be used in SIM-TD -- # LOCAL_CONTENT } -- general status of the controller


IntersectionStatusObject ::= BIT STRING{ manual (0), -- Manual Control is enabled. Timing reported is per programmed

values, etc but person at cabinet can manually request that certain intervals are terminated early (e.g. green)

stopTime (1), -- Stop Time is activated and all counting/timing has stopped. conflict (2), -- Intersection is in Conflict Flash. preempt (3), -- Preempt is Active transit (4), -- Transit Signal Priority (TSP) is Active proceedYel(5), -- Permission to proceed on yellow -- not to be used in SIM-TD reserved1 (6), -- Reserved reserved2 (7), -- Reserved as zero flashYelAll (8), -- controller is in yellow flash state for all legs (e.g. at night)

(see OCIT) flashYelMin (9), -- controller is in yellow flash state for minor legs only, major

legs are switched off (see OCIT) partOff (10), -- controller is partially switched off or partially yellow flashing

(see OCIT) problem (11), -- controller has communication problems (see OCIT) exceptional(12), -- exceptional operation (e.g. during maintenance) (see OCIT) off (13) -- controller is switched off (see OCIT) } MovementState ::= SEQUENCE { movementId [1] INTEGER OPTIONAL, laneCnt [2] INTEGER (1..255) OPTIONAL, -- not to be used in SIM-TD category TrafficCategory, --

indvidualTraffic, public transport, .. lineRef IA5String(SIZE(0..32)), -- see PTLineDescription laneSet LaneSet, -- the collection of lanes, to which this

state data applies currState [3]ColorState OPTIONAL, -- the state of a Motorised lane relevantManeuver TurnDirection, -- e.g. right turn pedState [4] PedestrianSignalState OPTIONAL, -- not to be used in SIM-TD specialState [5] SpecialSignalState OPTIONAL, -- not to be used in SIM-TD timeToChange [6] TimeToChange OPTIONAL, -- not to be used in SIM-TD stateConfidence [7] StateConfidence OPTIONAL, -- not to be used in SIM-TD yellState [8] SignalLightState OPTIONAL, -- not to be used in SIM-TD yellPedState [9] PedestrianSignalState OPTIONAL, -- not to be used in SIM-TD yellTimeToChange [10] TimeToChange OPTIONAL, -- not to be used in SIM-TD yellStateConfidence [11] StateConfidence OPTIONAL, -- not to be used in SIM-TD nextChanges SEQUENCE OF Change, -- description of next phase changes vehicleCount [12] INTEGER(0..60000) OPTIONAL, -- tailback pedDetect [13] PedestrianDetect OPTIONAL, -- not to be used in SIM-TD pedCount [14] INTEGER (0..60000) OPTIONAL, -- not to be used in SIM-TD ... -- # LOCAL_CONTENT } TrafficCategory ::= BIT STRING { privateTraffic (0), publicTransport_Road(1), publicTransport_Rail(2) } -- the collection of lanes, by num, to which some state data applies LaneSet ::= SET( SIZE(1..127)) OF LaneNumber -- change of signal phase Change ::= SEQUENCE{ minTimeToChange TimeToChange, -- a count of the minimum time remaining in this state maxTimeToChange TimeToChange, -- a count of the maximum time remaining in this state likelyTimeToChange TimeToChange, -- a count of the most propable time remaining in this

State confidence Confidence, -- a confidence value for likelyTimeToChange passState BOOLEAN, -- true, vehicles may pass predCnt INTEGER, -- for which state is this valid? ... } -- time interval until signal state change reserved meanings: 0, 65531, 65532, 65533, 65534,

and 65535. TimeToChange ::= INTEGER (0..65535)


SignalStateData ::= NotToUseSAEonly StateConfidence ::= NotToUseSAEonly DSRCmsgID ::= NotToUseSAEonly DescriptiveName ::= NotToUseSAEonly SignalState ::= NotToUseSAEonly PedestrianDetect::= NotToUseSAEonly PedestrianSignalState ::= NotToUseSAEonly SpecialSignalState ::= NotToUseSAEonly SignalLightState ::= NotToUseSAEonly

Ablauf Nachricht wird periodisch von der IRS an der LSA als Broadcast versendet (ca. 1Hz).

Die Nachricht wird von der IRS signiert.

1.2.12 Dezentrale Verkehrslage

Tabelle 1.13: Dezentrale Verkehrslage - Sotis

Packet Type

Content Type

Content Subtype


IT-Sicherheit

8 0 0 F_1.2.1 F_1.2.1 11g, 9g, 9f 12 Signiert

Beschreibung Aus den Bewegungsdaten der Fahrzeuge wird dezentral die Verkehrslage erstellt. Dies er-folgt nicht auf Basis einer digitalen Karte, sondern anhand eines Referenzgitternetzes. Hierzu konsolidieren die IVSs die Daten mit ihren eigenen Bewegungen und kommunizieren die Daten untereinander. Auch IRSs empfangen und senden entsprechende Information. Das entsprechende Verfahren mit dem definierten Nachrichtenformat ist unter dem Namen SOTIS „Self-Organizing Traffic Information System“ implementiert und publiziert (z.B. [12]) worden.

Format Die folgende ASN.1 Definition zeigt den Inhalt der Nachrichten.

-- Sends a part of the knowledgebase of one vehicle as broadcast to all other in range. -- Speed position and heading of originating station can be taken from the Network header SotisData ::= SEQUENCE { priority Priority, grl SEQUENCE SIZE(0..MAX) OF GeoReferenceList,

source MessageSource OPTIONAL } MessageSource ::= ENUMERATED { rsu (0), vehicle (1), truck (2) } -- A GeoReferenceList encodes a sequence of GeoReferencePoints to -- represent a road segment. -- It contains data defining the used global grid and a list of Geo Reference Points GeoReferenceList ::= SEQUENCE { basePoint ReferencePosition, -- base point of this Geo Reference List baseTime TimeStamp, dLatInDegree LatitudeOffset, -- grid distance in north direction dLonInDegree LongitudeOffset, -- grid distance in east direction accuracyLat LatitudeOffset, -- Granularity of latitude data accuracyLon LongitudeOffset, -- granularity of longitude data


accuracyHeading Direction, -- size of one heading segment in degree grpList SEQUENCE SIZE(0..500) OF GRP } -- The Geo Reference Point contains traffic data for one point -- on the global grid GRP ::= SEQUENCE { georeference SotisGeoRef, -- heading encoded as the heading in degree/accuracyHeading heading INTEGER (0..255), -- multiple of “accuracyHeading”, roadClass RoadClass, roadClassConfidence Confidence dataLeft [1] INTEGER (0..255) OPTIONAL, -- optional descripive data in direction left timeLeft [2] TTITimestamp OPTIONAL, dataRight [3] INTEGER (0..255) OPTIONAL, -- optional descripive data in direction right timeRight [4] TTITimestamp OPTIONAL } -- Efficient encoding of relative time offsets: -- (We accept decreasing accuracy with increasing time.) -- -- -30..30: 2-second steps : offset = I * 2000ms : -60s to 60s -- -60..-31: 10-second steps : offset = -60000ms + (i+30)*10000ms : -360s to -70s -- 30..60: 10-second steps : offset = 60000ms + (i-30)*10000ms : 70s to 360s -- -126..-61: 1-minute steps : offset = -360000ms + (i+60)*60000ms : -3960s to -420s -- 61..126 : 1-minute steps : offset = 360000ms + (i-60)*60000ms : 420s to 3960s -- -127/127 : invalid/reserved TTITimestamp ::= INTEGER (-127..127) -- Defines one point on the used global grid. A defined point -- always consists of one grid coordinate and one WGS coordinate SotisGeoRef ::= CHOICE { vRef [1] VerticalGrpRef, hRef [2] HorizontalGrpRef } VerticalGrpRef ::= SEQUENCE { -- WGS84 latitude relative to base Point latCoord INTEGER (0..2047), -- multiple of “accuracyLat” -- longitude as index of global grid line relative to basePt gridIndex INTEGER (0..255) } HorizontalGrpRef ::= SEQUENCE { -- WGS84 longitude relative to base Point lonCoord INTEGER (0..2047), -- multiple of “accuracyLon”, -- latitude as index of global gridline relative to basePt gridIndex INTEGER (0..255) }

Ablauf Die Nachricht wird von jedem Fahrzeug und von IRSs als Broadcast versendet. Das Sen-deintervall variiert je nach aktueller Situation, abhängig von:

• derzeitiger Netzwerklast, • Anzahl empfangener SOTIS Pakete von anderen Fahrzeugen, • Abweichungen der lokal vorhandenen Informationen von denen, die empfangen

werden.

Die Anpassung des Sendeintervalls erfolgt auf Anwendungsebene.


1.2.13 Verkehrslage - TrafficList

Tabelle 1.14: Verkehrslage - TrafficList

Packet Type

Content Type

Content Subtype


IT-Sicherheit

9 0 0 F_1.1.4 F_3.1.1, F_1.2.1, F_1.2.3

3g, 9g (zum Umsetzen 4f,

2c, 5f)

12 Signiert

Beschreibung Die Nachricht enthält abschnittsbezogene Verkehrsdaten, die zum Einfärben einer digitalen Karte oder für ein dynamisches Routing im Fahrzeug benutzt werden sollen.

Für die Versuchszentrale wird parallel zur und unabhängig von der Ausschreibung der Versuchszentrale (Stufe 4) ein Modul für eine neue Verkehrslage ausgeschrieben. Beide Auftragnehmer werden angewiesen, sich gemeinsam mit dem HLSV abzu-stimmen über das Format der Verkehrslage-meldungen. Sobald diese feststehen, werden sie in diesem Dokument ergänzt.

Format TrafficListData ::= SEQUENCE { linkInformationList SEQUENCE SIZE(1..128) OF LinkInformation } LinkInformation ::= SEQUENCE { startPoint OffsetPosition2D, -- position relative to reference position of message endPoint OffsetPosition2D, -- position relative to reference position of message wayPoints SEQUENCE SIZE(0..16) OF OffsetPosition2D,

-- optional waypoints of street segment --relative to reference position of message

trafficState TrafficFlowEffect }

Ablauf Jede zu versendende Nachricht wird von der IRS vor dem Versenden signiert.

1.2.14 Textnachricht – TextAnnouncement

Tabelle 1.15: Textnachricht - TextAnnouncment

Packet Type

Content Type

Content Subtype


IT-Sicherheit

10 0 0 F_1.3.1 F_1.3.1 9g (zum Umsetzen 4f)

11 Signiert

Beschreibung Die Nachricht enthält Textinformation, die dem Fahrer angezeigt werden soll, wenn das Fahrzeug einen definierten Ort passiert. Die Information kann in einer oder mehreren Sprachen übermittelt werden. Falls mehrere Sprachen übermittelt werden, sucht das Fahr-zeug-HMI die am besten geeignete Sprache aus.


Die Position, an der die Nachricht angezeigt wird, und die Gültigkeit der Information werden durch die entsprechenden Felder des C2XAppPayload vorgegeben (referencePosition, generationTime, expiryTime).

Im Rahmen von simTD wird die Nachricht für Umleitungshinweise eingesetzt.

TextAnnouncementData ::= SEQUENCE { multiLingualMessage SET SIZE(1..16) OF SEQUENCE{ language LanguageCode, caption IA5String(SIZE(1..32)) OPTIONAL, message IA5String(SIZE(1..255)) } }

Ablauf Die Nachricht wird von der IRS per Single-hop Broadcast an alle Fahrzeuge in der Umgebung gesendet. Dabei sollte jedes Fahrzeug die Möglichkeit haben, bei normaler Geschwindigkeit die Information mit einfacher Redundanz, d.h. zweimal in dem Kommuni-kationsbereich vor dem Anzeigepunkt zu erhalten.

Beispiel: Bei einem möglichen Kommunikationsbereich von 400m und einer designierten Geschwindigkeit von 40m/s bedeutet dies eine Zykluszeit von 400m / 40m/s / 2 = 5s.

Die Nachricht wird von der IRS signiert.

1.2.15 Differential GPS Korrekturdaten

Tabelle 1.16: Differential GPS Korrekturdaten

Packet Type

Content Type Content Subtype


IT-Sicherheit

12 Datenversion laut Tabelle

0 F_1.3.1 CCU (bessere Ortung)

9g (zum Umsetzen 4f)

11 Signiert

Beschreibung Die Daten werden gebraucht, um die GPS-Positionierung mit dem Differential-GPS-Verfahren in der IVS zu verbessern. Evtl. werden die Daten von einem Internetservice in der Zentrale abgerufen und an die IRSs verteilt. Alternativ können die Daten in der IRS erzeugt werden.

Die Daten müssen in der empfangenden IVS vom GPS Modul der CCU verarbeitet werden. Dazu ist es sinnvoll, dass die Nachrichten auf der CCU erkannt und dann dekodiert werden, damit sie direkt dem GPS Modul übergeben werden, ohne über die Umfeldtabelle auf der AU abgefragt zu werden.

Format Die Daten sind in den Rahmen C2X_Packet als OctetString enthalten, analog zu den „Unformatierten Daten“ (Kapitel 1.2.4).

Die eigentlichen Korrekturdaten sind in dem OctetString nach RTCM Standards kodiert. Der Typ und die Version der Korrekturnachrichten werden durch den Contenttyp im Transport Layer angezeigt. Die Kodierung der Version erfolg analog zu dem Daten-Typ „RTCM-Revision“ aus dem SAE J2735 StandardProposal wie in der Tabelle unten aufgelistet ist.


Tabelle 1.17: Korrektur Daten nach RTCM

Content Type

Version Content Type

Version

0 unknown 9 rtcmSP3

1 reserved 10 rtcmBINEX 2 rtcmCMR 19 rtcmRev2-xm (Used when

specific rev is not known) 3 rtcmCMR-Plus 20 rtcmRev2-0 4 rtcmSAPOS 21 rtcmRev2-1 5 rtcmSAPOS-Adv 23 rtcmRev2-3 (Std 10402.3) 6 rtcmRTCA 30 rtcmRev3-0 7 rtcmRAW 31 rtcmRev3-1 (Std 10403.1) 8 rtcmRINEX

Ablauf IRSs senden zyklisch das GPS Korrektursignal als Single-Hop Broadcast. Die Zykluszeit beträgt etwa 5s.

Jede zu versendende Nachricht wird von der IRS vor dem Versenden signiert.

1.3 IP-basierte Kommunikation

1.3.1 Allgemeines

IP basierte Kommunikation wird von den Funktionen 3.1.1. „Internetbasierte Dienstnutzung“ und 3.1.2. „Standortinformationsdienste“ genutzt.

Die Funktionen nutzen auf der Luftschnittstelle prinzipiell 2 Übertragungsvarianten:

• Eine verbindungsorientierte Übertragung zwischen funktionsspezifischen Komponenten auf IVS und ICS, die basierend auf TCP/IP über das Mobilfunknetz erfolgt (Nr. 3.1 und 3.2 in Abb. 1.1)

• Eine verbindungslose Übertragung von der funktionsspezifischen Komponente auf der IRS zur IVS basierend auf UDP/IP über 802.11bg WLAN im Adhoc Modus. Diese Variante wird nur für F3.1.2 genutzt und betrifft die Schnittstellen 9 und 12 in Abb.1.1.

Weiterhin nutzt die Funktion 3.1.2 eine TCP/IP Verbindung zwis

Documents

Deliverable D21.4 Kommunikationsprotokolle · 2018. 9. 25. · Deliverable D21.4 Spezifikation der Kommunikationsprotokolle Version 1.0 Verbreitung Öffentlich Projektkoordination