Hovering Data Cloud

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Essen
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Prof._Dr._Uwe_Kern
Typ: Fallstudienarbeit
Themengebiet: Connected Cars
Autor(en): Jens Rosemann und Theresa Daab
Studienzeitmodell: Abendstudium
Semesterbezeichnung:
Studiensemester: 2
Bearbeitungsstatus: begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis

1 Abkürzungsverzeichnis

AbkürzungBedeutung
BIPBruttoinlandsprodukt
C2I-CommunicationCar-to-Infrastructure-Communication
C2C-CommunicationCar-to-Car-Communication
C2CCCCar-to-Car-Communication-Consortium
HDCHovering Data Cloud
OICOrganic Information Complex
UMTSUniversal Mobile Telecommunications System
VANETVehicular Ad-Hoc Network
WLANWireless Local Area Network

2 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1Nahbereichskommunikation von/zum Fahrzeug
2Maut-Abrechnungssystem in Deutschland
3Beispiel einer On-Board-Unit
4Global Positioning System
5UMTS Netzabdeckung
6Fahrzeugkolonne
7Kollision ohne C2C Communication
8Kollision der Fahrzeuge mit C2C Communication
9Hovering Data Cloud signalisiert das Stauend
10Entwicklung der Verkehrleistung vom Jahr 2004 zum Jahr 2010
11Ursachen für Stau
12Meldung mit HDC, dass die Ampel rot wird
13Meldung mit HDC, dass wie lange die Ampel noch rot ist
14Speicherung von Informationen in eine HDC mittels lokalen Sensor
15Weiterleitung der HDC
16Verifizierung des Stauendes mittel HDC
17Überleben der HDC durch Zwischenspeicherung
18OFDM
19Hinweis auf ein Unfall mit Polizei
20Hinweis auf ein Stauende
21Funktionsweise von AutoCast
22Organic Information Complex im Zusammenhang mit Hovering Data Cloud
23Aggregation von Daten mittels Organic Information Complexes
24Fahrtzeit ermitteln mit Hilfe von Organic Information Complexes

3 Tabellenverzeichnis

Tab.-Nr.Tabelle
1Zurückgelegte Distanz zweier Fahrzeuge

4 Einleitung

Wissenschaftliche Untersuchungen des Stau- und Verkehrsforschers Michael Schreckenberger der Universität Duisburg-Essen ergaben, dass die Bürger zusammengerechnet 195.275.000[1]Tage pro Jahr im Stau stehen. Das ergibt auf einen Bundesbürger gerechnet ca. 2,4[1]Tage im Jahr, die mit Warten im Stau verbracht werden. Auch die Unfallstatistiken zeigen hohe Zahlen, denn insgesamt gab es 2.301.547[2] Unfälle im Jahr 2009 bei denen 4.154[2] Menschen starben.

Kommunikationsnetze zwischen den Fahrzeugen sollen diese Unfall- und Stauzahlen verringern. Dabei sollen Warnungen über Gefahrensituation z.B. ein hinter der Kurve liegengebliebenes Fahrzeug mit Hilfe von Sensoren an nachfolgende Fahrzeuge übermittelt werden. Aber auch die Kommunikation mit Infrastrukturen z.B. einen Stopp-Schild soll die Sicherheit im Autoverkehr erhöhen.

Um diese Ideen umzusetzen, haben sich die Firmen Audi, BMW, DaimlerChrysler und Volkswagen im Jahr 2002 zu einem Car-to-Car-Communication-Consortium (kurz: C2CCC) zusammengeschlossen[3]. Ein von dem C2CCC entwickelter Standard für die Kommunikation zwischen Fahrzeugen und Infrastruktur soll die Technologie jedem Verbraucher zugänglich machen.

Aus der Grundidee der Kommunikation zwischen Autos entwickelte die Universität Lübeck das System der Hovering Data Cloud. Dieses dient u.a. der Verringerung von Staus auf Autobahnen und der Weitergabe von Informationen über die Infrastruktur z.B. die Schaltungsphase einer Ampel an die Verkehrsteilnehmer. Es stellt sich die Frage wie die genannten Systeme zur Unfall- und Stauverringerung beitragen und welche Technologie die Systeme verwenden.

Zur Beantwortung dieser Fragen werden zu Beginn die Kommunikation zwischen Fahrzeugen und die eingesetzten Technologien erläutert. Darauf folgend werden anhand einer Beispielsituation die Vorteile der Kommunikation zwischen Autos zur Vermeidung von Unfällen beschrieben. Nach der Beschreibung der eingesetzten Technologien und Protokolle der Hovering Data Cloud, wird an zwei Anwendungsbeispielen die Funktionsweise dargestellt. Die aus diesem Verfahren entstehende Organic Information Complexes wird nachfolgend erläutert. Dieses Verfahren verbessert die Verarbeitung der Informationen über den Stau. Ein weiterer Vorteil der Organic Information Complexes wird anschließend anhand des Anwendungsbeispiels der Routenplanung aufgezeigt. In der abschließenden Zusammenfassung wird ein Fazit gezogen und die zukünftigen Entwicklungen der Verfahren beschrieben.

5 Grundlagen der Fahrzeugbezogenen Kommunikation

Mit dem Begriff der Fahrzeugbezogenen Kommunikation ist die Datenverarbeitung und der Informationsaustausch von und zum Fahrzeug gemeint[4].
Abbildung 1: Nahbereichskommunikation von/zum Fahrzeug
Abbildung 1: Nahbereichskommunikation von/zum Fahrzeug[5]

Die Fahrzeugbezogene Kommunikation lässt sich in zwei Formen unterteilen:

  1. Die Kommunikation findet in einer Infrastruktureinrichtung (z.B. Ampel, Straßenschild etc.) seine Quelle oder sein Ziel. Dies wird als Fahrzeug-zu-Infrastruktur-Kommunikation (englisch: Car-to-Infrastructure-Communication - kurz: C2I-Communication) bezeichnet[6].
  2. Ein Fahrzeug ist die Quelle oder das Ziel der Kommunikation. Diese Form wird als Fahrzeug-zu-Fahrzeug Kommunikation (englisch: car-to-car Communication – kurz: C2C-Communication) deklariert[7] .

In Abbildung 1 ist zu sehen, dass die beiden Formen der Kommunikation in Verkehrssituation miteinander agieren. Die Ampel ist in dieser Situation der Auslöser der Kommunikation. Durch die Fahrzeug-zu-Infrastruktur Kommunikation wird dem Fahrzeug gemeldet, dass die Ampel rot ist. Das Fahrzeug bremst und meldet diesen Warnhinweis mittels Fahrzeug-zu-Fahrzeug Kommunikation an die dahinterliegenden Fahrzeuge. Der Fahrer des letzten Fahrzeugs kann die Ampel nicht sehen, da der LKW die Sicht verdeckt. Trotz dieser Gegebenheit konnte das rechte Fahrzeug auf Grund der C2C-Communication und C2I-Communication frühzeitig bremsen.

5.1 Kooperative Gruppen

Bei der Fahrzeug-zu-Fahrzeug Kommunikation handelt es sich um ein selbst organisiertes und kommunizierendes Netz, das Gefahren automatisch reflektiert und diese Warnnachrichten weiterleitet.[8] Um Verhaltensentscheidungen beim Aushandeln gemeinsamer Fahrmanöver treffen zu können, wird ein top-down-Ansatz gewählt. Dies bedeutet, dass zunächst kooperative Gruppen von Fahrzeugen gebildet werden. Anschließend wird ein Lageplan in jeder Gruppe erstellt, der alle Objekte und deren Lage in der Gruppe abbildet und als Basis der Situationserkennung sowie Verhaltensentscheidung dient.

Bei der Gruppeneinteilung sind zwei Aspekte zu beachten.

  • Die Komplexität und somit die Schwierigkeit bei der Erkennung der Situation steigt, je größer die Gruppe ist. Dies führt zu einer erschwerten Entscheidungsfindung. Daher ist die Wahl einer geeigneten Gruppengröße von Nöten.
  • Es ist sinnvoll, Fahrzeuge, die ein gemeinsames Fahrmanöver absolvieren, in eine Gruppe einzuordnen. Dadurch wird ein sinnvolles Verhalten in der speziellen Situation möglich.

Mit Hilfe eines Bildungskriteriums lassen sich Gruppen bilden, die diese zwei Aspekte beinhalten.[9] Die genaue Berechnung dieses Kriterium wird in der Hausarbeit nicht behandelt. Grob lässt sich sagen, dass als Grundlage der Berechnung die Abstände zwischen den einzelnen Fahrzeugen und eine festgelegte Bewertungsfunktion für kooperative Gruppen dienen.

5.2 Technologien

5.2.1 Drahtlose Kommunikation

Abbildung 2: Maut-Abrechnungssystem in Deutschland
Abbildung 2: Maut-Abrechnungssystem in Deutschland[10]

Im Bereich der drahtlosen Kommunikation gibt es viele verschiedene Techniken. Von Klassikern wie einfache Funkverbindungen und Infrarot bis hin zu modernen Techniken wie Bluetooth oder WLAN muss im Bereich der C2X-Communication jedes Mittel geprüft werden. Jedoch lassen sich schnell einige der Kandidaten ausschließen.
Der klassische Funk beschreibt das einfache „analoge“ Funken. Hier werden keine komplexen Informationen übertragen, die für die C2X-Communication wichtig sind. Nur ein einfaches Sprachsignal wird übermittelt. GPS Informationen, Entfernungen oder auch Geschwindigkeiten werden nicht übermittelt.
Infrarot benötigt einen konstanten Sichtkontakt der beiden Übertragungspartner.[11] Durch große und kleine Unebenheiten und optische Hindernisse ist dieser Kontakt im normalen Straßenverkehr nicht zu gewährleisten. Außerdem können per Infrarot lediglich zwei Fahrzeuge miteinander kommunizieren. Eine schnelle Verbreitung z.B. eines Notfallsignals ist damit ausgeschlossen, da zu jedem Fahrzeug in der Nähe eine separate Verbindung aufgebaut werden müsste. An einem Auto müssten folglich viele Sensoren verteilt sein, damit in alle Richtungen mit mehreren Fahrzeugen kommuniziert werden könnte.
Bluetooth eignet sich nicht, da es nur über eine geringe Reichweite verfügt. Ohne besondere Verstärker liegt die Reichweite bei maximal 100 Metern und wird bereits durch Wände oder ähnliche Hindernisse stark eingeschränkt.[12]
Im Bereich des WLAN (engl. wireless local area network = drahtloses lokales Netzwerk) ist diese Analyse deutlich schwieriger, da es mehrere Standards gibt, die sich für unterschiedliche Anwendungsgebiete eignen.
Der älteste Standard 802.11 bietet nur eine recht geringe Übertragungsleistung von 2 Mbits/s.[13] Die erweiterten Standards 802.11b und 802.11g der IEEE (Institute of Electrical and Electronics Engineers) nutzen eine Funkfrequenz von 2,4 GHZ und bieten eine höhere Übertragungsgeschwindigkeit von 54 Mbits/s[14], haben jedoch genau wie der Standard 802.11 das Problem, dass die tatsächliche Geschwindigkeit durch viel Protokoll-Overhead deutlich geringer ist.[13] Ebenso sinkt die Datenübertragungsrate durch Hindernisse und Geräte, die mit unterschiedlichen Standards senden.
Der neuere Standard 802.11n, ebenfalls vom IEEE, kann auf einem höheren Frequenzband von 5 GHz funken und bietet durch einige technische Unterschiede eine deutlich höhere Übertragungsrate als die älteren Standards.[15] Theoretisch sind bis zu 600 Mbit/s möglich und erlauben so eine sehr schnelle Übertragung von wichtigen Signalen, die alle relevanten Informationen enthalten.

Abbildung 3: Beispiel einer On-Board-Unit
Abbildung 3: Beispiel einer On-Board-Unit[16]

Diese Standards sind jedoch für den Einsatz in C2X-Communication nicht uneingeschränkt geeignet. Übertragungsdistanzen von bis zu einem Kilometer müssen überbrückt werden; vor allem deutsche Autobahnen ohne Geschwindigkeitsbegrenzungen machen es erforderlich, dass das System auch bei Geschwindigkeiten von bis zu 250 km/h funktionieren muss. Daher muss die zentralisierte Struktur von den WLAN-Techniken umgestellt werden.[17] Gewöhnlicherweise gibt es einen zentralen Punkt, einen Router oder einen Access-Point, der die eingehenden Verbindungen verwaltet und weiterleitet. Bei einer Geschwindigkeit von 250 km/h bleibt auf einer Autobahn jedoch keine Zeit zu entscheiden, welches System nun die Rolle des Routers / Access-Points übernimmt. Die Organisation und Reorganisation der Netzwerkstruktur ist hier ein erhebliches Problem[18], welches vor allem bei hohen Geschwindigkeiten auftritt, da die Zeitfenster für die Kommunikation sehr klein sind.
Der Standard 802.11p, genannt Wireless Access for the Vehicular Environment (abgekürzt: WAVE, steht für „drahtloser Zugang für die Fahrzeugumgebung“), wurde von der IEEE aufgesetzt, um einige dieser Probleme zu lösen. Durch die Erhöhung der Funkfrequenz auf 5,9 GHz wird 802.11p nicht durch andere WLANs gestört.[19] Besonders bei Maut-Abrechnungssystemen, mit so genannten On-Board-Units (OBU), findet dieser Standard Anwendung. Die OBU, siehe Abbildung 2, kommuniziert mit den Mautstellen auf der Autobahn und sorgt so für die Basis einer korrekten Abrechnung der Mautgebühren, ohne, dass das Fahrzeug dafür extra halten muss. Ob sich das Fahrzeug dabei auf einer mautpflichtigen Straße bewegt, wird per GPS festgestellt. Alle relevanten Daten werden digital festgehalten und an die Mautzentrale gesandt. Dort findet die Abrechnung statt und wird an das Unternehmen weitergeleitet.

5.2.2 Global Positioning System

Abbildung 4: Global Positioning System
Abbildung 4: Global Positioning System[20]

Das Global Positioning System (kurz: GPS, Globales Positionsbestimmungssystem) ermöglicht die exakte Bestimmung der aktuellen Position eines GPS-fähigen Systems auf der Erde. Entwickelt wurde es Anfang der 70er Jahre vom Department of Defense (DoD, amerikanisches Verteidigungsministerium) der USA als militärisches System, ist aber inzwischen auch von der Zivilbevölkerung nutzbar. Rund um den Globus sind mindestens 24 Satelliten so verteilt, dass von jedem Ort auf der Welt zwischen 4 und 10 Satelliten „sichtbar“ sind.[21]
Denn bereits mit vier Satelliten kann eine exakte Bestimmung der Position auf dem Globus erfolgen, wie in Abbildung 4 zu sehen ist. Das Bodengerät, also z.B. das Navigationsgerät im Auto, verbindet sich zunächst mit drei Satelliten zur Bestimmung der Position auf Längen- und Breitengrad. Ein weiterer Satellit dient zum Zeitabgleich der Satelliten und des Bodengeräts, da alle Satelliten die Positionsänderung innerhalb einer gewissen Zeitspanne in ihre Berechnung einbeziehen. Gleichzeitig messen die Satelliten anhand von fixen Kontrollpunkten die aktuelle Abweichung, in der Abbildung als Delta bezeichnet. Von diesen Messpunkten sind die Positionsinformationen bekannt und es wird mit dem gemessen Wert verglichen. Diese Abweichung zwischen gemessenen Wert und dem fixen Wert des Kontrollpunkts ergibt die aktuelle Abweichung von Messungen in der Konstellation von Satelliten. Die aktuelle Position des Bodengeräts wird nun mit der gemessenen Abweichung verrechnet und ergibt die tatsächliche Position des Bodengeräts auf der Erde.
Mit diesem System kann genau bestimmt werden, wo die Sensoren eines Autos z.B. einen Unfall aufzeichnen. Diese Information kann dann in der C2X-Communication weitergegeben werden und nachfolgende Fahrzeuge werden vor dem Hindernis gewarnt oder können eine alternative Route berechnen. Ebenso könnten die Informationen in die Infrastruktur eingespeist werden, um die Information z.B. Rettungskräften oder der Polizei zur Verfügung zu stellen. So könnten Einsatzorte genau bestimmt werden und die Einsatzkräfte wären in der Lage die Gefahrenstelle direkt anzusteuern. Ebenso könnten Staus direkt in ein globales Kommunikationsnetz, z.B. das Internet, eingespeist werden und in jedem Navigationsgerät verarbeitet werden.

5.2.3 UMTS

Abbildung 5: UMTS Netzabdeckung
Abbildung 5: UMTS Netzabdeckung[22]

In einem Teilprojekt des Projekts FleetNet, einer Gemeinschaftsarbeit der Universität Hannover und der Firma Siemens, wurde versucht die Begrenzungen, die der 802.11p WAVE Standard mit sich bringt, zu umgehen. Wie bereits zuvor erläutert sind die relativ hohen Geschwindigkeiten, vor allem auf deutschen Autobahnen, und die Organisation und Reorganisation der Netzwerkstruktur ein großes Problem der WLAN Technik. Trotz aller Anpassungen des 802.11p Standards ist diese WLAN Technik jedoch weiter von deren Problemen betroffen.
Daher wurde in dem Teilprojekt die Benutzung von UTRA TDD untersucht. UTRA TDD steht für UMTS Terrestrial Radio Access Time Duplex Division. UMTS (Universal Mobile Telecommunications System, universelles mobiles Telekommunikationssystem) ist eine Technik, mit der mobilen Geräten, vor allem Handys und Laptops, der Zugang zum Internet ermöglicht wird. Der Zusatz Terrestrial Radio Access bedeutet "terrestrischer Funk-Zugang", also der Zugang zu dem System durch Funk von der Erdoberfläche aus.
TDD steht für Time Duplex Division und beschreibt eines von zwei Verfahren der Verbindungsherstellung mit UMTS.[23] Das andere Verfahren heißt Frequency Division Duplex (abgekürzt: FDD).[24] Bei dem FDD-Verfahren senden Basisstation und Mobilgerät in zwei unterschiedlichen Frequenzbändern für Up- und Downlink. Die beiden Kanäle werden jeweils über CDMA (Code Division Multiple Access) realisiert. CDMA ist ein Verfahren mit dem mehrere Geräte gleichzeitig auf einem Frequenzband senden und empfangen können.[25] Das Signal wird verbreitet und es wird ein Code benötigt, um die Informationen aus dem empfangenen Signal herauszufiltern.
Bei TDD kommunizieren Sender und Empfänger nicht auf unterschiedlichen Frequenzen sondern zu unterschiedlichen Zeiten. Dazu wird die Übertragung in unterschiedliche Timeslots (= Zeitscheiben) eingeteilt. Problem können auftreten, wenn diese Timeslots nicht genau eingehalten werden.[23]
Die Forschung mit UMTS in der Fahrzeugkommunikation befindet sich noch in einem frühen Stadium. Einigen Problemen, die die Nutzung von WLAN mit sich bringt, kann begegnet werden bzw. treten diese nicht auf. Jedoch bringt UMTS auch eigene Probleme mit sich. UMTS ist nicht überall auf der Welt verfügbar. Zudem ist die Verbindung z.B. aus einem Tunnel nicht möglich. Dies stellt das größte Problem da. Alleine in Deutschland ist, wie in Abbildung 5 dargestellt, die Netzabdeckung mit UMTS nicht vollständig. Jedoch bietet UMTS den Vorteil, dass ein Fahrzeug mit Empfang vollen Zugriff auf das Internet hat und somit noch weitere Informationen zur Verfügung hat.

6 Unfallvermeidung durch C2C Communication

Im Jahr 2009 wurden insgesamt 169.795[26][27] Unfälle registriert. Unfallursache ist hierbei das Auffahren auf ein anderes Fahrzeug. Bei diesen Auffahrunfällen starben 1.140[26][27] Personen. Im nachfolgenden Kapitel wird beschrieben, wie Fahrzeug-zu-Fahrzeug-Kommunikation Auffahrunfällen verhindern kann.

6.1 Ausgangssituation

Abbildung 6: Fahrzeugkolonne
Abbildung 6: Fahrzeugkolonne[28]

Um zu zeigen, wie Fahrzeug-zu-Fahrzeug-Kommunikation Auffahrunfälle verhindern kann, wird je Fahrzeug ein Kurvenverlauf in einem Funktionsgraph abgebildet. Der Kurvenverlauf ergibt sich aus der verstrichenen Zeit und den gefahrenden Metern.

In der Beispielsituation fahren drei Fahrzeuge auf einer Fahrbahn in die gleiche Richtung. Jedes Fahrzeug hält einen Abstand von 32 m zu dem vorausfahrenden Fahrzeug ein. Die Geschwindigkeit jedes Fahrzeugs beträgt 115,2 km/h. Somit bewegt sich jedes Auto in einer Sekunde 32 Meter. Bei der Abbremsung bewegt sich jedes Fahrzeug pro Sekunden vier Meter vorwärts. In Abbildung 6 wird das Ausgangsszenario für die nachfolgenden Funktionsgraphen illustriert. Das erste Auto in der Kolonne fährt auf ein Hindernis, z.B. ein stehendes Fahrzeug zu.

6.2 Unfallsituation ohne C2C Communication

Abbildung 7: Kollision ohne C2C Communication
Abbildung 7: Kollision ohne C2C Communication[28]

In Abbildung 7 sind die Funktionskurven der drei Fahrzeuge abgebildet, wenn keine Fahrzeug-zu-Fahrzeug-Kommunikation eingesetzt wird.

Der Autofahrer mit dem Fahrzeug 0 befindet sich vorne in der Autokolonne. Dieser sieht das Hindernis auf der Fahrbahn, dass sich in 120 m Entfernung von ihm befindet. Nach der Reaktionszeit von 1,5 Sekunden bremst der Fahrzeugfahrer. Der Fahrer mit dem Fahrzeug 1 nimmt die Bremsleuchten von dem vorausfahrenden Fahrzeug 0 war und bremst nach der Reaktionszeit von 1,5 Sekunden. In dieser Zeit ist das Fahrzeug weitere 48 Meter gefahren, da die Geschwindigkeit 32 Meter pro Sekunde beträgt. Somit befindet sich dieser Autofahrer genau 72 Meter vor dem Hindernis. Da die Verlangsamung 4 Meter pro Sekunden beträgt, findet der Aufprall des Autos 1 auf das Auto 0, 18 Sekunden nach dem Betätigen der Bremse statt. Der Fahrzeugfahrer des Fahrzeugs 2 verringert nach der Reaktionszeit seine Geschwindigkeit entsprechend des Autofahrers 1. Auch dieses Fahrzeug bewegt sich bei dem Bremsvorgang 4 Meter pro Sekunde vorwärts.

Es kommt schließlich zur Kollision der drei Fahrzeuge, da die Autofahrer ausschließlich auf visuelle Informationen reagieren. Der Fahrzeugfahrer 2 kann ohne Fahrzeug-zu-Fahrzeug Kommunikation nicht erkennen, dass der Fahrzeugfahrer 0 ein Hindernis wahrgenommen hat und aus diesem Grund bremst. Der Autofahrer erfährt die Information über Umwegen durch das Fahrzeug Nr. 1. Dies bedeutet, dass der Fahrzeugfahrer 2 erst nach der Reaktionszeit von Fahrzeugfahrer 1 und nach der eigenen Reaktionszeit die Geschwindigkeit verringern kann.

6.3 Unfallsituation mit C2C Communication

Abbildung 8: Kollision der Fahrzeuge mit C2C Communication
Abbildung 8: Kollision der Fahrzeuge mit C2C Communication[29]

Bei geringem Abstand zwischen den Fahrzeugen ist ein Auffahrunfall ohne Fahrzeug-zu-Fahrzeug-Kommunikation unumgänglich. Abbildung 8 zeigt, dass mit Hilfe einer Kommunikation zwischen den Fahrzeugen die Fahrzeugführer in der gleichen Ausgangssituation ein Auffahrunfall von dem Fahrzeug Nr. 2 verhindert werden kann.

Anders als bei der zuvor beschriebenen Situation sendet das Fahrzeug 0, nachdem der Autofahrer gebremst hat einen Hinweis mit Hilfe der C2C-Communication an die nachfolgenden Fahrzeuge. Dadurch bekommt das Fahrzeug 2 bei einem Wireless mit einer Wartezeit von 0,1 Sekunden bereits nach 0,1 Sekunden, entsprechend bei einem Wireless mit einer Wartezeit von 0,4 Sekunden nach 0,4 Sekunden die Informationen, dass das Fahrzeug 0 gebremst hat. Nach der Reaktionszeit von 1,5 Sekunden verringert das Fahrzeug 2 seine Geschwindigkeit. In dem Funktionsverlauf ist zu sehen, dass die Wartezeit von 0,4 Sekunden bei dem Wireless zu lang ist. Daher findet trotz C2C Communication ein Zusammenstoß der drei Fahrzeuge statt. Mit dem schnelleren Wireless von 0,1 Sekunden bremst das Fahrzeug 2 bereits nach 1,6 Sekunden, nachdem der Fahrer mit der Nummer 0 die Bremse bedient hat. Ohne Fahrzeug-zu-Fahrzeug-Kommunikation konnte das Fahrzeug 2 erst nach 3 Sekunden die Geschwindigkeit verringern. Der Funktionsverlauf zeigt, dass das Fahrzeug 2 bei einem Wireless mit einer Wartezeit von 0,1 Sekunden 5 Meter vor dem Hindernis zum stehen kommt.

Dieser Versuch zeigt, dass die Fahrzeug-zu-Fahrzeug-Kommunikation die Zahl von Auffahrunfällen verringert und somit zur Sicherheit im Straßenverkehr beiträgt.

7 Hovering Data Cloud

Das Institut für Telematik der Universität zu Lübeck und das Institut für Betriebssysteme und Rechnerverbund der TU Braunschweig entwickeln in dem Projekt „AutoNomos“ Systeme, die die Stauerkennung und Meldung auf Autobahnen beschleunigen. Diese Systeme arbeiten auf der Grundlage der Fahrzeug-zu-Fahrzeug-Kommunikation. Durch das Austauschen, Aufnehmen und Weitergeben der Informationen an andere Verkehrsteilnehmer wird die Datenerfassung schneller, als bei den heutzutage fest installierten Systemen.[30]

Das Problem bei der in Kapitel 6 beschriebenen Weitergabe der Verkehrsinformationen besteht darin, dass die Verkehrssituationen (z.B. ein Unfall) ortsfest bleibt. Die Fahrzeuge, die Träger der Information, bewegen sich jedoch. Dadurch wechseln die Datenstrukturen, die Informationen zu der aufgetretenen Verkehrssituation enthalten, ständig ihren Gastrechner.[31]
Abbildung 9: Hovering Data Cloud signalisiert das Stauende.
Abbildung 9: Hovering Data Cloud signalisiert das Stauende.[32]

Die Lösung ist das von den Universitäten entwickelte Verfahren der Hovering Data Cloud. Hovering Data Cloud (kurz: HDC), zu deutsch schwebende Datenwolke, beschreibt einen dynamischen Verkehrsbericht[33]. Dieser ist an die Situation gebunden[31]. Die Datenwolke beinhaltet von allen Fahrzeugen, die sich in einem bestimmten Radius von dem Ausgangspunkt der HDC befinden, die beteiligten Daten[34].

Es gibt zwei Arten von HDC. Zum einen die statische Hovering Data Cloud, die an einen festen Punkt gebunden ist. Zum anderen die dynamische, die eine zum Ort veränderliche Position misst.[35] Die statische HDC wird in Kapitel 7.2 am dem Anwendungsbeispiel einer Ampel erläutert. Die dynamische HDC wird z.B. bei Staus angewendet. Hierbei wird das Ende des Staus gemessen (siehe Abbildung 9). Diese Arbeitsweise wird in Kapitel 7.3 beschrieben.


7.1 Beweggründe für die Entwicklung

Abbildung 10: Entwicklung der Verkehrsleistung vom Jahr 2004 zum Jahr 2010
Abbildung 10: Entwicklung der Verkehrsleistung vom Jahr 2004 zum Jahr 2010

Im motorisierten Individualverkehr ist ein Zuwachs von 887,4[36]Mrd. Pkm im Jahr 2004 auf 1029,7[36] Mrd. Pkm im Jahr 2010 zu erwarten. Dies bedeutet einen Zuwachs von 16,03 %. Der Anstieg der Verkehrsleistung spiegelt sich in den Kosten, die durch Stau entstehen, wieder. Laut der Studien des EU-Weißbuchs beliefen sich die Kosten im Jahr 2001 auf 0,5%[37] des Bruttoinlandsproduktes, dies bedeute für Deutschland 21 Mrd. Euro[37]. Im Jahr 2010 steigen diese auf 1%[37] des BIP an.

Abbildung 11: Ursachen für Stau
Abbildung 11: Ursachen für Stau[38]

Die Bildung von Staus auf Autobahnen hat mehrere Ursachen. Zum einen gibt es keine zentral steuerende Instanz. Dadurch fährt jeder Verkehrsteilnehmer seinen persönlichen Fahrstil. Ein weiterer Grund ist die ungenutzte Kapazität der Autobahn. Es ist zu beobachten, dass die rechte Fahrspur von LKWs mit großem Abstand zueinander befahren wird. Wohingegen auf der Überholspur viele PKWs mit geringem Abstand fahren. Dies ist damit begründet, dass die Fahrer der PKWs nicht in die Lücken zwischen den LKWs fahren, da sie bezweifeln wieder auf die linke Spur gelassen zu werden. Weitere Gründe sind Baustellen oder Unfälle auf der Fahrbahn. Die hohe Verkehrsdichte spielt bei diesen genannten Ursachen eine wichtige Rolle. In Abbildung 11 sind die Ursachen von Stau prozentual abgebildet.

Die Einführung und Entwicklung einer Technologie zur Stauverhinderung bzw. -minimierung ist aufgrund der hohen Kosten notwendig. Daher entwickelten Universitäten das Verfahren der Hovering Data Cloud, das eine Lösung des Stauproblems verspricht. Aber nicht nur die Stauvermeidung war ein Auslöser der Entwicklung, sondern auch die allgemeine Verbesserung des Straßenverkehrs. So soll die HDC zur Sicherheit im Verkehr und zur Verringerung des Schadstoffausstoßes beitragen.

7.2 Statische HDC

Abbildung 12: Meldung mit HDC, dass die Ampel rot wird
Abbildung 12: Meldung mit HDC, dass die Ampel rot wird[39]
Abbildung 13: Meldung mit HDC, dass wie lange die Ampel noch rot ist
Abbildung 13: Meldung mit HDC, dass wie lange die Ampel noch rot ist[39]

Die Statische Hovering Data Cloud ist an einen Ort gebunden. Die Funktionsweise wird anhand einer Ampel veranschaulicht. In der Datenwolke sind die zukünftigen Schaltphasen, die Kennungen des ein- und ausgehenden Streckenabschnitts und der Umschaltzeitpunkt der Ampel gespeichert[40]. Bei jedem Phasenwechsel werden die Daten in der HDC aktualisiert und in einem fest vorgeschriebenen Radius um die Ampel herum mit dem Protokoll AutoCast verteilt. Somit entspricht die Lebenszeit der HDC in diesem Anwendungsbeispiel der Dauer der Ampelphase.

In Abbildung 12 können die Fahrzeugfahrer aufgrund der Informationen in der Hovering Data Cloud erkennen, dass die nächste Schaltphase in 12 Sekunden stattfindet. Die Fahrer können dadurch ihre Fahrweise anpassen, indem sie die Geschwindigkeit verringern. Auf dieser Weise wird der Verkehrsfluss positiv beeinflusst. Die Fahrzeugfahrer sind auf die Ampelschaltung vorbereitet und müssen daher nicht plötzlich bremsen. Zusätzlich wird das Fahren über eine rote Ampel vermieden, da die Autofahrer mit Hilfe einer auffälligen Informationsanzeige über die Schaltphase informiert werden.

Die Einsparung von Treibstoff mit Hilfe von Hovering Data Cloud wird in Abbildung 13 illustriert. Fahrzeuge, die vor einer roten Ampel stehen, erhalten über die HDC Informationen über die Dauer der aktuellen Ampelphase. Dadurch kann der Autofahrer entscheiden, ob sich das Abschalten des Motors lohnt. Infolgedessen wird der Schadstoffausstoß der Fahrzeuge durch die Verwendung der HDC verringert.

7.3 Dynamische HDC

Im Gegensatz zur statischen Hovering Data Cloud ist die dynamische HDC nicht an einem festen Punkt gebunden, sondern an einen veränderlichen Ort. Die Arbeitsweise einer dynamischen HDC wird nachfolgend anhand eines Staus beschrieben, da sich Stauanfang und Stauende abhängig von den Fahrzeugen bewegen.

7.3.1 Lebenszyklus

Abbildung 14: Speicherung von Informationen in eine HDC mittels lokalen Sensor
Abbildung 14: Speicherung von Informationen in eine HDC mittels lokalen Sensor[41]
Abbildung 15: Weiterleitung der HDC
Abbildung 15: Weiterleitung der HDC[41]
Abbildung 16: Verifizierung des Stauendes mittel HDC
Abbildung 16: Verifizierung des Stauendes mittel HDC[41]

Der Lebenszyklus einer Hovering Data Cloud wird anhand eines auftretenden beschädigten Fahrzeugs auf einer befahrenen Autobahn erläutert.

In der Abbildung 14 ist zu sehen, dass das Fahrzeug zunächst mit Hilfe eines lokalen Sensors das beschädigte Fahrzeug auf der Fahrbahn erkennt. Das Fahrzeug legt die genaue Position der Gefahrenstellen in eine Hovering Data Cloud ab. Anschließend wird der Inhalt der HDC als Broadcast-Nachricht über AutoCast gesendet,[41] da diese ein Datenpaket darstellt, dass an alle Knoten in einem Netzwerk übermittelt wird.[42]

Nachdem die Datenwolke erzeugt, mit Informationen gefüllt und weiter geleitet wurde, werten alle benachbarten Fahrzeuge die Informationen aus. Abbildung 15 zeigt, dass die Datenpakete zunächst lokal von jedem Fahrzeug gespeichert werden, da die Hovering Data Cloud für sie unbekannt ist. Auf diese Weise verbreitet sich die Datenwolke. Ein Fahrzeug, das sich der Situation nähert und auf Grund des Staus bremst, erfasst die Datenwolke und überprüft deren Inhalte mit der eigenen Position. Wenn diese korreliert, wird die lokal erfasste und somit aktuelle Position in die Datenwolke integriert. Somit wird der Messwert des Stauendes immer wieder aktualisiert. Bei Änderungen der Daten in der Hovering Data Cloud wird diese als Broadcast-Nachricht an alle benachbarten Fahrzeuge gesendet. Die anderen Fahrzeuge vergleichen die Messdaten mit ihrer Position und integrieren diese gegebenenfalls.[41]

Bei einem Stau wie in Abbildung 16 dargestellt, gibt es sowohl eine Hovering Data Cloud die Daten des Stauendes und eine die Messdaten des Stauanfang erfasst und aktualisiert.

7.3.2 Zwischenspeicherung in Datenelementen

Die Hovering Data Cloud ist an die Situation gebunden. Die Fahrzeuge die die HDC gespeichert haben bewegen sich. Dabei stellt sich die Frage, was mit den Daten passiert, wenn ein Fahrzeug den Bereich der Datenwolke verlässt. Es können zwei Situationen auftreten:

  1. Es gibt ein anderes Fahrzeug in dem Bereich der HDC.
  2. Das Fahrzeug befindet sich alleine in der HDC.

Sendet ein Fahrzeug Daten zu der HDC das sich näher an der Entstehungsquelle der HDC befindet als das Fahrzeug, dass den Bereich der HDC verlässt, wird die erste beschrieben Situation erkannt. Das Fahrzeug, das aus den Bereich der Datenwolke fährt, weiß nun, dass das Bestehen der HDC durch ein anderes Fahrzeug gesichert ist. Daher löscht das Fahrzeug die HDC lokal aus dem Speicher.

Abbildung 17: Überleben der HDC durch Zwischenspeicherung
Abbildung 17: Überleben der HDC durch Zwischenspeicherung[43]

Die andere Situation wird erkennbar, wenn das Fahrzeug keine Nachricht von einem anderen Fahrzeug über die betreffende HDC empfangen hat. Damit die HDC weiter bestehen kann, wird eine Weitergabe der Daten an den Gegenverkehr durchgeführt. Abbildung 17 veranschaulicht dieses Verfahren. Die Daten werden mit Hilfe des AutoCast-Protokolls weiter geleitet. Der Gegenverkehr dient als Art Zwischenspeicher, da dieser die Daten aus der HDC in dem lokalen Speicher festhält. Anschließend werden die Daten wieder an die Fahrzeuge auf der anderen Straßenseite weitergegeben. Durch diese Weitergabe wird die Hovering Data Cloud am Datenursprung gehalten und ihr Bestehen gesichert.[43]

7.3.3 Kontrollierte Verteilung von Daten

Bei der in Punkt 7.3.1 erläuterten interne Kommunikation hat jedes Fahrzeug die Möglichkeit die Daten in der Hovering Data Cloud auszulesen und zu verändern.

Abgesehen davon gibt es Warnmeldungen, bei der die Aufbereitung der Daten ausschließlich der Sender dieser Warnmeldung vornimmt. Warnmeldungen z.B. eine Meldung über ein Gegenstand auf der Fahrbahn, werden unverändert in einen bestimmten Umkreis an alle Fahrzeuge übertragen. Um ein unkontrolliertes Erstellen solcher Meldungen zu verhindern, ist ein Abstimmungsprozess notwendig. Neue Meldungen werden nur von Fahrzeugen generiert, die als letztes Daten in die Hovering Data Cloud abgelegt haben. Bevor jedoch eine Meldung von einem Fahrzeug erstellt wird, sendet dieses per Broadcast einen Flag. Dieser dient als Hinweis, der auf die bevorstehende Erstellung einer Warnmeldung aufmerksam macht. Der Flag spiegelt somit den Status der HDC wieder. Wenn nach einer begrenzten Zeit keine neuer Status empfangen wird, so kann das Fahrzeug die Warnmeldung erstellen. Zusätzlich wird der Sendezeitpunkt in der Hovering Data Cloud abgelegt, damit andere Fahrzeuge die Aktualität der Warnmeldung nachvollziehen können.[44]

7.4 Technologien

7.4.1 802.11p - WAVE

Ziel der Forschung an der Hovering Data Cloud war es, ein Netzwerk zu entwickeln, welches im schnellen Straßenverkehr verlustfrei senden kann und dabei eine hoch dynamische Netzwerkorganisation bzw. Netzwerkreorganisation ermöglicht.

Abbildung 18: OFDM
Abbildung 18: OFDM[45]

Durch die hohen Geschwindigkeiten und die Tatsache, dass die Bewegungsrichtung der Kommunikationspartner oft entgegengesetzt verläuft, musste in der Sendetechnik dem Doppler-Effekt entgegengewirkt werden. Dieser besagt, dass die Wellen eines sich bewegenden Senders vom Empfänger anders wahrgenommen und empfangen werden, wenn sich der Sender bewegt.[46] Dies gilt natürlich auch für das Senden in einem WLAN.
Gegen den Dopplereffekt bzw. allgemeine Störungen wurde in WAVE OFDM (orthogonal frequenz divison multiplex) eingeführt. OFDM bedeutet, wie in Abbildung 18 dargestellt, dass ein langes Signal in mehrere kurze Signale zerlegt wird. Diese kurzen Signale werden auch wiederholt, so dass ein kurzer Ausfall oder eine Störung in der Übertragung nicht den Informationsgehalt gefährden kann.
Wie bereits zu Beginn erläutert, ist es sehr schwer die Netzwerkorganisation für die HDC einzurichten. Von jedem Heimnetzwerk ist bekannt, dass die automatische IP-Adressen-Vergabe per DHCP einige Sekunden dauert. In einem stationären Einsatz zuhause oder im Betrieb ist dies kein Problem. Doch dieses Zeit ist im mobilen Einsatz sehr lange. Im Extremfall ist auf einer Autobahn ein Fahrzeug mit 80 km/h unterwegs, während es von einem Auto mit 250 km/h überholt wird. Geht man von einer effektiven Sendeentfernung von 250 Metern aus, dann müsste innerhalb von ca. 10 Sekunden die komplette Kommunikation abgeschlossen sein. Wie in Tabelle 1 eindeutig zu erkennen ist, ist das Fahrzeug nach 10 Sekunden noch knapp in der Sendereichweite von 250 Metern. Nach 15 Sekunden ist das schnellere Fahrzeug bereits knapp 500 Meter entfernt.

Tabelle 1: Zurückgelegte Distanz zweier Fahrzeuge

Fahrzeug Startpunkt Geschwindigkeit (km/h) Geschwindigkeit (m/s) Zeit (s) Zurückgelegte Entfernung (m) Position (m) Entfernung zwischen 1 und 2 (m)
1 0 250 69,4 10 694 694 222
2 250 80 22,2 10 222 472 222
1 0 250 69,4 15 1041 1041 458
2 250 80 22,2 15 333 583 458

Danach ist die Entfernung bereits zu groß. Daher muss die effektive Sendeleistung mindestens 500 Meter bis 1000 Meter betragen. Ansonsten bleibt wenig Zeit, um eine Netzwerkorganisation durchzuführen und alle Informationen, wie z.B. aktuelle Geschwindigkeit, Geo-Positions-Informationen usw., auszutauschen.
Denn in jedem Netzwerk können Kollisionen zwischen zwei Sendern auftreten.[47] Dies führt zu Verzögerungen, wenn Informationen bzw. Informationsteile nochmals gesendet werden müssen. Ist das Zeitfenster zu klein, werden nur unvollständige Informationen zwischen den Fahrzeugen ausgetauscht. Um diesen Problem entgegenzuwirken ist eine Implementierung von CSMA/CA oder einem anderen kollisionsvorbeugenden Protokoll unabdingbar. CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) bedeutet, dass der Sender vorher überprüft, ob das Sendemedium, z.B. ein Netzwerkkabel, gerade beansprucht wird. Ist dies nicht der Fall, so darf der Sender seine Informationen ins Netzwerk übertragen.[48]
Gelöst werden muss außerdem die Übertragung über die Line-Of-Sight (LOS, Sichtlinie) bzw. die Non-Line-Of-Sight (NLOS, nicht Sichtline). Solange der Übertragungspartner in der Nähe ist und direkt sichtbar ist, sich also in der LOS befindet, ist die Übertragung relativ simpel zu realisieren. Befindet sich der Übertragungspartner aber nicht mehr in der LOS, der sogenannten NLOS, muss die Übertragung über Hops, Sprünge über andere Stationen, stattfinden. Die Informationen, die übertragen werden soll, muss also über andere Fahrzeuge oder Infrastruktur geroutet werden. Wenn hier keine weiteren Fahrzeuge oder Infrastrukturstationen zur Verfügung stehen, kann die Information nicht übertragen werden.

7.4.2 VANET

Abbildung 19: Hinweis auf ein Unfall mit Polizei
Abbildung 19: Hinweis auf ein Unfall mit Polizei[49]

VANET (Vehicular Ad-Hoc Network) beschreibt ganz allgemein die Möglichkeit, dass Fahrzeuge auf der Straße ad-hoc in Kommunikation treten und Informationen austauschen können.
Dabei geht es um zweierlei Arten von Informationen. Zum einen sind dies die Fahrzeug-internen Informationen: Geschwindigkeit, Personenzahl, PS, Füllstand des Tanks, Öldruck, usw. Natürlich sind nicht alle diese Informationen in einem VANET für einen Kommunikationspartner interessant, aber theoretisch könnten diese Informationen in dem VANET kommuniziert werden.
Auf der anderen Seite sind esInformationen, die das Fahrzeug aus anderen Quellen bezieht. Hierbei handelt es sich z.B. um GPS Informationen, Stauinformationen aus dem Internet oder von anderen Fahrzeugen oder auch die geplante Route.[50]

Abbildung 20: Hinweis auf ein Stauende
Abbildung 20: Hinweis auf ein Stauende[51]

In einem VANET können diese Informationen durch den Austausch mit anderen Fahrzeugen zu mehr Sicherheit und auch effizienter Routenplanung beitragen. Wenn Fahrzeug A gerade in einen Stau hineinfährt, kann es diese Informationen mit Fahrzeug B teilen und es so auf den Stau aufmerksam machen. Dieses leitet die Information an Fahrzeug C weiter und das Risiko für einen Auffahrunfall ist deutlich geringer. Dieses Beispiel ist in Abbildung 20 dargestellt. Denkbar wäre auch, dass eine Unfallwarnung über mehrere Fahrzeuge weitergeleitet wird. Wie in Abbildung 19 dargestellt, könnte dann die Polizei, welche versucht zu dem Unfall vorzudringen, eine Anhalteanweisung an die Fahrzeuge, die sich auf dem Streckenabschnitt befinden, damit diese anhalten bzw. aus dem Weg fahren. Dieser Anhalteanweisung könnte sich dann ebenfalls durch das VANET schnell verbreiten und an die anderen Fahrzeuge weitergeleitet werden. So werden diese frühzeitig informiert und optimalerweise muss die Polizei dann nicht anhalten und kann so schneller zum Unfallort gelangen.

Das VANET ist also vielfältig einsetzbar. Alle Informationen die einem Fahrzeug zugänglich sind, können mit anderen geteilt werden und für unterschiedlichste Zwecke eingesetzt werden. Dabei gibt es im Grunde kaum noch Grenzen, da z.B. über UMTS oder ähnliche Techniken ein dauerhafter Internetzugriff möglich ist und so dem Fahrzeug z.B. (Un-)Wetter oder Stau-Informationen direkt zugestellt werden können. Die Verwendung der Informationen liegt dann in Händen des Fahrzeug-Herstellers bzw. bei den Kunden, die gewisse Wünsche äußern.

7.4.3 AutoCast

Für die Verteilung der Daten in z.B. einem mobilen Datennetz gibt es bereits ein Protokoll namens AutoCast.
Für den Entwurf war, wie zuvor bereits erläutert, besonders zu berücksichtigen, dass sich in einem mobilen Einsatz die Netztopologie ständig ändert und eine Funkverbindung eine weniger verlässliche Verbindung darstellt, als z.B. eine kabelgebundene Netzwerkverbindung. Damit trotzdem alle Informationen von Fahrzeug A an Fahrzeug B übertragen werden, werden alle Informationen durch das Protokoll AutoCast automatisch im Netzwerk verteilt. Eine Information wird in ein Datenelement verpackt. Dies besteht aus vier Komponenten[52]:

  • Nachricht

Die eigentlichen Informationen der Nachricht, z.B. GPS Koordinaten und bekannte Staumeldungen.

  • Verbreitungsraum

Das Gebiet für das die Information von Interesse ist. Ein Fahrzeug, welches einen Stau passiert hat, muss nicht mehr wissen, dass dieser Stau existiert.

  • Lebenszeit

Die Lebenszeit ist die Dauer, in der die Nachricht im Verbreitungsraum weiter verteilt wird.

  • Priorität

Ein Datenelement enthält auch die Priorität einer Nachricht. Eine Unfallwarnung über einen Unfall in z.B. 500 Metern ist wichtiger als z.B. eine Stauwarnung über einen Stau in 4 Kilometern Entfernung. Daher muss in diesem Beispiel die Unfallwarnung vor der Stauwarnung durch AutoCast verteilt werden.

AutoCast sorgt durch eine Broadcast Funktion dafür, dass alle Datenelemente, deren Lebenszeit noch nicht abgelaufen ist, ständig an die Umgebung verteilt werden. Dafür besitzt jedes Fahrzeug die Fähigkeit, solche Datenelemente zu erzeugen.[52]
Um das Protokoll weiter zu verschlanken und komplexen Routenberechnungen zuvor zu kommen, werden Informationen über Multi-Hop-Routen nicht gespeichert oder vorgehalten.[52] Durch die ständige Verteilung der Datenelemente werden alle Fahrzeuge im Verbreitungsraum optimalerweise erreicht. Es ist daher nicht nötig, dass Fahrzeug A weiß, dass es über Fahrzeug B und C eine Information an Fahrzeug D senden kann.
Vergleichbar ist dies mit dem menschlichen "Klatsch und Tratsch Verhalten". Alle Informationen werden an die Menschen in der Umgebung berichtet. Diese berichten dann den Menschen in ihrer Umgebung davon. Dadurch verbreiten sich die Informationen sehr schnell. Sollte eine diese Informationen besonders interessant sein, so wird diese schnell weiter berichtet und das normalerweise auch vor den anderen Informationen. Dies beschreibt dann auch ein System der Priorisierung.

Das AutoCast Protokoll muss drei Hauptanforderungen erfüllen[53]:

  • Verschiedene Verkehrssituationen
Je nach aktueller Verkehrslage und Netztopologie muss das Protokoll die Daten verlässlich verteilen. Zu unterscheiden sind hier z.B. die Szenarien eines Staus, viele Fahrzeuge auf engstem Raum, fließender Verkehr auf einer Autobahn und auch das große Problem des Gegenverkehrs, sehr wenig Zeit für den Datenaustausch.
Abbildung 21: Funktionsweise von AutoCast
Abbildung 21: Funktionsweise von AutoCast[54]
  • Kompromiss zwischen Datengröße (Informationsmenge) und Datenübertragungsgeschwindigkeit

Es müssen in kurzer Zeit möglichst viele sinnvolle Informationen übertragen werden. Daher muss ein Kompromiss zwischen der Datenmenge, die übertragen wird, und der Datenübertragungsgeschwindigkeit gefunden werden. Zu viele Informationen bergen das Risiko, dass bei den nicht 100% konstanten Funkverbindungen Daten verloren gehen bzw. nicht vollständig übertragen werden. Bei wenigen Informationen erhöht sich die Übertragungsgeschwindigkeit, aber es werden nicht alle relevanten Informationen übertragen.

  • Alle Knoten im Verteilungsraum sollen die Daten empfangen

Über Multi-Hop und Mitnahme von Datenelementen sollen alle im Verteilungsraum befindlichen Fahrzeuge die Daten erhalten.
Abbildung 21 zeigt die Funktionsweise von AutoCast.[55] Fahrzeug A erstellt ein Datenelement und sendet dieses an die umgebenden Knoten. Durch die Selbst-Adaption in dem AutoCast Protokoll verbreiten nur einige Fahrzeuge die Nachricht weiter. Es findet das sogenannte probabilistische Fluten statt. Ein Fahrzeug, das viele Nachbarn hat, kommuniziert mit diesen darüber, wer die Nachricht weitersendet, damit das Netzwerk nicht mit der gleichen Nachricht vollkommen verstopft wird. Durch die sogenannten Beacons bestimmt ein Fahrzeug, welche anderen Fahrzeuge in seiner Nähe sind. Es handelt sich um ein "Rund-Um"-Signal, welches die anderen Fahrzeuge im Sendeumkreis beantworten. Dadurch erkennen beide Fahrzeuge, dass sie in Sendereichweite sind und teilen die Informationen, die sie gespeichert haben.
Um die Nachricht auch in andere Netzwerke zu tragen, so genannte andere Netzpartitionen, wird die Nachricht per Store & Forward in ein anderes Netz getragen. Store & Forward bedeutet, dass ein Fahrzeug eine Nachricht durch den Verbreitungsraum trägt, in dem es die Nachricht aufbewahrt. Fahrzeug B und C wissen durch die Beacons von ihrer Anwesenheit in der Sendereichweite. Die Nachricht wird von Fahrzeug B aus der 1. Netzpartition an Fahrzeug C in der 2. Netzpartition übertragen. Hier kann die Nachricht nun wieder durch das probabilistische Fluten verbreitet werden.

8 Organic Information Complexes

Abbildung 22: Organic Information Complex im Zusammenhang mit Hovering Data Cloud
Abbildung 22: Organic Information Complex im Zusammenhang mit Hovering Data Cloud[56]

Die in Kapitel 7 beschriebene Hovering Data Cloud dient dem Erfassen der Daten auf räumlich begrenzen Verkehrsstrukturen.[44] Um räumlich ausgedehnte Informationen zu erzeugen werden Hovering Data Clouds zusammengefasst. Diese zusammengefassten Datenwolken werden als Organic Information Complexes bezeichnet (Organischen Informationskomplexen- kurz: OIC)[57]. Die Hovering Data Clouds bilden also somit die Grundlage für die Organic Information Complexes[58]

8.1 Entstehung
Abbildung 23: Aggregation von Daten mittels Organic Information Complexes
Abbildung 23: Aggregation von Daten mittels Organic Information Complexes[59]

Das Entstehen von OIC ist in Abbildung 23 abgebildet. Die Datenzusammenfassung nimmt von der oberen Abbildung bis zur unteren zu.

In der oberen Abbildung gibt es pro Stau jeweils zwei Hovering Data Clouds, die Daten des Stauanfangs bzw. Stauendes enthalten. Die Fahrzeuge erkennen, dass es zueinander passende HDCs gibt, dadurch findet eine Aggregation dieser HDCs statt. Es entsteht ein Organic Information Complexes, die den gesamten Stau, der von einer einzelnen HDC nicht erfasst werden könnte, beschreibt. Der OIC enthält z.B. Daten zur der Staulänge. Die neuen Informationen werden in einer neuen HDC abgelegt, die sich dort befindet, wo die beiden HDC des Stauendes und HDC des Stauanfangs zusammengeführt wurden. So ist es möglich, dass alle Fahrzeuge auf die Daten zugreifen können, da sie sich in den Kommunikationsradius von der HDC befinden.[60]

Nach einer erneuten Aggregation, kann festgestellt werden, dass sich zwischen den beiden Staus aufgrund des geringen Abstandes zueinander eine Stop-and-Go Welle befindet. Die Daten dazu werden in einer neuen HDC festgehalten. Durch Integration und Korrelation können nun Daten abgerufen und verändert werden.[59]

8.2 Routenplanung
Organic Information Complexes nehmen sowohl eine Beobachtungsfunktion als auch eine Kontrollfunktion wahr. OIC können z.B. Fahrzeuge, die an einen Stau heranfahren, eine Umleitungsmöglichkeit zur Verfügung stellen[57].
Abbildung 24: Fahrtzeit ermitteln mit Hilfe von Organic Information Complexes
Abbildung 24: Fahrtzeit ermitteln mit Hilfe von Organic Information Complexes[59]

Abbildung 24 veranschaulicht diese Funktion von OIC. Die in der Abbildung dargestellten Wege A, B und C führen zu einem gleichen Ziel. Auf der Strecke A wurde bereits ein Stau mit einer Stop-and-Go-Welle von einer OIC erfasst; dadurch verlängert sich die Reisezeit auf 120 Minuten. Die Strecke C ist aufgrund eines Verkehrsunfalls gesperrt. Auch diese Information ist bereits in einer OIC hinterlegt. Die OICs senden ihre gespeicherten Informationen an die herankommenden Fahrzeuge. An der Kreuzung, wo eine Umleitung möglich ist, werden die einzelnen Daten der OICs zu einer voraussichtlichen Fahrzeit zusammengefasst und in eine HDC abgelegt. Die Daten, d.h. die Reisezeiten der einzelnen Strecken, werden in der HDC fortlaufend aktualisiert. Fahrzeuge, die sich im Bereich der Hovering Data Cloud an der Kreuzung befinden, speichern die Daten lokal und können dadurch die kürzeste Strecke auswählen.

9 Zusammenfassung

9.1 Fazit

In der vorliegenden wissenschaftlichen Hausarbeit wurden Verfahren aufgezeigt, die die Kommunikation zwischen Fahrzeugen verbessert. Dazu wurde das Verfahren der Hovering Data Cloud und Organic Information Complexes, die HDCs benutzen, vorgestellt. Es wurde gezeigt, wie zunächst allgemein die Fahrzeug-zu-Fahrzeug-Kommunikation Unfälle vermeiden kann und anschließend anhand von Anwendungsbeispielen, wie HDC und OIC die Verkehrssicherheit und den Verkehrsfluss positiv beeinflussen. Die eingesetzten Technologien der Fahrzeug-zu-Fahrzeug-Kommunikation wurden anfänglich vorgestellt, um schließlich auf die neuartigen Technologien und eingesetzten Protokolle der HDC einzugehen.

Die Hovering Data Cloud ist im Gegensatz zur Fahrzeug-zu-Fahrzeug-Kommunikation ein sich selbst organisierendes System. Mit dem Verfahren ist das Sammeln und Auswerten von Informationen erdenklich, die nicht an einem Ort gebunden sind. Dadurch ist es z.B. möglich Daten über das Stauende bzw. den Stauanfang zu erfassen, obwohl sich diese kontinuierlich ändern.

Durch das Zusammenfassen mehrerer HDCs entstehen Organic Information Complexes. Diese ermöglichen eine Verkehrssituation als Ganzes zu betrachten. Zum Beispiel kann durch die hierarchische Aggregation der Daten von mehreren HDCs ein Stau als Ganzes beobachtet werden. Die von den HDC gesendeten Datenelemente werden verglichen. Wenn passende Datenelemente aufeinandertreffen, werden diese zusammengefasst und in eine neue Datenwolke gespeichert. Mit Hilfe von OIC wird es dadurch möglich Messdaten zu erstellen, die von einer einzelnen HDC nicht erfasst werden können. Diese HDC enthält z.B. die Länge des Staus.

9.2 Ausblick

Bei den Verfahren der Hovering Data Cloud und Organic Information Complexes wurden bisher nur beispielhafte Anwendungen von der Universität Lübeck umgesetzt und getestet. In dem Projekt AutoNomes ist die Weiterentwicklung der Verfahren geplant, sodass eine Vorhersage von Verkehrslagen durchgeführt werden kann. Das Ziel ist es den Straßenverkehr so zu beeinflussen, dass eine ungünstige Verkehrslage vermeidet oder zumindest abgeschwächt wird.[61]
In der Weiterentwicklung der Technologien für den mobilen Einsatz sind noch einige Probleme zu lösen. Vor allem sind hier der Doppler-Effekt bei hohen Geschwindigkeiten und auch die große Sendereichweite, die eine mobile Technik haben muss, zu nennen. Hier wurden in den vergangen Jahren schon große Fortschritte gemacht. Das Mautsystem in Deutschland beweist, dass es möglich ist, solche Systeme zu implementieren. Das Protokoll AutoCast hat in ersten Tests bereits vielversprechende Ergebnisse geliefert und konnte in kürzester Zeit über große Distanzen Informationen verteilen.[62] Jedoch ist z.B. der Einsatz von Infrastrukturknoten, welche eine Information per Internet über eine größere Distanz weiterleiten könnten, bisher wenig erprobt worden. Hier findet sich noch weiteres Potential, da eine Information über große Distanz weitergeleitet werden kann, ohne das Fahrzeuge in dem Zwischenraum benötigt werden, die die Datenelemente weitertragen bzw. weiterleiten. Diese würden von einem Infrastrukturknoten aufgenommen und an einem anderen wieder ausgesendet.

10 Fußnoten

  1. 1,0 1,1 Vgl. o.V. (2009)
  2. 2,0 2,1 Vgl. Statistisches Bundesamt (2009), S.5
  3. Vgl. Lübke (2009), S.1
  4. Vgl. Eberspächer/Speidel (2005), S.154
  5. Vgl. Eberspächer/Speidel (2005), S.158
  6. Vgl. Schnieder (2007), S.125
  7. Vgl. Schnieder (2007), S.124
  8. Vgl. Eberspächer / Tillmann (2005), S. 147
  9. Vgl. Schnieder (2007), S.177
  10. aus http://www.bag.bund.de/cae/servlet/contentblob/10450/poster/414/Mautsystem-klein.jpg (Zugriff: 2010-05-20)
  11. Vgl. Dembowski (2004), S. 75
  12. Vgl. Nasarek (2007), S. 246
  13. 13,0 13,1 Vgl. Kofler (2004), S. 813
  14. Vgl. Kofler (2004), S. 813
  15. Vgl. Dean (2009), S. 379
  16. aus http://www.bmvbs.de/Bild/original_1061013/on-Board-Unit-OBU.jpg (Zugriff: 2010-05-05)
  17. Vgl. Franz et. Al. (2005), S. 29f
  18. Vgl. Franz et. Al. (2005), S. 30
  19. Vgl. Bing (2008), S. 7
  20. aus http://www.umt.edu/geosciences/faculty/sheriff/Equipment_Techniques_and_Cheats/GPS/GPS_Images/Differential_GPS.jpg (Zugriff: 2010-05-05)
  21. Vgl. El-Rabbany (2002), S. 1f
  22. aus http://meingottundmeinewelt.de/wp-content/images/t-e-v-umts.gif (Zugriff: 2010-05-31)
  23. 23,0 23,1 Vgl. Wuschke (2003), S. 202
  24. Vgl. Wuschke (2003), S. 194
  25. Vgl. Frohberg, et. al. (2008) S. 128
  26. 26,0 26,1 Vgl. Statistisches Bundesamt (2009), S.9
  27. 27,0 27,1 Ausgenommen ist die Zahl der Unfälle, bei deren ein Fahrzeug entgegengekommen ist.
  28. 28,0 28,1 Vgl. Biswas et al. (2006), S.76
  29. Vgl. Biswas et al. (2006), S.77
  30. Vgl. Fekete et al. (2010), 00:12h
  31. 31,0 31,1 Vgl. Baumgarten (2008), S.143
  32. Vgl. Wegener / Hellbrück et al.(2009), S.3
  33. Vgl. Wegener / Schiller (2006), S.2
  34. Vgl. Wegener (2009), S. 37
  35. Vgl. Pfingsten / Rammig (2007), S.26
  36. 36,0 36,1 Vgl. BVU/ITP (2007), S.4
  37. 37,0 37,1 37,2 Vgl. Kommission der europäischen Gemeinschaft (2001), S.8
  38. Vgl. ADAC e.V. (2008), S.5
  39. 39,0 39,1 Vgl. Wegener (2009), S.114
  40. Vgl. Wegener (2009), S.113
  41. 41,0 41,1 41,2 41,3 41,4 Vgl. Wegener (2009), S.28
  42. Vgl. Ganten / Alex (2007), S.250
  43. 43,0 43,1 Vgl. Wegener (2009), S. 29
  44. 44,0 44,1 Vgl. Wegener (2009), S. 30
  45. Vgl. Kloiber, S. 17
  46. Vgl. Kenubühl et. al. (2008), S.64
  47. Vgl. Winkler (2004), S. 441
  48. Vgl. Scherff (2006), S.7
  49. Vgl. Plößl (2009), S. 9
  50. Vgl. Hartenstein, et. al. (2010), S. 23-24
  51. Vgl. Plößl (2009), S. 3
  52. 52,0 52,1 52,2 Vgl. Wegener (2009), S. 48
  53. Vgl. Wegener (2009), S. 49
  54. Vgl. Wegener (2009), S. 55
  55. Vgl. Wegener (2009), S. 54f
  56. Vgl. Fekete et al. (2006), S. S.132
  57. 57,0 57,1 Vgl. Pfingsten / Rammig (2007), S.27
  58. Vgl. Labahn (2005)
  59. 59,0 59,1 59,2 Vgl. Wegener / Hellbrück et al. (2009), S.4
  60. Vgl. Wegener (2009), S. 31
  61. Vgl. Wegener (2009), S. 141
  62. Vgl. Wegener (2009), S. 79, 92-94

11 Literatur- und Quellenverzeichnis

ADAC e.V. (2008) ADAC e.V.: Bedarfsgerechter Autobahnausbau-Fakten & Argumente kompakt, München 2008, http://www1.adac.de/images/Autobahnausbau_Fachinfo_0901_tcm8-241477.pdf, 16.5.2010 12:10
Baumgarten (2008) Baumgarten, Hermut: Das beste der Logistik – Innovationen, Strategien und Umsetzungen, Springer Verlag, Berlin 2008
Bern (2007) Bern, Karsten/ Luksch, Tobias: Autonome Mobile Systeme 2007, Springer, Kaiserslautern 2007
Bing (2008) Bing, Benny: Emerging technologies in wireless LANs: theory, design, and deployment, Cambridge University Press, Cambridge 2008
Biswas et al. (2006) Biswas, Subir/ Tatchikou, Raymond/ Dion, Francois: Vehicle-to-Vehicle Wireless Communication Protocols for Enhancing Highway Traffic Safety, in IEEE Communications Magazine, January 2006, S.74-82
BVU / ITP (2007) BVU/ITP: Prognose der deutschlandweiten Verkehrsverflechtungen 2025, FE-Nr. 96.0857/2005, München/Freiburg 14.11.2007,

http://www.bmv.de/Anlage/original_1024631/Verkehrsprognose-2025-Kurzfassung.pdf, 16.5.2010 14:31

David / Geihs (2009) David, Klaus/ Geihs, Kurt: Kommunikation in Verteilten Systemen, Springer Verlag, Kassel 2009
Dean (2009) Dean, Tamara: Network+ Guide to Networks, Cengage Learning, Boston 2009
Dembowski (2004) Dembowski, Klaus: PC Werkstatt II, Pearson Education, München 2004
Eberspächer / Speidel (2007) Eberspächer, Jörg/ Speidel, Joachim: Wachstumsimpulse durch mobile Kommunikation, Springer Verlag, Leipzig 2007
Eberspächer / Tillmann (2005) Eberspächer, Jörg / Tillmann, Herbert: Broadcast-Mediendienste im Spannungsfeld zwischen Märkten und Politik, Springer Verlag, Leipzig 2005
El-Rabbany (2002) El-Rabbany, Ahmed: Introduction to GPS: the Global Positioning System, Artech House, Norwood 2002
Fekete et al. (2010) Fekete, Sándor P./ Fischer, Stefan/ Hendriks, Bijörn: The AutoNomos Project, http://www.auto-nomos.de, 3.05.2010 15:31
Fekete et al. (2006) Fekete, Sándor P./ Schmidt, Cristiane/ Wegener, Axel /Fischer, Stefan: Hovering Data Clouds for Recognizing Traffic Jams, in: Proceedings of the 2nd International Symposium on Leveraging Applications of Formal Methods, Verification and Validation, 2006, S. 213-218
Franz et. al. (2005) Franz, Walter / Hartenstein, Hannes / Mauve, Martin: Inter-Vehicle-Communications Based on Ad-Hoc Network Principles, Universitätsverlag Karlsruhe, Karlsruhe 2005
Frohberg et. al. (2008) Frohberg, Wolfgang / Kolloschie, Horst / Löffler, Helmut: Taschenbuch der Nachrichtentechnik, Hanser Verlag, München 2008
Ganten / Alex (2007) Ganten, Peter H. / Alex, Wulf: Debian GNU /Linux: Grundlagen, Einrichtung und Betrieb, 3 Auflage, Springer Verlag, Leipzig 2007
Hartenstein et. al. (2010) Hartenstein, Hannes / Laberteaux, Kenneth: VANET Vehicular Applications and Inter-Networking Technologies Intelligent Transport Systems, John Wiley and Sons, West Sussex 2010
Hummel / Sterbenz (2008) Hummel, Karin Anna/ Sterbenz, James P. G.: Self-Organizing Systems, Springer Verlag, 2008, S. 243-247
Kneubühl et. al. (2008) Kneubühl, Fritz Kurt / Sigrist, Markus Werner: Laser, Gabler Wissenschaftsverlage, Wiesbaden 2008
Kofler (2004) Kofler, Michael: Linux, Pearson Education, München 2004
Kommission der europäischen Gemeinschaft(2001) Kommission der europäischen Gemeinschaft: Weissbuch- Die europäische Verkehrspolitik bis 2010- Weichenstellungen für die Zukunft- KOM(2001) 370, Brüssel 2001, http://www.tuvpt.de/neu/fileadmin/pdf/EU_Papiere/weissbuch_120901.pdf, 16.05.2010, 15:17
Labahn (2005) Labahn, Rüdiger: Artikel „Organic Computing“, 29. August 2005, http://www.mu-luebeck.de/aktuelles/pressemitteilungen/2005/0829orga.php, 3.5.2010 10:11
Lübke (2009) Lübke, Andreas: Car-to-Car Communication – Technologische Herausforderungen, Wolfsburg o. J., http://www.network-on-wheels.de/downloads/VDE2004_Luebke_Paper.pdf , 4.05.2010 12:20
Nasarek (2007) Nasarek, Marcus: Windows Vista Security: praxisorientierte Sicherheit für Profis ; [lösungsorientiert, praktikabel, wirtschaftlich ; mit Checklisten], O'Reilly Germany, Köln 2007
Pfingsten / Rammig (2007) Pfingsten, Andreas/ Rammig, Franz : Informationstechnik in Verkehr und Logistik, Düsseldorf 2007,

http://www.acatech.de/fileadmin/user_upload/Baumstruktur_nach_Website/Acatech/root/de/Publikationen/acatech_diskutiert/Tagungsband_Informatik%252520bewegt.pdf, 3.5.2010 12:05

Plößl (2009) Plößl, Klaus: Mehrseitig sichere Ad-Hoc-Vernetzung von Fahrzeugen, Gabler Verlag, Wiesbaden 2009
Scherff (2006) Scherff, Jürgen: Grundkurs Computernetze: Eine kompakte Einführung in die Rechnerkommunikation- anschaulich, verständlich, praxisnah. Mit online-service zum Buch, Vieweg+Teubner Verlag, Wiesbaden 2006
Schnieder (2007) Schnieder, Eckehard: Verkehrsleittechnik Automatisierung des Straßen- und Schienenverkehrs, Springer Verlag, Braunschweig 2007
Statisches Bundesamt Wiesbaden (2010) Statisches Bundesamt Wiesbaden: Verkehr- Verkehrsunfälle Dezember 2009, Fachserie 8, Reihe 7, Wiesbaden 2010
Wegener (2009) Wegener, Axel: Organic-Computing-Konzepte und deren Umsetzung für dezentrale Anwendungen im Straßenverkehr, http://www.students.informatik.uni-luebeck.de/zhb/ediss684.pdf, Lübeck 2009 , 4.5.2010 10:09
Wegener / Hellbrück et al. (2009) Wegener, Axel/ Hellbrück, Horst/ Fischer, Stefan/ Hendriks, Björn/ Schmidt, Christiane/ Fekete, Sándor P.: Designing a Decentralized Traffic Information System – AutoNomos. In: David, Klaus/ Geihs, Kurt: Kommunikation in Verteilten Systemen, Springer Verlag, Kassel 2009, S. 309-315
Wegener et al. (2006) Wegener, Axel / Schiller, Elad M. / Hellbrück, Horst / Fekete, Sándor P. / Fischer, Stefan: Hovering Data Clouds- A Decentralized and Self-Organizing Information System, 2006, in: Hummel, Karin Anna/ Sterbenz, James P. G.: Self-Organizing Systems, Springer Verlag, 2008, S. 243-247
Winkler (2004) Winkler, Peter: PC Lexikon 2005, Pearson Education, München 2004
Wuschke (2003) Wuschke, Martin: UMTS: Paketvermittlung im Transportnetz, Protokollaspekte. Systemüberblick, Vieweg+Teubner Verlag, Wiesbaden 2003
o.V. (2009) o. V. (2009): Artikel „Bundesbürger stehen 535000 Jahre im Stau“, 13.09.2009, http://www.welt.de/vermischtes/article4523182/Bundesbuerger-stehen-535-000-Jahre-im-Stau.html, 6.5.2010 09:06
Persönliche Werkzeuge