Kooperative Systeme sind zurzeit Gegenstand vieler Projekte und Entwicklungen. Erste Anwendungen stehen vor der Markteinführung. Die Vernetzung von Fahrzeugen mit Verkehrszentralen stellt besondere Anforderungen nicht nur an die funktionalen Erweiterungen der Zentralensysteme, sondern insbesondere auch an ihren grundlegenden Aufbau und ihre Leistungsfähigkeit. Im Projekt simTD hat Hessen Mobil erstmals eine vollwertige, kooperative Verkehrszentrale entwickelt, die nicht nur die Kommunikation mit den Fahrzeugen realisiert, sondern auch kooperative, verkehrstechnische Anwendungen umsetzt. Dieser Beitrag stellt anhand der Entwicklungen aus simTD den Aufbau einer solchen kooperativen Verkehrszentrale vor, der die erfolgreiche Umsetzung der speziellen Anforderungen kooperativer Anwendungen ermöglicht.

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

1 Einleitung

Zur Steigerung der Verkehrssicherheit und zur Optimierung der Verkehrsqualität werden seit Jahren erfolgreich Verkehrsbeeinflussungssysteme unterschiedlicher Art und Zielsetzung auf Autobahnen sowie im urbanen städtischen Verkehrsnetz betrieben. Gesteuert und betrieben werden sie von Verkehrszentralen der jeweiligen Straßenbetreiber. Dabei operieren diese Verkehrszentralen derzeit überwiegend autark und technisch weitgehend unvernetzt zueinander.

Neben den seit Jahren erfolgreich betriebenen kollektiven Verkehrsbeeinflussungsanlagen wird aktuell intensiv daran geforscht, Daten aus dem Fahrzeug für die Verkehrsbeeinflussung zu nutzen und auch Daten an einzelne Fahrzeuge zur individuellen Verkehrsinformation und -beeinflussung zu senden. Auch Fahrzeuge untereinander können dabei Informationen austauschen. Diesen Datenaustausch bezeichnet man als Car to X (Car2X) Kommunikation, das die beiden möglichen Kommunikationswege zwischen zwei Fahrzeugen (C2C) und zwischen Fahrzeug und straßenseitiger Infrastruktur (C2I) zusammenfasst.

In der jüngeren Vergangenheit wurden verschiedene Initiativen gestartet, um über Betreibergrenzen hinweg durchgängige Steuerungskonzepte zu etablieren. Dabei müssen sowohl technische als auch organisatorische Aspekte bedacht werden (siehe FGSV 2008 [1]). Darüber hinaus wurden in den letzten Jahren zahlreiche Forschungsprojekte zu kooperativen Systemen durchgeführt bzw. sind in Bearbeitung. Dazu zählen beispielweise die Projekte

•    Aktiv

•    CVIS

•    SafeSPOT

•    Travolution

•    simTD

•    UR:BAN

•    CONVERGE

Die Projekterfahrungen insbesondere aus simTD (Sichere Intelligente Mobilität – Testfeld Deutschland, siehe SIMTD 2013 [7]) zeigen, dass die Fahrzeugseite bereit ist für die Implementierung von Car2X-Diensten. Auch die im Rahmen des Projekts simTD konzipierte und entwickelte kooperative Verkehrszentrale hat in der Praxis erwiesen, für den produktiven Einsatz einsatzbereit zu sein.

In den nachfolgenden Kapiteln wird nach einer Erläuterung wesentlicher technischer Grundlagen in Kapitel 2 zunächst in Kapitel 3 auf die speziellen Anforderungen an eine kooperative Verkehrszentrale eingegangen. In Kapitel 4 wird dann der Aufbau einer solchen Zentrale dargestellt, der sich aus diesen Anforderungen ergeben hat. Anschließend wird in Kapitel 5 auf die zentrale Funktion einer kooperativen Zentrale, die Datenfusion von zentralenseitigen und fahrzeugseitigen Daten, näher eingegangen. Kapitel 6 stellt dann die wesentlichen Ergebnisse dar, die das simTD-Projekt hinsichtlich der kooperativen Verkehrszentrale hervorgebracht hat.

2 Grundlagen

Zum Gesamtverständnis werden zunächst einige Erläuterungen zu Begrifflichkeiten gegeben, die zum weiteren Verständnis hilfreich sind.

2.1 simTD ICS

Die ITS Central Station (ICS) ist die Versuchszentrale des Projektes simTD. Als erste kooperative Verkehrszentrale kommunizierte die ICS während des Feldversuchs mit mehr als 120 Fahrzeugen und über 100 ITS Roadside Stations (IRS). Durch die Kopplung mit den Verkehrszentralen des Landes Hessen und der Stadt Frankfurt (Zentralenverbund) wurden zusätzlich die bereits verfügbaren Daten und Informationen aus diesen Systemen integriert.

2.2 simTD IRS

Die ITS Roadside Stations (IRS) sind an der Straße installierte Kommunikationseinrichtungen, die mit den Fahrzeugen über einen speziellen, für den mobilen Einsatz entwickelten WLAN-Standard kommunizieren. Sie sind insbesondere für die Weiterleitung von Informationen zwischen Fahrzeug und ICS verantwortlich.

2.3 C2X Meldungen

DENs (Decentralized Environmental Notification) sind Nachrichten, die Information zu genau einem ortsgebundenen Ereignis enthalten, z.B. über ein Stauende oder Nebelgebiet. Dieses Ereignis kann punktförmig oder ausgedehnt sein.

PVD (ProbeVehicleData) sind aggregierte Fahrzeugdaten über die Fahrhistorie. Das heißt, es werden Wegpunkte mit Zeitstempeln zur Berechnung einer Durchschnittsgeschwindigkeit abgelegt. Zusätzlich werden Temperaturdaten und Scheibenwischeraktivität abgelegt.

CAMs (Cooperative Awareness Messages) sind Nachrichten, die Zustandsinformationen der Senders (IRS oder Fahrzeuge) übermitteln. Dies sind z.B. bei Fahrzeugen Informationen über die aktuelle Geschwindigkeit.

2.4 SOA – Serviceorientierte Architektur

Die serviceorientierte Architektur (SOA) ist ein sogenanntes Architekturmuster der Informationstechnik.

Die serviceorientierte Architektur findet im Bereich der verteilten Systeme Anwendung. Dabei werden Dienste (Services) so erstellt, dass es möglich wird durch die Zusammenfassung (Orchestrierung) mehrerer einfacher Dienste Geschäftsprozesse nachzubilden. Diese Dienste müssen dabei nicht aus einer Quelle (Hersteller, Server, …) stammen, sondern können nach Bedarf aus den in einem verteilten System vorhandenen Diensten zusammengestellt werden.

Funktional bedeutet dies, dass ein Dienst eine zentrale Aufgabe im Verbund der Zentrale übernimmt. Ein klassisches Beispiel hierzu ist ein zentraler map Matching Dienst.

2.5 ESB – Enterprise Service Bus

Der Enterprise Service Bus (ESB) ist ein weitergehendes Architekturmuster zur Realisierung einer SOA.

Kernpunkte eines ESB sind:

•    Bus statt Punkt-zu-Punkt-Verbindungen

•    Adapter zum Anschluss bestehender Dienste

•    Transformations- und Routingdienste

In der allgemeinen Beschreibung eines ESB werden keine Standards, Softwareplattformen usw. definiert. Es gibt unterschiedliche Produkte, die dieses Architekturmuster implementieren.

2.6 OSGi (von Open Services Gateway initiative)

Unter dem Begriff OSGi Service Plattform (siehe OSGI [8]) versteht man eine hardwareunabhängige Softwareplattform, auf deren Basis Anwendungen („Bundle“) und Dienste („Service“) verwaltet werden können. Diese Plattform wird häufig im ‚embedded‘ Bereich eingesetzt, z.B. in Fahrzeugen, in der Gebäudeautomatisierung oder Set-Top Boxen.

3 Anforderungen

Eine kooperative Verkehrszentrale muss drei wesentliche Anforderungen erfüllen, die in bisherigen Verkehrszentralen keine oder lediglich eine untergeordnete Rolle spielen:

•    Gemeinsames räumliches Referenzierungssystem für Fahrzeuge und Zentrale:
Für die angebundenen Zentralen (z.B. die städtische und die Autobahnzentrale) müssen ein gemeinsames räumliches Referenzierungssystem und weitere technische Schnittstellen definiert werden, um mit der kooperativen Zentrale zu kommunizieren. Diese Thematik wird vor allem in [1] diskutiert und wird im Rahmen dieses Artikels nicht weiter beleuchtet.

•    Einheitliche Verkehrs- und Wetterlage auf Basis mobiler und stationärer Datenquellen:
Aus verschiedenen Datenquellen mit unterschiedlichem Zeit- und Raumbezug müssen Rückschlüsse auf die aktuelle Verkehrs- und Wetterlage gezogen werden können. Dies kann mittels Datenfusion erfolgen.

•    Skalierbare Systemarchitektur, die insbesondere auch den zukünftigen Anforderungen hinsichtlich Ausstattungsgrad gewachsen ist:
Die Architektur einer kooperativen Zentrale ist so zu wählen, dass die Zentrale große Datenmengen verarbeiten kann und skalierbar ist. Fahrzeuggenerierte Daten sind in ihrer Grundstruktur deutlich feingranularer als die bisher in VRZen verwendeten stationären Daten. Dieser Effekt verstärkt sich noch bei zunehmenden Ausstattungsraten. Bei zunehmendem fortschreitenden Ausstattungsgrad nimmt dann dieses ohnehin schon größere Datenvolumen deutlich zu.

Für das Projekt simTD wurden neben den funktionalen Anforderungen auch weitere Anforderungen an den Aufbau der Zentrale gestellt:

•    Es soll eine auf einer Service Oriented Architecture (SOA) basierende, offene Plattform zur Realisierung der benötigten Services und Funktionen der kooperativen Zentrale geschaffen werden.

•    Zur Realisierung dieser SOA soll ein Enterprise Service Bus eingesetzt werden, damit der problemlose Austausch von Modulen und Komponenten durch beliebige Anbieter ermöglicht wird und Daten über zentrale Schnittstellen des ESB ausgetauscht werden können.

•    Der ESB soll als Integrationsplattform OSGi unterstützen und diesbezüglich kompatibel mit den in den Fahrzeugen oder IRS eingesetzten Softwareumgebungen sein, um den Projektpartnern die Integration von Modulen in die ICS zu erleichtern.

4 Aufbau einer kooperativen Verkehrszentrale

4.1 Architektur der Zentrale

Die grundlegende Anforderung an die Architektur ist die Verwendung eines ESB als zentraler Baustein. In der simTD ICS wurde der ESB in zwei verschiedenen Konfigurationen bei der Umsetzung der Systemarchitektur eingesetzt. Zuerst wurde die „klassische“ Konfiguration als Laufzeitumgebung für alle Anwendungen gewählt. Dies stellte sich während der Integrationsphase und ersten Betriebsphase als nicht optimal heraus, so dass im Folgenden der ESB als zentraler Makler verwendet wurde und sich schließlich eine hybride Architektur als zielführend ergeben hat. Die beiden Varianten werden im Folgenden kurz dargestellt.

Insbesondere die Performanceanforderungen an eine kooperative Zentrale führten schließlich zu einer hybriden Systemarchitektur für die ICS (siehe auch HÜBNER 2013 [6]).

4.1.1 ESB als Laufzeitumgebung für Anwendungen

In fast allen Anwendungsbeispielen laufen die Anwendungen und Services ‚im‘ ESB. Hierbei wird OSGi als ‚Anwendungstyp‘ verwendet.

Die Vorteile dieser Konfiguration sind, dass alle Bundles zentral über den ESB administriert werden können, (theoretisch) die Bundles/ Anwendungen zur Laufzeit austauschbar sind und die Services zentral über den ESB aufgefunden werden können.

Es ergeben sich jedoch auch gravierende Nachteile:

•    Der ESB ist ein Single-Point-of-Failure. D.h., dass ein fatales SW-Problem einer Komponente zum Absturz des ESB führt

•    Es ergeben sich lange Startzeiten des ESB, da immer alles neu gestartet werden muss

•    Die Austauschbarkeit zur Laufzeit funktioniert häufig nicht

•    OSGi ist in Enterprise-Softwareumgebungen sehr komplex, was zu stark erhöhten Integrationsaufwänden führt

4.1.2 ESB als zentraler Makler

In der angepassten Konfiguration wurden zentrale, aufwändige Services nicht im ESB ausgeführt, sondern es wurde im ESB lediglich der Zugriff auf diese Services konfiguriert. Zusätzlich kann die Lastverteilung für diese Services im ESB konfiguriert werden.

Der Nachteil dieser Konfiguration ist, dass spezielle Laufzeitumgebungen für die Services benötigt werden, die nicht im ESB laufen. Daraus ergibt sich eine komplexere Systemüberwachung. Allerdings können hier bewährte Produkte zum Einsatz kommen, so dass die Nachteile wieder aufgewogen werden. Z.B. wird als Laufzeitumgebung Apache tomcat eingesetzt und die Systemüberwachung erfolgt über den Systemmonitor des GeoDyn2® Produktes der Heusch/Boesefeldt GmbH.

Der wesentliche Vorteil dieser Konfiguration ist, dass das Gesamtsystem deutlich robuster wird. Ein fataler Fehler in SW-Komponenten, die in tomcat-Instanzen laufen, kann den ESB nicht mehr zum Absturz bringen. Zudem wird die Startzeit für den Neustart solcher Komponenten erheblich verkürzt, da nicht mehr der gesamte ESB mit allen Komponenten neugestartet werden muss. Der Vorteil verkürzter Startzeiten ergibt sich auch bei Wartungsarbeiten und Patches, wobei die Services weiterhin zentral über den ESB aufgefunden werden können.

4.1.3 Resultierende Systemarchitektur

Als Ergebnis der o. g. Erfahrungen aus der Implementierungs- und Integrationsphase wurde die serviceorientierte Architektur (SOA) auf Basis von SOAP-Webservices realisiert, bei der lediglich die „Orchestrierung“ der Services über einen Enterprise Service Bus (ESB) geschieht, als Laufzeitumgebung hingegen tomcat-Instanzen zum Einsatz kommen.

Im weiteren Verlauf der Umsetzung stellte sich zudem die Frage, ob die durch den ESB bereitgestellten Kommunikationsmechanismen für die systeminterne Kommunikation nutzbar sind. Ein Vorteil dieser Mechanismen ist, dass sie eine allgemeine, generische Schnittstelle zum Datenaustausch bereitstellen und somit die Einbindung von Komponenten erleichtern können. Entsprechende Lasttests ergaben allerdings, dass diese den hohen Anforderungen beim Austausch von Massendaten von den stationären Detektoren und den Fahrzeugen nicht gewachsen sind.

Daher war es erforderlich jene Systemteile, die mit großen Datenmengen operieren, über einen eigenen, performanten Datenbus kommunizieren zu lassen. Diese „datenzentrierten“ Komponenten wurden mithilfe der GeoDyn2®-Middelware als datenzentriertes Subsystem an den ESB angekoppelt. Die entsprechenden Komponenten kommunizieren je nach Bedarf direkt über den GeoDyn2®-Datenverteiler. Funktionalitäten, die im Gesamtsystem zentrale Dienste bereitstellen, sind als hybride Services realisiert, die aus Performancegründen zusätzlich an den Datenbus angebunden sind.

Insgesamt ergibt sich hiermit die hybride Systemarchitektur, wie sie in Abbildung 1 skizziert ist.

Abbildung 1: Aufbau einer kooperativen Zentrale

4.2 Funktionsabläufe in einer kooperativen Zentrale

Eine kooperative Zentrale hat zum Ziel, Daten aus kooperativen Systemen (z.B. Car2X) zu übernehmen, diese mit zentralenseitig generierten Daten aus anderen angeschlossenen Zentralen zu veredeln und die Daten so aufzubereiten, dass diese für unterschiedliche Zwecke (z.B. Steuerung, Information) weiter genutzt werden können. Einen Überblick über die Funktionsabläufe in einer kooperativen Zentrale gibt Abbildung 2.

Abbildung 2: Funktionsablauf in einer kooperativen Zentrale

Zunächst werden die Daten aus den unterschiedlichen Systemen (z.B. VRZ, städtische VM- Zentrale, Car2X-System) übernommen und in eine gemeinsame Datenhaltung integriert. Dabei muss beachtet werden, dass die Daten in Echtzeit verarbeitet werden müssen, um hochaktuelle Informationen über den Zustand (Verkehr, Witterung) zu erhalten. Außerdem muss auf Skalierbarkeit des Systems geachtet werden, da insbesondere bei den fahrzeugseitig generierten Daten davon auszugehen ist, dass durch den zunehmenden Ausstattungsgrad das Datenvolumen deutlich steigen wird.

Anschließend erfolgt eine Datenfusion, die in Kapitel 5 weiter erläutert wird.

Die so vorliegenden Daten können einerseits zur Qualitätssteigerung der kollektiven Steuerung und Verkehrsinformation genutzt werden, andererseits aber auch zur Nutzung für individuelle Verkehrsinformationen und fahrzeugseitige Anwendungen zur Steigerung der Verkehrssicherheit. Langfristig können Daten einer kooperativen Zentrale auch das autonome Fahren wirkungsvoll unterstützen.

4.3 Aufbau der Zentrale

Nach Festlegung der grundlegenden Architektur und Abläufe der Zentrale ist ein weiterer, essentieller Schritt die Identifikation der zentralen Querschnittsfunktionen im System sowie deren geeignete Abbildung in die Services der SOA.

Hierbei wurden die folgenden Dienste identifiziert und realisiert:

•    Allgemeiner Datendienst
Dieser Dienst gewährt Zugriff auf alle im System verfügbaren Daten.

•    Map Matching
Alle benötigten Funktionen zur Ortsreferenzierung sind in diesem Dienst realisiert. Die Kernaufgabe ist dabei die Abbildung von fahrzeugbasierten Ortsinformationen auf Koordinatenbasis auf das im System hinterlegte Straßennetz.

•    Objektinformationsdienst
Neben dem reinen Zugriff auf Daten ist insbesondere für die Realisierung der Benutzeroberfläche ein objektorientierter Zugriff auf Daten und Informationen sinnvoll. Dieser wird durch den Objektinformationsdienst realisiert. Er wird zudem auch von anderen Services angefragt, sobald objektorientiert auf Daten zugegriffen werden muss.

•    Shape Service
Zur Visualisierung aller im System verfügbaren Daten als Attribute des Straßennetzes wurde dieser Service realisiert. Er erzeugt von beliebigen, ortsreferenzierten Daten geografische Darstellungen auf der Netzbasis.

Die verschiedenen Anwendungsservices nutzen diese zentralen Dienste. Die Vorteile eines solchen serviceorientierten Vorgehens sind in den folgenden Features zu sehen:

•    Vielfach benötigte Funktionen werden in Services gebündelt und über klar definierte Service-Schnittstellen bereitgestellt.

•    Die Schnittstellen stellen nicht nur Daten, sondern insbesondere auch anwendungsnahe Methoden zur Verfügung und vereinfachen somit die Realisierung der Anwendungsmodule.

•    Im Gegensatz zu Software-Bibliotheken werden Services nur einmal in den Hauptspeicher geladen und optimieren somit die Speichernutzung im System.

Performancekritische Services können „stateless“ realisiert werden, wodurch eine Skalierung leicht durch Mehrfachinstanziierung mit vorgelagerter Lastverteilung realisiert werden kann. Dies ist insbesondere für jene Services unerlässlich, deren Belastung mit der Anzahl Fahrzeuge als Datenlieferanten steigt (z.B. Map Matching).

5 Funktionen einer kooperativen Zentrale

5.1 Grundlagen der Datenfusion

Daten des gleichen Informationstyps aus verschiedenen Datenquellen unterliegen in der Regel einer unterschiedlichen Ortsreferenzierung und/oder Zeitreferenzierung. Zu den systemischen Kernausgaben der Datenfusion gehört es daher zunächst, die Daten in ein einheitliches Referenzierungsschema zu bringen.

Anschließend können dann die Daten inhaltlich fusioniert werden, wobei davon auszugehen ist, dass die Daten auch einer unterschiedlichen Semantik unterliegen können. Als Beispiel dient hier ein Verkehrslagedatum, das aus einer Quelle vierstufig nach MARZ 1999 [2] und aus einer anderen Quelle sechsstufig nach HBS 2001 [3] vorliegt.

5.1.1 Fusion unterschiedlicher Ortsbezugssysteme

Zentralenseitig aufbereitete Daten liegen in der Regel in einer linearen Referenzierung vor. Ein gängiges Referenzierungssystem im Außerortsbereich ist beispielsweise die Location- Code-Liste des RDS-TMC oder Open-LR. Fahrzeugseitige Informationen werden mit einer GPS-Koordinate (Punkt) verortet.

Diese unterschiedlichen Ortsbezüge werden nun mittels Map-Matching aufeinander abgebildet. Dies muss in quasi Echtzeit erfolgen, damit relevante Informationen über den aktuellen Zustand (Witterung und Verkehr) daraus gewonnen werden können und für Information und Steuerung hinreichend schnell zur Verfügung stehen. Hinsichtlich einer produktiven Anwendung ist neben der Echtzeitforderung („On-the-fly“ Map Matching) darauf zu achten, dass durch die Einzelfahrzeugdaten die Datenmenge im Vergleich zum  bisherigen Datenvolumen, mit dem heutige Verkehrszentralen operieren müssen, um ein Vielfaches steigt.

Dazu führt ein intelligentes, optimiertes Matching-Verfahren eine Verortung auf der Karte anhand von Koordinaten und Zusatzinformationen wie der Himmelsrichtung, dem „heading“ oder einer Koordinatenspur, dem sogenannten „approach“, durch. Analog werden Informationen an die Fahrzeuge mit einer Koordinatenspur übermittelt. Soll ein Linienobjekt aus mehreren Koordinaten „gematcht“ werden, so wird für jeden Punkt eine Menge von möglichen Straßen (RoadElementen) ermittelt und zwischen allen möglichen Kombinationen ein Routing durchgeführt. Aus den sich so ergebenen Routen wird die wahrscheinlichste nach verschiedenen Kriterien wie z.B. kürzeste Route und der Summe der Abstände der Originalpunkte zur Route (kleinster Fehler) ausgewählt.

Abbildung 3: On-the-fly Map Matching

Um den Anforderungen des „On-the-fly“ Map Matching für Einzelfahrzeugdaten gerecht zu werden, ist der Map-Matching-Service softwaretechnisch als stateless Webservice umgesetzt. Dies bedeutet, dass jeder Matching-Aufruf für sich genommen vollständig ist und ohne Kontext, wie z.B. der Anmeldung an einen konkreten Service auskommt. Dadurch ist es möglich steigenden Anforderungen an die Menge der Matchings z.B. durch mehr Fahrzeuge oder durch Verkürzung des Meldezyklus der Fahrzeuge durch eine einfache Lastverteilung gerecht zu werden. Hierbei können z.B. durch eine Konfiguration des ESB Aufrufe an Map-Matching-Service nach verschiedenen Strategien an konkrete Services auf unterschiedlichen Rechner verteilt werden, welche die Aufrufe dann parallel abarbeiten.

5.1.2 Fusion unterschiedlicher Zeitbezüge

Zentralenseitig aufbereitete Daten liegen in der Regel in festen Erfassungszyklen vor. Im Außerortsbereich werden Verkehrs- und Umfelddaten üblicherweise in 1-min Intervallen erfasst. Die Gültigkeitsdauer ist damit ebenfalls festgelegt, indem das Datum bis zum nächsten Erfassungszyklus gültig ist.

Im Gegensatz dazu liefern fahrzeugseitige Informationen ein spontanes Einzeldatum und werden mit einer GPS-Koordinate (Punkt) verortet. Da nicht davon auszugehen ist, dass man in einem bestimmten zeitlichen Abstand eine aktualisierte Information dieses Fahrzeugs erhält, müssen in diesem Fall ggf. situationsbezogen Gültigkeitszeiträume definiert werden.

Neben punktuellen Informationen können aus fahrzeugseitigen Daten auch wertvolle streckenbezogene Daten generiert werden. Dabei muss eine automatische Lebenszeitprüfung stattfinden, um z.B. Rastplatzaufenthalte auszuschließen.

5.2 Verkehrslagefusion

Die Berechnung der Verkehrslagefusion in der simTD Versuchszentrale erfolgt für Autobahnen durch das Verkehrsanalysemodul ASDA/FOTO, welches von der Daimler Verkehrsforschung im Auftrag von Hessen Mobil in simTD konsequent bezüglich Datenfusion mit Car2X-Daten weiterentwickelt wurde. Die urbane Verkehrslage wurde mit dem Modell UTA der Daimler Verkehrsforschung ermittelt. Grundsätzliche Informationen zur Funktionsweise dieser beiden Modelle sind in REBORN 2010 [5] beschrieben.Abbildung 4 zeigt ein Beispiel einer solchen Fusion für die Autobahn im Bereich der Verkehrsbeeinflussungsanlage (VBA) auf der BAB A5 im Raum Frankfurt.

Abbildung 4: Verkehrslagefusion von Detektor- (links oben) und Fahrzeugdaten (rechts oben)

In der Abbildung werden Fahrzeugtrajektorien und von ASDA/FOTO erkannte Staubereiche in einem Weg-Zeit-Diagramm dargestellt. Im Teilbild oben links ist gut zu erkennen, an welcher Stelle die stationäre Detektion der Streckenbeeinflussungsanlage endet (zusätzlich verdeutlicht durch die gestrichelte graue Linie). Die Stauerkennung von ASDA/ FOTO kann über diesen stationären Erfassungsbereich hinaus dementsprechend keine Aussagen treffen. Im Teilbild oben rechts oben erkennt man, dass auf Basis von Fahrzeugdaten vollständige Staubereiche in ihrer Ausdehnung über die stationäre Erfassung hinaus erkannt werden. Allerdings ist hierzu eine ausreichende Anzahl ausgestatteter Fahrzeuge erforderlich. Die Fusion beider Daten, im Teilbild unten dargestellt, vereint die Vorteile beider Quellen und liefert ein sehr genaues Verkehrslagebild. Durch den Fusionierungsansatz von stationären und fahrzeuggenerierten Daten ist dieses Verfahren robust gegen unterschiedliche Penetrationsraten mit ausgestatteten Fahrzeugen im realen Betrieb. Wenn keine fahrzeugseitigen Daten im Analyseintervall vorliegen, dann wird automatisch die Verkehrslage ausschließlich auf Detektordaten (Bild oben links) ermittelt.

Aus den so fusionierten Daten können anschließend Verkehrsmeldungen erstellt werden. Diese können sowohl zum Versand mittels DATEX II als auch über Car2X Meldungen (DEN) bereitgestellt werden.

5.3 Wetterlagefusion

Die Wetterlagefusion erfolgt auf Grundlage des Verfahrens zur Situationsbewertung, das nachfolgend (s. auch [4]) vorgestellt wird.

Folgende Datenquellen werden dabei berücksichtigt:

•    infrastrukturseitige Sensorik (TLS Umfelddaten FG3) via VZH

•    fahrzeugseitige Wetterdaten via Car2X-Kommunikation (DEN-Nachrichten, Fahrhistorie)

Aus den Daten unterschiedlicher Datenquellen werden zunächst sog. Situationen gebildet. Eine Situation beschreibt einen diskreten, zeitlich und räumlich zugeordneten Zustand eines bestimmten Typs mit einer zugeordneten Aussage zur Qualität bzw. Zuverlässigkeit (Ergebniswertgüte) und des Verfahrens. Die zeitliche Gültigkeit ist über die Intervalllänge des erfassten Datums beschrieben. Der räumliche Kontext kann sowohl lokal (Detektor, Zustandsmeldung eines Fahrzeugs) als auch räumlich sein (Wetterabschnitt aus SWIS). Situationstypen können beispielsweise Fahrbahnzustand, Sichtverhältnisse, Temperaturen etc. sein.

Voraussetzung für ein solches Fusionsverfahren ist weiterhin die Kenntnis der Ergebnisgüte, also die Bewertung der Güte des Ergebnisses aus Sicht des Bewertungsverfahrens (darin können z.B. auch Messdatengüten eingehen) sowie die Verfahrensgüte (wie ist die Güte/Zuverlässigkeit des Verfahrens selbst) bekannt sind bzw. festgelegt werden können.

Die Verfahrensgüte wird über einen Parameter festgelegt. Mit der Verfahrensgüte kann berücksichtigt werden, inwieweit dem Verfahren grundsätzlich vertraut wird. Die Ergebnisgüte wird hier räumlich festgelegt. Im unmittelbaren räumlichen Umfeld wird die Zuverlässigkeit des Messwerts als sehr genau (Ergebnisgüte: 100%) angesehen. Je weiter man sich vom Messort entfernt, desto größer wird die Unsicherheit des Messdatums. Fahrzeugseitigen Daten wird pro Situationstyp eine räumlich feste Datengüte zugewiesen. Daher können pro Messgröße und Verfahren eine Anzahl von Bereichen und deren Zuverlässigkeit konfiguriert werden.

Anschließend werden den Messwerten sogenannte Zustandsprioritäten zugeordnet, wobei kritische Zustände höhere Prioritäten erhalten. Weiterhin erfolgt die Berechnung einer Ergebnisgüte auf Abschnitte als über die Länge gewichtetes Mittel der Einzelgüten aller Datenquellen pro Situationstyp.

5.4 Nutzung fusionsierter Daten

Die Daten liegen georeferenziert mit einem zeitlichen Bezug vor und können zur weiteren Verwendung über die Informations- und Nachrichtenservices sowie für Winterdienstzwecke genutzt werden.

Dabei kann eine Formatwandlung der Daten erfolgen, z.B.:

•    Verkehrsmeldungen → DEN-Messages für die Fahrzeuge

•    DEN-Message → Verkehrsmeldungen

•    Verkehrsmeldungen und Massendaten → Datex II

•    Verkehrsmeldungen → TPEG

5.5 Weitere Funktionen

Da sie für den strukturellen Aufbau einer kooperativen Verkehrszentrale nicht relevant sind, wird hier auf die Beschreibung der weiteren in simTD realisierten Zentralenfunktionen verzichtet. Zu nennen sind hier u.a.

•    Baustelleninformation
Detailinformation zu Baustellen für den Fahrer

•    Umleitungsempfehlung
Routenempfehlung auf Basis der aktuellen Verkehrslage

•    Verkehrszeichenassistent
Darstellung von statischen Verkehrszeichen im Fahrzeugdisplay

•    virtuelle VBA
Darstellung von dynamischen Verkehrszeichen im Fahrzeugdisplay.

Weitere Informationen zum Projektumfang von simTD befinden sich auch in [4].

6 Ergebnisse aus simTD

Im Projekt simTD wurde in der Zeit von November 2009 bis Dezember 2010 eine kooperative Zentrale erstellt und in Betrieb genommen, die als Versuchszentrale (Intelligent Central Station – ICS) in einem umfangreichen Feldversuch mit mehr als 120 Fahrzeugen und über 100 IST Roadside Stations (IRS) sowie einer Kopplung zu den Verkehrszentralen des Landes Hessen und der Stadt Frankfurt diente. Auf Basis der dort gemachten Erfahrungen konnten insbesondere für den Aufbau der Zentrale wesentliche Erkenntnisse gewonnen werden.

6.1 Umsetzung der Anforderungen

Im Rahmen des Projektes simTD wurde eine kooperative Verkehrszentrale mit dem oben beschriebenen Konzepten realisiert. Insgesamt hat sich gezeigt, dass die Anforderungen an eine solche Zentrale hiermit erfolgreich umgesetzt werden konnten.

6.1.1 Anforderungen an die Systemarchitektur

Alle realisierten Services müssen zustandslos und deshalb leicht skalierbar sein. Diese Anforderung wurde mit der zuvor beschriebenen hybriden Architektur erreicht.

Der Nutzen einer solchen Architektur kann sich wie folgt zusammenfassen lassen:

•    Die Mengen/Performance-Anforderungen kooperativer System können über die Skalierbarkeit schon heute gelöst werden. Dazu wurden die relevanten Services zustandslos realisiert und können somit über eine Lastverteilung mit Mehrfachinstanziierung skaliert werden. Damit wird die Leistung solcher Dienste lediglich durch die eingesetzte Hardware begrenzt, die wiederum durch Hinzunahme weiterer Server leicht erweiterbar ist.

•    Der ESB als zentraler Makler stellt die einfache Integration von Server-Komponenten, insbesondere auch anderer Hersteller, sicher. Durch Unterstützung des OSGi- Frameworks stand den Projektpartnern eine bekannte und im Fahrzeugumfeld übliche Integrationsplattform zur Verfügung.

•    Die gewählte Architektur weist gerade hinsichtlich Wartbarkeit und Erweiterbarkeit wesentliche Vorteile auf und stellt damit gerade in der Welt der sich schnell und umfangreich weiterentwickelnden, kooperativen Systeme die Nachhaltigkeit der Systementwicklung sicher.

6.1 Realisierung der Funktionen

Die bei der Umsetzung gewählte Aufteilung in die Services hat sich bewährt. Zentrale Funktionen in den realisierten Services führen zu einer optimalen Modularisierung und Skalierbarkeit. Die einzelnen Anwendungsmodule können so auf ihre funktionalen Aufgaben beschränkt werden. Dies vereinfacht eine Umsetzung von solchen Funktionen durch Dritte sowie die Integration bestehender Verfahren (z.B. ASDA/FOTO).

Die Problematik der Ortsreferenzierung wurde durch den Querschnittsservice Map Matching gelöst. Dieser Service stellt hinsichtlich Skalierbarkeit mit zunehmendem Ausstattungsgrad der Fahrzeuge die kritische Komponente dar. Auch sie wurde daher zustandslos realisiert und kann damit beliebig instanziiert werden.

Die Datenfusion auf Basis des ASDA/FOTO-Verfahrens hat sehr gute Ergebnisse gezeigt. Da das Verfahren für die detektierten Störungen im Netz qualitativ hochwertige Verlustzeiten ermittelt, liefert es zudem die Grundlagen für dynamische Routenempfehlungen und Reisezeitinformation.

7 Zusammenfassung

Der simTD Feldversuch stellt die erste Bewertung einer vollständigen Systemumgebung und Architektur zur Realisierung kooperativer Anwendungen dar, welche auch eine vollwertige, kooperative Verkehrszentrale inkludiert. Die Zentrale musste hierzu vollständig neu entworfen und implementiert werden. Größe und funktionale Bandbreite des simTD-Projektes stellten auch eine Vielzahl nicht-funktionaler Anforderungen an das Zentralensystem. Während der Entwurfsphase wurden diese Anforderungen detailliert analysiert und eine geeignete Systemarchitektur musste sorgfältig ausgewählt werden. Übliche Ansätze, die heute in Verkehrszentralen Anwendung finden, erfüllen die hier gestellten Anforderungen nicht in ausreichender Form. Daher wurde ein neuer, hybrider Ansatz gewählt, welcher auf einer serviceorientierten Architektur mit ESB basiert und ein hoch-performantes Subsystem integriert, welches eine datenzentrierte Architektur mit Datenverteiler nutzt. Im Rahmen von Implementierung, Test, Integration und Feldversuch hat sich dieser Ansatz bewährt. Er stellt eine effiziente Realisierung der vielfältigen und z.T. vollständig neuen Anforderungen kooperativer Systeme dar.

Literatur

[1]    FGSV: Hinweise zu Planung und Betrieb von betreiberübergreifenden Netzsteuerungen in der Verkehrsbeeinflussung; Forschungsgesellschaft für Straßen- und Verkehrswesen (FGSV), Köln, 2008

[2]    MARZ: Merkblatt für die Ausstattung von Verkehrsrechnerzentralen und Unterzentralen (MARZ), Ausgabe 1999; Bundesanstalt für Straßenwesen (BASt), Bergisch Gladbach, 1999

[3]    HBS: Handbuch für die Bemessung von Straßenverkehrsanlagen; Forschungsgesellschaft für Straßen- und Verkehrswesen (FGSV), Köln, 2001

[4]    FGSV: Hinweise zum Einsatz von Steuerungsverfahren in der Verkehrsbeeinflussung; Forschungsgesellschaft für Straßen- und Verkehrswesen (FGSV), Köln, 2012

[5]    REHBORN, H.; PALMER, J.; KERNER, B. Verkehrslagefusion für simTD – Systembeschreibung; Daimler Verkehrsforschung, Sindelfingen, 2010

[6]    HÜBNER, D.; RIEGELHUTH, G. A new system architecture for cooperative traffic centres – the simTD field trial, Proceedings ITS World Congress, 2013

[7]    SIMTD. Projektbroschüre simTD, www.simtd.de Publikationen/Informationsmaterial, 2013

[8]    OSGi.    OSGiTM – The Dynamic Module System for Java™, OSGiTM Alliance, www.osgi.org