Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.
1 Einleitung
Die Weiterentwicklung von Verkehrstelematiksystemen benötigt hoch qualitative Verkehrsinformationen in Echtzeit. Seit nunmehr fast einer Dekade wird unter steigendem Druck an der Verbesserung des Verkehrsmanagements gearbeitet. Die Methoden, wie an die hierfür notwendigen Verkehrsdaten gelangt wird, haben sich eminent verbessert und Hauptaugenmerk liegt nun an der wirtschaftlichen Abdeckung des gesamten betroffenen Straßennetzes.
Nach einer Studie des ADAC steht der durchschnittliche Autofahrer rund 65 Stunden im Jahr im Stau, Tendenz steigend. Im Stau werden jährlich rund 14 Milliarden Liter Kraftstoff unnötigerweise verbraucht. [5]
Die verwendeten Systeme lassen sich in zwei Gruppen teilen, die In-Situ-Messung, also Systeme die an den Verkehrsadern permanent montiert werden und der Floating Car Data (FCD) Systeme, die sich in den Fahrzeugen mit dem Verkehr bewegen. BLIDS Networks wird der ersten Gruppe zugeordnet, obwohl sich die erfassten Merkmale (Bluetooth Gerät) im Fahrzeug befinden.
Im folgenden Bericht wird auf die Ergebnisse der umfangreichen Anwenderberichte sowohl in urbanen Gebieten als auch auf Autobahnen und Schnellstraßen eingegangen.
2 Grundlagen zum Messverfahren
Die Bluetooth RF (physikalische Netzwerkschicht) verwendet das Lizenzfreie ISM Band auf 2,4GHz. Auf dieser Frequenz befinden sich auch andere Funktechniken, wie WLAN und DECT. Der Bluetooth Standard setzt auf binäre Frequenz-Modulation und die spektrale Ausbreitung wird durch ein Frequenzhopping-Verfahren erreicht, das eine robuste aber auch hoch integrierbare Tranceiver Lösung ermöglicht. Dies ermöglicht die Integration von Bluetooth in eine sehr breite Anwendungsbasis. Hier seien als Beispiele die Integration in moderne Handys, Autos, Navis und Headsets erwähnt, natürlich entstehen permanent neue Anwendungen (siehe speziell Bluetooth 4.0). [6]
2.1 Bluetooth Grundlagen
Das für die Anwendung von BLIDS notwendige Bluetooth Kernsystem (BT device, Abbildung 1) umfasst lediglich die vier untersten Netzwerkschichten des gesamten Bluetooth Software Protokols.
Bild 1: Bluetooth Software Protokol
Jedes Bluetooth-Gerät besitzt eine eindeutigen 48-bit Adresse (BD_ADDR). Abbildung 2 zeigt den Aufbau der Adresse, bestehend aus einem 24-bit Lower Address Part (LAP), einem 8-bit Upper Address Part (UAP) und einem 16-bit Non-significant Address Part (NAP). Der LAP wird von dem BT-Gerätehersteller vergeben. UAP und NAP bilden die Hersteller- Identifikation, die von der IEEE vergeben wird.
Bild 2: Bluetooth Adresse BD_ADDR
Die BT-Geräteadresse kann vom Nutzer nicht geändert werden. Eine Maskierung der Adresse für ein anonymes Inquiry oder Paging ist folglich nicht möglich.
Bild 3: State machine des Link Controllers
Bei Bluetooth ist die Sichtbarkeit und Kontaktierbarkeit gegenüber externen Geräten steuerbar. Dies wird durch zwei Scan-Modi erreicht. Der Inquiry-Scan-Modus steuert die Sichtbarkeit eines BT-Gerätes nach außen und der Page-ScanModus die Kontaktierbarkeit. Sind beide Modi deaktiviert, ist ein Bluetooth-Gerät vollkommen unsichtbar und kann nicht kontaktiert werden. Beim Inquiry beschränkt sich die Kommunikation, auf den Austausch von ID- bzw. FHS-Paketen. Zusätzlich kann ein Nutzer festlegen, wann und wie lange sein Bluetooth-Gerät von anderen Geräten gefunden werden kann (Inquiry Scan Substate).
Bild 4: Inquiry Prozedur bei BLIDS
Beim Inquiry sendet das Bluetooth-Gerät (Abbildung 4) dabei in regelmäßigen Abständen ID- Pakete aus. ID-Pakete enthalten einen so genannten Inquiry Access Code (IAC), der Bluetooth-Geräten in der Umgebung signalisiert, dass jemand versucht sie zu finden. Der IAC ist zwar von dem Lower Address Part (LAP), den 24 niederwertigen Bits einer BT- Geräteadresse, abgeleitet, es lässt sich daraus jedoch nicht die Bluetooth-Adresse rekonstruieren [7]. Das ID-Paket eines Bluetooth-Gerätes enthält demnach keine verwertbaren Informationen über seine Quelle. Eine Bluetooth-Inquiry-Prozedur ist demnach für den Initiator anonym.
Tabelle 1: Geräte gescannt / Zeit
Gefundene Geräte antworten auf ein Inquiry mit einem FHS-Paket (FHS=Frequency Hopping Synchronization). Ein FHS-Paket enthält unter anderem die BT-Geräteadresse und den aktuellen Wert der Systemuhr des Absenders. Das Eintreffen eines FHS-Paketes wird vom Empfänger nicht quittiert. [7]
Mit der Verwendung des ab Bluetooth V1.2 zulässigen interlaced inquiry scan modes ist es möglich bereits nach 3,84s 99% aller umliegenden scanning devices zu finden, es wird aber die in der Bluetooth SIG Spezifikation empfohlene tinquiry=10,24s Zykluszeit für die BLIDS Sensoren verwendet. Innerhalb der tinquirywird jede BT-Adresse nur einmal gescannt. [3]
2.2 Embedded System als Telematik Sensor
Bild 5: Blockschaltbild des BLIDS-Sensors
Auf dem mit einem ARM9 basierten System läuft ein embedded Linux, das auf die genauen Anforderungen eines energiesparenden Sensorsystems zugeschnitten ist. Damit ist auch ein OTA (over the air) update der Firmware möglich und das System ist damit fernwartbar und Service-freundlich. Verwendete Distribution OpenEmbedded, linux-2.6.29-stamp9g20
Die Software des Sensors besteht aus 2 Gruppen, dem Betriebssystem und der Firmware. Zusätzlich gibt es noch ein Web-basiertes Konfigurationstool.
Die Funktionsweise der Firmware kann folgendermaßen zusammengefasst werden:
In einem Scan-Zyklus von z.B. 10,24s werden mithilfe eines Bluetoothmodul (erweiterbar auf max. 4 Module) in der Umgebung in einem einstellbaren Umkreis alle sichtbaren Bluetoothdevices erfasst. Hierzu wird der Device Discovery Mode verwendet, es wird ausschließlich die Bluetooth Adresse, clock, class of device, used page scan und names of devices ausgelesen. Weitere verbindungsorientierte Protokollteile von Bluetooth werden nicht verwendet.
Die erkannten Adressen werden mit einem genauen Zeitstempel versehen und verschlüsselt in ein lokales file geschrieben und über das gewählte Übertragungsmedium (Ethernet, GPRS) an einen Server übertragen.
Bild 6: Software Stack BLIDS-Network
Wie in der Abbildung 6 zu sehen wird zur Weiterverarbeitung vom BLIDS Server mehrere Dienste benötigt um die Daten zu backupen und in eine Datenbank zu schreiben. Über Schnittstellen wie Json/Rest können die Daten auch beliebig in andere Systeme exportiert werden, oder mit BLIDS Online über Standardbrowser zur Anzeige gebracht werden.
2.3 Kryptographie
Anonymisieren ist das Verändern personenbezogener Daten derart, dass die Einzelangaben über persönliche oder sachliche Verhältnisse nicht mehr oder nur mit einem unverhältnismäßig großen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder bestimmbaren natürlichen Person zugeordnet werden können.
Pseudonymisieren ist das Ersetzen des Namens und anderer Identifikationsmerkmale durch ein Kennzeichen zu dem Zweck, die Bestimmung des Betroffenen auszuschließen oder wesentlich zu erschweren. [2]
Verkehrsflussanalysen sind ein Bereich in dem Pseudonymisierung eingesetzt wird. Verschiedene Quellen erfassen die Fahrzeuge. Aus diesen Daten soll ein Muster des Verkehrsflusses erstellt werden. Daher ist es unumgänglich, dass ein Fahrzeug bei allen Erfassungspunkten denselben Identifikator erhält. Jedoch dürfen keine Daten, die für eine Nachverfolgung der Person geeignet wären, verwendet werden um konform mit dem Datenschutzgesetz zu sein.
Tabelle 2: Erfasste BT-Daten - Beispieldatensatz
Wie in Tabelle 2 zu sehen wird die BT-Adresse im Sensor mittels (secure) Hash Funktion in eine 160bit Adresse umgewandelt. Die BT-Adressen werden zu keinem Zeitpunkt in Klartext abgespeichert. Die Hashfunktion wird mithilfe eines sich täglich ändernden ‚SaltValue‘ eingesetzt: HASH(BluetoothID||SaltValue). Die gesicherte Verwaltung des SaltValues wird von einem ‚trusted Server‘ erledigt. [2]
2.4 Statistische Relevanz der Daten
Die Überprüfung der Relevanz der mit BLIDS erhobenen Daten obliegt der statistischen Betrachtung und insbesondere der Einsatz von modellhaften Hochrechnungen von der Stichprobe auf die Grundgesamtheit. Die sogenannten Regressionsmodelle reichen von linearen Modellen über Modelle mit quadratischen Term bis hin zu Mischmodellen. Es wird in diesem Bericht aber nicht näher auf die Details eingegangen, da dies den Rahmen sprengen würde. Die diesbezüglichen Untersuchungen [1] wurden sowohl für Autobahn- und Schnellstraßenbereich als auch für urbanes Gebiet durchgeführt.
Für die Güte eines Modells ist nicht die Anzahl der registrierten Bluetoothsignale und somit die Quote ausschlaggebend, sondern deren Verlauf, und Fluktuation. Auf Verläufe mit linearen oder quadratischen Steigungen, wird mittels engerer Faktorisierung und eventueller Errechnung eines Regressionsmodells mit quadratischem Term, reagiert. Varianzinhomogenität, wird mittels Box-Cox-Transformation der zugrundeliegenden Daten, begegnet. Quotenschwankungen werden mittels Glättungen ´begradigt´. Mit all diesen Maßnahmen erzielt man markante Modellverbesserungen. Mittels geeigneter Wahl der Messstandorte und starkes Engagement bezüglich der Filterung der Daten, wird vor Beginn der eigentlichen Regressionsanalyse, ein guter Grundstein gelegt.
Bild 7: Lineare Regression Beispiel - BT-Schätzdaten und Radarmessung
Eine zweiwöchige Gegenüberstellung wie in Abbildung 7 der Schätzdaten mit den tatsächlichen Verkehrsfrequenzen zeigt eine sehr gute Treffergenauigkeit des errechneten Modells. Größere Abweichungen des Modells werden durch die Enge des 95 prozentigen Konfidenzintervalls für den Mittelwert negiert. Insgesamt verdeutlicht dieser Plot eine sehr gute Anpassung des errechneten Konfidenzintervalls, und spiegelt den tatsächlichen Frequenzverlauf gut wieder. Die beobachtete Gesamtfrequenz liegt immer im 95 prozentigen Prognoseintervall für den Einzelwert. Die Schätzgenauigkeit des errechneten Regressionsmodells wird dadurch bestätigt.
Viele Personen assoziieren mit einer möglichst hohen Bluetoothquote bessere Hochrechnungsmöglichkeiten und daher auch realitätsnahe Aussagen über den tatsächlichen Verkehr. Basierend auf den Erkenntnissen der durchgeführten Regressionsanalysen kann man das nicht generell sagen. Nicht nur die Höhe der Quote ist ausschlaggebend für gute Ergebnisse, sondern auch deren Verlauf.
3 Anwendungsszenarien
3.1 Störfallerkennung/Reisezeitermittlung auf Autobahnen [8]
Im Auftrag der Autobahndirektion Nordbayern wurden im Großraum Nürnberg umfassende Untersuchungen durchgeführt.
Neue Technologien im Bereich der Bluetooth-Module wurden eingehend getestet, u.a. wurde dadurch z.B. die Empfangsempfindlichkeit von 82 dB auf über 90 dB erhöht.
Um durch Optimierung und Adaptierung der Antennentechnik die höchst mögliche Detektion zu erreichen, wurden Tests mit unterschiedlichen Antennen, wie Yagi-Antennen,
Richtantennen, Dipolantennen und Patch-Antennen durchgeführt. Parallel wurden weitere Testreihen zur Verbesserung der Antennentechnik in Zusammenarbeit mit der Fachhochschule in Graz (Campus 02) durchgeführt und umgesetzt.
Bild 8: Stau zwischen AS Neuendettelsau und AS Langwasser
Eine der wichtigsten Anforderungen für die Steuerung von Netzbeeinflussungsanlagen stellt die Störfallerkennung dar, sowohl mit fest installierten Sensoren als auch mit mobilen Einheiten, die vor allem für den Baustelleneinsatz in Frage kommen.
Aus den mit BLIDS erfassbaren Verkehrskenngrößen können die folgenden Methoden einer Störfallerkennung abgeleitet werden:
Häufung der BT-Wiedererkennungen im Empfangsbereich des Sensors.
Hier handelt es sich um die Möglichkeit die Scanzykluszeit (innerhalb derer eine BT Adresse nur genau einmal erkannt wird) parametrieren zu können - beispielsweise mit 10s Scanzykluszeit. Es wird damit eine durchaus brauchbare Kenngrößenbildung in Form eines Faktors möglich, der direkt proportional der Verweildauer der Fahrzeuge innerhalb des Empfangskorridors entspricht.
Anstieg des arithmetischen Mittelwerts der am Ende eines Abschnitts errechneten Reisezeiten.
Die beiden Werte der errechneten Reisezeit der auf einem Abschnitt befindlichen Gruppen (LKW und PKW) können durchaus Störfälle implizieren im Falle, dass ein plötzlicher Anstieg oder Abfall einer/beider Werte zu beobachten ist. Dies könnte sowohl ein Störfall im besagten Abschnitt als auch im darauffolgenden Abschnitt sein.
Fehlende BT-Adressen am Ende eines Abschnitts.
Dieser Ansatz geht davon aus, dass innerhalb einer bestimmten Zeit eine Stichprobe am Ende des Abschnitts wieder gescannt werden sollte, so nicht eine Fahrtunterbrechung oder sonstiges eingetreten ist. Mit einer Faktor-Bildung könnte dies zu einer Störfallerkennung beitragen.
Klassifizierung der BT-Adressen nach LKW/PKW.
Könnte über mehrere Beobachtungsabschnitte mit Bezug auf die errechnete Reisezeit erfolgen.
Fusionierung aller Störfallparameter.
Eine zuverlässige Indikation eines Störfalls kann aber nur die Fusionierung aller gewonnen Parameter sein kombiniert mit dem Abgleich von historischen Tagesgängen.
Tabelle 3: Mischverteilungsanalyse eines Werktages
Mit Hilfe einer Mischverteilungsanalyse kann man auf Grund einer vorliegenden Stichprobe eine Geschwindigkeitsklassifizierung vornehmen, d.h.: es ist möglich für jede Geschwindigkeits-Gruppe die jeweiligen Kennzahlen, wie durchschnittliche Geschwindigkeit und Streuung zu ermitteln.
Ergebnis BLIDS V30, Messung an MS Kitzingen und MS Wolfsgraben:
Sensor: BLIDS V30 (modifizierter BLIDS-Sensor, aktuellste Version)
Zeitraum: 21.06.2010 (0.00 Uhr) bis 27.06.2010 (23.59 Uhr)
BT-Erfassungsquote:
Im Querschnitt (richtungsunabhängig, beide Fahrtrichtungen) Anzahl der BT-Scans bezogen auf die Gesamtanzahl der vorbeifahrenden Fahrzeuge (ohne Mehrfach-Scans, die etwa durch langsam vorbeifahrende Fahrzeuge verursacht werden).
Tabelle 4: BT-Erfassungsquote
Detektionsquote (Pärchenbildung):
Als Anzahl der ermittelten BT-Pärchen bezogen auf die Anzahl der in der jeweils betrachteten Richtung vorbeifahrenden Fahrzeuge, Fahrtrichtung Süden Kitzingen nach Wolfsgraben bzw. Fahrtrichtung Norden Wolfsgraben nach Kitzingen.
Tabelle 5: Detektionsquote (Pärchenbildung)
3.2 Verkehrsüberwachung in urbanem Gebiet
Bild 9: Reisezeit über BLIDS-webPortal
Wie aus der Abbildung 9 zu erkennen sind die Messstationen an Stadteinfahrtsstraßen positioniert und könne sowohl als Verkehrsparameter für Verkehrsbeeinflußungsanlagen dienen als auch als Qualitätssicherungsmaßnahme um der Öffentlichkeit die Wirksamkeiten von Verkehrsbeeinflußungsmaßnahmen zu erläutern.
3.3 Allgemeine Messaufgaben
Auszüge aus dem Bericht: ‚Untersuchung einer Telematiklösung für die Insel Usedom‘, Logos, Ingenieur- und Planungsgesellschaft mbH
Aus Sicherheitsgründen (Diebstahl) wurden 9 Sensoren in Schaltschränken von LSA- Steuergeräten oder den Streckenstationen (Zählstellen) untergebracht. Damit war auch die Stromversorgung der Sensoren gesichert. Am Standort Redoute wurde ein Leerschrank gestellt. Hier erfolgte die Stromversorgung über einen Akku. Folgende Standorte wurden ausgerüstet:
Bild 10: Verkehrserhebung auf Usedom
In den Sommermonaten kann das Straßennetz den Verkehr nicht mehr bewältigen. Die Verkehrsstärke q übersteigt die Kapazität C des jeweiligen Fahrstreifens.
Bild 11: Online-Web-Darstellung der Datenerfassung
Die Onlinedaten werden alle 30 Sekunden aktualisiert. Dies ermöglicht eine zeitnahe Feststellung der tatsächlichen Reisezeiten eines jeden Streckenabschnittes. Dargestellt sind zunächst alle vorhandenen Stationen (A bis J) und die Anzahl der jeweiligen erfassten Bluetoothsignale innerhalb der letzten 15 min oder des letzten Zeitfensters in dem mindestens 5 Pärchen gezählt wurden. Des Weiteren werden die aktuellen Reisezeiten aller Routen mit der jeweiligen Anzahl der gefundenen Bluetooth-Pärchen dokumentiert.
4 BLIDS – Systemübersicht
4.1 Hardware
4.1.1 Sensor
1. BLIDS-Sensor
2. Netzteil - 24 Volt Netzteil
3. Kabelklemme
4. Kombinierte GSM und GPRS-Antenne
5. Bluetooth-Antenne
6. Klebepad für die Kombi-Antenne
4.1.2 Server
Bild 12: BLIDS Server Software 'Installer' für Windows Server
Bild 13: BLIDS Server Konfigurations-/Verwaltungssoftware
In der Status-Anzeige werden die Informationen über die dem Projekt zugeordneten Sensoren angezeigt.
Die zulässige Hardware, die für eine Windows Installation zu verwenden ist kann folgendermaßen zusammengefasst werden:
2 GB Hauptspeicher
Mindestens 150 GB Festplattenspeicher
Microsoft Windows Server 2003 SP2 Microsoft-IIS 6.0
.NET 3.5 SP1
ASP.NET MVC 1.0
Offene Ports: 25 für Email Benachrichtigung und 21 für Ftp Uploads
4.1.3 Analyse/Auswertung/Frontend
Für die Analyse der erhobenen Daten wurden unter anderem auch parametrierbare Filteralgorithmen entwickelt, die bei wichtigen errechneten Verkehrsdaten, wie die Reisezeit zwischen zwei oder mehreren Messpunkten, die für die Fragestellung unrichtigen Daten wie Fußgänger, Fahrtunterbrecher, Quell-/Zielverkehr etc. aus den Rohdaten herausfiltern. [10]
Diese teilen sich in statische und dynamische Filter, die auch das Thema der zu berücksichtigenden Zeitstempeln bei Mehrfacherfassung aufgrund von langsamen Verkehrsbewegung an den Messstationen berücksichtigt.
4.1.4 Wirtschaftliche Betrachtung
Die folgenden Listenpreise beziehen sich auf ein Lizenzmodell, das alle notwendigen Hardware- und Softwarekomponenten beinhaltet (siehe 4.1.1 und 4.1.2). Für den Betrieb fallen somit keine weiteren laufenden Kosten an (Ausnahme: Datenverbindungskosten)
Anwendungsbereich Autobahn: 1.400,-€/Sensor
Anwendungsbereich urbanes Gebiet: 7.200,-€/Sensor
Achtung: Server-Systemvorraussetzungen wie Hardware und Betriebssystem sind im Preis nicht enthalten.
5 Literatur
5.1 Schriftenreihen
[1] Gerhard Krottmaier, Statistische Evaluierung der Genauigkeit von BLIDS Messsystemen für unterschiedliche Verkehrsszenarien, Diplomarbeit an derTechnische Universität Graz, 2010
[2] Andreas Grinschgl, Kryptographische Anonymisierung bei Verkehrsflussanalysen, Institut für Angewandte Informationsverarbeitung und Kommunikationstechnologie (IAIK), Diplomarbeit an der Technische Universität Graz, 2010
[3] Brian S. Peterson, Member, IEEE, Rusty O. Baldwin, Senior Member, IEEE, and Jeffrey P. Kharoufeh, Bluetooth Inquiry Time Characterization and Selection, 2006
[4] Martin Margreiter, Reisezeitberechnung und Störungserkennung mit Bluetooth- Kennungen, Masterarbeit am LEHRSTUHL FÜR VERKEHRSTECHNIK - TECHNISCHE UNIVERSITÄT MÜNCHEN, 2010
5.2 Online-Quellen
[5] http://de.wikipedia.org/wiki/Verkehrstelematik
[6] http://www.bluetooth.com/English/Technology/Works/Pages/Overview_of_Operation.asp x
[7] http://www.vs.inf.ethz.ch/publ/se/handy_iuk2003.pdf
5.3 Anwender/Kundenberichte
[8] BLIDS-Network im Auftrag der Autobahndirektion Nordbayern, Bericht 14.07.2010
[9] ‚Untersuchung einer Telematiklösung für die Insel Usedom‘, Logos, Ingenieur- und Planungsgesellschaft mbH, 2010
[10] Traveling time – Filter algorithms, Granit Luzhnica, c.c.com GmbH, 2010 |
