Erster Entwurf "Gesamtarchitektur" - Dokument D 01 der Projektgruppe 1 Systemarchitektur - Entwurf; Version 2.0

Transkript

1 Erster Entwurf "Gesamtarchitektur" - Dokument D 01 der Projektgruppe 1 Systemarchitektur - Entwurf; Version

2 4 Inhalt 0. Verwendung dieses Dokuments Einleitung Anforderungen an die Systemarchitektur Dienst Baustellenwarnung Allgemeine Beschreibung der Prozessschritte Zusammenstellen der Daten (Inhalt) Fahrtrichtung ermitteln Positionskette ermitteln Zusammenstellen Daten (Betrieb) Entscheidung: Verbindung zu Zentrale? Filtern nach relevanten Meldungen Weiterverarbeitung Fehlermeldung Gesperrte Fahrstreifen ermitteln Kombination von mehreren fahrbaren Absperrtafeln Entscheidung "BMS / BIS verfügbar" Verschneiden mit BMS / BIS Daten [optional] Entscheidung "Operator verfügbar" Plausibilisieren der Daten durch einen Operator [optional] Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über andere Medien Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über Mobilfunk Meldung generieren (DENM) Darstellung der Meldung im Fahrzeug Allgemeine Beschreibung der Architektur Modul Inhaltliche Daten zusammenstellen Schnittstelle S Modul Richtung Modul Positionskette Entscheidungsmodul "Verbindung zur Zentrale" Schnittstelle S Modul Betriebliche Daten zusammenstellen Schnittstelle S Modul Filtern Schnittstelle S Modul Weiterverarbeitung Fehlermeldung Schnittstelle S Modul Fahrstreifen Sperrung Schnittstelle S Optional: Modul Kombination von >1 fahrbarer Absperrtafel Schnittstelle S Modul Weiterverwendung Länder intern Entscheidungsmodul "BIS / BMS verfügbar" Schnittstelle S Optional Modul Verschneiden mit BMS / BIS Daten... 34

3 Entscheidungsmodul "Operator verfügbar?" Schnittstelle S Optional Modul Plausibilisieren (Operator) Schnittstelle S Modul Distribution von Daten Schnittstelle S Modul Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über andere Medien Schnittstelle S Modul Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über Mobilfunk Schnittstelle Schnittstelle S Modul DENM erzeugen Schnittstelle S Modul Präsentation der Meldung Baustellenwarner Stand-Alone Lösung Varianten zur Implementierung Variante 1 dezentrale Lösung Variante 2 zentrale Lösung Variante 3 gemischt zentral und dezentrale Lösung Dienst Fahrzeugseitige Datenerfassung Glossar... 49

4 6 0. Verwendung dieses Dokuments Dieses Dokument ist die Grundlage für die Entwicklung der Prototypen im C-ITS Corridor in Deutschland für die Anwendung Baustellenwarner. 1. Einleitung Dieses Dokument beschreibt den ersten Entwurf der Architektur für den Cooperative ITS (C-ITS) Corridor Rotterdam Frankfurt/M Wien. Das Dokument fasst die ursprünglich im Projekthandbuch aufgeführten Dokumente - Zwischenbericht "Anforderungsanalyse an die Gesamtarchitektur" - Bericht "Anforderungsanalyse an die Gesamtarchitektur" - Erster Entwurf "Gesamtarchitektur" zusammen. Die einzelnen Dokumente sind in den nachfolgenden Kapiteln reflektiert. Das vorliegende Dokument ist folgendermaßen aufgebaut: - Kapitel 2 beinhaltet die Dokumentation der Anforderungen an eine Systemarchitektur für das C-ITS Corridor Projekt dies entspricht den beiden Dokumenten zur Anforderungsanalyse (siehe oben) - Kapitel 1 enthält eine allgemeine Beschreibung der Abläufe, die zur Umsetzung der beiden Dienste Baustellenwarnung und fahrzeugseitige Verkehrslage notwendig sind. ANMERKUNG: Momentan erfolgt hier ein Fokus auf die Baustellenwarnung weitere Dienste werden zeitnah ergänzt. - Kapitel 3.2 beschreibt allgemein die Architektur. Hier wird über den in Kapitel 1 beschriebenen Prozess hinaus im Detail auf die unterschiedlichen Module, die Schnittstellen, ausgetauschten Daten und Kommunikationswege eingegangen. - Kapitel 1 widmet sich der praktischen Anwendung der Architektur und beschreibt verschiedenen Möglichkeiten für eine konkrete Architektur Implementierung in der Infrastruktur Kapitel 3 und 4 beschreiben unabhängig von einer zukünftigen möglichen technischen Ausgestaltung die Architektur für den C-ITS Corridor. Diese allgemeine Beschreibung wird zu einem späteren Zeitpunkt (nach Abschluss der Untersuchungen zur Architektur) im Projekt dazu dienen, eine Entscheidung für eine der in Kapitel 5 beschriebenen möglichen Implementierungen zu treffen.

5 7 Die Beschreibung der Architektur orientiert sich an der von der FGSV entwickelten Methodik der Pyramide 1 (Abbildung 1). Die Schichten der Pyramide stellen den Zusammenhang zwischen dem angestrebten Ziel und den dafür erforderlichen Semantiken, Methoden, Vereinbarungen und Techniken dar. Die unterschiedlichen Aspekte einer Architektur werden in der FGSV Pyramide in fünf Schichten gebündelt ausgehend von strategischen Überlegungen an der Spitze bis zur technischen Umsetzung am Fuß der Pyramide. Das vorliegende Dokument betrachtet die Ebenen "Prozesse", "Informationsflüsse", "Datenaustauschmechanismen" in Kap. 3+4 und abschließend die "Infrastruktur (eingesetzte Technik)" in Kap. 5. Abbildung 1 Pyramide als Modell zur Beschreibung von IVS Architekturen [Quelle: FGSV-Nr. 305] 1 Hinweise zur Strukturierung einer Rahmenarchitektur für Intelligente Verkehrssysteme (IVS) in Deutschland - Notwendigkeit und Methodik [FGSV-Nr. 305]

6 8

7 9 2. Anforderungen an die Systemarchitektur Für die Implementierung der beiden Dienste Baustellenwarner und fahrzeugseitige Verkehrslage sowie auch für die künftige Erweiterung um zusätzliche kooperative Anwendungen werden folgende Anforderungen an die Architektur gestellt: ID Bereich Anforderungen 001 GEN Die Architektur muss um weitere Dienste erweiterbar sein 002 GEN Die Architektur muss die Implementierung der Dienste Baustellenwarnung und fahrzeugseitige Verkehrslage ermöglichen 003 GEN Die Architektur muss sicherstellen, dass Dritte die Daten gesichert abgreifen können 004 GEN Die Dienste müssen in bestehende Architekturen der Straßenbetreiber integriert werden können 005 GEN Es müssen Schnittstellen zu den bestehenden Systemen bestehen 006 GEN Das System muss ausfallsicher sein Kriterien für ausfallsicher: 007 GEN Der Betrieb des Systems soll mit möglichst wenigen Eingriffen des Personals auskommen (maximale Automatisierung der Abläufe) 008 GEN Die Architektur muss so gestaltet sein, dass unterschiedliche technische Implementierungen dieser Architektur (Umsetzung mittels Komponenten) möglich sind. 009 GEN Unterschiedliche Implementierungen der Architektur sollen miteinander interoperabel sein. 010 GEN Für die Distribution von Daten sind bestehende Plattformen (MDM) vorzusehen. 011 GEN Die Implementierung der Architektur in Deutschland soll interoperabel mit Implementierung in den Nachbarländern (Niederlande, Österreich) sein. 012 GEN Bestehende Systeme, die die Dienste Baustellen-Warnung oder fahrzeugseitige Verkehrslage oder Teile dieser Dienste bereits heute umsetzen, müssen in die Architektur integriert werden (z.b. DORA, DIANA II) 013 GEN Die Architektur muss Nachrüstlösungen für bereits bestehende (Teil-)Systeme ermöglichen. 014 GEN Die Architektur muss Erweiterungen der Dienste (Version 2, 3, n) ermöglichen. Im Falle des Baustellen-Warners betrifft dies bspw. die Einbeziehung der Vorwarntafel. 015 GEN Die Baustellen-Warnung soll auch Dritten bereitgestellt werden. 016 GEN Die (Zwischen-)Ergebnisse aus den kooperativen Diensten sollen auch für interne Zwecke (Verkehrsrechnerzentrale) zur Verfügung stehen. 017 GEN Die betrieblichen Meldungen sollen für interne Zwecke (Verkehrsrechnerzentrale) zur Verfügung stehen. 018 GEN Es sollte möglichst eine Baustellenmanagement- oder Baustelleninformationssystem vorliegen aus dem zusätzliche Daten für den Baustellen-Warner bezogen werden können. 019 GEN Eine Kombination mehrerer Hänger muss seitens des Dienstes verarbeitet werden können.

8 UC Für den Dienst Baustellenwarner müssen die Richtlinien für die Sicherung von Arbeitsstellen (RSA) berücksichtig werden. 021 UC Entsprechend der Richtlinien für die Sicherung von Arbeitsstellen (RSA) kann eine Arbeitsstelle kürzerer Dauer (AkD) mit einem oder mehreren fahrbaren Absperrtafeln eingerichtet werden. 022 UC Die Beschreibung der Architektur muss zukünftig auf weitere Use Case erweiterbar sein. 023 UC Von einer Baustelle muss mindestens ihre Position und der gesperrter Fahrstreifen übertragen werden. 024 UC Für die fahrzeugseitige Datenerfassung muss mindestens XXX übertragen werden 025 COM Die Architektur muss die Nutzung von Mobilfunk für die Kommunikation zwischen fahrbarer Absperrtafel und Zentrale vorsehen 026 COM Die Architektur muss die Nutzung von Mobilfunk und ETSI ITS G5 für die Kommunikation zwischen Infrastruktur und Fahrzeug vorsehen 027 COM Die Architektur muss offen für neue Kommunikationstechnologien sein 028 COM Die Architektur muss die bestehende straßenseitige Kommunikation integrieren 028 COM Alle Außenschnittstellen müssen mittels standardisierter Protokolle umgesetzt werden. 029 COM Es sollen nur Daten ausgetauscht werden, die in einem Data Dictionary registriert sind. 030 COM Die Kommunikation mit der Verkehrsrechnerzentrale muss in DATEX II erfolgen. 031 COM Soweit möglich müssen bereits existierende Nachrichtenformate für die Kommunikation verwendet werden. 032 COM Für die Kommunikation mit den Fahrzeugen sind für Day 1 die Nachrichten CAM und DENM zu verwenden. 033 LOC Es muss eine Codierung der Ereignisse erfolgen, die von den Fahrzeugen verstanden wird [WGS 84]. 034 LOC Es muss eine Codierung der Ereignisse erfolgen, die von der Verkehrsrechnerzentrale verstanden wird. 035 LOC Es muss eine Codierung der Ereignisse erfolgen, die für einen Austausch der Meldungen mit Dritten geeignet ist. 036 SEC Die Kommunikation muss abgesichert sein 037 SEC Die Sicherheitsarchitektur muss sicherstellen, dass Dritte keine Nachrichten im Namen des Straßenbetreibers versenden kann 038 SEC Die Sicherheitsarchitektur muss sicherstellen, dass Dritte keine Nachrichten manipulieren können 039 SEC Die Sicherheitsarchitektur muss sicherstellen, dass Dritte das System nicht zum erliegen bringen können / Überlast (Denial of Service Attack)

9 11 SEC Eine detaillierte Übersicht der Anforderungen an die Security befindet sich in den Dokumenten der PG 6.1 Security 040 PRI Die implementierten Dienste müssen die Anforderungen des Datenschutzes erfüllen die Architektur muss entsprechend gestaltet sein. PRI Eine detaillierte Übersicht der Anforderungen seitens des Datenschutzes befindet sich in den Dokumenten der PG 6.2 Privacy

10 12 3. Dienst Baustellenwarnung 3.1. Allgemeine Beschreibung der Prozessschritte Grundlage für die Ausführung des Dienstes Baustellenwarnung zu Arbeitsstellen kürzerer Dauer ist folgender allgemeine Prozess, dessen Prozessschritte im Detail in den folgenden Absätzen erläutert werden: Abbildung 2 Darstellung des Prozessablaufs für den Dienst Baustellenwarnung im Gesamten Bei der Beschreibung der Prozessschritte ist eine Zuordnung der Prozesse zu bestimmten Komponenten bzw. Akteuren noch nicht beabsichtigt. Exemplarisch erfolgt dies in einem späteren Schritt, mögliche Optionen sind in Kapitel 3.4 skizziert. Die Einbeziehung des Vorwarners in die Gesamtarchitektur erfolgt zu einem späteren Zeitpunkt des Gesamtprojektes C-ITS Corridor.

11 Zusammenstellen der Daten (Inhalt) Abbildung 3 Darstellung des Prozessschritts Zusammenstellen der Daten Im Prozessschritte Zusammenstellen der Daten (in der Abbildung grün hervorgehoben) werden die Ausgangsdaten für den Dienst Baustellenwarner von den technischen Systemen der fahrbaren Absperrtafel abgerufen. D.h. die Geoposition von der Ortungseinheit und die Stellung des Pfeils der Sperrtafel werden abgefragt Fahrtrichtung ermitteln Abbildung 4 Darstellung des Prozessschritts Fahrtrichtung ermitteln Aus (mindestens) zwei Positionen der fahrbaren Absperrtafel und den zugehörigen Zeitstempeln wird die Fahrtrichtung der fahrbaren Absperrtafel bestimmt.

12 Positionskette ermitteln Abbildung 5 Darstellung des Prozessschritts Positionskette ermitteln Eine noch zu definierende Anzahl von Positionspunkten wird zu einer Positionskette ("Trace") zusammengefügt. Dies ist eine Anforderung der Automobilindustrie, da dies für die Richtungsbestimmung und Zuordnung der Meldung im Fahrzeuggerät benötigt wird. Darüber hinaus wird die Information auch zentralenseitig benötigt Zusammenstellen Daten (Betrieb) Abbildung 6 Darstellung des Prozessschritts Zusammenstellen Daten (Betrieb) Im Prozessschritte Zusammenstellen der Daten werden die Daten für den Betrieb des Dienstes Baustellenwarner von den technischen Systemen der fahrbaren Absperrtafel abgerufen.

13 Entscheidung: Verbindung zu Zentrale? Im Entscheidungsschritt "Verbindung zur Zentrale" wird geprüft, ob die fahrbare Absperrtafel eine Verbindung zur Zentrale aufbauen kann. Ist dies nicht möglich, wechselt die fahrbare Absperrtafel in den Stand-Alone Betrieb. Abbildung 7 Darstellung der Entscheidung "Verbindung zur Zentrale" Filtern nach relevanten Meldungen Abbildung 8 Darstellung des Prozessschritts Filtern nach relevanten Meldungen Aus allen von den fahrbaren Absperrtafeln ankommenden Meldungen (Inhalt und Betrieb) werden die für die weitere Verarbeitung benötigten Meldungen heraus gefiltert. Aussortiert zur weiteren Verarbeitung in der Verkehrsrechnerzentrale (siehe Kapitel 3.1.7) werden die Betriebs- / Fehlermeldungen, die Baustellendaten werden im Rahmen des kooperativen Dienstes weiterverarbeitet.

14 Weiterverarbeitung Fehlermeldung Abbildung 9 Darstellung des Prozessschritts Weiterverarbeitung Fehlermeldung Fehlermeldungen und andere betriebliche Meldungen werden nachdem sie heraus gefiltert wurden separat im System des Bundeslandes verarbeitet und ausgewertet Gesperrte Fahrstreifen ermitteln Abbildung 10 Darstellung des Prozessschritts Gesperrten Fahrstreifen ermitteln Aus der Pfeilstellung und der Position der fahrbaren Absperrtafel sowie einer Karte wird der gesperrte Fahrstreifen ermittelt. Anordnungen von mehreren fahrbaren Absperrtafeln werden im in Kapitel beschriebenen Prozessschritt betrachtet.

15 Kombination von mehreren fahrbaren Absperrtafeln Abbildung 11 Darstellung des Prozessschritts Kombination von mehreren fahrbaren Absperrtafeln Werden zur Absicherung einer Arbeitsstelle kürzerer Dauer mehrere fahrbare Absperrtafeln eingesetzt, so ermittelt dieses Modul anhand der Position und Pfeilstellung der einzelnen fahrbaren Absperrtafeln die Spursperrung gesamt Entscheidung "BMS / BIS verfügbar" Abbildung 12 Darstellung der Entscheidung "BMS / BIS verfügbar" Im Entscheidungsschritt "BMS / BIS verfügbar" wird geprüft, ob in der Zentrale ein BMS / BIS zur Verfügung steht, von dem zusätzliche Informationen zur Baustelle bezogen werden können. Ist dies nicht möglich, werden durch die fahrbare Absperrtafel nur die Basisinformationen an die Fahrzeuge übertragen.

16 Verschneiden mit BMS / BIS Daten [optional] Abbildung 13 Darstellung des Prozessschritts Verschneiden mit BMS / BIS Daten Existiert ein Baustelleninformations- oder Baustellenmanagementsystem, so können die von den fahrbaren Absperrtafeln verfügbaren Daten mit weiteren Daten zusammengeführt und angereichert werden. Dies können beispielsweise lokale Streckengeometrien oder der Grund für die Arbeiten sein. Das Modul ist momentan optional vorgesehen, da - nicht alle Bundesländer über ein Baustelleinformations- oder Baustellenmanagementsystem verfügen - nicht in allen Bundesländern die Arbeitsstellen kürzerer Dauer im BIS / BMS vorgehalten werden

17 Entscheidung "Operator verfügbar" Im Entscheidungsschritt "Operator verfügbar" wird geprüft, ob in der Zentrale ein Operator bereit steht, der die Meldung auf Plausibilität prüft. Abbildung 14 Darstellung der Entscheidung "Operator verfügbar" Plausibilisieren der Daten durch einen Operator [optional] Abbildung 15 Darstellung des Plausibilisieren durch Operator Es besteht die Möglichkeit, dass ein Operator die Korrektheit der Baustellenmeldung überprüft.

18 Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über andere Medien Die Daten aus den vorhergehenden Schritten können von Dritten (z.b. Service Providern) zur Weiterverarbeitung in deren Diensten verwendet werden. Die angereicherten Informationen können bspw. über Internet / Rundfunk weiterverteilt werden. Abbildung 16 Darstellung des Prozessschritts Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über andere Medien Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über Mobilfunk Die Daten aus den vorhergehenden Schritten können von Dritten (z.b. Service Providern) zur Weiterverarbeitung in deren Diensten verwendet werden. Die angereicherten Informationen werden über Mobilfunk an die Fahrzeuge übermittelt. Abbildung 17 Darstellung des Prozessschritts Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über Mobilfunk

19 Meldung generieren (DENM) Die Daten aus den vorhergehenden Schritten werden in ein für Fahrzeuge verständliches Format gebracht: DENM. Abbildung 18 Darstellung des Prozessschritts Meldung generieren (DENM) Darstellung der Meldung im Fahrzeug Abbildung 19 Darstellung des Prozessschritts Darstellung der Meldung im Fahrzeug Die empfangene Meldung wird seitens des Fahrzeugs weiterverarbeitet und schließlich dem Fahrer präsentiert. Die detaillierten Abläufe werden in der Projektgruppe IVS Fahrzeugseitiges System erarbeitet.

20 Allgemeine Beschreibung der Architektur Auf Grundlage der in Kapitel 1 beschriebenen Prozessschritte werden nun die bereits bekannten auszutauschenden Daten, Protokolle und Schnittstellen im Detail beschrieben. Erst im letzten Schritt in Kapitel 6 erfolgt die finale technische Ausgestaltung. Für eine übersichtliche Darstellung haben die folgenden Kapitel eine einheitliche Struktur: Module werden wie folgt beschrieben - Eingangsdaten (Datenannahme): hier werden die unterschiedlichen Daten benannt, die für die Verarbeitung innerhalb des Moduls benötigt werden. Über eine Schnittstelle (Datenannahme) werden sie dem Modul zugeführt. Soweit bekannt ist der Datentyp der einzelnen Eingangsdaten benannt. - Funktionalität des Moduls: hier wird kurz beschrieben, was innerhalb des Moduls passiert, d.h. welche Operationen auf den Eingangsdaten ausgeführt werden um die Ausgangsdaten zu erhalten - Ausgangsdaten (Datenabgabe): hier werden die unterschiedlichen Daten benannt, die bei der Verarbeitung innerhalb des Moduls entstehen. Über eine Schnittstelle (Datenabgabe) werden sie anderem zur Verfügung gestellt. Soweit bekannt ist der Datentyp der einzelnen Ausgangsdaten benannt. Schnittstellen werden wie folgt beschrieben - Ausgetauschte Daten: hier wird kurz beschrieben / aufgelistet, welche Daten über die Schnittstelle ausgetauscht werden - Format für Datenaustausch: hier wird das für den Datenaustausch benutzte Nachrichtenformat beschrieben - Kommunikationsmedium: hier wird der verwendete Kommunikationskanal benannt

21 23 Abbildung 20 Teil 1 Darstellung des Gesamtprozesses für Baustellenwarnung Details der Abbildung werden in den nächsten Kapiteln vergrößert. Module / Prozessschritte, die für den kooperativen Dienst Baustellenwarnung benötigt werden sind schwarz unterlegt Module / Prozessschritte, die für betriebliche oder Länder-interne Zwecke benötigt werden sind blau unterlegt.

22 Modul Inhaltliche Daten zusammenstellen Dateninhalt Datenformat Eingangsdaten (Datenannahme) ID des Baustellenhängers Zahl Koordinaten aus Ortung WGS 84 Zeitstempel (UTC) Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Pfeilstellung 1 (Leuchtpfeil) [0, 1, 2] Pfeilstellung 2 (Blechpfeil) [0, 1, 2] Zuverlässigkeit 2 Zahl in [%] Funktionalität des Moduls Ausgangsdaten (Datenabgabe) Zusammenstellen der Daten aus Ortungseinheit und Anzeige Pfeilstellung der Absperrtafel Meldung mit ID, Koordinaten, Pfeilstellungen und nenschnittstelle fahrbare proprietär momentan In- Zeitstempel Absperrtafel Schnittstelle S1 2 "Zuverlässigkeit" ist ein Qualitätswert und gibt an, wie verlässlich die (Eingangs-)Daten sind.

23 25 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium ID Koordinaten Zeitstempel Pfeilstellungen (1 und 2) Zuverlässigkeit Proprietär da Modul-intern Modul-intern Modul Richtung Dateninhalt Datenformat Eingangsdaten (Datenannahme) Koordinaten WGS 84 Zeitstempel (UTC) Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Zuverlässigkeit Zahl in [%] Funktionalität des Moduls Ermitteln der Fahrtrichtung der fahrbaren Absperrtafel anhand der zeitlichen Abfolge der Positionen Ausgangsdaten (Datenabgabe) Fahrtrichtung In Grad (0 bis 360 ) Zeitstempel (UTC) Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Zuverlässigkeit Zahl in [%] Modul Positionskette

24 26 Dateninhalt Datenformat Eingangsdaten (Datenannahme) Koordinaten WGS 84 Zeitstempel (UTC) Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Zuverlässigkeit Zahl in [%] Funktionalität des Moduls Erstellen einer Positionskette aus Einzelpositionen (Trace der fahrbaren Absperrtafel) Ausgangsdaten (Datenabgabe) Positionskette [n] Positionen WGS 84 Zeitstempel (UTC) [n] Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Zuverlässigkeit Zahl in [%] Entscheidungsmodul "Verbindung zur Zentrale" Es wird geprüft ob die fahrbare Absperrtafel eine Verbindung zur Zentrale via Mobilfunk aufbauen kann Schnittstelle S2 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium ID Position / Koordinaten Fahrtrichtung Positionskette (Trace) Pfeilstellungen (1 und 2) Zeitstempel Zuverlässigkeit DATEX II angestrebt Mobilfunk Das Format für den Datenaustausch ist bisher noch nicht standardisiert. Dies wird angestrebt.

25 Modul Betriebliche Daten zusammenstellen Dateninhalt Datenformat Eingangsdaten (Datenannahme) ID Zahl Geschwindigkeit fahrb. Absperrtafel Zahl in [km/h] Verkehrszustand (Seitenradar-Daten) Die Datenformate werden Status Absperrtafel Sensordaten (z.b. Füllstand von Brennstoffzellen) Batteriespannung im Rahmen der Prototypenentwicklung spezifiziert. Zeitstempel (UTC) Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Funktionalität des Moduls Zusammenstellen der Daten, die für den Betrieb relevant Ausgangsdaten (Datenabgabe) Schnittstelle S3 sind Meldung mit betrieblich relevanten Daten DATEX II mit TLS Codes (angestrebt) Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium Betriebs- / Fehlermeldung DATEX II angestrebt Mobilfunk Das Format für den Datenaustausch ist bisher noch nicht standardisiert. Dies wird angestrebt.

26 Modul Filtern Dateninhalt Datenformat Eingangsdaten (Datenannahme) Baustellendaten DATEX II angestrebt Betriebs- / Fehlermeldungen DATEX II angestrebt Funktionalität des Moduls Filtern der eingehenden Meldungen von den fahrbaren Absperrtafeln, Auswahl der für den Dienst Baustellenmeldung relevanten Meldungen Ausgangsdaten (Datenabgabe) ausgewählte Baustellenmeldungen DATEX II angestrebt Gebündelte Betriebs- / DATEX II angestrebt Fehlermeldungen

27 Schnittstelle S4 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium Betriebs- / Fehlermeldung DATEX II angestrebt Mobilfunk / Internet / Intranet (intern) Modul Weiterverarbeitung Fehlermeldung Eingangsdaten (Datenannahme) Funktionalität des Moduls Ausgangsdaten (Datenabgabe) Dateninhalt Datenformat Betriebs- / Fehlermeldungen DATEX II angestrebt Die Betriebs- / Fehlermeldungen werden weiterverarbeitet und stehen weiteren Diensten der Länder Zentrale zur Verfügung Extrahierte Daten aus Betriebs- / proprietär Fehlermeldungen

28 30 Die Details der Weiterverarbeitung der Fehlermeldung sind nicht im Fokus der Beschreibung des Dienstes Baustellenwarner und werden ab diesem Schritt nicht weiter vertieft Schnittstelle S5 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium Baustellenmeldung DATEX II angestrebt Mobilfunk / Internet / Intranet (intern) Modul Fahrstreifen Sperrung

29 31 Dateninhalt Datenformat Eingangsdaten (Datenannahme) ID des Baustellenhängers Zahl Koordinaten aus Ortung WGS 84 Zeitstempel (UTC) Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Pfeilstellung 1 (Leuchtpfeil) [0, 1, 2] Pfeilstellung 2 (Blechpfeil) [0, 1, 2] Zuverlässigkeit Zahl in [%] Karte Noch nicht spezifiziert Funktionalität des Moduls Ermitteln der gesperrten Fahrstreifen. Ausgangsdaten (Datenabgabe) Gesperrte Fahrstreifen [n] als Zahl ( ) (Nummer des Fahrstreifens) Zeitstempel (UTC) Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Zuverlässigkeit Zahl in [%] Schnittstelle S6 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium Baustellenmeldung ergänzt um gesperrte Fahrstreifen DATEX II angestrebt Mobilfunk / Internet / Intranet (intern) / Modul-intern Das Format für den Datenaustausch ist bisher noch nicht standardisiert. Dies wird angestrebt.

30 Optional: Modul Kombination von >1 fahrbarer Absperrtafel Dateninhalt Datenformat Eingangsdaten (Datenannahme) Gesperrte Fahrstreifen [n] als Zahl ( ) Positionen [n] WGS 84 Baustellenmeldung DATEX II angestrebt Zuverlässigkeit Zahl in [%] Funktionalität des Moduls Kombinieren von mehreren fahrbaren Absperrtafeln Ausgangsdaten (Datenabgabe) Gesperrte Fahrstreifen Noch nicht spezifiziert Zeitstempel Datum und Uhrzeit (DD.MM.YYYY hh:mm:ss) Erweiterte Baustellenmeldung DATEX II angestrebt Zuverlässigkeit Zahl in [%] Schnittstelle S7

31 33 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium Baustellenmeldung DATEX II intern Modul Weiterverwendung Länder intern Dateninhalt Datenformat Eingangsdaten (Datenannahme) Baustellenmeldungen DATEX II angestrebt Funktionalität des Moduls Die Baustellenmeldungen werden weiterverarbeitet und stehen weiteren Diensten der Länder Zentrale zur Verfügung Ausgangsdaten (Datenabgabe) Extrahierte Daten aus Baustellenmeldungen proprietär Die Details der Weiterverarbeitung der Fehlermeldung sind nicht im Fokus der Beschreibung des Dienstes Baustellenwarner und werden ab diesem Schritt nicht weiter vertieft Entscheidungsmodul "BIS / BMS verfügbar" Es wird geprüft ob ein Baustelleninformations- oder Baustellenmanagementsystem verfügbar ist Schnittstelle S8 Ausgetauschte Daten ID Position Zuverlässigkeit Fahrtrichtung

32 34 Format für Datenaustausch Kommunikationsmedium Gesperrter Fahrstreifen Gesperrte Fahrstreifen bei mehreren fahrbaren Absperrtafeln Proprietär Modul-intern Optional Modul Verschneiden mit BMS / BIS Daten Dateninhalt Datenformat Eingangsdaten (Datenannahme) Baustellenmeldung proprietär Daten aus BMS / BIS (Details DATEX II siehe unten) Funktionalität des Moduls Baustelleninformation werden um BMS / BIS Daten ergänzt durch verschneiden mit entsprechender Datenbank Ausgangsdaten (Datenabgabe) Position des Hängers proprietär Spursperrung Fahrtrichtung Zeitstempel Zusatzinformationen ID des Regelplans Zusatzfeld (Freitext) Daten aus BIS / BMS - Verkehrsrechtliche Anordnungen (z.b. zulässige Höchstgeschwindigkeit - Eindeutige Baustellen-ID - Art der Maßnahme (z.b. Mäharbeiten, Schutzplankenreparaturen, Unfallabsicherung, Absicherung bei Hochwasser) - Geplanter zeitlicher Beginn und zeitliches Ende oder Dauer der Arbeiten - Räumlicher Beginn und räumliches Ende der Maßnahme (geplante Länge / Ausdehnung) - Fahrtrichtung - Verkehrsführung (Gesperrte Fahrstreifen / Spurreduzierung) - Stationäre oder Wander-Baustelle Entscheidungsmodul "Operator verfügbar?" Es wird geprüft ob eine Plausibilisierung der Meldung durch einen Operator erfolgen soll.

33 Schnittstelle S9 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium Baustellenmeldung mit Zusatzinformationen proprietär intern Optional Modul Plausibilisieren (Operator) Eingangsdaten (Datenannahme) Funktionalität des Moduls Ausgangsdaten (Datenabgabe) Dateninhalt Datenformat Baustellenmeldung mit Zusatzinformation proprietär Baustellenmeldung wird durch Operator auf Plausibilität überprüft Plausibilisierte Baustellenmeldung mit Zusatzinfor- DATEX II angestrebt mation Schnittstelle S10 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium DATEX II Meldung DATEX II Profil Internet

34 Modul Distribution von Daten Dateninhalt Datenformat Eingangsdaten (Datenannahme) DATEX II Meldung DATEX II Profil Funktionalität des Moduls Distribution von Baustellendaten auf die unterschiedlichen Abnehmer Ausgangsdaten (Datenabgabe) DATEX II Meldung DATEX II Profil Schnittstelle S11 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium DATEX II Meldung mit Position des Hängers, Spursperrung, Fahrtrichtung, Zeitstempel ggf. Zusatzinformationen DATEX II Profil Internet

35 Modul Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über andere Medien Dateninhalt Datenformat Eingangsdaten (Datenannahme) DATEX II Meldung DATEX II Profil Daten aus eigenen Datenbanken offen Funktionalität des Moduls Baustelleninformation wird in die Systeme des Verkehrsinformationsanbieters eingelesen und weiterverarbeitet Ausgangsdaten (Datenabgabe) Meldung mit Position, proprietär Spursperrung und Fahrtrichtung Meldung mit Position, proprietär Spursperrung, Fahrtrichtung und Zusatzinformationen Schnittstelle S12 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium Meldung mit Position des Hängers, Spursperrung, Fahrtrichtung, Zeitstempel ggf. Zusatzinformationen Proprietär Internet, Rundfunk oder andere Medien Modul Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über Mobilfunk

36 38 Dateninhalt Datenformat Eingangsdaten (Datenannahme) DATEX II Meldung DATEX II Profil Daten aus eigenen Datenbanken offen Funktionalität des Moduls Baustelleninformation wird in die Systeme des Verkehrsinformationsanbieters eingelesen Ausgangsdaten (Datenabgabe) TPEG Meldung mit Position, TPEG Spursperrung und Fahrtrichtung TPEG Meldung mit Position, TPEG Spursperrung, Fahrt- richtung und Zusatzinformationen Schnittstelle 13 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium TPEG Meldung mit aktueller Position des Hängers, Spursperrung, Fahrtrichtung eventuell ergänzt um Zusatzinformationen TPEG Mobilfunk Schnittstelle S14

37 39 Ausgetauschte Daten Format für Datenaustausch Kommunikationsmedium Payload für DENM: Position des Hängers, Spursperrung, Fahrtrichtung, Zeitstempel, ggf. Zusatzinformationen Wird im Rahmen der Prototypenentwicklung spezifiziert Mobilfunk / Intranet / modul-intern Das Format für den Datenaustausch ist bisher noch nicht standardisiert. Dies wird angestrebt Modul DENM erzeugen Dateninhalt Datenformat Eingangsdaten (Datenannahme) Payload für DENM Wird im Rahmen der Prototypenentwicklung spezifiziert Funktionalität des Moduls Payload für DENM in DENM Meldung konvertieren Ausgangsdaten (Datenabgabe) DENM Meldung mit Position, DENM mit Road Works Spursperrung und Warning Container Fahrtrichtung evt. ergänzt um Zusatzinformationen DENM Meldung mit aktueller DENM mit IVI Container Position des Hängers, Pfeilstellung Schnittstelle S15 Ausgetauschte Daten Format für Datenaustausch DENM Meldung mit aktueller Position des Hängers, Spursperrung, Fahrtrichtung eventuell ergänzt um Zusatzinformationen DENM mit Road Works Warning Container

38 40 Kommunikationsmedium DENM mit IVI Container ETSI ITS G5 (WLAN p) Modul Präsentation der Meldung Eingangsdaten (Datenannahme) Dateninhalt DENM Meldung mit aktueller Position des Hängers, Spursperrung und Fahrtrichtung DENM Meldung mit aktueller Position des Hängers, Pfeilstellung Datenformat DENM mit Road Works Warning Container DENM mit IVI Container Funktionalität des Moduls Ausgangsdaten (Datenabgabe) TPEG Meldung mit Position TPEG des Hängers, Spursperrung, Fahrtrichtung und Zusatzinformationen Geeignete Präsentation der Baustellenmeldung für Fahrer Darstellung der Baustellenmeldung proprietär

39 Baustellenwarner Stand-Alone Lösung Im Falle, dass die fahrbare Absperrtafel nicht mit dem Backend kommunizieren kann, besteht die Notwendigkeit, dass ein alternativer Betriebsmodus vorgesehen ist, in welchen die fahrbare Absperrtafel dann wechselt. Dieser wird als Stand-Alone Betrieb bezeichnet. Abbildung 21 Darstellung des Stand-Alone Betriebs Im Stand-Alone Betrieb besteht keine Verbindung mit der Verkehrsrechnerzentrale, d.h. der Hänger ist im autarken Betrieb. Dies wird nach Zusammenstellen und Verarbeiten der Daten geprüft. Für den Fall, dass keine Verbindung besteht, entfallen die Bausteine, die in Abbildung 21 grau eingefärbt sind. Auf der fahrbaren Absperrtafel wird eine leere DENM mit den verfügbaren Daten ergänzt, diese wird anschließend in die Fahrzeuge übertragen. Die Abläufe des Systems sind so definiert und seitens der Architektur implementiert, dass der Stand-Alone Fall nur selten zur Anwendung kommt. Sobald im Rahmen einer Arbeitsstelle kürzerer Dauer einmal eine Mobilfunkverbindung ins Backend bestanden hat, liegen die entsprechenden Daten auf der fahrbaren Absperrtafel vor. Dementsprechend kann in den meisten Fällen mehr als nur eine Basis-DENM an die Fahrzeuge übertragen werden selbst wenn zum Übertragungszeitpunkt keine Mobilfunkverbindung ins Backend besteht.

40 Varianten zur Implementierung Für die technische Umsetzung der Architektur, die die Implementierung der beiden Dienste Baustellenwarnung und Fahrzeugseitige Datenerfassung ermöglicht, ergeben sich aus aktueller Sicht drei unterschiedliche Lösungsansätze. Die technischen Umsetzungen sind funktional gleichwertig, sie sind lediglich hinsichtlich Kosten und Risiken voneinander abzugrenzen. Zum aktuellen Zeitpunkt erfolgt keine Entscheidung für eine der drei Möglichkeiten. Um diese Entscheidung treffen zu können ist zunächst eine detailliertere Betrachtung der Gesamtarchitektur und eine abschließende Spezifikation der einzelnen Module, Schnittstellen und übertragenen Daten notwendig. Im Folgenden werden die drei möglichen technischen Umsetzungen beschrieben. Diese unterscheiden sich im Wesentlichen in der Umsetzung der zentralenseitigen Funktionalitäten. Hierbei handelt es sich um die Module - Filtern aller Zustandsmeldungen des Sperranhängers in Betriebs- / Fehlermeldungen und Meldungen für den Endnutzer-Dienst - Ermitteln der gesperrten Fahrstreifen - Verschneiden der Endnutzer-Dienst Meldungen mit Informationen aus dem länderspezifischen Baustelleninformations- bzw. Baustellenmanagementsystems sofern im Land vorhanden - Kombination mehrerer Sperranhänger einer Arbeitsstelle sofern erforderlich Variante 1 dezentrale Lösung In einer dezentralen Lösung werden die zentralenseitig vorzusehenden Module wie sie im Detail in Kapitel 3.2 dargestellt sind in jedem einzelnen Bundesland implementiert. Für die Einführung des C-ITS Corridors heißt dies, dass zunächst eine entsprechende Architektur mit den genannten Modulen zur Umsetzung der beiden Dienste in Hessen aufgebaut wird. Im Rahmen des Roll-Outs folgen die Bundesländer Baden-Württemberg, Bayern, Nordrhein- Westfalen und Rheinland-Pfalz. Anschließend wird auf die verbliebenen Bundesländer ausgerollt. In den einzelnen Bundesländern werden Instanzen (=identische Kopien) der Module in die jeweilige, länderspezifische straßen- und zentralenseitige Infrastruktur integriert. Der MDM ist in einer verteilten Lösung zentraler, verbindender Knoten. Über ihn wird die Baustellenwarnung in unterschiedlichen Detaillierungsformen (nur fahrbare Absperrtafel-Info, fahrbare Absperrtafel-Info + Zusatzinformationen) den Bundesländern und Dritten zur Verfügung gestellt wird.

41 43 Es ergibt sich folgende Verteilung der Zuständigkeiten für eine verteilte Umsetzung (Abbildung 22). Abbildung 22 Zuordnung der Zuständigkeiten für eine verteilte Lösung (Variante 1) In einer auf die zum Einsatz kommender Komponenten beschränkten Sicht ergibt sich folgende Darstellung (Abbildung 25). Abbildung 23 Schematische Komponentendarstellung der dezentralen Lösung

42 Variante 2 zentrale Lösung In einer zentralen Lösung bietet eine Kooperative Zentrale den einzelnen Bundesländern die zentralenseitig vorzusehenden Module, über welche diese nicht selbst verfügen, zentral an. In einer zentralen Lösung erfolgen die Erfassung der Basisdaten und erste Vorverarbeitungsschritte in den von den einzelnen Bundesländern betriebenen fahrbaren Absperrtafeln. Für die Filterung und Weiterverarbeitung nutzen die Bundesländer zentral bereitgestellte Module. Das Ergebnis der Datenverarbeitung wird über den MDM bereitgestellt und kann dort von den Bundesländern (und Dritten) abgegriffen werden. Liegt in den Bundesländern ein Baustelleninformations- oder Baustellenmanagementsystem vor, können die Daten aus dem vorangegangen Verarbeitungsschritt mit Daten aus diesen Systemen verschnitten werden. Dies erfolgt in den einzelnen Bundesländern. Die Ergebnisse werden über den MDM zur Verfügung gestellt. Um die Baustellenmeldung für die Fahrzeuge lesbar zu machen müssen diese in einem einheitlichen Format, der DENM codiert werden. Für diese Aufgabe nutzen die Bundesländer wiederum zentral bereitgestellte Module.

43 45 Es ergibt sich folgende Verteilung der Zuständigkeiten (Abbildung 24): Abbildung 24 Zuordnung der Zuständigkeiten für eine zentrale Lösung (Variante 2) In einer auf die zum Einsatz kommender Komponenten beschränkten Sicht ergibt sich folgende Darstellung (Abbildung 25). Abbildung 25 Schematische Komponentendarstellung der zentralen Lösung

44 Variante 3 gemischt zentral und dezentrale Lösung In einer gemischt zentral und dezentralen Lösung werden die Variante 1 dezentrale Lösung und die Variante 2 zentrale Lösung miteinander kombiniert. Dies heißt, dass einzelne Bundesländer soweit die technischen Voraussetzungen dort bestehen die benötigten Module in ihre jeweilige Architektur integrieren. Andere Bundesländer nutzen die zentral in einer Kooperativen Zentrale bereit gestellten Module um die beiden Funktionen umzusetzen. Eine Entscheidung für Variante 1 oder 2 erfolgt jeweils länderspezifisch. Durch die Verwendung der gleichen Module, sowohl in einer dezentralen als auch zentralen Lösung ist die Umsetzung in einem kombinierten System möglich.

45 47 Für das System DORA wurde bereits ein DATEX II Profil entwickelt. Außerdem existiert ein DA- TEX II Profil BIS für die Darstellung der Dauerbaustellen im MDM. Es ist zu überprüfen, welches der beiden Protokolle geeignet ist, die oben genannten Informationen zu übertragen. Sofern notwendig sollen Anpassungen erfolgen. Erstrebenswertes Ziel ist es, nur ein Datex II Profil für Baustellen zu haben, in dem AlD und AkD abgebildet werden können. Für die Überführung der Baustelleninformationen in das DATEX II Profil BIS stehen im Verlauf des Dienstes Baustellenwarnung zwei unterschiedlich umfangreiche Datensätze bereit. Einerseits eine Art Basisinformation, die lediglich aus der Position des Hängers, der Fahrtrichtung, der Positionskette, der Spursperrung und einem Zeitstempel besteht. Andererseits können diese durch Zusatzinformationen aus dem BIS / BMS ergänzt sein. Beide Datensätze sollen in der gleichen DATEX II Meldung untergebracht werden. Dementsprechend wird im Modul "DATEX II Meldung erstellen" abhängig von den verfügbaren Eingangsdaten eine DATEX II Meldung zusammen gestellt. Sind Informationen nicht verfügbar, so bleiben die entsprechenden Felder in der Meldung jeweils leer.

46 48 4. Dienst Fahrzeugseitige Datenerfassung Als zweiter Dienst wird die Fahrzeugseitige Datenerfassung implementiert. Eine Ergänzung um die entsprechenden Prozesse erfolgt zu einem späteren Zeitpunkt.

47 49 Glossar AkD Arbeitsstelle kürzerer Dauer AlD Arbeitsstelle längerer Dauer BIS Baustelleninformationssystem BMS Baustellenmanagementsystem CAM Cooperative Awareness Message (standardisiert in ETSI ) C-ITS Cooperative ITS DATEX II Standardisiertes Datenaustauschformat für die Kommunikation zwischen Zentralen DENM Decentralized Environmental Notification Message (standardisiert in ETSI ) DORA Dynamische Ortung von Arbeitsstellen INS Integrationsnetz Straße ITS Intelligent Transport Systems IVI In-Vehicle Information MDM Mobilitätsdaten Marktplatz TPEG Transport Protocol Experts Group WGS 84 World Geodetic System 1984