Andreas Kochs hat an der RWTH Aachen Bauingenieurwesen studiert und dort am Institut für Straßenwesen promoviert. Seit 2004 hat er als Mitarbeiter der momatec GmbH verschiedene Projekte zum Datenmanagement bearbeitet und u.a. das FOPS-Projekt zur Erstellung des OKSTRA kommunal geleitet. Er war Mitglied im Vorstand des KIM-Straße e.V. und Leiter der Geschäftsstelle des Vereins. Seit September 2011 ist Andreas Kochs Mitarbeiter der BASt und an das BMVBS abgeordnet.

Die Bereiche des Straßenbetriebs (oder auch Straßenbewirtschaftung) und des Verkehrsmanagements sind innerhalb der Straßen- und Verkehrsverwaltung häufig organisatorisch und IT-technisch getrennt. Aufgrund unterschiedlicher Anforderungen der jeweiligen Geschäftsprozesse an die Daten und das Datenmanagement haben sich die Datenstandards und die Fachanwendungen unabhängig voneinander entwickelt.

Am Beispiel von Baustelleninformationen kann aufgezeigt werden, wie Daten, die im Bereich des Straßenbetriebs erzeugt werden, wichtiger Input für die Prozesse des Verkehrsmanagements sind. Dabei müssen zum Datenaustausch die Hürden der unterschiedlich ausgeprägten Datenstandards und IT-Systeme überwunden werden.

Dieser Beitrag beschreibt Konzepte zur Verknüpfung von Straßenbetrieb und Verkehrsmanagement am Beispiel der Standards OKSTRA^®, OKSTRA kommunal und DATEX II und des Fachobjektes Baustelle und basiert u.a. auf einer Studie für die BASt, die die momatec GmbH in Zusammenarbeit mit den Firmen interactive instruments GmbH und Heusch Boesefeldt GmbH bearbeitet hat.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

Fachliche, organisatorische und technische Medienbrüche zwischen Straßenbetrieb und Verkehrsmanagement

Zwischen den Geschäftsprozessen in den Bereichen Straßenbetrieb und Verkehrsmanagement (Intelligent Verkehrssysteme (IVS)) besteht eine Vielzahl von Beziehungen und Abhängigkeiten.

Als Beispiel seien die im Straßenbetrieb geplanten und durchgeführten Straßenbaumaßnahmen genannt. Diese Maßnahmen werden häufig in einem „internen“ Prozess nur unter Einbeziehung der Organisationseinheiten des Betriebs geplant und abgestimmt. Erst in einem späten Stadium des Prozesses werden die Belange, Anforderungen und Auswirkungen auf den Verkehr und das Verkehrsmanagement wie die Änderung eines Lichtsignalprogramms, die Erzeugung einer Verkehrsmeldung oder die Schaltung einer Umleitungsstrecke über dWiSta betrachtet. Eine Optimierung der Maßnahmen vor dem Hintergrund des Verkehrsflusses erfolgt nur in begrenztem Maße. Eine Berücksichtigung der Auswirkungen z.B. durch die Querschnittseinschränkung und damit veränderte Leistungsfähigkeiten und Reisezeiten in der Verkehrsmodellierung und der Verkehrsprognose erfolgt selten, so dass im Verkehrsmanagement häufig von einer „falschen“ Netzverfügbarkeit ausgegangen wird.

Im kommunalen Umfeld, vor allem bei kleineren Kommunen, ist es häufig der Fall, dass kein eigentliches Verkehrsmanagementsystem existiert (im Sinne einer Verkehrszentrale), so dass Verkehrsmeldungen alleine aus dem Straßenbetrieb erzeugt werden könnten (z.B. Verkehrsmeldungen über Baustellen, Sperrungen, Veranstaltungen usw.).

Neben der organisatorischen Trennung der beiden „Welten“ ist häufig auch eine technische Hürde zu überwinden. Grundlage für gemeinsame Geschäftsprozesse in beiden „Welten“ sind zwar die gleichen Fachobjekte („Die Baustelle“), aber je nach Anwendungsfall besitzen diese verschiedenen Eigenschaften. In beiden „Welten“ existieren deshalb unterschiedliche, jeweils spezialisierte Abbildungen von Fachobjekten und Netz in Form von standardisierten Datenmodellen und Datenaustauschschnittstellen wie z.B. dem OKSTRA^®, OKSTRA kommunal und DATEX II, welche die übergreifende Kommunikation von IT-Systemen aus beiden „Welten“ aufgrund ihrer unterschiedlichen Modellierung erschweren.

Schritte hin zum Zusammenwachsen der „Welten“

Zur Nutzung von Daten aus dem Straßenbetrieb im Bereich der IVS, beispielsweise zur Erzeugung von Verkehrsinformationen aus Datenbeständen der Baustellenplanung und -disposition, ist es notwendig, dass eine Durchgängigkeit zwischen den Fachdaten- und den Netzmodellen in den beiden Bereichen hergestellt wird. Dies umfasst vor allem die relevanten Ordnungssysteme und die Darstellung des Netzes. Vor dem Hintergrund aktuellen Entwicklungen zur Einführung des Mobilitäts Daten Marktplatzes MDM gewinnt die Bereitstellung von Verkehrsinformationen aus dem Straßenbetrieb (vor allem in den Kommunen) an neuer Relevanz.

Referenzierungsgrundlage für alle Fachdaten ist das Netzmodell. Hier existieren in den beiden Bereichen vielfältige Netze, die zumeist als Knoten-Kanten-Modelle (mit oder ohne Geometrie) ausgebildet sind. Die Bildungsregeln für die Netzmodelle von OKSTRA^® und OKSTRA kommunal im Bereich des Straßenbetriebs und von GDF, RDS/TMC-Location Code List und der Bundeseinheitlichen VRZ unterscheiden sich dabei aber teilweise deutlich.

Eine Analyse der Netzmodelle ergibt, dass die grundlegenden Unterschiede vor allem zwischen dem OKSTRA^® und den Modellen aus dem Verkehrsmanagement bestehen:

• Die Netzmodelle von GDF und der Bundeseinheitl. VRZ sehen jeweils eine Achse pro Fahrbahn vor. Der OKSTRA^® sieht hingegen nur eine Achse auch bei zweibahnigen Straßen vor. Dies führt dazu, dass umfangreiche Umreferenzierungen notwendig werden und teilweise keine eindeutigen Zuordnungen erfolgen können.
• Im OKSTRA^® ist es nicht möglich, dass Fachdaten auf die GDF-nahe Sicht der Straßenelemente und Verbindungspunkte referenziert werden. Um diese Fachdaten z.B. auf GDF umzureferenzieren, wäre erst eine „interne“ Umreferenzierung aus dem Netzknoten-Stationierungssystem auf die GDF-Sicht im OKSTRA^® nötig, bevor eine Umreferenzierung auf GDF möglich wäre.
• Im OKSTRA^® werden die Beschleunigungs- und Verzögerungsstreifen an Anschlussstellen den Rampen (also den Ästen) zugeordnet, in GDF stellen sie einen zusätzlichen Fahrstreifen der Hauptfahrbahn dar. Aus dieser unterschiedlichen Sichtweise folgt, dass die Lage der Nullpunkte im OKSTRA^® und der Junction in GDF und die Länge der Äste von der Länge der entsprechenden Road Elements in GDF deutlich voneinander abweichen.
• Die Strukturierung von komplexen Knotenpunktsystemen im Netzmodell der bundeseinheitlichen VRZ weicht deutlich von den Ansätzen im OKSTRA^® und in GDF ab, so dass umfangreiche Zerschlagungen und Neu-Aggregierungen von linienhaften Objekten bei einer Umreferenzierung notwendig wären.

Das Netzmodell des OKSTRA kommunal ist eng angelegt an das GDF-Modell, wobei die Übereinstimmung von GDF-Netzen und kommunalen Netzen z.B. aus der Straßendatenbank davon abhängig ist, welchen Detaillierungsgrad die Kommune bei der Netzerfassung wählt.

Im OKSTRA^® und OKSTRA kommunal auf der einen Seite als auch in DATEX II auf der anderen Seite werden gleichartige Objekte von unterschiedlichen Sichten her modelliert. Dabei besitzen z.B. die Objekte der Klasse roadworks in DATEX II andere Eigenschaften als eine Arbeitsstelle_an_Strassen im OKSTRA^® oder ein Ereignis im Entwurf des entsprechenden Datenmodells für den OKSTRA kommunal. Über Abbildungsregeln können die Eigenschaften dieser Klassen aber soweit aufeinander abgebildet werden, dass ein Datentransfer aus dem Straßenbetrieb ins Verkehrsmanagement unter Erhaltung der relevanten Informationen möglich ist.

Es gibt verschiedene Möglichkeiten, die Verknüpfung von zwei Netzmodellen zu erreichen. Im Bereich der Datenschemata sind zwei Ansätze möglich:

1. Nachmodellierung einer in Modell A benötigten Objektklasse aus Modell B bei Übernahme der Semantik aus Modell B unter Berücksichtigung der Modellierungsregeln aus Modell A. (Beispiel: Integration von RDS/TMC-LCL in OKSTRA^® oder in Netzmodell der Bundeseinheitlichen VRZ). Problem ist die hohe Abhängigkeit zwischen den Fortschreibungen der beiden Standards A und B.

2. Einführung eines generischen Containers (Containerobjektklassen) in Modell A, der die benötigten Objektklassen aus Modell B enthalten kann. Vorteil ist die lose Kopplung der Standards. Außerdem kann der Container beliebige Objektklassen aus beliebigen anderen Modellen enthalten.

Im Bereich der vorhandenen Datensätze (z.B. GDF-Datensatz oder OKSTRA kommunal-Datensatz) gibt es wiederum zwei Möglichkeiten zur Verknüpfung der Daten:

1. Zusammenführung von Datenbeständen aus zwei Quellen durch Verschmelzung (Conflation) und Erzeugung eines Transformationsnetzes, welches die Eigenschaften der beiden Ausgangsnetze enthält (Beispiel: Straßennetzgrundlage SNG für GDF- und OKSTRA-Netz). Für diese Variante ist es unabdingbar, zunächst das Modell festzulegen, nach dem das Transformationsnetz aufgebaut werden soll.
Im nächsten Schritt sind

• die gemeinsamen Objekte der Netze zu identifizieren,
• ausgehend von der gemeinsamen Netzstruktur die im Zielnetz fehlenden netzkonstituierenden Objekte einzurichten und
• die im Zielnetz fehlenden Fachobjekte bzw. die Eigenschaften der dort vorhandenen Objekte zu ergänzen.

Das zentrale Problem dabei ist die Identifizierung der den beteiligten Netzen gemeinsamen Objekten. Die Ergänzung netzkonstituierender Objekte hängt zudem davon ab, wie exakt sich die neu hinzukommenden Fachobjekte sich auf das Gesamtnetz referenzieren lassen. Dies ist häufig nur durch manuelle Beurteilung zu gewährleisten. Das Transformationsnetz muss regelmäßig neu erzeugt werden, wenn die Ausgangsnetze in einer neuen Version vorliegen.

2. Verknüpfung von Ausgangsnetzen durch das Abspeichern von Beziehungen zwischen den Objekten und Erzeugung von Referenzierungstabellen. Dieser Ansatz erfordert nicht die explizite Überführung von Fachobjekten eines Systems in ein anderes. Dennoch ist für eine erfolgreiche Anwendung des Verfahrens eine Vorschrift erforderlich, die Auskunft darüber gibt, wie die fachlichen Eigenschaften eines Datenbestandes semantisch auf die eines anderen abzubilden sind.

Für die gegenseitige Umreferenzierung der Netze (ohne Berücksichtigung der Fachsemantik) werden Tabellen benötigt, die punkt- und linienförmige Referenzierungen der Netze aufeinander abbilden können. Die Abbildung erfolgt im einfachsten Falle dadurch, dass Ortsreferenzen, gegeben durch eine Identifikation eines linearen Objekts (z.B. im Falle des OKSTRA^® Abschnittskennungen) und eine punktuelle oder lineare Verortung darauf im Quellsystem auf ebensolche im Zielsystem umgesetzt werden. Voraussetzung dafür sind stabile Identifikatoren in beiden Systemen. (Wegen der Fortschreibungen in den beteiligten Netzen sind die Tabellen nachzuführen, wenn sich Änderungen ergeben haben.) Liegen keine stabilen Identifikatoren vor, oder wird die Identifizierung der zugrundeliegenden linearen Netzelemente wie etwa bei RDS/TMC durch eine Kombination von Identifikatoren vorgenommen (primäre und sekundäre Locations), wird die Aufgabe der Referenzabbildung entsprechend schwieriger.

Alternativ zu den oben genannten Methoden zur Verknüpfung oder Harmonisierung der verschiedenen Datenmodelle wurden die Nutzung von On-the-Fly-Referenzierugnsmethoden wie OpenLR^® oder die Möglichkeiten der Linearen Referenzierung (z.B. in DATEX II) analysiert. Vor allem die Nutzung von OpenLR^® zum Austausch von Netzreferenzen aus einem Netzmodell in ein anderes sollte in Zukunft vertieft untersucht werden. 

Medienbruchfreier Datenaustausch zwischen Straßenbetrieb und Verkehrsmanagement

Zur Schaffung eines medienbruchfreien Datenaustauschs zwischen Straßenbetrieb und IVS könnte ein Konvertierungs-Dienst die Umreferenzierung des Objektes auf das Zielnetz sowie die „Übersetzung“ der Fachdaten in den Zielstandard übernehmen. Dieser Konvertierungs-Dienst dient als Verbindungsglied zur Vernetzung von verschiedenen IT-Systemen aus den beiden „Welten“. Grundlage sind standardisierte Schnittstellen, welche die bisher getrennt existierenden IT-Systeme miteinander verbinden. Hierbei spielen GML-basierte Datenmodelle und der Einsatz von OGC^® Web Services eine große Rolle. Die im Straßenbetrieb relevanten Standards OKSTRA^® und OKSTRA kommunal liegen bereits als GML-Applikationsschemata vor. Mit dem Ergebnis des EU-Projektes eMotion liegt z.B. auch für den zentralen Standard DATEX II im Bereich IVS bereits ein validierter Vorschlag für eine GML-basierte Version vor.

Der Konvertierungs-Dienst nimmt Daten in einem standardisierten Format (z.B. OKSTRA^® oder OKSTRA kommunal) entgegen und führt das Mapping der Fachdaten nach definierten Abbildungsregeln durch (z.B. in das Format von DATEX II). Zusätzlich muss eine Umreferenzierung in ein Netzmodell erfolgen, welches vom Empfänger „gelesen“ werden kann. Dies könnte z.B. eine Umreferenzierung aus dem ASB-Netz in eine RDS/TMC-Location oder die Erzeugung einer OpenLR^®-Location sein, die vom Empfänger der Daten in eine beliebige Netzreferenz (z.B. GDF) übersetzt wird.

Damit bei einem standardisierten Datenaustausch z.B. auf Basis von OKSTRA^® oder OKSTRA kommunal, der bei der Anwendung von Web Services auf XML basiert, auch externe – also fremde Inhalte – transportiert werden können, wäre die Integration eines generischen Containers in die XML-Schemata der Standards denkbar. Ein solcher Container würde es ermöglichen, dass Inhalte, die nicht im jeweiligen Standard definiert sind, trotzdem standard-konform übertragen werden könnten. Damit wäre es beispielsweise möglich, dass einer Arbeitsstelle im OKSTRA^® eine GDF-Netzreferenz oder Attribute der Objektart „roadworks“ aus DATEX II mitgegeben werden könnten. 

Die Baustelle als Beispiel für ein Austauschobjekt

Ein Beispiel für die Schnittstellen zwischen Straßenbetrieb und Verkehrsmanagement ist der Lebenszyklus einer Baustelle. Eine Baumaßnahme wird vor dem Hintergrund des Bedarfs (z.B. in Abhängigkeit des Straßenzustands als Erhaltungsmaßnahme) und dem verfügbaren Budget geplant. Bei der Koordination verschiedener im Straßennetz geplanter Maßnahmen sollten die verkehrlichen Wirkungen dieser Maßnahmen und die netzweiten Auswirkungen auf den Verkehrsfluss möglichst früh berücksichtigt werden. Frühzeitig sollten die relevanten Baustellenkenngrößen wie Lage, Dauer, Verkehrsführung an das Verkehrsmanagement übergeben werden, damit dort analysiert werden kann, welche Auswirkungen die Baumaßnahmen netzweit auf den Verkehrsfluss haben und welche verkehrsbeeinflussenden Maßnahmen wie Verkehrsteuerung, Verkehrslenkung und Information ergriffen werden können/müssen.

Die Baustellenbeschreibung in DATEX II zielt auf die Erzeugung einer Verkehrsmeldung mit Beschreibung der Lage und der verkehrlichen Auswirkungen ab, wogegen im OKSTRA^® eher die baulichen und baubetrieblichen Eigenschaften beschrieben werden. In der folgenden Tabelle wird aufgezeigt, wie aus dem OKSTRA^® Informationen für eine DATEX II-Baustellenmeldung erzeugt werden können (im Beispiel ohne Netzreferenz).