-
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!
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 2
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 3
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:
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 4
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 5
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/�
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 6
• 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/�
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 7
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/
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 8
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
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 9
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 10
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
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 11
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 ... }
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 12
-- 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
Quelle Senke Schnittstelle Traffic Class
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
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 13
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 14
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
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 15
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 16
1.2.6 Ereignisdaten - DecEnvNotification (DEN)
Tabelle 1.4: Ereignisdaten - DecEnvNotification (DEN)
Packet Type
Content Type
Content Subtype
Quelle Senke Schnittstelle Traffic Class
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 17
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 18
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 19
1.2.7 Fahrhistorie - ProbeVehicleData
Tabelle 1.8: Fahrhistorie - ProbeVehicleData
Packet Type
Content Type
Content Subtype
Quelle Senke Schnittstelle Traffic Class
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 20
1.2.8 Fahrtziel – Destination
Tabelle 1.9: Fahrtziel - Destination
Packet Type
Content Type
Content Subtype
Quelle Senke Schnittstelle Traffic Class
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 21
1.2.9 Kreuzungstopologie - Intersection
Tabelle 1.10: Kreuzungstopologie - Intersection
Packet Type
Content Type
Content Subtype
Quelle Senke Schnittstelle Traffic Class
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 {
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 22
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),
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 23
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
Quelle Senke Schnittstelle Traffic Class
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)
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 24
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
Quelle Senke Schnittstelle Traffic Class
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
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 25
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)
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 26
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
Quelle Senke Schnittstelle Traffic Class
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
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 27
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 28
1.2.13 Verkehrslage - TrafficList
Tabelle 1.14: Verkehrslage - TrafficList
Packet Type
Content Type
Content Subtype
Quelle Senke Schnittstelle Traffic Class
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
Quelle Senke Schnittstelle Traffic Class
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 29
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
Quelle Senke Schnittstelle Traffic Class
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.
-
Deliverable D21.4 Version 1.0 | 29.09.2009 | Seite 30
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