Erster Entwurf Gesamtarchitektur - c-its-korridor.de C-ITS.pdf · schriebenen Prozess hinaus im Detail auf die unterschiedlichen Module, die Schnittstel- len, ausgetauschten Daten

Erster Entwurf "Gesamtarchitektur"

- Dokument D 01 der Projektgruppe 1 Systemarchitektur -

Entwurf; Version 2.1

25.06.2014

4

Inhalt

0. Verwendung dieses Dokuments ..................................................................................... 6

1. Einleitung ........................................................................................................................ 6

2. Anforderungen an die Systemarchitektur ...................................................................... 9

3. Dienst Baustellenwarnung ............................................................................................ 12

3.1. Allgemeine Beschreibung der Prozessschritte .................................................... 12

3.1.1. Zusammenstellen der Daten (Inhalt) ....................................................... 13

3.1.2. Fahrtrichtung ermitteln ........................................................................... 13

3.1.3. Positionskette ermitteln .......................................................................... 14

3.1.4. Zusammenstellen Daten (Betrieb) .......................................................... 14

3.1.5. Entscheidung: Verbindung zu Zentrale?.................................................. 15

3.1.6. Filtern nach relevanten Meldungen ........................................................ 15

3.1.7. Weiterverarbeitung Fehlermeldung ........................................................ 16

3.1.8. Gesperrte Fahrstreifen ermitteln ............................................................ 16

3.1.9. Kombination von mehreren fahrbaren Absperrtafeln ............................ 17

3.1.10. Entscheidung "BMS / BIS verfügbar" ....................................................... 17

3.1.11. Verschneiden mit BMS / BIS Daten [optional] ........................................ 18

3.1.12. Entscheidung "Operator verfügbar" ........................................................ 19

3.1.13. Plausibilisieren der Daten durch einen Operator [optional] ................... 19

3.1.14. Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über andere Medien ........................................................................................ 20

3.1.15. Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über Mobilfunk ................................................................................................ 20

3.1.16. Meldung generieren (DENM) .................................................................. 21

3.1.17. Darstellung der Meldung im Fahrzeug .................................................... 21

3.2. Allgemeine Beschreibung der Architektur .......................................................... 22

3.2.1. Modul Inhaltliche Daten zusammenstellen ............................................. 24

3.2.2. Schnittstelle S1 ........................................................................................ 24

3.2.3. Modul Richtung ....................................................................................... 25

3.2.4. Modul Positionskette .............................................................................. 25

3.2.5. Entscheidungsmodul "Verbindung zur Zentrale" .................................... 26

3.2.6. Schnittstelle S2 ........................................................................................ 26

3.2.7. Modul Betriebliche Daten zusammenstellen .......................................... 27

3.2.8. Schnittstelle S3 ........................................................................................ 27

3.2.9. Modul Filtern ........................................................................................... 28

3.2.10. Schnittstelle S4 ........................................................................................ 29

3.2.11. Modul Weiterverarbeitung Fehlermeldung ............................................ 29

3.2.12. Schnittstelle S5 ........................................................................................ 30

3.2.13. Modul Fahrstreifen Sperrung .................................................................. 30

3.2.14. Schnittstelle S6 ........................................................................................ 31

3.2.15. Optional: Modul Kombination von >1 fahrbarer Absperrtafel ............... 32

3.2.16. Schnittstelle S7 ........................................................................................ 32

3.2.17. Modul Weiterverwendung Länder intern ............................................... 33

3.2.18. Entscheidungsmodul "BIS / BMS verfügbar" ........................................... 33

3.2.19. Schnittstelle S8 ........................................................................................ 33

3.2.20. Optional Modul Verschneiden mit BMS / BIS Daten ............................... 34

5

3.2.21. Entscheidungsmodul "Operator verfügbar?" .......................................... 34

3.2.22. Schnittstelle S9 ........................................................................................ 35

3.2.23. Optional Modul Plausibilisieren (Operator) ............................................ 35

3.2.24. Schnittstelle S10 ...................................................................................... 35

3.2.25. Modul Distribution von Daten ................................................................. 36

3.2.26. Schnittstelle S11 ...................................................................................... 36

3.2.27. Modul Vorbereitung der Meldung für weitere Verkehrsinformationsdienste – über andere Medien ................................................................................ 37

3.2.28. Schnittstelle S12 ...................................................................................... 37

3.2.29. Modul Vorbereitung der Meldung für weitere Verkehrsinformationsdienste – über Mobilfunk ........................................................................................ 37

3.2.30. Schnittstelle 13 ........................................................................................ 38

3.2.31. Schnittstelle S14 ...................................................................................... 38

3.2.32. Modul DENM erzeugen ........................................................................... 39

3.2.33. Schnittstelle S15 ...................................................................................... 39

3.2.34. Modul Präsentation der Meldung ........................................................... 40

3.3. Baustellenwarner Stand-Alone Lösung ............................................................... 41

3.4. Zuordnung der Module zu Komponenten ........................................................... 42

3.5. Varianten zur Implementierung .......................................................................... 43

3.5.1. Variante 1 – dezentrale Lösung ............................................................... 43

3.5.2. Variante 2 – zentrale Lösung ................................................................... 46

3.5.3. Variante 3 – gemischt zentral und dezentrale Lösung ............................ 48

3.6. Schnittstellen – DATEX II Profile .......................................................................... 49

4. Dienst Fahrzeugseitige Datenerfassung ....................................................................... 50

Glossar .................................................................................................................................... 51

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 Anforde-rungsanalyse (siehe oben)

- Kapitel 3.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 zeit-

nah ergänzt. - Kapitel 3.2 beschreibt allgemein die Architektur. Hier wird über den in Kapitel 3.1 be-

schriebenen Prozess hinaus im Detail auf die unterschiedlichen Module, die Schnittstel-len, ausgetauschten Daten und Kommunikationswege eingegangen.

- Kapitel 3.3 beschreibt den Dienst für den Fall, dass keine Verbindung zur Zentrale auf-genommen werden kann

- Kapitel 3.4 enthält eine allgemeine Zuordnung der Module zu Komponenten – zunächst unabhängig von einer späteren Implementierung

- Kapitel 3.5 widmet sich der praktischen Anwendung der Architektur und beschreibt ver-schiedenen Möglichkeiten für eine konkrete Architektur Implementierung in der Infra-struktur

Kapitel 3.1 und 3.2 beschreiben unabhängig von einer zukünftigen möglichen technischen Aus-gestaltung 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 die-nen, eine Entscheidung für eine der in Kapitel 3.5 beschriebenen möglichen Implementierungen zu treffen.

7

Die Beschreibung der Architektur orientiert sich an der von der FGSV entwickelten Methodik der Pyramide1 (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 un-terschiedlichen Aspekte einer Architektur werden in der FGSV Pyramide in fünf Schichten ge-bündelt – ausgehend von strategischen Überlegungen an der Spitze bis zur technischen Umset-zung am Fuß der Pyramide.

Das vorliegende Dokument betrachtet die Ebenen "Prozesse", "Informationsflüsse", "Datenaus-tauschmechanismen" in Kap. 3.1+3.2 und abschließend die "Infrastruktur (eingesetzte Technik)" in Kap. 3.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]

8

9

2. Anforderungen an die Systemarchitektur

Für die Implementierung der beiden Dienste Baustellenwarner und fahrzeugseitige Verkehrsla-ge 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 inte-griert 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 Im-plementierungen dieser Architektur (Umsetzung mittels Komponenten) mög-lich sind.

009 GEN Unterschiedliche Implementierungen der Architektur sollen miteinander in-teroperabel sein.

010 GEN Für die Distribution von Daten sind bestehende Plattformen (MDM) vorzuse-hen.

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 fahrzeugseiti-ge 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ögli-chen. 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 in-terne Zwecke (Verkehrsrechnerzentrale) zur Verfügung stehen.

017 GEN Die betrieblichen Meldungen sollen für interne Zwecke (Verkehrsrechner-zentrale) zur Verfügung stehen.

018 GEN Es sollte möglichst eine Baustellenmanagement- oder Baustelleninformati-onssystem 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.

10

020 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 erwei-terbar sein.

023 UC Von einer Baustelle muss mindestens ihre Position und der gesperrter Fahr-streifen ü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 zwi-schen 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 integrie-ren

028 COM Alle Außenschnittstellen müssen mittels standardisierter Protokolle umge-setzt werden.

029 COM Es sollen nur Daten ausgetauscht werden, die in einem Data Dictionary regis-triert sind.

030 COM Die Kommunikation mit der Verkehrsrechnerzentrale muss in DATEX II erfol-gen.

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 ver-standen wird [WGS 84].

034 LOC Es muss eine Codierung der Ereignisse erfolgen, die von der Verkehrsrechner-zentrale 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)

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 be-findet sich in den Dokumenten der PG 6.2 Privacy

Eine detaillierte Dokumentation der Anforderungen zu den einzelnen Komponenten der Ge-samtarchitektur (z.B. IRS, ICS und Erweiterung der Zentrale) finden sich in den Spezifikationen der jeweiligen Projektgruppen.

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 beabsich-tigt. 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.

13

3.1.1.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 fahrba-ren Absperrtafel abgerufen. D.h. die Geoposition von der Ortungseinheit und die Stellung der Pfeile der Sperrtafel werden abgefragt.

3.1.2.Fahrtrichtung ermitteln

Abbildung 4 Darstellung des Prozessschritts Fahrtrichtung ermitteln

Aus (mindestens) zwei Positionen der fahrbaren Absperrtafel und den zugehörigen Zeitstem-peln wird die Fahrtrichtung der fahrbaren Absperrtafel bestimmt.

14

3.1.3.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 Richtungs-bestimmung und Zuordnung der Meldung im Fahrzeuggerät benötigt wird. Darüber hinaus wird die Information auch zentralenseitig benötigt.

3.1.4.Zusammenstellen Daten (Betrieb)

Abbildung 6 Darstellung des Prozessschritts Zusammenstellen Daten (Betrieb)

Im Prozessschritte Zusammenstellen der Daten (Betrieb) werden die Daten für den Betrieb des Dienstes Baustellenwarner von den technischen Systemen der fahrbaren Absperrtafel abgeru-fen.

15

3.1.5.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 Ab-sperrtafel in den Stand-Alone Betrieb.

Abbildung 7 Darstellung der Entscheidung "Verbindung zur Zentrale"

3.1.6.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 Be-triebs- / Fehlermeldungen. Die Baustellendaten werden im Rahmen des kooperativen Dienstes weiterverarbeitet.

16

3.1.7.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.

3.1.8.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 ge-sperrte Fahrstreifen ermittelt.

Anordnungen von mehreren fahrbaren Absperrtafeln werden im in Kapitel 3.1.9 beschriebenen Prozessschritt betrachtet.

17

3.1.9.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 fahr-baren Absperrtafeln die Spursperrung gesamt.

3.1.10.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.

18

3.1.11.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 an-gereichert 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 Baustellenmanagement-system verfügen

- nicht in allen Bundesländern die Arbeitsstellen kürzerer Dauer im BIS / BMS vorgehalten werden

19

3.1.12. Entscheidung "Operator verfügbar"

Im Entscheidungsschritt "Operator verfügbar" wird geprüft, ob in der Zentrale ein Operator be-reit steht, der die Meldung auf Plausibilität prüft.

Abbildung 14 Darstellung der Entscheidung "Operator verfügbar"

3.1.13. 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. Der Vorgang der Plausibiliserung soll soweit wie möglich automatisiert werden, eine Plausibili-serung durch einen Operator soll nur in Konfliktfällen stattfinden (optional).

20

3.1.14. Vorbereitung der Meldung für weitere Verkehrsinformationsdienste über andere Me-

dien

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

3.1.15. 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

21

3.1.16.Meldung generieren (DENM)

Die Daten aus den vorhergehenden Schritten werden in ein für Fahrzeuge verständliches For-mat gebracht: DENM.

Abbildung 18 Darstellung des Prozessschritts Meldung generieren (DENM)

3.1.17.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.

22

3.2. Allgemeine Beschreibung der Architektur

Auf Grundlage der in Kapitel 1 beschriebenen Prozessschritte werden nun die bereits bekann-ten 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 (Da-tenannahme) 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 pas-siert, d.h. welche Operationen auf den Eingangsdaten ausgeführt werden um die Aus-gangsdaten zu erhalten

- Ausgangsdaten (Datenabgabe): hier werden die unterschiedlichen Daten benannt, die bei der Verarbeitung innerhalb des Moduls entstehen. Über eine Schnittstelle (Datenab-gabe) 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 Nachrich-tenformat beschrieben

- Kommunikationsmedium: hier wird der verwendete Kommunikationskanal benannt

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 Baustellen-warnung benötigt werden sind schwarz unterlegt – Module / Prozessschritte, die für betriebliche oder Länder-interne Zwecke benötigt wer-den sind blau unterlegt.

Eine detaillierte Spezifikation der einzelnen Module wird im Rahmen der prototypischen Umsetzung in den Arbeitsgruppen PG2 und PG 4 er-stellt. Die detaillierten Beschreibungen, welche auch für die zukünftigen Ausschreibungen verwendet werden, erfolgen in enger Abstimmung mit der PG 1 um die Konsistenz zwischen den Spezifikationen sicher zu stellen.

Für die zentralen Schnittstellen des Dienstes Baustellenwarnung wird die Harmonisierung mit den anderen beteiligten C-ITS Corridor Ländern angestrebt. Drüber hinaus sollen diese in die Standardisierung eingebracht werden, um bei einem zukünftigen europäischen Roll-Out die In-teroperabilität mit anderen Implementierungen zu sichern.

24

3.2.1.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ässigkeit2 Zahl in [%]

Funktionalität des Moduls Zusammenstellen der Daten aus Ortungseinheit und An-zeige Pfeilstellung der Absperrtafel

Ausgangsdaten (Datenabgabe) Meldung mit ID, Koordina-ten, Pfeilstellungen und Zeitstempel

proprietär – momentan In-nenschnittstelle fahrbare Absperrtafel

3.2.2.Schnittstelle S1

2 "Zuverlässigkeit" ist ein Qualitätswert und gibt an, wie verlässlich die (Eingangs-)Daten sind.

25

Ausgetauschte Daten ID Koordinaten Zeitstempel Pfeilstellungen (1 und 2) Zuverlässigkeit

Format für Datenaustausch Proprietär da Modul-intern

Kommunikationsmedium Modul-intern

3.2.3.Modul Richtung


Eingangsdaten (Datenannahme) Koordinaten WGS 84


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°)



3.2.4.Modul Positionskette

26


Eingangsdaten (Datenannahme) Koordinaten WGS 84



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)


3.2.5.Entscheidungsmodul "Verbindung zur Zentrale"

Es wird geprüft ob die fahrbare Absperrtafel eine Verbindung zur Zentrale via Mobilfunk auf-bauen kann.


Ausgetauschte Daten ID Position / Koordinaten Fahrtrichtung Positionskette (Trace) Pfeilstellungen (1 und 2) Zeitstempel Zuverlässigkeit

Format für Datenaustausch DATEX II angestrebt

Kommunikationsmedium Mobilfunk

Das Format für den Datenaustausch ist bisher noch nicht standardisiert. Dies wird angestrebt.

27

3.2.7.Modul Betriebliche Daten zusammenstellen


Eingangsdaten (Datenannahme) ID Zahl

Geschwindigkeit fahrb. Ab-sperrtafel

Zahl in [km/h]

Verkehrszustand (Seitenra-dar-Daten) Die Datenformate werden

im Rahmen der Prototy-penentwicklung spezifi-ziert.

Status Absperrtafel

Sensordaten (z.B. Füllstand von Brennstoffzellen)

Batteriespannung


Funktionalität des Moduls Zusammenstellen der Daten, die für den Betrieb relevant sind

Ausgangsdaten (Datenabgabe) Meldung mit betrieblich re-levanten Daten

DATEX II mit TLS Codes (angestrebt)


Ausgetauschte Daten Betriebs- / Fehlermeldung




28

3.2.9.Modul Filtern


Eingangsdaten (Datenannahme) Baustellendaten DATEX II angestrebt

Betriebs- / Fehlermeldun-gen

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 Baustellen-meldungen

DATEX II angestrebt

Gebündelte Betriebs- / Fehlermeldungen

DATEX II angestrebt

29


Ausgetauschte Daten Betriebs- / Fehlermeldung


Kommunikationsmedium Mobilfunk / Internet / Intranet (intern)

3.2.11.Modul Weiterverarbeitung Fehlermeldung


Eingangsdaten (Datenannahme) Betriebs- / Fehlermeldun-gen

DATEX II angestrebt

Funktionalität des Moduls Die Betriebs- / Fehlermeldungen werden weiterverarbei-tet und stehen weiteren Diensten der Länder Zentrale zur Verfügung

Ausgangsdaten (Datenabgabe) Extrahierte Daten aus Be-triebs- / Fehlermeldungen

proprietär

30

Die Details der Weiterverarbeitung der Fehlermeldung sind nicht im Fokus der Beschreibung des Dienstes Baustellenwarner und werden ab diesem Schritt nicht weiter vertieft.


Ausgetauschte Daten Baustellenmeldung


Kommunikationsmedium Mobilfunk / Internet / Intranet (intern)

3.2.13.Modul Fahrstreifen Sperrung

31


Eingangsdaten (Datenannahme) ID des Baustellenhängers Zahl

Koordinaten aus Ortung WGS 84


Pfeilstellung 1 (Leuchtpfeil) [0, 1, 2]

Pfeilstellung 2 (Blechpfeil) [0, 1, 2]


Karte Noch nicht spezifiziert

Funktionalität des Moduls Ermitteln der gesperrten Fahrstreifen.

Ausgangsdaten (Datenabgabe) Gesperrte Fahrstreifen [n] als Zahl (|…|3|2|1|) (Nummer des Fahrstrei-fens)




Ausgetauschte Daten Baustellenmeldung ergänzt um gesperrte Fahrstreifen


Kommunikationsmedium Mobilfunk / Internet / Intranet (intern) / Modul-intern


32

3.2.15.Optional: Modul Kombination von >1 fahrbarer Absperrtafel


Eingangsdaten (Datenannahme) Gesperrte Fahrstreifen [n] als Zahl (|…|3|2|1|)

Positionen [n] WGS 84

Baustellenmeldung DATEX II angestrebt


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 Baustellenmel-dung

DATEX II angestrebt



33

Ausgetauschte Daten Baustellenmeldung


Kommunikationsmedium intern

3.2.17.Modul Weiterverwendung Länder intern


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.

3.2.18.Entscheidungsmodul "BIS / BMS verfügbar"

Es wird geprüft ob ein Baustelleninformations- oder Baustellenmanagementsystem verfügbar ist.


Ausgetauschte Daten ID

Position

Zuverlässigkeit

Fahrtrichtung

34

Gesperrter Fahrstreifen

Gesperrte Fahrstreifen bei mehreren fahrbaren Absperr-tafeln


Kommunikationsmedium Modul-intern

3.2.20.Optional Modul Verschneiden mit BMS / BIS Daten


Eingangsdaten (Datenannahme) Baustellenmeldung DATEX II angestrebt

Daten aus BMS / BIS (De-tails siehe unten)

DATEX II

Funktionalität des Moduls Baustelleninformation werden um BMS / BIS Daten er-gänzt durch verschneiden mit entsprechender Datenbank

Ausgangsdaten (Datenabgabe) Position des Hängers Spursperrung Fahrtrichtung Zeitstempel Zusatzinformationen ID des Regelplans Zusatzfeld (Freitext)

DATEX II angestrebt

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

3.2.21.Entscheidungsmodul "Operator verfügbar?"

Es wird geprüft ob eine Plausibilisierung der Meldung durch einen Operator erfolgen soll.

35


Ausgetauschte Daten Baustellenmeldung mit Zusatzinformationen


Kommunikationsmedium intern

3.2.23.Optional Modul Plausibilisieren (Operator)


Eingangsdaten (Datenannahme) Baustellenmeldung mit Zu-satzinformation

DATEX II angestrebt

Funktionalität des Moduls Baustellenmeldung wird durch Operator auf Plausibilität überprüft

Ausgangsdaten (Datenabgabe) Plausibilisierte Baustellen-meldung mit Zusatzinfor-mation

DATEX II angestrebt


Ausgetauschte Daten DATEX II Meldung

Format für Datenaustausch DATEX II Profil

Kommunikationsmedium Internet

36

3.2.25.Modul Distribution von Daten


Eingangsdaten (Datenannahme) DATEX II Meldung DATEX II Profil

Funktionalität des Moduls Distribution von Baustellendaten auf die unterschiedli-chen Abnehmer

Ausgangsdaten (Datenabgabe) DATEX II Meldung DATEX II Profil


Ausgetauschte Daten DATEX II Meldung mit Position des Hängers, Spursper-rung, Fahrtrichtung, Zeitstempel – ggf. Zusatzinformatio-nen

Format für Datenaustausch DATEX II Profil

Kommunikationsmedium Internet

37

3.2.27.Modul Vorbereitung der Meldung für weitere Verkehrsinformationsdienste –

über andere Medien



Daten aus eigenen Daten-banken

offen

Funktionalität des Moduls Baustelleninformation wird in die Systeme des Verkehrs-informationsanbieters eingelesen und weiterverarbeitet

Ausgangsdaten (Datenabgabe) Meldung mit Position, Spursperrung und Fahrt-richtung

proprietär

Meldung mit Position, Spursperrung, Fahrtrich-tung und Zusatzinformati-onen

proprietär


Ausgetauschte Daten Meldung mit Position des Hängers, Spursperrung, Fahrt-richtung, Zeitstempel – ggf. Zusatzinformationen

Format für Datenaustausch Proprietär

Kommunikationsmedium Internet, Rundfunk oder andere Medien

3.2.29.Modul Vorbereitung der Meldung für weitere Verkehrsinformationsdienste –

über Mobilfunk

38



Daten aus eigenen Daten-banken

offen

Funktionalität des Moduls Baustelleninformation wird in die Systeme des Verkehrs-informationsanbieters eingelesen

Ausgangsdaten (Datenabgabe) TPEG Meldung mit Positi-on, Spursperrung und Fahrtrichtung

TPEG

TPEG Meldung mit Positi-on, Spursperrung, Fahrt-richtung und Zusatzinfor-mationen

TPEG

3.2.30.Schnittstelle 13

Ausgetauschte Daten TPEG Meldung mit aktueller Position des Hängers, Spur-sperrung, Fahrtrichtung –eventuell ergänzt um Zusatzin-formationen

Format für Datenaustausch TPEG



39

Ausgetauschte Daten Payload für DENM: Position des Hängers, Spursperrung, Fahrtrichtung, Zeitstempel, ggf. Zusatzinformationen

Format für Datenaustausch Wird im Rahmen der Prototypenentwicklung spezifiziert

Kommunikationsmedium Mobilfunk / Intranet / modul-intern


3.2.32.Modul DENM erzeugen


Eingangsdaten (Datenannahme) Payload für DENM Wird im Rahmen der Proto-typenentwicklung spezifi-ziert

Funktionalität des Moduls Payload für DENM in DENM Meldung konvertieren

Ausgangsdaten (Datenabgabe) DENM Meldung mit Positi-on, Spursperrung und Fahrtrichtung – evt. er-gänzt um Zusatzinformati-onen

DENM mit Road Works Warning Container

DENM Meldung mit aktuel-ler Position des Hängers, Pfeilstellung

DENM mit IVI Container


Ausgetauschte Daten DENM Meldung mit aktueller Position des Hängers, Spur-sperrung, Fahrtrichtung –eventuell ergänzt um Zusatzin-formationen

Format für Datenaustausch DENM mit Road Works Warning Container

40


Kommunikationsmedium ETSI ITS G5 (WLAN 802.11p)

3.2.34.Modul Präsentation der Meldung


Eingangsdaten (Datenannahme) DENM Meldung mit aktuel-ler Position des Hängers, Spursperrung und Fahrt-richtung

DENM mit Road Works Warning Container

DENM Meldung mit aktuel-ler Position des Hängers, Pfeilstellung


TPEG Meldung mit Position des Hängers, Spursperrung, Fahrtrichtung und Zusatzin-formationen

TPEG

Funktionalität des Moduls Geeignete Präsentation der Baustellenmeldung für Fah-rer

Ausgangsdaten (Datenabgabe) Darstellung der Baustel-lenmeldung

proprietär

41

3.3. Baustellenwarner Stand-Alone Lösung

Im Falle, dass die fahrbare Absperrtafel nicht mit dem Backend kommunizieren kann, besteht die Notwendigkeit, dass ein alternativer Be-triebsmodus 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 ent-sprechenden 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.

42

3.4. Zuordnung der Module zu Komponenten

Im Rahmen der prototypischen Implementierung in Hessen werden die in Kapitel 3.2 beschrie-benen Module unterschiedlichen Komponenten zugeordnet. Dies ist notwendig um eine ent-sprechende Umsetzung zu ermöglichen – lässt aber darüber hinaus die Entscheidung zu den be-reits thematisierten (und in Kapitel 3.5 im Detail beschriebenen) Implementierungsvarianten offen, da es sich hierbei lediglich um eine Zuordnung funktionaler Module zu technischen Kom-ponenten handelt. Die Möglichkeiten der Realisierung des Dienstes "Baustellenwarner" auf Ba-sis der Komponenten wird in Kapitel 3.5 adressiert.

Bei der Umsetzung des Dienstes werden im Wesentlichen folgende technische Komponenten zum Einsatz kommen:

- (Klassische) Fahrbare Absperrtafel erweitert um die sogenannten IRS Box, welche aus einer Weiterentwicklung des bereits existierenden DORA Systems und einer ITS _G5 Kommunikationseinheit besteht3

- Kooperative Zentrale, welche die für den "Baustellenwarner" benötigten zusätzlichen Funktionalitäten bündelt4

- (Klassische) Verkehrszentrale, welche bereits bestehende Funktionalitäten dem Dienst "Baustellenwarner" zur Verfügung stellt (z.B. Ortung einer FAT auf Karte, Daten aus dem BMS / BIS, Weiterverarbeitung von betrieblichen Meldungen / Fehlermeldungen)

- MDM als Plattform zum Austausch von Daten - Fahrzeuge als Empfänger der Warnmeldungen (hier nicht näher betrachtet)

Im Rahmen der Prototypen Implementierung wurde folgende Zuordnung von Modulen zu Komponenten definiert (Abbildung ).

Sperranhänger

Länder Zentrale

Zentrale Dritter

Fahrzeug

MDM

Modul

Richtung

Modul Optional

Verschneiden mit BMS / BIS Daten

Modul

DENM erzeugen

Datenannahme Datenabgabe


Datenannahme

Modul

Inhaltl. Daten zusammenst.

Datenabgabe

Modul

Distribution von Daten



Modul

Präsentation der Meldung


MDM

Modul

PositionsketteDatenannahme Datenabgabe

Daten beziehen

Modul

Vorbereitung der Meldung für weitere Verkehrsinfo Dienste - über Mobilfunk

Datenabgabe

Hänger klappt

auf

Datenannahme

Modul

Kombination von >1 Sperranhänger

Datenabgabe

Datenannahme

Modul

Betriebl. Daten zusammenst.

Datenabgabe

Datenannahme

Modul

Weiterverarb. Fehlermeldung

Datenabgabe

Datenannahme

Modul

Weiterverw. Länder-intern

Datenabgabe

Daten beziehen

Modul

Vorbereitung der Meldung für weitere Verkehrsinfo Dienste – andere Medien

Datenabgabe

Dienste in Zentrale

Modul

Fahrstreifen Sperrung


Karte

Modul Optional

Plausibilisieren (Operator)

Datenannahme DatenabgabeDatenannahme Datenabgabe

Verbindung zu Zentrale?

BIS / BMS verfügbar?

Operator verfügbar?

nein

ja

nein

ja

nein

ja

Modul

Filtern

Kooperative Zentrale

Optional:weitere / andere

Datenquellen

Abbildung 22 Zuordnung der Module auf Komponenten

3

die detaillierte Beschreibung erfolgt in Projektgruppe PG4

4

die detaillierte Beschreibung erfolgt in Projektgruppe PG 2

43

Der Komponente "Fahrbare Absperrtafel" werden die in Abbildung 22 blau umrandeten Modu-le zugeordnet. Hierbei handelt es sich um die Module "Inhaltliche Daten zusammenstellen", "Richtung", "Positionskette" und "DENM erzeugen".

Der Komponente "Kooperative Zentrale" werden die in Abbildung 22 gelb umrandeten Module zugeordnet. Hierbei handelt es sich um die Module "Filtern", "Fahrstreifen Sperrung", "Kombi-nation von >1 Sperranhänger" sowie der Aufruf der (externen) Funktionen "Verschneiden mit BMS / BIS Daten" und "Plausibilisieren".

Die Implementierungsvarianten für die Komponente "Kooperative Zentrale" sind in Kapitel 3.5 beschrieben.

Der Komponente "Verkehrszentrale" werden die in Abbildung 22 rot umrandeten Module zu-geordnet. Hierbei handelt es sich um die Module zur internen Weiterverarbeitung der Daten / Fehlermeldungen, "Map-Matching des Sperranhängers", "Verschneiden mit BMS / BIS Daten" und "Plausibilisieren".

3.5. Varianten zur Implementierung

Für die praktische 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 detail-liertere 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 unter-scheiden sich im Wesentlichen in der Umsetzung der kooperativen zentralenseitigen Funktiona-litä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 - Kombination mehrerer Sperranhänger einer Arbeitsstelle – sofern erforderlich - Auslösen des Verschneidens der Endnutzer-Dienst Meldungen mit Informationen aus

dem länderspezifischen Baustelleninformations- bzw. Baustellenmanagementsystems – sofern im Land vorhanden

- Auslösen der Plausibilisierung der Meldungen

3.5.1.Variante 1 – dezentrale Lösung

In einer dezentralen Lösung werden die zentralenseitig vorzusehenden Module wie sie im De-tail in Kapitel 3.2 dargestellt sind in jedem einzelnen Bundesland implementiert.

44

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 ausge-rollt. 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.

45

Es ergibt sich folgende Verteilung der Zuständigkeiten für eine verteilte Umsetzung (Abbildung 23).

Abbildung 23 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 26).

Abbildung 24 Schematische Komponentendarstellung der dezentralen Lösung

46

3.5.2.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 Vorverarbeitungs-schritte in den von den einzelnen Bundesländern betriebenen fahrbaren Absperrtafeln.

Für die Filterung und Weiterverarbeitung nutzen die Bundesländer zentral bereitgestellte Mo-dule.

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 Sys-temen verschnitten werden. Dies erfolgt in den einzelnen Bundesländern. Die Ergebnisse wer-den über den MDM zur Verfügung gestellt.

Um die Baustellenmeldung für die Fahrzeuge lesbar zu machen müssen diese in einem einheit-lichen Format, der DENM codiert werden. Für diese Aufgabe nutzen die Bundesländer wiede-rum zentral bereitgestellte Module.

47

Es ergibt sich folgende Verteilung der Zuständigkeiten (Abbildung 25):

Abbildung 25 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 26).

Abbildung 26 Schematische Komponentendarstellung der zentralen Lösung

48

3.5.3.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 Bundes-länder – soweit die technischen Voraussetzungen dort bestehen – die benötigten Module in ih-re jeweilige Architektur integrieren. Andere Bundesländer nutzen die zentral in einer Koopera-tiven 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.

49

3.6. Schnittstellen – DATEX II Profile

Für das System DORA wurde bereits ein DATEX II Profil entwickelt. Außerdem existiert ein DATEX II Profil BIS für die Darstellung der Dauerbaustellen im MDM. Es ist zu überprüfen, wel-ches der beiden Protokolle geeignet ist, die oben genannten Informationen zu übertragen. So-fern notwendig sollen Anpassungen erfolgen. Erstrebenswertes Ziel ist es, nur ein DATEX II Pro-fil 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. Einer-seits eine Art Basisinformation, die lediglich aus der Position des Hängers, der Fahrtrichtung, der Positionskette, der Spursperrung und einem Zeitstempel besteht. Andererseits können die-se 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 zu-sammen gestellt. Sind Informationen nicht verfügbar, so bleiben die entsprechenden Felder in der Meldung jeweils leer.

50

4. Dienst Fahrzeugseitige Datenerfassung

Als zweiter Dienst wird die Fahrzeugseitige Datenerfassung implementiert.

Die Beschreibung der Architektur ist für den zweiten Teil des Dokument "Erster Entwurf "Ge-samtarchitektur"" geplant.

51

Glossar

AkD Arbeitsstelle kürzerer Dauer

AlD Arbeitsstelle längerer Dauer

BIS Baustelleninformationssystem

BMS Baustellenmanagementsystem

CAM Cooperative Awareness Message (standardisiert in ETSI 102 637-2)

C-ITS Cooperative ITS

DATEX II Standardisiertes Datenaustauschformat für die Kommunikation zwischen Zent-ralen http://www.datex2.eu/

DENM Decentralized Environmental Notification Message (standardisiert in ETSI 102 637-3)

DORA Dynamische Ortung von Arbeitsstellen

INS Integrationsnetz Straße

ITS Intelligent Transport Systems

IVI In-Vehicle Information

MDM Mobilitätsdaten Marktplatz http://www.mdm-portal.de/

TPEG Transport Protocol Experts Group

WGS 84 World Geodetic System 1984

Documents

Erster Entwurf Gesamtarchitektur - c-its-korridor.de C-ITS.pdf · schriebenen Prozess hinaus im Detail auf die unterschiedlichen Module, die Schnittstel- len, ausgetauschten Daten