Extending the Information Horizon through Floating Car Data

Sarah Blatnig Martina Schelander sblatnig@edu.uni-klu.ac.at mschelan@edu.uni-klu.ac.at 1. Einleitung

Um Informationen über Fahrzeuge auf der Straße zu erhalten, bieten sich mehrere Methoden an. Man unterscheidet zwischen querschnittsbezogenen Messungen, wie z.B, Induktionschleifen, Videokameras oder automatische Nummernschilderkennung, die auch als passive Methoden bezeichnet werden und fließenden Informationsquellen. Wir werden in unserer Arbeit auf die fließenden Informationsquellen eingehen.

Floating Car Data (FCD) ist ein Teilbereich von CVHS (Cooperative Vehicle Highway System) [1]. Das Konzept von Floating Car Data ist es, Informationen von Fahrzeugen im Verkehrsgeschehen zu sammeln. Diese Fahrzeuge werden als fließende Informationsquellen betrachtet, daher der Begriff „Floating“. Die Fahrzeuge sammeln Daten, die den Verkehr, betreffen und übermitteln diese an eine Zentrale. Jede Nachricht, die an die Zentrale geschickt wird, beinhaltet die Zeit und den Ort an dem sich das Fahrzeug zu diesem Zeitpunkt befindet. Die Position wird mit Hilfe von GPS bestimmt. Die Zentrale sammelt die Daten, benutzt einen Map Matching Algorithmus und verarbeitet die Daten, um den aktuellen Verkehrszustand zu ermitteln. Die verarbeiteten Daten werden an Reisende und Straßenbehörden übermittelt um diese über das Verkehrsgeschehen zu informieren und somit auch die Sicherheit und das Straßenmanagement zu verbessern. Ein Vorteil von FCD ist, dass die Daten schon vorhanden sind und es keiner zusätzlichen Ausstattung, wie bei passiven Methoden, bedarf.

FCD bringt viele Vorteile mit sich. Durch das Sammeln der Geschwindigkeits- und Ortsdaten kann ein Stau leicht bestimmt werden. Werden von vielen Fahrzeugen die gleichen Geschwindigkeitsprofile gemeldet, kann das Verkehrsbild genau und in Echtzeit bestimmt werden. Es ist möglich die aktuellen Reisezeiten für einen bestimmten Straßenabschnitt zu bestimmen. Dies steht ganz im Gegensatz zu Route Guidance [2], wo die Reisezeiten auf historischen Daten basieren. Ein Route Guidance System sagt dem Fahrer genau welche Route er fahren muss um an sein Ziel zu gelangen, FCD hingegen versorgt den Fahrer mit Informationen während der Reise und überlässt ihm selbst die Entscheidung welche Straße er nimmt. Weiters ist auch eine Kartengenerierung aus den FCD Daten möglich. So erhält man aktuelle Karten mit Informationen, die gerade für den Weg den man fährt benötigt werden. Des Weiteren ermöglicht FCD eine bessere Verkehrsplanung und ein besseres Flottenmanagement für z.B. Polizei oder Busunternehmen. FCD kann auch geographisch richtige Wetterdaten generieren, was für das Straßenmanagement einen großen Vorteil bedeutet, weil man genau planen kann wann und wo z.B. Pflüge oder Salzstreuer eingesetzt werden müssen [1]. Zudem ist FCD relativ ausfallsicher. Da viele Fahrzeuge Daten sammeln, ändert sich nichts wenn ein Fahrzeug ausfällt. 2. Anwendungsgebiete

Es gibt verschiedene Fahrzeugarten, die als Informationsquelle dienen können. Zum einen können Busse Daten senden. Busse sind jedoch keine sehr guten Informationsquellen, da es oft eigene Busspuren gibt, die nicht den aktuellen Verkehrszustand für die Allgemeinheit widerspiegeln. Taxis sind im städtischen Bereich gut geeignet, da es viele gibt und sie schon mit Onboard-Kommunikationsgeräten ausgestattet sind. Im ländlichen Bereich hingegen sind LKWs und Privatfahrzeuge am Besten dazu geeignet Daten zu sammeln. Bei Privatfahrzeugen gibt es jedoch Probleme mit dem Datenschutz, da die Fahrer dazu aufgefordert werden ihren Aufenthaltsort und ihre Geschwindigkeit zu übermitteln. Die Fahrer, die ihre Daten teilen, profitieren zwar davon, da sie auch Informationen zurückbekommen, aber die Privatsphäre wäre nicht gestützt, was viele Autofahrer stören würde. Eine Lösung für dieses Problem wäre, dass bei der Übermittlung der Geschwindigkeits- und Positionsdaten an die Zentrale, keine FahrzeugID mitgeschickt wird. Somit wäre nicht

identifizierbar welches Fahrzeug, welche Informationen sendet und die FCD Benutzer würden sich nicht ihrer Privatsphäre beraubt fühlen. Ein weiteres Problem ist die Frage des Dateneigentums. FCD Systeme produzieren große Mengen an Daten und es stellt sich die Frage ob diese Daten dem Fahrzeugbesitzer, der sie sendet, der Zentrale, die sie verarbeitet oder dem Fahrzeughersteller, der die Ausstattung zum Sammeln der Daten herstellt gehören. Um das Vertrauen der Öffentlichkeit zu gewinnen müssten sich FCD Systeme langsam bewähren um diese Fragen mit der Zeit zu klären.

Der Nutzen der durch FCD Systeme gesammelten Daten wäre sehr vielfältig. Er würde privaten Nutzern helfen ihr Ziel auf dem schnellsten Weg zu erreichen und auch die Sicherheit erhöhen. Die Daten würden den Verkehrsrechenzentralen bei der Auswertung des aktuellen Verkehrszustandes unterstützen. Auch das Flottenmanagement kann durch FCD unterstützt werden, da Taxiunternehmer, Lieferanten oder Transportunternehmen besser planen könnten wann und wo wie viele Fahrzeuge gebraucht werden. Verkehrsplaner in Gemeinden, Mobilfunkbetreiber und Navigationssystemhersteller könnten ebenfalls Nutzern aus FCD ziehen. [1] 3. Technologien Abhängig vom Kommunikationsmedium und der FCD Methode variieren die Kommunikationskosten. Sie können sehr schnell sehr hoch werden, da Datenpakete im Abstand von wenigen Minuten gesendet werden. Die aktuellen FCD Forschungen beschäftigen sich mit der Minimierung der Datenmenge und einer daraus folgenden Reduktion der Kommunikationskosten. Die Datenübertragung von dem Fahrzeug zur Zentrale und wieder an das Fahrzeug zurück setzt sich aus drei Teilen zusammen, Data Reporting, Data Dissemination und Data Cleansing. [1]

Data Reporting[1] ist das Übertragen der Daten an die Zentrale. Dies geschieht in der Form von kurzen Mitteilungen die zwar zeitrelevant jedoch nicht zeitkritisch sind. Das bedeutet, dass Übertragungsverzögerungen von wenigen Minuten für Verkehrs- und Wetterinformationen akzeptabel sind. Bei Sicherheitsinformationen ist jedoch weniger Latenz erforderlich. Die Kommunikationskosten steigen mit der Frequenz der Datenübermittlung. Die Lösung zur Senkung der Kommunikationskosten liegt in Onboard-Datenbanken, welche nur dann mittels Broadcast aktualisiert wird, wenn sich die Fahrzeugsituation von jener in der Datenbank unterscheidet. Eine andere Lösung in einem ausgereiften FCD System, in dem ein Großteil aller Fahrzeuge Daten sendet, wäre, dass nicht alle Fahrzeuge zu jeder Zeit Informationen übermitteln. Es würde reichen, wenn nur ein Teil Informationen an die Zentrale sendet, denn dies würde den Verkehrszustand ausreichend beschreiben. Für diesen Ablauf würde eine Kommunikationsmanagementschleife benötigt werden, die den Fahrzeugen zeitweise mitteilt, die Datenmeldung zu unterlassen.

Die Datenübermittlung kann mit Hilfe von verschiedenen Technologien durchgeführt werden. Taxis können die Daten mit Hilfe von Funk an die Zentrale übermitteln. Für private Nutzer würden sich Mobiltelefontechnologien wie GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunication System) oder EDGE (Enhanced Data Rates for GSM Evolution) anbieten.

Eine andere mögliche Übertragungstechnologie ist DSRC (Dedicated Short Range Communication)[6]. Dies ist eine automatische Kommunikation zwischen Fahrzeugen oder zwischen Fahrzeugen und Empfangsstationen am Straßenrand. Die Kommunikation zwischen zwei Fahrzeugen wird zur Vermeidung von Kollisionen eingesetzt und die Kommunikation mit den Empfangsstationen am Straßenrand um Staumeldungen und Navigationsdaten zu übertragen, aber auch zur Mauterfassung. Die US-amerikanische Federal Communications Commission hat DSRC im Frequenzbereich von 5,9 GHz eine Bandbreite von 75 MHz zugewiesen. Der Vorteil an DSRC ist, dass die Kommunikation einem bestimmten Fahrzeug direkt zugeordnet werden kann. [wikipedia] DSRC Empfangsstationen werden vor allem in Japan des Öfteren eingesetzt. DSRC ist eine gute Kommunikationstechnologie, da auch die Kosten kein Thema sind, weil das System von der Regierung betrieben wird.

WAVE (Wireless Access for the Vehicular Environment)[6] ist eine Erweiterung von IEEE 802.11 (Wireless LAN) zur Unterstützung von ITS-Applikationen. Dies inkludiert den Datenaustausch zwischen Fahrzeugen und dem Straßenrand, wo sich Hotspots befinden. WAVE wurde noch nicht standardisiert, aber eine Standardisierung ist für 2008 zu erwarten.

Es gibt verschiedene Strategien, wann ein Fahrzeug neue Daten schicken sollte. Das ILTU (ID Triggered Location Update) ist eine Update-Strategie, bei der ein Update der Geo-Position dann ausgeführt wird, wenn das Fahrzeug in eine neue Straße einbiegt. Beim DTTLU (Distance Threshold

Triggered Location Update) wird ein Update ausgelöst, sobald die Distanz zwischen der aktuellen Position des Fahrzeuges und der zuletzt aufgezeichneten Position ein bestimmtes, vordefiniertes Limit überschreitet. Eine weitere Strategie ist STTLU (Speed Threshold Triggered Location Update), bei der ein Update ausgelöst wird, wenn die aktuelle Geschwindigkeit die zuletzt aufgezeichnete um einen vordefinierten Wert über- oder unterschreitet.

Data Dissemination [1] hat die Aufgabe die Floating Car Daten an die Benutzer zu verteilen. Sie sollte ein standortabhängiges Service sein, was bedeutet, dass Services wie angepasste Verkehrsinformation, personalisiertes Routing oder geographisch gezielte Werbeanzeigen angeboten werden sollten.

Die Nachrichtengröße ist hier ein wenig größer als bei dem Data Reporting. Die Daten können durch die gleichen Technologien wie beim Data Reporting an die FCD Benutzer zurückgesendet werden. Sie können aber auch durch die Broadcast Methoden von RDS-TMC (Radio Data System – Traffic Message Channel), digitales Audiobroadcast (DAB) oder ein Satelliten Radio übertragen werden. RDS-TMC ist eine Technik, die den Datenstrom zu einem Signal des FM Radios hinzufügt. Das FM Radio im Fahrzeug kann den Datenstrom extrahieren und auf einem LCD Display des Radios anzeigen.

Data Cleansing[1] ist wichtig um irrelevante Daten herauszufiltern. Die Daten müssen auf Plausibilität geprüft und redundante Informationen entfernt werden. Für FCD sind Fahrzeuge, die aus anderen Gründen als Staus stoppen nicht nützlich. Dieses Problem ist vor allem bei Taxis relevant, da diese oft stehen bleiben um Passagiere ein- oder aussteigen zu lassen. Onboard Daten die für das Data Cleansing verwendet werden beinhalten Tür- und Fensterstatus, Benzinlevel, Reifendruck, Airbagstatus, Crashsensoren und Sensoren, die die Rauheit der Straße bestimmen.

4. Floating Car Data Systeme in den USA Im Vergleich zu Japan sind die FCD Aktivitäten in den USA eher bescheiden. Allerdings ist auch hier eine positive Entwicklung zu erkennen. Wir werden ein System aus Minnesota kennen lernen, dass Extended Floating Car Data einsetzt.

4.1. Das Minnesota Projekt In Minnesota wurde im Jahr 2004 vom Minnesota Department of Transportation (DOT) in Zusammenarbeit mit Ford ein FCD Projekt ins Leben gerufen. Der Automobilhersteller Ford ist in einige FCD Aktivitäten eingebunden. Offenbar wird durch diese Zusammenabreiten versucht eine höhere Kundenbindung zu erreichen, da man gewisse Komponenten bereits beim Kauf in Fahrzeuge integrieren kann. Das Ziel des Minnesota Projektes war es Verkehrs- sowie Wetterdaten zu übermitteln. Diese Ausweitung auf Wetterdaten ist jedoch nur durch den zusätzlichen Einsatz von Sensoren möglich. Wir werden später in dieser Arbeit noch ein Projekt von BMW kennen lernen, bei dem ebenfalls Wetterdaten übermittelt werden und deshalb eine Vielzahl zusätzlicher Messeinrichtungen am Fahrzeug notwendig sind. Als Datenlieferanten sollten hier Polizeiautos, Rettungen, LKWs und Fahrzeuge in staatlichem Besitz dienen. Durch diese hybride Auswahl von Fahrzeugen kann eine gute Abdeckung verschiedenster Straßen gewährleistet werden. LKWs liefern beispielsweise gute Daten für Überlandstraßen und Autobahnen während Polizeiautos auch für kleine Straßen innerhalb der Stadtgrenzen gute Werte liefern. Hoffnungen die man in das Minnesota Projekt stecke, waren die schnellere Erkennung von Unfällen, bessere Straßenwartung, da man Zugriff auf Wetterdaten hat. Geringere Kosten als bei bisherigen querschnittsbezogenen Messungen. Daten die für die Unfallerkennung herangezogen werden sind beispielsweise Reisezeiten zwischen Kreuzungen. Sollten diese innerhalb kurzer Zeit unverhältnismäßig niedrig werden, so ist das ein Indiz für ein Hindernis auf dem Straßenabschnitt. Des Weiteren zeigt ein ungewöhnlich häufiger Wechsel zwischen Beschleunigung und Bremsvorgang einen Stop and Go Verkehr an. Daten die bei Wettervorhersagen helfen sind Informationen über aktivierte Fahrhilfen, wie ABS oder ESP. Wenn mehrere Fahrzeuge in einer Region öfter den Gebrauch des ABS Systems melden, dann sind die Straßenverhältnisse offenbar schlecht.

5. Europäische Floating Car Data Systeme Wir werden im Folgenden vier europäische Floating Car Data Systeme vorstellen. In Europa gibt es viele FCD Initiativen, die einerseits von Forschungseinrichtungen und andererseits von Automobilherstellern vorangetrieben werden. Der Staat tritt oft als Partner in diesen Projekten in Erscheinung, da ein positiver Effekt auf die Verkehrsplanung und den Straßenbau im Allgemeinen gesehen wird. Die meisten Systeme, wie die Beispiele aus Deutschland und Österreich dienen in erster Linie zur Verkehrszustanderfassung. Es gibt aber auch Systeme, wie jenes Aus Schweden, dass in erster Linie Wetter bedingte Probleme erkennen soll und die Straßenverwaltung bei ihren Aufgaben unterstützen soll.

5.1. DLR Taxiflotte Das Deutsche Zentrum für Luft- und Raumfahrt (DLR) besitzt unter ihren 31 Instituten in ganz Deutschland ein Zentrum für Verkehrsforschung in Berlin. Rund 80 Mitarbeiter arbeiten dort in den fünf Bereichen Verkehrsinformatik, Verkehrssystemanalyse, Verkehrssystemtechnik, Verkehrsgeografie und Verkehrskommunikationssysteme. Am Institut für Verkehrsforschung wurde das Taxi FCD System ins Leben gerufen. Als Datenlieferanten für das FCD System dienen 8500 Taxis in ganz Deutschland. In Norddeutschland sind in Hamburg und Berlin ca. 1900 Taxis eingebunden. Die restlichen 6600 sind im Süden Deutschlands auf die Städte Frankfurt, Nürnberg, Stuttgart und München aufgeteilt. Da das System aber leicht skalierbar und ausbaufähig ist steht einer Erweiterung nichts im Wege. Hinzu kommen noch weitere 200 Taxis in Wien. Abbildung 1 zeigt die Systemarchitektur des TAXI FCD Systems des DLR. Die Positionsermittlung der Taxis erfolgt über GPS während die Position dann anschließend über eine Funkverbindung an die Taxizentrale übertragen wird. Von dort gelangen die Daten zum FCD-Server des DLR, wo sie aufbereitet werden und Reisezeiten aus ihnen errechnet werden. Anschließend versucht man über verschiedenen Provider diese Informationen über GPRS, SMS oder den RDS-TMC Radiokanal an die Anwender zu übermitteln, die mit diesen Echtzeit Informationen in der Lage sind effizientere Routen zu planen. Ziel und Idee des Systems war eine Verkehrszustanderfassung mit Hilfe dieser FCD Daten. Die FCD Technologie sollte sich als kostengünstige Alternative zu querschnittsbezogenen Messungen bewähren. Begonnen wurde mit einem Pilotprojekt in Nürnberg. Als Partner trat die Taxizentrale Nürnberg in Erscheinung. In einem Nachfolgeprojekt, das den Namen ORINOKO trägt, wurden die FCD Daten zusammen mit anderen Messdaten kombiniert.

Abbildung 1. Systemarchitektur des DLR TAXI FCD

Das Ziel war eine umfassende Verkehrszustanderfassung und auch die Einbindung von Event Planung und der damit einhergehenden Verkehrsbelastung. Da das Projekt erfolgreich war kam es sogar zu einer Zusammenarbeit mit der Stadt Ningbo in China, die nun mit über 2000 Taxis ihr eigenes Taxi-FCD System betreibt. Eine Frage, die sich in Zusammenhang mit den Taxi-FCD Daten jedoch immer stellt, ist die Frage der Qualität der Messungen. Die Qualität ist stark von der Abdeckung des Straßennetzes durch die Taxis abhängig. Analysen des DLR ergaben, dass die Abdeckung durchaus gut bis exzellent war. Es wurde ermittelt, dass ein Taxi im Schnitt 20.000 bis 30.000 Kilometer im Jahr zurücklegt. Die meisten Fahrten bleiben innerhalb der Stadtgrenzen. Gerade Autobahnen und Hauptverkehrsverbindungen in der Stadt werden fast zu 100% abgedeckt. Genau diese Verbindungen sind für Staudatenerfassung von Interesse. Auffällig ist auch, dass gerade für die Nachtstunden viele Taxiwerte vorliegen, was bei privaten Fahrzeugen oder LKWs nicht der Fall ist. Dadurch ist die Abdeckung auch in der Nacht ideal.

5.2. OPTIS OPTIS ist ein schwedisches FCD Projekt, das im Jahr 2000 startete. OPTIS steht für Optimized Traffic in Schweden. Es war Teil eines größeren Projektes mit dem Titel „Green Car“, in dem es darum ging ein möglichst umweltfreundliches Fahrzeug zu bauen. In erster Linie war die Forschung auf umweltfreundliche Antriebsysteme konzentriert. Durch das FCD System sollte es jedoch möglich werden die Reisezeiten zwischen zwei Punkte drastisch zu verringern und das Fahrzeug auf diese Weise umweltfreundlicher machen. Im Gegensatz zu anderen Sensortechnologien sollte FCD die Kosten reduzieren. Nach dem Projekt zeigte sich eine Reduktion der Kosten um die Hälfte im Vergleich zu Technologien wie Induktionsschleifen. Das Projekt Budget von 2000 bis 2006 betrug 1,8 Milliarden schwedische Kronen (= 207 Millionen €) Davon kam allein eine halbe Milliarde vom schwedischen Staat. Weitere Projektpartner waren die schwedischen Automobilhersteller Saab, Volvo und Scania. Die Entwicklung des Systems verlief in fünf Schritten: A. Implementierung des FCD Systems In diesem Schritt wurden die notwendigen Algorithmen und Systemarchitekturen entworfen und entwickelt. B. Verifizierung der Algorithmen durch Simulationen Als das System fertig war wurde es mit Hilfe von Mikrosimulationen getestet. Diese Simulationen sollte beweisen, dass das System richtig und zuverlässig arbeitet, bevor tatsächlich in Hardware für echte Feldversuche investiert wurde. Dabei wurden die Daten, die aus Mikrosimulationen stammen in das FCD System übertragen. Anschließend wurden die Ergebnisse des FCD Systems mit den Ergebnissen die die Mirkomodelle erhielten verglichen. C. Erste Feldversuche von April bis September 2006 mit 250 Fahrzeugen in Götheborg Die Aufteilung der Fahrzeuge war eher hybrid. So bestand die Menge der Testfahrzeuge zu 50% aus Taxis, zu 23% aus Lieferanten, 7% waren Autos des Staates und die restlichen 20% waren Privatautos. D. Verifikation der Simulationen mit den Ergebnissen der Feldstudien Um die Qualität der Simulationen zu überprüfen wurden die Ergebnisse der Simulationen mit den Ergebnissen der realen Feldversuche verglichen. E. Großes Nachfolgeprojekt in Stockholm und Götheborg mit 3% der Fahrzeuge Da das Projekt erfolgreich verlief wurde bereits ein Nachfolgeprojekt gestartet, das in den Städten Stockholm und Götheborg realisiert wird und 3% der Fahrzeuge dort inkludieren soll.

5.3. Das FLEET System

Im Projekt FLEET (Fleet Logistics Service Enhancement with Egnos & Galileo Satellite Technology) wurde ein Reisezeit-Informationsdienst für den Raum Wien auf Basis von Fahrzeug-generierten Daten demonstriert. FLEET ist ein Floating Car Data System, dass seit 2003 von Arsenal Research entwickelt und betrieben wird. Als Datenlieferanten dienen hier inzwischen 800 Taxis der Taxiflotte 31300 in Wien, die mit GPS Einheiten ausgestattet sind. Zu Beginn des Projektes waren es lediglich 200 Taxis mit GPS Einheiten. Die restlichen 600 Taxis übermittelten jeweils nur ihre Start- und Zieladresse an die Zentrale. Diese Taxis wurden auch als OD-Taxis (Origin-Destination) bezeichnet. Hier war zusätzlicher Routingaufwand notwendig. Das System musst mit Hilfe der Start und Zieladresse den wahrscheinlichsten Weg des Taxis durch die Stadt ermitteln und dann mit Hilfe der Zeit für die Fahr auf die Geschwindigkeit auf den Streckenabschnitten rückrechnen. Mit den gesammelten Daten werden mittlere Reisezeiten für alle Straßenabschnitte der Stadt errechnet. Auf diese Weise können Echtzeitverkehrsinformationen, wie Staudaten, generiert werden. Bei der Datensammlung werden folgende Schritte abgearbeitet [7, 10]:

– Jedes Taxi übermittelt seine Position und auch einen Status alle 15 Sekunden. Es werden also fixe Update Punkte verwendet. Es kann jedoch vorkommen, dass diese Updaterate nicht immer aufrechterhalten werden kann. Wichtig ist hierbei jedoch nur, dass man weiß wann ein Wert angekommen ist und nicht ob es wirklich in der 15 Sekunde passiert ist. Wir haben diese Strategie bereits als zeit-relevante aber nicht zeit-kritische kennen gelernt. Statusinformationen beinhalten Daten darüber, ob das Taxi gerade einen Fahrgast transportiert, oder auf dem Weg zu einem Fahrgast ist. Es ist auch möglich einen Folgeauftrag im Status zu kennzeichnen.

– Die Daten werden via Funk an die Taxizentrale übermittelt – Die Daten werden über eine XML Schnittstelle an die Server von Arsenal Research übertragen – Dort werden nicht plausible Daten ausgefiltert und die Daten via Map Matching auf Tele Atlas

Karten projiziert – Nach einer Kategorisierung werden die Daten analysiert und mittlere Reisezeiten ermittelt

Abbildung 2 zeigt das Ergebnis der Verkehrssituationserfassung für Wien. Die roten Streckenabschnitte zeigen Straßen, deren mittlere Reisezeiten gerade über dem Normalwert liegen, was umgekehrt bedeutet, dass man dort im Moment nur sehr langsam vorankommt. Die grünen Bereiche zeigen Streckenabschnitte, die noch nicht ausgelastet sind und in denen man ungehindert fahren kann. Die gelben Bereiche kennzeichnen Übergänge von stark befahrenen zu nicht ausgelasteten Straßen. Man kann deutlich den Wiener Gürtel und den Ring in der Mitte der Grafik erkennen, da sie Zonen sind, in denen der Verkehrsfluss in der Regel sehr gering ist, da die Dichte der Fahrzeuge immer sehr hoch ist.

Abbildung 2. Errechnete Verkehrssituation in Wien aus den Daten des FLEET Systems

Das Fluss Diagramm, dass in Abbildung 3 zu sehen ist, zeigt den Prozessfluss des FLEET Systems unter Berücksichtigung der OD-Taxis. Es werden die einzelnen Stufen der Datenverarbeitung von der Sammlung der Inputdaten über die Verarbeitung der erhaltenen Datenpunkte bis zur Berechnung der Reisezeiten illustriert. Hier werden zunächst die Positionsdaten in einer Datenbank automatisch gespeichert. Die Arbeit erledigen einfache Deamon Prozesse. Die erhaltenen Positionen werden dann anschließend durch einen Map Matching Algorithmus auf ein Straßennetz umgelegt. Anschließend kann ein Router die wahrscheinliche Strecke zwischen Start und Ziel berechnen. Die verschiedenen erhaltenen Strecken werden zusammengefasst betrachtet und anschließend wird mit Hilfe gespeicherter Ganglinien eine Tabelle mit den Reisezeiten für Streckenabschnitte berechnet. Ganglinien sind Beschreibungen der Reisezeiten entlang einer bestimmten Strecke im Verlauf eines bestimmten Zeitintervalls. In der Regel betrachtet man den Abschnitt jeweils für einen Zeitraum von 24 Stunden.

Abbildung 3. Prozessfluss des FLEET Systems

5.3.1 Anforderungen und Vorbereitungen Bevor das System implementiert werden konnte musst einige Vorbereitungen getroffen werden [8]. Zunächst war es notwendig den relevanten Straßenausschnitt des Systems zu definieren und für diesen Bereich notwendiges Kartenmaterial digital aufzubereiten. Um das Map Matching durchzuführen war es notwendig ein exaktes Abbild der Straßenzüge, „Road Elements“ zu modellieren. Für das Routing wurde ein doppelt gerichteter Graph gebildet, dessen Segmente meist von einer Kreuzung zur nächsten führten. Zusätzlich wurden Einbahninformationen gesammelt und Abbiegerelationen gebildet. Die Abbiegerelationen sind die Definition aller erlaubten Bewegungen eines Fahrzeuges bei einer Kreuzung. Kreuzungen zwischen zwei Straßen ohne jegliche Beschränkungen in der Richtung erlauben also 8 Abbiegerelationen. Manchmal sind jedoch nicht alle Abbiegemöglichkeiten erlaubt. Wir möchten im Folgenden ein Beispiel für so eine Abbiegerelation vorstellen. In Abbildung 4 ist eine Autobahnkreuzung mit den Straßen A und B zu sehen. Straßen werden der Einfachheit halber oft mit einer Up und einer entgegen gesetzten Down Richtung bezeichnet. Hier kennzeichnet der Pfeil die Up Richtung.

Abbildung 4. [9] Straßenkreuzung mit zwei Straßen A und B Aus dieser Information kann ein Diagramm erstellt werden, dass die erlaubten Abbiegemöglichkeiten modelliert. Ein solches Diagramm ist in Abbildung 5 zu sehen. Erlaubt sind demnach A up�B up, A up�B down, A down�B down. Sowie die Weiterfahrt auf der aktuellen Spur, also A up�A up, A down �A down und B up�B up, B down �B down.

Abbildung 5. [9] Erlaubte Abbiegerelationen für die Kreuzung

Um nun die erlaubten Wege zu modellieren genüg im Fall von zwei Straßen eine 4*4 Matrix (2 Richtungen * 2 Straßen). Die 1 in der Hauptdiagonale lässt erkennen, dass die Weiterfahrt in die gleiche Richtung möglich ist.

5.3.2 Definition der Schnittstellen Für die Übertragung der Floating Car Data von der Taxizentrale zum FCD Server des Arsenals wurde eine XML Schnittstelle entwickelt. Der folgende Ausschnitt ist ein Teil dieser XML Information, die von den Taxis gesammelt wird. Es handelt sich dabei um einen Rohdatenauszug der Daten, die zu Beginn in einer Datenbank gesammelt werden. Wichtige Elemente sind die Start X- und Y Position und die End X- und Y Position. Der Status gibt an, ob das Taxi gerade einen Kunden hat oder auf dem Weg zu einem ist. Zeitstempel und benötigte Zeit sind wichtig.

5.3.3 Import der Daten und Berechnung der historischen Ganglinien Für die Verarbeitung der Messdaten wurde ein relationale Datenmodell entwickelt, das die Verarbeitung von unterschiedlichen Datenquellen und Messwerten ermöglicht. Da der Verkehrszustand maßgeblich von zeitlichen Faktoren abhängt, Arbeitstage, Feiertage und Ferientage haben unterschiedliche Charakteristika, wurden unterschiedliche Kategorien erstellt, denen die neu ermittelten Daten zugeordnet werden. Es gibt insgesamt 18 Tageskategorien für die die Ganglinien erstellt werden. Zur Berechnung werden folgende mathematische Methoden benötigt wobei n die Größe der Probe bezeichnet[8]. Mittelwert und Streuung von Geschwindigkeiten pro Lane (für historische Ganglinie):

vvv

nnh

nh nn

11

1,

,+−=

−

Startbedingung

11,vv h

=

Au Ad Bu Bd

Au 1 0 1 1

Ad 0 1 0 1

Bu 0 0 1 0

Bd 0 0 0 1

Standardabweichung der Einzelgeschwindigkeiten

1,*)1(1,)2(1 )()()(

2222

−

−+−⋅−+−⋅−=n

nhnvnnhnvnv

vvss

i

n

Startbedingung

ih vv 1, =

01

=sv

Abbildung 6 zeigt ein Diagramm in dem die Streuung der mittleren Geschwindigkeiten für den Wiener Gürtel an einem Werktag dargestellt ist. Die X-Achse ist die Zeitachse und teilt den 24-stunden Intervall ein. Auf der Y-Achse werden die mittleren Geschwindigkeiten und zusätzlich die Streuungen als Abweichungen der Einzelgeschwindigkeiten dargestellt. Es ist dabei zu beobachten, dass die Streuung in der Nacht größer ist als Tagsüber. Das kann dadurch erklärt werden, dass in der Nacht die Straße weniger dicht befahren ist. Durch die geringere Dichte, also weniger Fahrzeuge pro Straßenabschnitt, können die einzelnen Fahrzeuge ihre Geschwindigkeit unabhängiger wählen. Wenn die Dichte sehr hoch ist, sodass Staubedingungen herrschen, dann können die Fahrzeuge keinen unterschiedlichen Geschwindigkeiten wählen, wie das tagsüber und im Berufsverkehr am Gürtel der Fall ist.

Abbildung 6. Streuung der mittleren Geschwindigkeiten am Wiener Gürtel in 24 Stunden

5.3.4 Komponenten zur Verarbeitung der Floating Car Daten Abbildung 7 zeigt die Komponenten des Fleet Systems, die in C++ implementiert wurden. Anschließend werden die einzelnen Stufen bei der Datenverarbeitung gesondert betrachtet [8]. A. Zuordnung zur Karte (Map Matching)

0,00

10,00

20,00

30,00

40,00

50,00

60,00

00:0

0

01:0

0

02:0

0

03:0

0

04:0

0

05:0

0

06:0

0

07:0

0

08:0

0

09:0

0

10:0

0

11:0

0

12:0

0

13:0

0

14:0

0

15:0

0

16:0

0

17:0

0

18:0

0

19:0

0

20:0

0

21:0

0

22:0

0

23:0

0

00:0

0

Tageszeit

mitt

lere

Ges

chw

indi

gkei

t [km

/h]

+/- S

treu

ung

mitt

lere

Ges

chw

indi

gkei

t

Vor dem Beginn der Auswertungen werden die Meldungen der Taxi-Fahrten auf Plausibilität geprüft und unplausible Fahrten, wie beispielsweise kreisförmige Fahrten, zu kurze oder zu lange Fahrten, durch Filter aus der Datenbasis auszuscheiden. Von allen Taxifahrten ist die Position von Start und Ziel der Fahrt bekannt und kann einem Straßenabschnitt zugeordnet werden. Die Positionen von Fahrten mit GPS-Positionierung werden anhand von Position und Richtung dem nächstliegenden Straßenabschnitt des Knoten-Kanten-Modells zugeordnet. Falls die Zuordnung nicht eindeutig möglich ist, werden die Fahrten nicht für die Auswertung herangezogen. Map Matching ist der Vorgang, bei dem eine Koordinate oder eine Folge von Koordinaten einem vorhandenen, digitalisierten Straßennetz zugeordnet wird. Abbildung 8 zeigt einen Map Matching Vorgang für eine einzelne Koordinate an ein vorhandenes Straßennetz. Der rote Punkt bezeichnet dabei den gemessenen Punkt des Fahrzeuges und der Pfeil die Fahtrichtung. Dieser würde laut der Messwerte neben der Straße liegen. Nun darf aber davon ausgegangen werden, dass sich das Fahrzeug auf der Straße und nicht neben ihr befindet und es sollte nun der Punkt gefunden werden an dem sich das Fahrzeug tatsächlich befindet. Die schwarzen Linien kennzeichnen das im System vorhandene Straßennetz. Wichtig ist hierbei, dass auch Heading Informationen gesammelt und im Netzt gespeichert sind. Also die Richtung des Fahrzeuges und die erlaubten Fahrtrichtungen in einer Straße.

Abbildung 7. [8] Komponenten des FLEET FCD Systems Grundsätzlich wird der Punkt jener Verbindung zugeordnet, die die geringste Orthogonaldistanz zum Punkt aufweist und eine Richtungsfahrbahn in der Richtung des Headings des Fahrzeuges existiert. In unserem Beispiel würde sich der Punkt näher an der südlich gelegenen Straße befinden. Allerdings ist diese eine Einbahn und kommt aus diesem Grund nicht in Frage.

Abbildung 8. Map Matching für einzelne Koordinate Ein anderer Ansatz beim Map Matching berücksichtigt eine Historie einzelner Positionswerte eines Fahrzeuges. Man betrachtet als nicht einzelwerte sondern beispielsweise die letzten fünf Positionen, die das Fahrzeug übermittelt hat. Durch diese Methode werden die Zuordnungen viel genauer. Für komplizierte Straßennetzte, mit mehreren Ebenen sind diese Methoden ideal. GPS Einheiten wären zwar in der Lage auch die Höhe des Fahrzeuges zu ermitteln, allerdings werden diese Daten in den FCD Systemen selten gesammelt und aus diesem Grund gar nicht an die Zentrale übermittelt. Sollte ein Fahrzeug sich auf einer Brücke befinden, die über eine andere Straße führt, so kann aus der Historie der Positionen geschlossen werden auf welcher Straße sich das Fahrzeug wirklich befindet. Abbildung 9 zeigt, wie eine solche Sammlung von Positionsdaten zur Zuordnung an ein Straßennetz aussehen könnte.

Abbildung 9. Map Matching Vorgang mit mehreren aufeinander folgenden Punkten

B. Routensuche (Routing) Die Fahrten von Taxis mit GPS-Positionierung werden auf Basis einer Serie von Positionen rekonstruiert. Wenn Fahrten mit Quell-Ziel-Informationen vorliegen oder die Abstände der GPS-Meldungen keine exakte Registrierung des Weges erlauben, wird mit dem Router für Einzelfahrten der kürzeste Weg zwischen zwei bekannten Punkten bestimmt. Das Routing erfolgt mit Hilfe eines optimierten Dijkstra Algorithmus zur Bestimmung kürzester Wege in einem Graphen. Es wird angenommen, dass Taxis in der Regel die kürzeste Route wählen. Es hat sich in der Vergangenheit gezeigt, dass diese Annahme durchaus zutreffend war. Für die Beurteilung des Verkehrszustandes und der Reisezeiten auf Korridoren können Quell-Ziel-Informationen verwendet werden, weil sie in der Regel eine gute Berechnung der mittleren Geschwindigkeit erlauben. C. Berechnung der aktuellen Reisezeit (Eval Datapoints)

Nun wird für jede Fahrt eine mittlere Geschwindigkeit berechnet. Diese wird auf jedes Straßensegment, die bereits im ersten Schritt vor der Implementierung ermittelt wurden, im Laufe dieser Fahrt aufgeteilt. Um das unterschiedliche Geschwindigkeitsniveau verschiedener Straßen zu berücksichtigen, wird die auf diesem Straßensegment gefahrene freie Geschwindigkeit oder die normale Geschwindigkeit (aus der historischen Ganglinie) mit in die Berechnung einbezogen. Aus den Geschwindigkeiten pro Straßensegment wird mit Hilfe gewichteter (harmonischer) Mittelung die mittlere räumliche Geschwindigkeit eines Straßenabschnittes berechnet. Durch die Gewichtung mit der Zeit, die die Geschwindigkeit eines Einzelfahrzeuges gefahren wurde, wird der Einfluss der Einzelgeschwindigkeiten auf die räumliche mittlere Geschwindigkeit berücksichtigt. Zur Berechnung kommen folgende Methoden zum Einsatz. Mittelwert der Geschwindigkeit pro Straßensegment und Fahrtrichtung:

nl

n

nl

n

ii

n

ini

nnl

n

ii

n

ini

nl

vs

vs

ss

tvs

ssv

+

+=

+

+=

−

−

=

−

=

−

−

=

−

=

�

�

�

�

1

1

1

1

1

1

1

1

1

1

si Wege einzelner Fahrten auf Lane sn Weg der n-Fahrt tn Reisezeit einzelner Fahrten auf Lane

nlv Mittlere Geschwindigkeit auf Lane bei n-Werten

Startbedingung

tsv l

1

11=

ssi

i 1

1

1

=�=

D. Korrektur der aktuellen Reisezeiten (Prog Traveltime) Der zeitliche Verlauf von Geschwindigkeitswerten auf einem Segment kann nicht durch ein exaktes, deterministisches Modell abgebildet werden. Unbekannte Faktoren, wie das Fahrverhalten der Autofahrer, Ampelsteuerungen, Umwelteinflüsse, fließen zu jedem Zeitpunkt in das System ein. Diese Faktoren können als Streuung der Geschwindigkeiten gemessen werden. Aus diesem Grund liefern hier stochastische Methoden, in denen unbekannte Faktoren berücksichtig werden könne, bessere Ergebnisse. Der Kalman Filter ist eine gute Methode, um Modelle der Zeitreihen (historische Ganglinien der Geschwindigkeit) mit aktuell berechneten Werten zu kombinieren. Während der Geschwindigkeitswert der historischen Ganglinie ein Mittelwert mit hoher Präzision ist, hängt die Präzision des aktuellen Wertes von der Zahl der vorhandenen Messwerte ab und variiert daher stark. Die unterschiedlichen Präzisionswerte können mit einem Kalman Filter modelliert werden. Der erhaltene, korrigierte Wert weist eine geringere Abweichung von der tatsächlichen mittleren Geschwindigkeit auf als der historische Wert oder der aktuelle Wert für sich. Ein Kalman Filter ist eine Kombination von Gleichungen, um Zustandswerte eines zeitdiskreten Prozesses zu berechnen. Der zeitliche Verlauf des Prozesses wird durch einen autoregressiven Term, einen optionalen Stellwert und eine Zufallsgröße, die hier als Prozess-Streuung bezeichnet wird, beschrieben.

�

Streuung-ProzessStellgröße

*

Termsiver autoregres

~*~11 −− ++= tttt uBxAx µ

������

Für jeden Zeitschritt werden der aktuelle Messwert und eine Streuung benötigt.

� �

Streuung-MesstProzesswer

~*

Messwertttt xHy σ+=

���

Der Kalman Filter funktioniert iterative. Der Wert für den nächsten Zeitschritt wird vorhergesagt und aus dem vorhergesagten Wert und dem Messwert wird ein korrigierter Wert berechnet. Als Prozesswert wird nun die Differenz zum historischen Wert der entsprechenden Tagesklasse betrachtet, welche die Charakteristika des zeitlichen Verlaufes der Geschwindigkeiten in jedem Straßensegment erfasst. Diese Differenz kann als zeitlich konstanter Wert mit zufälliger Streuung betrachtet werden, und somit kann ein lineares Modell eingesetzt werden.

� �

Streuung-Prozess Differenzche tatsächli

~~11 −− += ttt xx µ

� � �

Streuung-Mess Differenzhetatsächlic

~

Differenzgemessenettt xy σ+=

Um die Größe von Prozess- und Mess-Streuung zu bestimmen, wurden historische Ganglinien auf einer Vergleichsstrecke untersucht. Die Prozess-Streuung wurde auf Basis der mittleren Streuung des Mittelwertes einer historischen Ganglinie mit rund +/- 3 km/h abgeschätzt und die Mess-Streuung wurde auf Basis der mittleren Streuung der Einzelwerte einer historischen Ganglinie mit rund +/- 5 - 10 km/h abgeschätzt. Die Streuung der Geschwindigkeit wurde auf den gewählten Testrouten für März 2004 berechnet. Die Ergebnisse sind in folgender Tabelle dargestellt.

Nr. Teststrecke L [m] Streuung des

korrigierten Wertes [km/h]

Reststreuung zw. korrigiertem Wert und aktuellem Messwert

[km/h] 1-0 Ring (gesamte Strecke) 4146 3.0 – 4.0 3.5 – 4.0 2-1 "2er-Linie"

(Donaukanal bis Alser Strasse) 4470

3.0 – 4.0 2.5 – 3.5

2-2 "2er Linie" (Roßauer Lände – Donaukanal) 5225

3.0 – 4.0 2.5 – 3.5

3-1 Nordbrücke (20.Bez - 21.Bez) 850

3.0 – 4.0 8.5 – 10.5

3-2 Nordbrücke (21.Bez - 20.Bez) 849

3.0 – 4.0 8.5 – 10.0

4-1 Gürtel (Anschluss A23 – Spittelau) 10913

3.0 – 4.0 3.0 – 4.0

4-2 Gürtel (Spittelau - Anschluss A23) 11196

3.0 – 4.0 3.0 – 4.0

5-1 Westeinfahrt (Auhof - Karlsplatz) 11372

3.0 – 4.0 4.5 – 5.5

5-2 Westausfahrt (Karlsplatz - Auhof) 11572

3.0 – 4.0 4.5 – 5.5

6-1 A4 (Urania - Flughafen Schwechat) 18227

3.0 – 4.0 11.5 – 13.0

6-2 A4 (Flughafen 18302 3.0 – 4.0 13.5 – 15.5

Schwechat - Urania) + gute Abdeckung durch Floating Cars � zufriedenstellende Abdeckung durch Floating Cars - geringe Abdeckung durch Floating Cars Tabelle aus [8]. Streuung der Geschwindigkeiten E. Evaluierung der Qualität der Reisezeiten Die Qualität der ermittelten Reisezeiten hängt maßgeblich von der Abdeckung des Straßennetzes durch die Taxiflotte ab. Am Kapitel zur DLR Taxiflotte wurde bereits die Abdeckung durch Taxis genauer betrachtet. Im FLEET Projekt wurde eine ähnliche Analyse durchgeführt. Die Ergebnisse sind in der folgenden Tabelle zusammengefasst:

Nr. Teststrecke Fahrleistung der Taxiflotte auf Teststrecken [km / (h * km Strecke)]

Bewertung

L [m] Mittelwert SD 1-0 Ring (gesamte Strecke) 4146 3.7 2.4 + 2-1 "2er-Linie"

(Donaukanal bis Alser Strasse) 4470

3.3 2.1 +

2-2 "2er Linie" (Roßauer Lände – Donaukanal) 5225

5.4 3.2 +

3-1 Nordbrücke (20.Bez - 21.Bez) 850

0.8 0.4 -

3-2 Nordbrücke (21.Bez - 20.Bez) 849

0.8 0.5 -

4-1 Gürtel (Anschluss A23 – Spittelau) 10913

2.2 1.4 +

4-2 Gürtel (Spittelau - Anschluss A23) 11196

2.4 1.4 +

5-1 Westeinfahrt (Auhof - Karlsplatz) 11372

1.3 0.9 �

5-2 Westausfahrt (Karlsplatz - Auhof) 11572

1.3 1.2 �

6-1 A4 (Urania - Flughafen Schwechat) 18227

2.0 2.5 �

6-2 A4 (Flughafen Schwechat - Urania) 18302

0.2 0.3 -

+ gute Abdeckung durch Floating Cars � zufrieden stellende Abdeckung durch Floating Cars - geringe Abdeckung durch Floating Cars Tabelle aus [8]. Abdeckung durch die FCD Taxis 5.4. BMW XFCD

XFCD wurde von BMW entwickelt und wird als FCD System der zweiten Generation bezeichnet. Extended Floating Car Data bedeutet, dass Daten gesammelt werden, die über die üblichen Positions- und Geschwindigkeitsmessungen hinausgehen. Es werden zusätzlich Wetterdaten und Daten, die den Straßenzustand beschreiben gemessen. Anfang 2005 waren 78.000 BMW-Fahrzeuge mit XFCD ausgestattet und die Anzahl steigt stetig an. [1]

XFCD basiert auf Exception Reporting, Datenmanagement, verbesserte Event-detection Algorithmen und verbessertem Data Cleansing. Exception Reporting bedeutet, dass nicht ständig Daten geschickt werden, sondern die On-board Datenbank wird nur dann upgedatet, wenn sich die Fahrzeugsituation ändert. Die verbesserten Algorithmen filtern falsche Daten heraus, damit der Benutzer keine redundanten Daten erhält. Falsche Daten sind z.B. Stehenbleiben um einen Passagier ein- oder aussteigen zu lassen oder weil der Tank leer ist. [6]

Die Daten werden, wie man in Abbildung 1 erkennen kann, durch verschiedene Sensoren und Signale gemessen. Es gibt einen Regensensor, der die Aktivität der Scheibenwischer misst, Geschwindigkeitssensoren, Crashsensoren und eine Abstandsmessung zum Vorderfahrzeug. Auch der Zustand der Lichter und Bremsen und die Temperatur werden gemessen und es gibt eine Reibungsüberwachung, was bedeutet, dass der Luftwiderstand des Fahrzeugs gemessen wird, und die Schmierung des Motors überwacht wird. Weiters sind die BMW-Fahrzeuge mit ABS (Antiblockiersystem), DSC (Dynamische Stabilitätskontrolle), ACC (Adaptive Cruise Control) und Navigationssystemen ausgestattet. ABS[6] wirkt, vor allem bei Vollbremsungen durch Regelung des Bremsdruckes in kurzen Intervallen, dem Blockieren der Räder entgegen. DSC[6] ist ESP (Elektronisches Stabilitätsprogramm) und wurde von BMW mit einem eigenen Namen versehen. ESP bzw. DSC ist ein Fahrassistenzsystem, welches versucht die Sicherheit des Fahrzeuges zu erhöhen indem einzelne Räder gezielt gebremst werden, womit versucht wird ein Schleudern zu verhindern und dem Fahrer die Kontrolle über das Fahrzeug zu sichern. Durch das gezielte automatische Abbremsen der einzelnen Räder wird sowohl das Übersteuern als auch das Untersteuern des Fahrzeuges verhindert. ACC [6] misst mit Hilfe eines RADAR Sensors die Geschwindigkeit und die Position des Vorderfahrzeugs und bestimmt so den idealen Abstand und die Geschwindigkeit des mit ACC ausgestatteten Fahrzeuges, womit Auffahrunfälle verhindert werden sollen. [3]

Abbildung 10. [3] Sensoren und Signale zur Datenerfassung Wetterdaten werden durch die Abfrage des Scheibenwischerstatus, der Geschwindigkeit, der ABS Signale, des Frontscheinwerferstatus, der Temperatur und der Navigation gemessen. Dies ermöglicht die Bestimmung des Niederschlags, der Sichtverhältnisse und des Straßenzustandes. Ein reger Scheibenwischerbetrieb, niedrigere Geschwindigkeit und eingeschaltete Frontscheinwerfer lassen auf Niederschlag an jenem Ort, wo sich das Fahrzeug befindet, schließen. Zum Data Cleansing werden Steuerungswinkel, Tür- und Fensterstatus, Benzinlevel, Reifendruck, Distanz von anderen Objekten, Airbagstatus, Positionsdaten und noch einige weitere Daten gemessen. Wenn das Fahrzeug keine Geschwindigkeit aufweist und eine Türe geöffnet ist, sind die Daten irrelevant, da der Fahrer wahrscheinlich nur stehen geblieben ist, um Passagiere ein- oder aussteigen zu lassen oder um auszusteigen. Diese Information ist für andere Fahrzeuglenker unbrauchbar und wird herausgefiltert. [5] Ein Beispiel für die Funktionsweise von XFCD ist in Abbildung 2 dargestellt. Das Fahrzeug übermittelt, wenn ein Auto auf die Gefahrenzone zufährt, eine visuelle und hörbare Warnung an den Fahrer. Zuvor wird die Information mit Hilfe von GPS einem Relevanzcheck unterzogen, indem

gemessen wird ob sich das Fahrzeug wirklich auf die Gefahrenzone zubewegt. Die Information wird im Service Center generiert und Informationen von einem Traffic Information Center (TIC) werden miteinbezogen. Das System im Fahrzeug empfängt die Informationen über Mobilfunk und gibt sie, wenn sie relevant sind, an den Fahrer weiter. [3]

Abbildung 11. [3] Gefahrenwarnung mittels Extended Floating Car Data Die wichtigsten Aspekte von XFCD wurden in Tabelle 1 noch einmal zusammengefasst. Hier wird zusätzliche Hardware in Form von Sensoren benötigt und so ist es möglich, außer den bei FCD üblichen Geschwindigkeits- und Positionsdaten, Wetterdaten zu messen und Straßenverhältnisse zu bestimmen. Die Vorteile sind, dass die Daten effizient gesendet werden, d.h. dass redundante Daten entfernt werden, die Sicherheit erhöht wird und das der Verkehrszustand, inklusive aktuellem Wetter, Sichtverhältnisse, Niederschlag und Straßenverhältnisse, genau erfasst werden kann. 6. Japanische Floating Car Data Systeme Japan nimmt eine Vorreiterrolle im Einsatz von Floating Car Data Systemen ein. Dort wurden bereits sehr früh Taxis wie auch private Fahrzeuge für die Datensammlung verwendet. Dieser Umstand scheint in der hohen Verkehrsdichte in Japan begründet zu sein. Der Hauptgrund für den Einsatz von FCD ist zuverlässige Stauwarnung und die schnelle (Echtzeit basierte) Berechnung von Alternativrouten.

6.1. Smartway

Das Japanische Ministerium für Land, Infrastruktur und Transport (MLIT) begann 1999 Floating Car – Techniken für die Straßenverwaltung zu erforschen. Dies ist Teil von Smartway, dessen Zweck es ist sowohl langfristiges Straßenmanagement und Evaluierung von Straßenumbauten, sowie Geschwindigkeitsmessungen und Emissionsmessungen durchzuführen, wofür die Daten werden nicht in Echtzeit verarbeitet werden. [1] Begonnen wurde 1999 mit der Erhebung von Verkehrsinformationen in 16 Städten. 2001 wurden schon 4700 Fahrzeuge zur Meldung von Stauinformationen auf einem 11.000 km umfassenden Straßennetz eingesetzt. Im Jahr 2002 kamen auch Busse als Testfahrzeuge hinzu und 2004 gab es 10.000 Testfahrzeuge, die Verkehrsdaten meldeten. [5]

Smartway umfasst mehrere Applikationen, dazu zählen Elektronische Mauterhebung (Electronic Toll Collection – ETC), ein Fahrzeuginformations und –kommunikationssystem (Vehicle Information and Communication System - VICS), das Smart Cruise System und Straßenmanagement und –evaluierung. [4] Smartway ist eine ITS Plattform und besteht aus mehreren Schichten, wie in Abbildung 3 ersichtlich wird. Die wichtigsten Applikationen sind das Smart Cruise System und das Straßenmanagement. Für das Straßenmanagement und –evaluierung ist die Straßenoberfläche von großer Bedeutung, während das Smart Cruise System den Verkehr und die Struktur einer Straße als Information benötigt. Diese Daten werden über Kommunikationsservices und auf Fahrzeugen montierten Services übertragen. Die dazu benötigte Hardware sind Sensoren, Straßen-Fahrzeugkommunikation, ein Interface am Straßenrand und im Fahrzeug. Die Daten werden übertragen und in jene Form gebracht in der die Applikationen sie benötigen.

Abbildung 12. [4] Smartway Architektur Das Smart Cruise System [4] ist ein Echtzeit Fahrthilfesystem und besteht aus intelligenten Fahrzeugen und einer intelligenten Straße und soll die Sicherheit erhöhen. Die intelligenten Fahrzeuge werden als ASV (Advanced Safety Vehicle) und die intelligente Straße als AHS (Advanced Crusie System) bezeichnet. Die Ausstattung von Straße und Fahrzeug ist in Abbildung 4 zu sehen. Das ASV ist mit Sensoren, einem Mensch-Maschine-Interface, Auslösern und einer ECU (Electronic Control Unit) ausgestattet. Die ECU ist ein eingebettetes System, welches eines oder mehrere Subsysteme im Fahrzeug kontrolliert [wiki]. Es gibt eine Straße-Fahrzeug Kommunikationseinheit, die es auch am Straßenrand gibt. Der wichtigste Sensor ist der Lane Marker Sensor der die Straße nach speziellen Markierungen abtastet und das Fahrzeug so auf der Spur halten soll. Am Straßenrand gibt es Sensoren, die die Konditionen der Straßenoberfläche überwachen und Hindernisse erkennen. Entdeckt ein Sensor ein Hindernis, wird dies dem Fahrzeug mitgeteilt und es kann dementsprechend darauf reagieren.

Abbildung 13. Komponenten des Smart Cruise Systems Das Smart Cruise System soll Kollisionen mit Hindernissen weiter vorne auf der Straße vermeiden. Durch die Sensoren am Straßenrand sollen z.B. Hindernisse nach einer Kurve vorzeitig entdeckt und dem Fahrzeug mitgeteilt werden, damit man noch rechtzeitig ausweichen kann. Das Hinausschießen über eine Kurve und das Abkommen von der Straße sollte vermieden werden, indem die Lane Marker Sensoren die Straße abtasten und das Fahrzeug lenkt sobald sich die Straßenmarkierungen nicht mehr in der Mitte des Fahrzeuges befinden. Auch Kollisionen bei der Überquerung von Kreuzungen oder beim Rechtsabbiegen sollten durch Hindernissensoren vermieden werden. Derselbe meldet auch wenn sich Fußgänger auf der Straße befinden und das Fahrzeug kann rechtzeitig gebremst werden. Durch Sensoren, die die Straßenoberfläche überwachen kann der Straßenbelagszustand bestimmt werden und durch weitere Sensoren können Abstände zu anderen Fahrzeugen bestimmt und in weiterer Folge korrigiert werden. [4] Die wichtigsten Aspekte von Smartway werden in Tabelle 2 noch einmal zusammengefasst. Smartway ermöglicht eine gute Auswertung von Straßenbauprojekten indem man Messungen vor und nach dem Umbau durchführt. Die Erhöhung der Sicherheit ist einer der bedeutendsten Vorteile von Smartway. Die Übermittlung der Daten durch die Kommunikation zwischen Straße und Fahrzeug unterscheidet Smartway von anderen FCD Systemen und auch seinem Hauptzweck, dem Straßenmanagement, wird in andren FCD Projekten keine so große Bedeutung beigemessen. 7. Gegenüberstellung der vorgestellten Fallbeispiele Die folgenden zwei Tabellen sollen als direkte Gegenüberstellung der sechs vorgestellten Fallbeispiele dienen. Wir haben uns dabei auf die sechs wichtigsten Eigenschaften der Floating Car Data Systeme konzentriert. Der Punkt Hardware ist insofern wichtig, da er zu einem großen Teil die Kosten des Systems definiert. Auffällig ist, dass in den USA das FCD System eher zur Ermittlung und Vorhersage der Straßenverhältnisse verwendet wird, während Europa und Japan in erster Linie auf Verkehrszustanderfassung und die Verbesserung von Stausituationen hoffen. Obwohl zur Positionierung mehrere Möglichkeit erforscht sind/werden, wird in erster Linie immer GPS eingesetzt, da es die genauesten und zuverlässigsten Werte liefert. In Europa wird auch meist auf die Verbesserung der GPS Qualität durch die EGNOS Satelliten gehofft. Die Positionierung über Zellzugehörigkeit in einem GSM Netz wurde in einem Projekt bei Arsenal Research in Wien im indirekten Zusammenhang mit FLEET erprobt.

Hardware Datensammlung Positionierung DLR Taxiflotte

GPS, sonst keine zusätzliche Hardware notwendig

Fahrzeug ID, Zeitstempel, GPS Position, Taxi Status Update alle 15-120 Sekunden

GPS

BMW XFCD

Zusätzliche Sensoren Verkehr, Wetterdaten (Niederschlag, Fernsicht), Straßenverhältnisse

GPS

OPTIS Volvo OnCall Units mit OPTIS Algorithmus OnCall enthält GSM Kommunikationsfähigkeit und GPS

ID, Fahrzeugtyp, Position, Geschwindigkeit

GPS

FLEET

Eur

opa

Funk (in den Taxis vorhanden) GPS

ID, Zeitstempel, Position, Taxi Status, Update alle 15 Sekunden

GPS, GSM Netzt Zellzugehörigkeit (PROMOS)

Minnesota

USA

GPS, Sensoren für die Wetterdaten Sensoren für die Fahrzeugfunktionen

Geschwindigkeit, Position, Fahrtrichtung, Scheibenwischer Aktivität, Lichtstatus, Außentemperaturen, Informationen über die Bodenhaftung

GPS

Smartway

Japa

n

Zusätzliche Sensoren

Straßenperformanz, Straßenbauprojekte auswerten, Reisegeschwindigkeiten, Fahrzeugemissionen, Stauinformationen

Kommunikationspunkte entlang der Strecke

Übermittlung Verarbeitung Nutzen DLR Taxiflotte

Funk (in den Taxis schon vorhanden)

Map Matching auf NAVTEQ Karten, Reisezeiten, Berücksichtigung historischer Daten

Verkehrszustandserfassung, Flottenoptimierung, Stauwarnung, Erreichbarkeitsanalyse

BMW XFCD

Exception Reporting, Onboard Datenbank Report nur bei Abweichung der Normalwerte

Fahrzeugzustand, Wetter, Straßenzustand

Effizientes Senden von Daten Erhöhung der Sicherheit Verkehrszustandserfassung

OPTIS

Eur

opa

Zu Beginn GSM mit SMS (gute Abdeckung) Arbeit an GPRS

Map Matching, Berechnung der Reisezeiten

Information für Reisende, Beitrag zum „Green Car“ durch geringere Fahrzeiten

als Alternative FLEET Funk der Taxis Map Matching

Reisezeitermittlung für Streckenabschnitte

Verkehrszustandmessung, Staudaten

Minnesota U

SA

Übermittlung an „Condition Aquisition Reporting System“

Ermittlung der Wetterdaten, Übertragung an elektronische Verkehrsinformationstafeln

Schnelle Erkennung von Unfällen, Bessere Datenqualität durch Fusion, erkennen der Wettersituation, geringere Kosten als bisherige Verfahren

Smartway

Japa

n

Straße – Fahrzeug Kommunikation

Straßenzustand, Fahrverhalten, Abstände bestimmen, Evaluierung

Vermeidung von Unfällen, Emissionsmessung, Evaluierung des Verkehrs, Straßenmanagement

8. Zusammenfassung Wir haben in dieser Arbeit das Prinzip der Verkehrsdatenerfassung aus Floating Car Data Systemen kennen gelernt. Im Gegensatz zu querschnittsbezogenen Messungen fungieren hier Fahrzeuge, die durch den Verkehr „fließen“ als Datenlieferanten. Die übermitteln in regelmäßigen Abständen Daten an eine Verkehrszentrale, die aus diesen Daten den Verkehrszustand erfassen kann. Da die zusätzlich notwenige Hardware für diese Aufgabe relativ billig ist, stellt Floating Car Data eine billige Alternative zu anderen Technologien, wie beispielsweise Induktionsschleifen, dar. In der Regel müssen nur zusätzliche GPS Einheiten in den Fahrzeugen installiert werden und eine Möglichkeit die Daten an die Zentrale zu übermitteln vorhanden sein. Wenn man bei der Auswahl der Fahrzeuge klug vorgeht, beispielsweise eine Taxiflotte für sich gewinnt, ist die zusätzliche Investition sehr gering. Allerdings ist auf Seite der Datenverarbeitung größerer Aufwand, der aber nicht unbedingt finanzieller Natur sein muss, notwendig. Die Daten, die von den Fahrzeugen geliefert werden sind in der Regel nicht sauber, dass heißt, die Abweichungen von den tatsächlichen Positionen im Straßennetz können mitunter erheblich sein. Man benötigt Technologien wie Map Matching, um die Positionen richtig zuzuordnen. Zusätzlich müssen die Daten als strecken- bzw. streckenabschnittsbezogen interpretiert werden. Die erhaltenen Reisezeiten werden immer in Bezug zum Zeitpunkt gesetzt, in dem sie aufgezeichnet werden. Es werden verschiedene Kategorien verwendet. Mathematische Methoden, wie Kalman Filter, müssen angewendet werden, um die historischen mit den aktuellen Daten zu kombinieren. Des Weiteren haben wir auch extended Floating Car Data Systeme, wie jenes von BMW, kennen gelernt. Hier werden nicht nur Positionen sondern viele zusätzliche Daten, wie Straßentemperatur, Reifendruck oder den Zustand der Lichter, übermittelt. Diese Daten ermöglichen das Wetter und den Zustand der Straßen zu bestimmen und können hilfreiche Hinweise für die Straßenverwaltung oder den Fahrer selbst darstellen. Allerdings ist hier zusätzlicher Aufwand für die Hardware notwendig, da das Fahrzeug mit einer Reihe zusätzlicher, eventuell teuerer, Sensoren ausgestattet werden muss. Wir haben die verschiedenen Technologien, die bei Floating Car Data Systemen zum Einsatz kommen kennen gelernt. Dabei wurden verschiedenste Floating Car Data Systeme in Europa, Japan und den USA vorgestellt. Die Systeme werden in den verschiedenen Kontinenten aus unterschiedlichen Gründen eingesetzt, da auch die Verkehrsdichte von sehr stark (Japan) über moderat (Europa) bis zu eher gering (USA) variiert. Während in Japan der Hauptgrund für den Einsatz, die Vermeidung von Staus ist, wird in den USA oft ein Frühwarnsystem für schlechte Wetter- und Straßenverhältnisse gewünscht. Wir haben die verschiedenen Systeme mit einander verglichen, indem wir die sechs wichtigsten Eigenschaften der Systeme in einer Tabelle direkt gegenüber gestellt haben. Die sechs Kriterien waren zusätzlich notwendige Hardware, die mitunter den Preis eines solchen Systems bestimmt, die Datensammlung und die Ermittlung der Position, obwohl hier in der Regel GPS eingesetzt wird, da es am zuverlässigsten ist und die genaueste Positionierung erlaubt. Zusätzlich

wurde noch nach der Art der Datenübermittlung zur Zentrale und den verschiedenen Verarbeitungsschritten dort unterschieden. Nicht zuletzt haben wir noch versucht herauszufinden, was die Anwender oder Betreiber für Vorteile aus der Anwendung des Systems ziehen können, da dieser Punkt den Einsatz des Systems rechtfertigen sollte. Wenn der Preis den Nutzen übersteigt ist das System nicht sinnvoll. Reine Forschungsprojekte, mit der Aufgabe das Einsatzgebiet und die Möglichkeiten zu erforschen sind inzwischen eher selten. Meist waren diese Projekte um das Jahr 2000 angesiedelt. 9. Literatur [1] R. Bishop, Intelligent, Vehicle Technology and Trends, Artech House Its Library 2005. [2] K. Kyamakya, ITS: User Services, Applications, and Standards, Verkehrstelematik II 2006. [3] W. Huber, M. Lädke, R.Ogger, Extended Floating Car Data for the Acquisition of Traffic Information, BMW, Bosch, DDG 1999. [4] A. Yamakawa, ITS in Japan – Smartway, Smart Cruise System and Standardization, The ITS Sector Initiative 2001. [5] R.Bishop, Floating Car Data Projects Worldwide: A Selected Review, ITS America Annual Meeting 2004. [6] Wikipedia, www.wikipedia.org, 2006 [7] FLEET Endbericht, Arsenal Research, Oktober 2004. [8] Spezifikation FLEET Outputstruktur, Spezifikation_FCD_Qualv_V1-3, Bernhard Nowotny, 4.5.2005. [9] R. H. Güting, V. T. de Almeida, and Z. Ding. Modeling and querying moving objects in networks.VLDB ournal, 2005. To appear. Also available as Technical Report 308, Fernuniversitat Hagen, Fachbereich Informatik at http://www.informatik.fernuni-hagen.de/import/pi4/papers/PaperMon.pdf. [10] FLEET to Industrial Design, Arsenal Research, 2005.