Location Based Services für den öffentlichen Verkehr

Fachhochschule Darmstadt - Fachbereich Informatik
Location Based Services für den
öffentlichen Verkehr
Bachelorarbeit
am Fachbereich Informatik
Fachhochschule Darmstadt
von
Bastian Fincke
Referenten:
Prof. Dr. W. Fuhrmann
Prof. Dr. J. Reichardt
Entstanden in Zusammenarbeit mit:
T-Systems Nova GmbH Technologiezentrum
Am Kavalleriesand 3
64295 Darmstadt
www.t-systems.de
Tag der Abgabe:
26. April 2004
Verfassererklärung
Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfaßt und keine anderen
als die angegebenen Quellen und Hilfsmittel verwendet habe.
Darmstadt, den 26. April 2004
Bastian Fincke
Rhönring 107
64289 Darmstadt
Fachhochschule Darmstadt - Fachbereich Informatik
Matrikelnummer 627 991
Inhaltsverzeichnis
1 Einleitung und Aufbau der Arbeit
2
2 Definitionen
4
2.1
Location Based Services . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Mobiles Endgerät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Nutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4
Öffentlicher Verkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.5
WGS84 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.6
Gauß-Krüger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.7
Points of Interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3 Location Based Services
3.1
3.2
Möglichkeiten zur Ortsbestimmung . . . . . . . . . . . . . . . . . . . .
8
3.1.1
Manuelle Eingabe . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.2
Ortsbestimmung per Satellit . . . . . . . . . . . . . . . . . . . .
8
3.1.3
Mobilfunkbasierte Möglichkeiten der Ortsbestimmung . . . . . .
11
3.1.4
Übersicht über die verschiedenen Möglichkeiten . . . . . . . . .
12
Von Koordinaten zum Ort . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4 Anwendungen für den öffentlichen Verkehr
4.1
4.2
8
15
Voraussetzungen und Möglichkeiten . . . . . . . . . . . . . . . . . . . .
15
4.1.1
Fernverkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.1.2
Nahverkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.1.3
Sightseeing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Vorhandene Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.2.1
HEAG Verkehrs-GmbH Darmstadt . . . . . . . . . . . . . . . .
17
4.2.2
Berliner Fenster . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.2.3
TRAIN-INFOSCREEN Hamburg . . . . . . . . . . . . . . . . .
18
4.2.4
Fahrinfo SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2.5
Electronic-Onboard-Ticketing Uni Augsburg . . . . . . . . . . .
19
1
Inhaltsverzeichnis
5 LBS4FIBB und TrainGuide
5.1
5.2
5.3
5.4
5.5
Vorstellung des Projektsystems . . . . . . .
Analyse und Design . . . . . . . . . . . . .
5.2.1 Anforderungsanalyse . . . . . . . .
5.2.2 Bildschirmübersicht . . . . . . . .
5.2.3 Programmablauf für den Nutzer . .
Programmaufbau . . . . . . . . . . . . . .
5.3.1 Positioning . . . . . . . . . . . . .
5.3.2 Anwendungsarchitektur . . . . . .
Die einzelnen fertigen Module . . . . . . .
5.4.1 Datenbank . . . . . . . . . . . . .
5.4.2 LBS4FIBB . . . . . . . . . . . . .
5.4.3 TrainGuide . . . . . . . . . . . . .
5.4.4 Administrationsseite für LBS4FIBB
5.4.5 Übersichtskarte . . . . . . . . . . .
Standort bestimmen Ausblick für LBS4FIBB und TrainGuide . .
20
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
21
21
23
23
24
24
25
27
28
29
32
34
34
. . . . . . . . . . . . . . . .
35
6 Schlussbetrachtung
37
Literatur
39
7 Anhang
40
1. Einleitung und Aufbau der Arbeit
Diese Arbeit ist im Rahmen einer studienbegleitenden Zusammenarbeit mit dem Technologiezentrum Darmstadt entstanden. Das Technologiezentrum ist eine Business Unit der
T-Systems Nova, die wiederum ein Tochterunternehmen der Deutschen Telekom AG ist.
Das Thema dieser Arbeit - Location Based Services (LBS) für den öffentlichen Verkehr
- hat sich im Verlauf der Praxisphase bei T-Systems entwickelt, wobei die Abkürzung
„LBS“ im mobilen Bereich stehender Begriff geworden ist. Mit der Bezeichnung „Öffentlicher Verkehr“ kann zum einen ein Fernverkehrszug, aber auch eine Straßenbahn im
Nahverkehr oder ein Bus, der für Sightseeing genutzt wird, gemeint sein. Auch ein Taxi
ist ein öffentliches Verkehrsmittel, hier sind LBS aber derzeit noch weniger oder gar nicht
von Bedeutung.
Vielen Studien sagen LBS in den nächsten Jahren grosse Wachstumschancen voraus, weshalb die Entwicklung von marktfähigen Systemen zur Zeit von vielen Mobilfunkprovidern
vorangetrieben wird.
Am Anfang der Arbeit steht die Definition wichtiger Begriffe. Hier wird geklärt, was LBS
genau sind und welche Vorteile Nutzer daraus ziehen können. Wichtig ist hierbei, gleich
am Anfang zu definieren, auf welcher Art von Geräten die Anwendungen laufen sollen.
Daher wird der Begriff „Mobiles Endgerät“ geklärt werden, zu dem sich in der Literatur
verschiedene Definitionen finden. Schliesslich werden auch Ortungsinstrumente genauso
wie die dazu benötigten Koordinatensysteme beschrieben.
Im 3. Kapitel wird genauer auf LBS eingegangen. „Worum handelt es sich ?“ und „Wie
funktionieren LBS?“ sind hier wichtige Fragen. Darüber hinaus geht es allgemein um
3
Lokalisierungs- und Einsatzmöglichkeiten sowie die Vor- und Nachteile von LBS. Grundlage vieler Lokalisierungsvorgänge sind Koordinatensysteme, von denen aus eine Abbildung in den realen Raum benötigt wird, um dem Nutzer verwertbare Informationen geben
zu können.
Im Folgenden geht es um konkrete Anwendungsbereiche von LBS für den öffentlichen
Verkehr, aufgeschlüsselt nach den verschiedenen Arten von Verkehrsmitteln. Erst wird
der Aufbau von Anwendungen allgemein, anschließend unterschiedliche Anwendungensideen im Einzelnen betrachtet. Weiterhin werden in diesem Kapitel unterschiedliche bereits in Benutzung befindliche Anwendung vorgestellt, z.B. die Fahrzeuglokalisierung der
Darmstädter HEAG Verkehrs GmbH als einfaches Beispiel für Haltestellenansagen und
Terminals an Haltestellen als grundlegende ortsbezogene Dienste.
Im darauf folgenden Kapitel steht ein Beispiel aus der Praxis im Vordergrund: Der Demonstrator für Fast Internet in Bus und Bahn und die darauf aufbauende LBS-Anwendung,
die Nutzern Ortsinformationen zur Verfügung stellt. Dieses Kapitel fußt direkt auf der Zusammenarbeit mit T-Systems.
Insgesamt geht es in dieser Arbeit um bestehende Informationssysteme für den öffentlichen Verkehr. Ihre Funktionsweise und ihr Aufbau werden hier genauso behandelt wie
der Versuch gemacht, einen generellen Überblick über bestehende Systeme zu geben. Als
Letztes wird ein Versuch gewagt, die kommende Entwicklung abzuschätzen.
Im Anhang befindet sich eine CD mit einer Anleitung und aller zur Installation des bei
T-Systems entstandenen Systems benötigten Dateien. Selbstverständlich ist hier auch der
komplette Sourcecode enthalten.
2. Definitionen
2.1 Location Based Services
Location Based Services, auch „Dependent Services“ oder „Ortsbezogene Dienste“ genannt, sind normaler Weise mobile Angebote, die auf den jeweiligen Aufenthaltsort des
Nutzers Bezug nehmen. Hjelm schreibt in seinem Buch [Hjel02]:
„The concept Location-Dependent Services usually refers to wireless services
dependent on a certain location, for example, the location of the requesting
mobile station.“
Weiterhin unterscheidet Hjelm zwei verschiedene Typen von Anwendungen:
• User-requested
• Triggert-Services
Bei User-requested Anwendungen bekommt das System einmal die Position übermittelt
und generiert dadurch eine passende Information für den Nutzer. Ein Beispiel:
• Der Benutzer schreibt eine SMS mit dem Inhalt „Taxi Darmstadt“
• Das System antwortet ihm mit der Nummer eines oder mehrerer lokaler Taxianbieter.
Triggert-Services-Anwendungen laufen normalerweise länger und interagieren mit dem
Benutzer. Der Server erhält in regelmäßigen Abständen, während die Anwendung läuft,
aktuelle Positionsdaten des Nutzers und verarbeitet diese zum Beispiel zu einer Position auf einer Karte oder zu einem Bewegungsprofil. Turowski und Pousttchi ergänzen in
ihrem Buch [TuPo04, Seite 73]:
2.2. Mobiles Endgerät
5
„Ortsbezogene Dienste (Location Based Services, LBS) sind Dienste,
• die über mobile elektronische Kommunikationstechniken (typischerweise Mobilfunk) zur Verfügung gestellt werden,
• für deren Ausführung der aktuelle Standort des dienstaufrufenden Nutzers (und/oder eines anderen Nutzers) bekannt sein muss und
• deren Ausführung abhängig von diesem Standort erfolgt.“
Diese Arbeit setzt sich im Speziellen mit Diensten auseinander, die den Aufenthaltsort des
Verkehrsmittels, nicht wie die meisten LBS den Ort des Nutzers, als Grundlage nehmen.
Weiterhin geht es um Triggert-Services, da der Aufenthaltsort des Verkehrsmittels dem
Server (der sich sogar darin befinden kann) durchgängig zur Verfügung steht und der
Server somit auf den jeweiligen Aufenthaltsort reagieren kann.
2.2 Mobiles Endgerät
In [TuPo04] wird ein mobiles Endgerät hauptsächlich durch zwei Kriterien beschrieben:
1. Allgegenwärtigkeit
2. 1:1-Beziehung zum Nutzer
Eines der besten Beispiele hierfür ist das Mobiltelefon. Es ist normalerweise genau einem
Benutzer zugeordnet, der es (fast) immer bei sich hat oder zumindest haben kann. Ein
Laptop erfüllt diese Kriterien nicht in dem selben Maße, deshalb bezeichnen Turowski
und Pousttchi es ausdrücklich nicht als mobiles Endgerät, sondern als Arbeitsplatzrechner
[TuPo04, Seite 57], den man zwar leicht mitnehmen kann, der aber zu seiner Einsatzfähigkeit eine gewisse Infrastruktur benötigt.
Abweichend hiervon gelten Laptops in dieser Arbeit als mobile Endgeräte. Dies hat folgenden Hintergrund: In vielen Verkehrsmitteln gibt es mittlerweile Anschlüsse, um z.B.
Laptops anzuschließen, und mit einer mittleren Akkulaufzeit von drei Stunden kann ein
Laptop sinnvoll mobil genutzt werden. Über die oft eingebauten WLAN- oder BluetoothSchnittstellen kann dieser leicht und kostengünstig in ein vorhandenes Netz eingebunden
werden.
Andere mögliche Endgeräte sind PDA1 , da auf ihren Displays schon einiges an Informationen dargestellt werden kann. Neuere PDA haben WLAN- oder Bluetooth- Schnittstellen und können somit, genau wie Laptops, eingebunden werden.
1
Personal Digital Assistent
2.3. Nutzer
6
Bei Handys und Smartphones sind die Displays sehr klein und Netzanbindungen nicht
so leicht möglich, wie bei den beiden oben genannten Geräten. Eine Möglichkeit, diese
in ein Netz einzubinden, wäre hier die Infrarotschnittstelle. Aber auch, wenn Infrarotanschlüsse sehr billig sind, wären sehr viele Schnittstellen erforderlich und es gäbe weitere
Probleme, z.B. müsste generell eine Sichtverbindung bestehen. Auch eine Anbindung per
GPRS oder UMTS ist nicht unproblematisch, da auf der Basis aktueller Gebührenstrukturen hohe Verbindungsentgelte entstehen können und die Zuordnung des Nutzers zu einem
bestimmten Verkehrsmittel nicht mehr möglich ist.
2.3 Nutzer
Der Nutzer ist ein Fahrgast des öffentlichen Verkehrs, dem es wichtig ist, die Reisezeit
sinnvoll zu nutzen und dazu ein mobiles Endgerät zur Verfügung hat. Sein Gerät läßt
sich über eine im Fahrzeug vorhandene Schnittstelle mit dem Bordnetz verbinden. Die
Schnittstelle kann ein normaler Netzwerkanschluss per Kabel, aber auch WLAN oder
Bluetooth sein.
2.4 Öffentlicher Verkehr
Der öffentliche Verkehr, auf den sich diese Arbeit bezieht, beinhaltet zunächst alle nicht
individuellen Verkehrsmittel, wie z.B. Busse oder Bahnen. Am interessantesten sind sicher Verkehrsmittel, die der Nutzer über einen längeren Zeitraum benutzt, da er beispielsweise in einer S-Bahn, in der er sich nur fünf bis zehn Minuten aufhält, kaum seinen
Laptop anschalten wird.
2.5 WGS84
Das WGS84 ist eines von vielen Koordinatensystemen und wird von Winfried Böhm in
[Böhm03] wie folgt erklärt:
„Das World Geodetic System 1984 ist ein international vereinbartes Bezugssystem, das auf der nur kugelähnlichen Erde[...]einen bestimmten Referenzpunkt definiert, um beliebige andere Punkte positionsmässig festlegen zu können.“
Ein Vorteil von diesem System ist, dass es die ganze Welt umspannt und nicht wie viele
andere Koordinatensysteme nur für einen Ausschnitt gebraucht werden kann. Das WGS84
wird oft in Dezimalnotation, aber auch in Gradnotation genutzt. Die meisten GPS-Geräte
liefern Gradnotation, da man mit dieser aber nur schwer rechnen kann, wird oft das Dezimalsystem verwendet. Beispiele dazu siehe unten.
2.6. Gauß-Krüger
7
2.6 Gauß-Krüger
Das Landesamt für Vermessung und Geobasisinformation Rheinland-Pfalz [LVG04] definiert die Gauß-krüger Koordinaten wie folgt:
„Gauß-Krüger-Koordinaten sind ebene rechtwinklige Koordinaten, die aus
Rechts- und Hochwert (zweidimensional) bestehen. Die Erdoberfläche -annähernd
eine Kugel- muß in eine Ebene abgebildet werden. Hierbei soll die Längen-,
Winkel- und Flächentreue möglichst gewahrt werden. Zur Vermeidung störender Abbildungsverzerrungen auf die Gauß-Krüger-Abbildungsebene dürfen die Rechtswerte bestimmte Beträge nicht überschreiten. Es wurden daher Abbildungsstreifen mit einer seitlichen Ausdehnung von drei Längengraden (Meridianstreifensysteme) festgelegt. Der Rechtswert eines Punktes ist
dann der senkrechte Abstand vom Mittelmeridian des Abbildungsstreifens.
Der Hochwert ist der Abstand des Punktes vom Äquator, gemessen entlang
des Mittelmeridians.“
Zum Vergleich: Hauptbahnhof Darmstadt
Länge: 49◦ 52’ 36”
Breite: 8◦ 37’ 88”
WGS84 Dezimal Länge: 49,872738
Breite: 8,631415
Gauß-Krüger
Rechtswert: 3473578.97m
Hochwert: 5526320.26m
WGS84 in Grad
2.7 Points of Interest
Punkte, die für den Nutzer interessant sein könnten, nennt man Points of Interest, abgekürzt POI. Interessante Punkte, sind verschiedene Orte, an denen das betreffende Verkehrsmittel direkt oder indirekt vorbeikommt. Hier wird auch die Möglichkeit gegeben,
Werbung für lokal Gewerbetreibende einzufügen.
3. Location Based Services
3.1 Möglichkeiten zur Ortsbestimmung
Bei der Ortsbestimmung unterscheidet man generell zwei Vorgehensweisen. Findet das
Gerät selbst seinen Standort heraus, so benennt man das mit dem englischen Wort positioning, das man nicht mit dem deutschen Wort positionieren verwechseln sollte. Positioning
kann z.B. durch ein eingebautes GPS-Gerät erfolgen.
Liegt die Ortungsinstanz außerhalb des Geräts, so spricht man von tracking. Dies kann in
einem Mobilfunktnetz z.B. durch Abfrage der Cell-ID funktionieren.
3.1.1 Manuelle Eingabe
Dies ist die einfachste Art des positionings. Der Nutzer gibt z.B. in einer SMS oder auf
einer WAP-Seite seinen Standort an. Diese Art der Positionsbestimmung ist technisch
sehr einfach umsetzbar. Bei LBS für den öffentlichen Verkehr ist meist die Position des
Fahrzeuges vorrangig. Eine interessante Anwendungsmöglichkeit haben die Berliner Verkehrsbetriebe seit Februar 2004 im Angebot. Mehr dazu im Kapitel 4.2.2.
3.1.2 Ortsbestimmung per Satellit
Das bekannteste und am meisten zur satellitengestützten Postitionsbestimmung genutzte
System ist GPS. Diese Abkürzung steht für Global Positioning System. Es wurde vom
amerikanischen Verteidigungsministerium für eine militärische Nutzung im Ausland entwickelt. Wie der Name schon sagt, handelt es sich hierbei um Positioning, da das Gerät
seine Position eigenständig feststellt. Die Geräte empfangen Signale von etlichen - in der
Regel 24 - Satelliten, die in einer Höhe von ca. 20.200 km die Erde umkreisen. Die Satelliten sind dabei so angeordnet, dass von fast jedem Punkt der Erde immer mindestens
3.1. Möglichkeiten zur Ortsbestimmung
9
Abbildung 3.1: Satellitenortung aus [Hjel02]
vier Satelliten im Sichtbereich liegen. Hierbei gilt: Je näher man am Äquator ist, umso
mehr Satelliten liegen erreichbar. Dies bedeutet hier, dass ein Satellit eine direkte Luftlinie zum Empfänger hat. Wolken stören hierbei nicht, aber Wände oder ein Autodach
können ein Problem sein. Für die Standortmessung senden diese Satelliten Signale aus,
mit denen eine Laufzeitmessung möglich ist. Damit kann der Empfänger die Entfernung
zu diesen bestimmen. In den Signalen sind Uhrzeit und Standort enthalten. Mit drei Entfernungen kann man im dreidimensionalen Raum einen Standort bestimmen. Ein vierter
Satellit wird zur genauen Zeitabstimmung gebraucht. Die Genauigkeit hängt dabei immer
von mehreren Faktoren, wie Abschattung und Reflektionen durch Gebäude und Anzahl
der Satelliten im Empfangsbereich, ab. Wenn die empfangenen Signale von einem Gebäude oder einem Berg reflektiert werden, ergeben sich dadurch Verlängerungen der Laufzeit
und somit Ungenauigkeiten. Neuere GPS-Empfänger können die Signale von bis zu zwölf
Satelliten gleichzeitig empfangen, dadurch wird das Ergebnis verbessert.
Die Ausgabe eines GPS-Empfängers geschieht über das NMEA-Protokoll. Dieses Protokoll ist von der „National Marine Electronics Association“ entwickelt und standardisiert
worden. Das Protokoll besteht aus Sätzen, die bis zu 82 Zeichen lang sein können, immer
mit einem $-Zeichen beginnen und am Ende eine optimale Prüfsumme und ein CR/LF1
haben.
1
Carrige Return/Line Feed = Zeilenumbruch
3.1. Möglichkeiten zur Ortsbestimmung
10
Als Beispiel ein Satz, der während der Erstellung dieser Arbeit aufgezeichnet wurde:
$GPRMC,221025.200,A,4952.3667,N,00837.8810,E,0.23,170.85,051103„∗08
Der Reihe nach bedeutet das:
GP
GPS Empfänger
RMC
Recommended minimum sentence C = Minimaler Satz
221025
Uhrzeit 22:10:25
A
Daten in Ordnung,
alternativ V Warnung
4952.3667 Grad nördliche Breite und
837.8810
östliche Länge nach dem WGS84 System
0.23
Geschwindigkeit des Empfängers in Knoten
170.85
Kurs des Empfängers (0 bei Stillstand)
Datum
5.11.2003
∗08
Prüfsumme
DGPS
DGPS steht für Differential-GPS. Hierbei errechnet eine feststehende Station mit einem
genau bekannten Standort einen Fehlerkorrekturwert für jeden einzelnen im Sichtbereich
befindlichen Satelliten. Diesen Korrekturwert gibt sie dann per Funk, meist über ein FMRadio-Netzwerk an mögliche DGPS-Empfänger weiter. Diese benutzen den Wert dann,
um ihre eigene Position genauer zu bestimmen.
Assisted GPS
Einem Assisted-GPS (A-GPS) Empfänger wird z.B. von einem Mobilfunkbetreiber beim
Anschalten eine ungefähre Schätzung gegeben, wo das Gerät sich gerade befindet. Somit
ist dem Gerät in etwa bekannt, wo es die Satelliten suchen muss, und kann dann relativ
schnell die vorhandenen Positionsdaten verbessern. Zum Vergleich schafft ein AssistedGPS-Gerät eine Positionsbestimmung innerhalb von etwa einer Minute. Ein Kaltstart eines nicht Assisted-GPS-Gerätes, das somit noch keine möglichen Positionsdaten hat, dauert bis zu zwölf Minuten.
A-GPS ist somit eine zweigeteilte oder Hybrid-Lösung. Es ist Tracking und Positioning
in einem, da es sowohl geortet wird, als auch selbst seine Position bestimmt.
3.1. Möglichkeiten zur Ortsbestimmung
11
Weitere satelitengestützte Ortungssysteme
Alternative satellitengestütze Navigationsysteme sind Glonass und Galileo. Glosnass ist
ein System aus Russland, das außerhalb Russlands wenig verbreitet ist. Galileo ist ein Projekt der Europäischen Union, das die Unabhängigkeit vom amerikanischen GPS-System
zum Ziel hat. Bis jetzt ist das System noch in der Planung. Bis zur Realisierung werden
sicherlich noch einige Jahre vergehen.
3.1.3 Mobilfunkbasierte Möglichkeiten der Ortsbestimmung
Hierfür gibt es bereits verschiedene Optionen. Beachten sollte man hierbei, dass diese
Daten vom Mobil Service Provider zur Verfügung gestellt werden müssen. Damit ist man
erstens abhängig und zweitens ist das aus datenschutzrechtlichen Gründen kritisch zu
sehen. Durch die 1:1-Beziehung eines Nutzer zu seinem Handy kann man hier Bewegungsprofile aufnehmen und natürlich auch speichern. Aber dies sei hier nur am Rande
erwähnt.
Cell-ID und Cell-ID++
Die Ortsbestimmung über Cell-ID ist eine Form des Trackings. Die Technik beruht darauf,
dass jeder Nutzer eines Mobilfunkgerätes, der im Netz unterwegs ist, immer in genau einer Zelle angemeldet ist, und zwar meist in der, von deren Antennen er das stärkste Signal
empfängt. In einer Datenbank sind nun die Koordinaten des Mittelpunktes der Zelle angegeben. Somit ist der ungefähre Aufenthaltsort des Nutzer bekannt. Die Genauigkeit hängt
somit von der Größe der Zelle ab und ist innerhalb von Städten und Ballungsgebieten ca.
100 bis 150 Meter, auf dem Land kann das mehrere Kilometer ausmachen. Manche Zellen
sind noch in Einzelstücke unterteilt, sogenannte „sectored cells“ , die es ermöglichen, den
Aufenthalt genauer zu bestimmen. Das System nennt man dann Cell-ID++.
Observed Time Difference
Unter diesem Namen lassen sich zwei sehr ähnliche Verfahren zusammenfassen. Bei Enhanced Observed Time Difference (E-OTD) und Observed Time Difference of Arrival
(OTDOA) werden die Entfernungen zu mindestens 3 Antennen gemessen, indem man
ähnlich wie bei GPS die Zeit mißt, die die Signale zwischen Antenne und mobilem Endgerät brauchen. Beim E-OTD wird die Messung vom Handy durchgeführt, es stellt die
Zeit fest, die die Funksignale von der Basisstation zum mobilen Endgerät benötigen. Somit handelt es sich um Positioning.
Im Gegensatz dazu wird beim OTDOA die Zeit gemessen, die Signale vom Handy zu
mindestens 3 Basisstationen brauchen. Diese Zeiten werden an eine Measurement-Unit
geleitet und dort vom Mobilfunkprovider ausgewertet. Die Ortsinformation ist jetzt nicht
mehr im Handy vorhanden, damit ist OTDOA klar ein Tracking-Verfahren. Beide Verfahren erreichen eine Genauigkeit von ungefähr 50 bis 150m.
12
3.1. Möglichkeiten zur Ortsbestimmung
Angel of Arrival
Angel of Arrival (AOA) ist ein weiteres Ortungssystem: Hier wird durch eine spezielle
Antennenkonstellation zu drei verschiedenen Basisstationen der Winkel des ankommenden Signals berechnet. Auch diese Daten werden wieder an eine Measurement-Unit weitergeleitet, diese ermittelt die drei Winkelgeraden, an deren Schnittpunkt sich dann das
mobile Endgerät befindet. Die Genauigkeit entspricht der von OTDOA und E-OTD. Da
auch hier die Ortung vom Mobile Service Provider durchgeführt wird, ist auch dieses ein
Trackingsystem.
3.1.4 Übersicht über die verschiedenen Möglichkeiten
Frank Felten von der VIAG Interkom GmbH & Co hat in dem Buch [TeLe02] eine Übersicht über die verschiedenen Lokalisierungsverfahren zusammengestellt:
C-ID
C-ID++
AOA
E-OTD
OTDOA
GPS
A-GPS
Netz
Netz
Netz
Hybrid
Netz
Endger.
Hybrid
Genauigkeit
--
-
-
+
0
++
++
Geschwindigkeit
++
++
++
+
0
--
+
Abhängigkeit v. Umweltfaktoren s.u.
++
-
-
+
0
-
-
Netzwerkseitiger
Aufwand
++
++
0
0
0
++
0
Endgeräteseitiger
Aufwand
++
++
++
0
++
--
--
Netz- oder Endgerätebasiert
Legende: ++...beste Leistung, 0...mittlere Leistung, - -...schlechteste Leistung
„Zur Abhängigkeit von Umweltfaktoren: Wind, Regen, Vegetation, hohe Gebäude oder
besondere topographische Konstellationen können zur Reflexion von Mobilfunksignalen („Multi-Path“-Effekte) oder zur Beeinflussung von Signalstärken führen, die bei den
unterschiedlichen Verfahren mehr oder weniger ins Gewicht fallen.“
Aus der Tabelle sieht man deutlich, dass es große Unterschiede bei den verschiedenen
Möglichkeiten gibt. Bei der Auswahl einer Positioningart sollte man beachten, dass alle
Möglichkeiten, die Daten aus dem GSM-Netz brauchen, nur beim Mobile Service Provider (MSP) vorhanden und so von außerhalb nur schwer zu bekommen sind. Somit bietet
sich GPS - oder später Galileo - für den öffentlichen Verkehr an, sobald keine Zusammenarbeit mit einem MSP vorhanden ist.
3.2. Von Koordinaten zum Ort
13
3.2 Von Koordinaten zum Ort
Problematisch bei LBS ist es, von Koordinaten zu einem realen Ort zu kommen. Wenn
ein System Koordinaten hat, dann weiß es natürlich noch nicht, wie die zugehörige Straße heißt, oder welche POI in der Nähe sind. Die Abstraktion von einem Punkt, ermittelt
mit einem der Ortungsverfahren, zu einem bestimmten Ort ist also schwierig. Einfach
nur jeden POI in einer Datenbank abzuspeichern, reicht nicht. In diesem Fall würde die
Übersetzung von den Koordinaten, die vom Ortungssystem kommen, zum Ort (z.B. Straßennamen) des POI fehlen.
Um dieses Problem zu lösen gibt es mehrere Ansätze, von denen zwei hier vorgestellt
werden sollen.
Die erste Möglichkeit ist, in einer Datenbank zu jedem POI die Koordinaten in einem
rechtwinkligen Koordinatensystem abzuspeichern. Dies ist wichtig, damit in regelmäßigen Abständen die Entfernung zu diesem Punkt mit geringem Aufwand berechnet werden
kann. Der POI ist dann im Programm zu erwähnen, sollte der berechnete Abstand geringer
als ein vorher festgelegter, zu diesem POI spezifischer Radius sein. Da sich der Aufwand
linear mit der Anzahl der Punkte vergrößert, funktioniert dieses Verfahren so nur mit einer
begrenzten Anzahl von Punkten. Bei einer hohen Anzahl von Punkten müssen diese nach
Gebieten sortiert werden. Wenn dem System bekannt ist, dass ein POI sehr weit entfernt
ist, dann kann daher auch der Nachbarpunkt nicht viel näher sein.
Zur Vereinfachung kann man auch noch für jeden POI jedesmal einen Faktor X berechnen:
X (m) = Geschwindigkeit (m/s) * Zeit (s)
Sollte die zuletzt errechnete Entfernung abzüglich dieses Faktors größer als der zum POI
gehörende Radius sein, so muss die Entfernung nicht neu berechnet werden. Es reicht,
das Ergebnis der Subtraktion als Entfernung abzuspeichern. Sollte die Entfernung kleiner
als der Radius sein, muss die Entfernung neu berechnet werden, da die Richtung des
zurückgelegten Weges nicht bekannt ist. Wichtig hierbei ist, dass die Abwägung, ob die
Entfernung zu einem Punkt berechnet wird oder nicht, nicht mehr Rechenzeit kostet, als
das Ausrechnen der Entfernung selber. In einem rechtwinkligen Koordinatensystem ist
das eine Anwendung des Satzes des Pythagoras, und somit nur ein geringer Aufwand.
Eine andere Möglichkeit ist es, mit allen POI einen Nachbarschaftsgraph aufzubauen.
Die einzelnen Knoten sind die POI, die verbindenden Kanten stehen für die Nachbarschaftsbeziehung zwischen den Punkten und eventuell der Entfernung. Um die POI vom
Ort her besser beschreiben zu können, sollte man eine Bounding Box um diese bilden und
diese dann abspeichern. Ein GPS Gerät liefert nicht nur die Koordinaten, sondern auch die
3.2. Von Koordinaten zum Ort
14
Abbildung 3.2: Nachbarschaftsgraph
Richtung, in der sich das Fahrzeug bewegt. Somit wäre es sinnvoll, einer Kante auch noch
eine Himmelsrichtung als Beschreibung zu geben. Somit kann das System abschätzen in
Richtung welches POI sich das Fahrzeug bewegt.
Zu erwähnen ist, dass es ein Problem bei allen LBS ist, eine gute Datenbank aufzubauen. Denn so ein System macht nur dann Sinn, wenn es auf eine hohe Anzahl an POI
zurückgreifen kann. Und von all diesen POI muss eine genaue Positionsangabe, in dem
benutzten Koordinatensystem, gemessen werden.
Abschliessend ist darauf hinzuweisen, dass LBS4FIBB auf der vorher gennannten ersten
Möglichkeit beruht.
4. Anwendungen für den öffentlichen
Verkehr
4.1 Voraussetzungen und Möglichkeiten
LBS-Anwendungen im öffentlichen Verkehr können sehr unterschiedlich sein. Die bekannteste ist die Haltestellenansage. Der Server im Fahrzeug erkennt, entweder durch
Eingabe des Fahrers oder durch verschiedene Techniken - wie in Kapitel 3 beschrieben -,
seinen Aufenthaltsort und weist durch eine Anzeige und/oder eine Lautsprecherdurchsage die Fahrgäste auf die nächste Haltestelle und evtl. Anschlußmöglichkeiten hin. Je nach
Verkehrsmittel macht es aber wenig Sinn, eigens dafür einen Computer einzusetzen. In
einem Flugzeug z.B. kann dies ganz leicht eine Stewardess oder der Pilot übernehmen,
da die Anzahl der Stops sehr gering im Verhältnis zur Zeit ist. Dafür gibt es bei vielen
Airlines schon einen Bildschirm im Flugzeug, an dem der Fluggast auf einer Karte die
Strecke verfolgen kann.
Wichtig für die Akzeptanz eines solchen Systems ist, dass die Investitionen in Zeit und
Geld für den Benutzer in einem guten Verhältnis zur Leistung stehen. Einem Fahrgast
einer S-Bahn, der die nächsten Haltestellen wissen will, kann man nicht zumuten, seinen
Laptop hochzufahren, die Netzwerkeinstellungen vorzunehmen und dann vielleicht noch
ein Programm herunterzuladen.
Deshalb sollte bei allen Anwendungen, bei denen ein Nutzer sein eigenes mobiles Endgerät nutzt, darauf geachtet werden, dass er am besten nur Standardsoftware braucht, um
den Dienst zu nutzen. Optimal ist hier natürlich ein Browser, da auf fast allen Systemen
mindestens einer installiert ist. Ein Browser ist eine standardisierte Schnittstelle, die leicht
zu benutzen ist. Über einen entsprechend konfigurierten Access Point ist es möglich, auf
dem Gerät eine bestimmte Seite zu öffnen, und somit dem Nutzer Dienste direkt zur Verfügung zu stellen.
4.1. Voraussetzungen und Möglichkeiten
16
Die Verbindung des Mobilen Endgerätes sollte über WLAN oder Bluetooth funktionieren. Dies sind Standardprotokolle, die heute den Stand der Technik darstellen. Aber auch
eine Verbindung per Netzwerkkabel ist möglich und kann eine gute Ergänzung sein. Bei
Verbindungen über Netzwerkkabel oder Bluetooth ist die Reichweite so gering, dass man
den Nutzer auch im Verkehrsmittel sehr genau lokalisieren kann, und es somit auch möglich ist, Tickets auf diesem Weg zu kaufen, ohne dass der Nutzer genauere Informationen
eingeben muss. Ein Vorteil, den die Uni Augsburg in ihrem Projekt „Electronic-OnboardTicketing1 “ausnutzt.
Auch über festeingebaute Bildschirme ist es möglich, dem Fahrgast Informationen zur
Verfügung zu stellen. So eine Lösung gibt es z. B. in Berlin mit dem „Berliner Fenster2 “.
Dort werden aktuelle Nachrichten, mit Werbung gemischt, in der U-Bahn angezeigt. Sehr
angenehm an der Lösung ist, dass sie mit immer zwei zusammengeschalteten Monitoren
funktioniert. Auf einem sind die ganz normalen Bilder, auf dem zweiten ist dann ein erläuternder Text dargestellt. Das hat den Vorteil, dass man den Text, der relativ gross sein
muss, nicht direkt ins Bild einblendet. Weiterhin wird durch diese Lösung niemand gestört, der sich unterhalten oder lesen will, da eine Audioausgabe verzichtbar ist.
Eine Möglichkeit ist es, dem Nutzer ein Terminal zur Verfügung zu stellen. Etwas ähnliches hatte die Deutschen Bahn AG in der ersten Generation der ICEs installiert. Hier hatte
der Nutzer die Möglichkeit, sich über Zugverbindungen und andere Angebote der Bahn
zu informieren. Wenn man hier dem Nutzer LBS und vielleicht auch noch einen Internetzugang anbietet, könnte eine derartige Möglichkeit einen nützlichen Service darstellen.
4.1.1 Fernverkehr
Das wohl größte potenzielle Anwendungsgebiet dürfte sich im Fernverkehr eröffnen.
Fahrgäste haben hier mehr Zeit als in anderen Verkehrsmitteln. Eventuelle durch den Nutzer durchzuführende Installationsarbeiten zur Nutzung des Systems sind im Verhältnis zur
Fahrt gesehen gering. Fahrgäste haben hier oft das Bedürfnis, sich über Anschlusszüge zu
informieren. Beispielsweise wenn der Zug Verspätung hat, oder für Kurzentschlossene,
ist es interessant, Informationen über Hotels und Restaurants am Zielort zu bekommen.
Aber in Fernverkehrszügen oder -bussen ist es im Gegensatz zu Flugzeugen schwieriger,
die Informationen aktuell zu halten, da hier eine durchgehende Internetverbindung aufgrund von z.B. Tunnels oft nicht gegeben ist. Mit diesem Problem setzt sich T-Systems
zur Zeit auseinander3 .
Im Flugverkehr ist dies einfacher. Über Satelliten und Hochgeschindigkeitsempfgangsund Sendeanlagen wird zur Zeit ein Teil der Flugzeuge mit Internet ausgestattet. Viele
Nutzer verbinden genau aus diesem Grund ihr Laptop mit einem Bordsystem. Über die1
siehe Kapitel 4.2.5
Mehr dazu im Kapitel 4.2.2
3
Siehe dazu die Einleitung von Kapitel 5
2
4.2. Vorhandene Lösungen
17
ses können dann auch ohne großen Mehraufwand LBS angeboten werden.
4.1.2 Nahverkehr
Im Nahverkehr sind die Anwendungsmöglichkeiten geringer. Wie schon erwähnt, ist hier
oft nicht genügend Zeit vorhanden, damit der Nutzer ein eigenes Gerät sinnvoll in das
Bordnetz einbinden kann. Es bietet sich also an, Terminals oder Bildschirme, die fest im
Verkehrsmittel installiert sind, zu benutzen.
Werbung ist hier für lokale Anbieter, die auf Angebote hinweisen wollen, sicherlich interessant. Diese könnte eingespielt werden, sobald sich das Verkehrsmittel in der Nähe des
Werbenden befindet.
Problematisch sind aber die hohen Kosten für Bildschirme und die Wartung des Systems.
4.1.3 Sightseeing
Ein LBS-System ist für die Touristische Nutzung „Sightseeing“ nutzbar. Anwendern kann
ein Mobiles Endgerät an die Hand gegeben werden, an dem sie ihre Wunschsprache einstellen können. Über Kopfhörer bekommen sie dann die gewünschten Informationen und
können vielleicht sogar noch zwischen verschiedenen Versionen (z.B. Kinder, Erwachsene, Senioren etc.) auswählen. Somit kann eine Sightseeingtour gleichzeitig in verschiedenen Sprachen angeboten werden. Auch kann z.B. ein normaler Stadtbus genutzt werden, der auf seiner Tour an verschiedenen Sehenswürdigkeiten vorbeifährt. Touristen und
Pendler können somit einen Bus gleichzeitig nutzen.
4.2 Vorhandene Lösungen
Hier soll eine Auswahl von Services für den öffentlichen Verkehr vorgestellt werden. Diese Auflistung ist nicht vollständig, gibt aber einen Überblick über vorhandene Lösungen.
4.2.1 HEAG Verkehrs-GmbH Darmstadt
Die HEAG Verkehrs-GmbH aus Darmstadt ist bei der Lokalisierung ihrer Fahrzeuge ein
gutes Beispiel. Schon seit einiger Zeit sieht das Unternehmen es als ein wichtiges Ziel,
immer einen genauen Überblick über den Aufenthaltsort aller Fahrzeuge ihrer Flotte zu
haben. Jede Linie hat einen festen Anfangspunkt. Von diesem Punkt an werden die gefahrenen Meter gemessen. Auf der Strecke gibt es ein bis zwei feste Baken, um eventuelle
Fehler zu erkennen und ggf. Korrekturen einzuleiten. Für jede Haltestelle gibt es in einer Datenbank einen dazu passenden Sollwert, der mit dem aktuellen Istwert abgeglichen
wird. Es ist also immer bekannt, wie weit es noch bis zur nächsten Haltestelle ist.
Alle sieben Sekunden fragt die Leitstelle automatisch diese Daten per Funk ab, und hat
4.2. Vorhandene Lösungen
18
somit immer einen genauen Überblick über die jeweilige Position der Fahrzeuge und etwaige Abweichungen vom Fahrplan.
Mit diesen Daten werden dann die Displayanzeigen und Haltestellenansagen im Fahrzeug
gesteuert. Gleichzeitig werden die Daten aber auch benutzt, um an größeren Haltestellen
wartenden Fahrgästen mitzuteilen, wie lange es noch bis zum Eintreffen des nächsten
Busses/der nächsten Straßenbahn einer Linie dauert.
Nach eigenen Angaben sind die Lokalisierungsdaten zur Zeit auf etwa 15m genau. Ein
Problem ist aber, dass dieses System nur schwer feststellen kann, wenn ein Fahrzeug die
Route verlässt. Dies ist erst möglich, wenn das System bemerkt, dass das Fahrzeug an
keiner Bake mehr vorbeifährt. Um dieses Problem zu lösen, und um eine höhere Genauigkeit zu erreichen, soll in Zukunft noch in jedes Verkehrsmittel zusätzlich ein GPS-Gerät
eingebaut werden. Beide Systeme sollen dann parallel laufen und das Ergebnis weiter
verbessern. Weiteres unter www.heag.de
4.2.2 Berliner Fenster
Das Berliner Fenster ist ein Projekt der Berliner Fenster GmbH, die eine Tochtergesellschaft der Berliner Verkehrsbetriebe (BVG) ist. Wie in Kapitel 4.1 beschrieben, arbeitet
diese Lösung mit einem Zweimonitorsystem ohne Audioausgabe. Die Vorteile liegen darin, dass nicht interessierte Fahrgäste nicht gestört werden, interessierte aber von jedem
Sitzplatz aus das Programm verfolgen können. Durch den zweiten Monitor, der nur für
Texte genutzt wird, kann die Schrift hinreichend gross sein, ohne Teile des Bildes zu verdecken.
Die gegenwärtig installierte technische Lösung läßt keine LBS zu, da in allen Zügen das
gleiche Programm gesendet wird. Die Inhalte erreichen per DAB-DMB4 den Zug. Dafür werden die Daten erst in die U-Bahnhöfe übertragen und dann per Lichtwellenleiter,
die in den Tunnels installiert sind, zu den Zügen weitergegeben. Auch wenn die Daten
in den Zügen zwischengespeichert werden, läuft im Prinzip in allen Zügen das gleiche
Programm. Eine Livesendung wäre ohne Probleme möglich. Um LBS anbieten zu können, wird zur Zeit versucht, das System mit der Zentrale des RBL5 zu verbinden. Somit
wäre dem System bekannt, wo der Zug sich gerade befindet. Nun könnte man in der Sendezentrale für das Berliner Fenster verschiedene Programme für verschiedene Züge oder
Aufenthaltsorte versenden. Zur Zeit laufen, laut Auskunft der Berliner Fenster GmbH,
erste Tests in dieser Richtung.
4.2.3 TRAIN-INFOSCREEN Hamburg
In Hamburg gibt es ein sehr ähnliches System, wie in Berlin. Hier werden die Daten über
WLAN an den Stationen in die Bahn übertragen. Das System ist über die Haltestellenansagen mit der Leitstelle gekoppelt, dadurch ist der Aufenthaltsort bekannt.
4
5
Digital Multimedia Broadcasting
Rechnergesteuertes Betriebsleitsystem
4.2. Vorhandene Lösungen
19
Infoscreen kommt mit nur einem Monitor aus, arbeitet aber mit der Haltestellenansage
direkt zusammen. Bei Einfahrt in einen Bahnhof wird erst der Stationsname angezeigt.
Wenn dies gebucht ist, kann direkt darauf folgend eine Werbung eines lokalen Anbieters
gesendet werden. Dies ist für Gewerbetreibende in dem betreffenden Bahnhof sehr interessant, um die Bekanntheit zu erhöhen und auf laufende Aktionen hinzuweisen. Weiter
Informationen zum TRAIN-INFOSCREEN unter www.infoscreen-hamburg.de
und www.hochbahn.de.
4.2.4 Fahrinfo SMS
Ein anderer Service der BVG ist ein ortsbezogener Dienst, der auf die Lokalisierung des
Anwenders per manueller Eingabe setzt. Der Kunde schickt eine SMS mit einer eindeutigen Haltestellennummer, an der er abfahren möchte, an den Zentralrechner. Er erhält
direkt eine Antwort mit Echtzeitinformationen über die nächsten 5 an dieser Haltestelle abfahrenden Verkehrsmittel. Die Nummer steht an jeder Haltestelle, kann aber auch
per WAP abgefragt werden. Kosten entstehen nur für den WAP-Dienst und die versendete SMS zum Standardpreis. Die Antwort-SMS ist zum Zeitpunkt der Erstellung dieser
Arbeit kostenlos. Somit ist dies ein sinnvolles System, um an kleinen Haltestellen Anzeigeterminals zu sparen. Mehr Informationen zu diesem Projekt unter: www.bvg.de.
4.2.5 Electronic-Onboard-Ticketing Uni Augsburg
Die Uni Augsburg hat zur Cebit 2003 ein System zum Ticketkauf im Zug vorgestellt. Der
Nutzer geht zum Bahnhof, und erst wenn er sicher weiß, welchen Zug er erreicht hat,
kauft er über seinen PDA im Zug sein Ticket. Dazu muss er sich vorher ein Programm
herunterladen, bleibt aber während des ganzen Vorgangs anonym. Seinen PDA verbindet
er über Bluetooth mit dem Bordnetz. Somit weiß das System, ob er sich in der 1. oder
2. Klasse befindet, und auch an welcher Station er eingestiegen ist. Der Kunde muss nur
noch Zahlungsweise, Ziel der Reise und mögliche Vergünstigungen (BahnCard) auswählen. Sobald er sich das Ticket gekauft hat, bekommt er eine Ticket-ID. Diese ID gibt er an
den Schaffner weiter, der dann mit einem eigenen Gerät das Ticket überprüft und entwertet.
Bei der Entwicklung wurde nach Auskunft von Professor Dominik Haneberg, einem der
Projektleiter, auf die Sicherheit des Systems und Anonymität des Nutzers Wert gelegt.
Weiterhin berichtet er, dass die Deutsche Bahn AG bis jetzt kaum Interesse gezeigt hat.
Für das Verkehrsunternehmen würde das Projekt grosse Investitionen in Hardware bedeuten. Wahrscheinlich würden mit diesem System viele Nutzer auch erst ein Ticket kaufen,
wenn der Schaffner schon in Sicht ist. Somit ist das System für den Kunden sehr interessant, für die Deutsche Bahn aber vorerst nicht. Weitere Informationen im Internet:
http://www.informatik.uni-augsburg.de/swt/Publications.htm.
5. LBS4FIBB und TrainGuide
5.1 Vorstellung des Projektsystems
LBS4FIBB und TrainGuide bilden zusammen ein Gesamtsystem, welches während meiner Praxisphase im Technologiezentrum der Firma T-Systems entstanden ist. Das System
ist eine Erweiterung eines Forschungsprojektes mit dem Ziel, Nutzern des öffentlichen
Verkehrs Internet zur Verfügung zu stellen. Der Name des Projekts ist „Fast Internet in
Bahn und Bus“ (FIBB). In diesem Projekt wird ein Server, der sich in dem Verkehrsmittel
befindet, über unterschiedliche Funktechniken ans Internet angeschlossen. Der Fahrgast
kann sich mit seinem Laptop oder PDA mit diesem Server verbinden und somit über das
Internet z.B. seine Emails abrufen, aber auch über einen VPN-Client in einem Firmennetzwerk arbeiten. Sollte sich die Verbindungstechnik des FIBB in sein Heimatnetz ändern,
merkt der Kunde das nicht (Seamless Handover).
Die Anbindung der Nutzer im Zug erfolgt durch WLAN, ist aber auch mit Bluetooth möglich. Wichtig für dieses Projekt ist, dass der Nutzer nur einen Browser auf seinem Gerät
braucht, Betriebssystem des Nutzers und Art des mobilen Endgerätes darf keine Rolle
spielen. Mit diesem Projekt angesprochene mobile Endgeräte sind genau die Endgeräte
wie in Kapitel 2.2 dieser Arbeit definiert.
Meine Aufgabe im Rahmen des Praxissemesters war nun, den Nutzern Location Based
Services zur Verfügung zu stellen. Beispiele sind hierfür
• eine Karte mit Anzeige des jeweiligen Standorts,
• Informationen zu in der Nähe liegenden Sehenswürdigkeiten,
• Informationen zu den nächsten Haltepunkten, Anschlussverbindungen und eventuell aktuellen Verspätungen, Übernachtungsmöglichkeiten, Veranstaltungen und Restaurants und
5.2. Analyse und Design
21
• Werbung für Geschäfte in der Nähe der nächsten Haltestellen.
5.2 Analyse und Design
5.2.1 Anforderungsanalyse
Da es sich bei FIBB zum Zeitpunkt der Erstellung der Arbeit um einen Demonstrator handelt, sollte ein Modul für diesen entwickelt werden, das sich auch zu Vorführungszwecken
eignet. Dazu war eine Strecke in Darmstadt auszuwählen, zu der eine Art Cityguide entstehen sollte. Bei der Realisierung gab es Anforderungen aus Sicht eines Nutzers, aus
Sicht eines Administrators und allgemeine Anforderungen:
Anforderungen aus Sicht des Nutzers:
1. Punkte in der Nähe: Ein Liste soll dem Nutzer aktuell in der Nähe befindliche POI
anzeigen
2. Informationen zu den POI: Der Nutzer soll die Möglichkeit haben, Informationen
zu den angezeigten POI zu erhalten. Dazu sollen Hyperlinks angezeigt werden, über
die er durch Klicken auf externe oder interne Internetseiten gelangt.
3. Audiomodus: Der Nutzer soll die Möglichkeit haben, sich über einen Audiomodus Informationen anhören zu können, eine Art virtueller Stadtführung. Hierbei ist
immer der POI entscheidend, dessen Entfernung am geringsten ist. Dieser Audiomodus soll - einmal angeschaltet - automatisch immer zu genau dem am nächsten liegenden POI Informationen abspielen. Dabei soll der Nutzer die Möglichkeit
haben, sich die letzten beiden Sequenzen noch einmal anzuhören, aber auch eine
Sequenz zu überspringen.
4. Übersichtskarte: Auf der Übersichtskarte wird simuliert, dass der Demonstrator
sich nicht wirklich bewegt, und nur eine virtuelle Route entlangfährt. Für eine Demonstration ist es also sinnvoll, dem Betrachter auf einer einfachen Karte zu zeigen,
wo sich das System gerade befindet.
Anforderungen eines Systemadministrators:
1. POI hinzufügen: Ein Administrator muss mit möglichst wenig Aufwand einen
neuen POI in das System aufnehmen können. Dazu gehört, dass das System mit
möglichst vielen verschiedenen Koordinatensystemen umgehen kann, und es muss
reichen, als Informationen einen externen Link anzugeben. Audioinformationen
sind keine Pflicht, können aber ohne Probleme später hinzugefügt werden. Sollte
z.B. ein neuer Werbepartner aufgenommen werden wollen, muss das einfach und
schnell gehen.
5.2. Analyse und Design
22
2. POI bearbeiten: Änderungen an den Informationen müssen leicht und schnell
durchführbar sein.
3. POI löschen: Einen einmal hinzugefügten Punkt sollte man löschen, aber auch
deaktivieren können, sollte z.B. ein Werbevertrag auslaufen, oder eine Sehenswürdigkeit geschlossen haben.
Abbildung 5.1: Anwendungsfälle des realisierten Systems für Administrator und Nutzer
Allgemeine Anforderungen:
1. Browserfähigkeit: Der Nutzer muss keine weiteren Programme auf seinem mobilen Endgerät installieren, eine wichtige Zugangsvoraussetzung zur breiten Akzeptanz des Systemes.
2. Modularer Aufbau: Um diesen Demonstrator später wieder- bzw. weiterverwenden zu können, sollte er aus einfachen wiederverwertbaren Modulen bestehen, die
eine hohe Anzahl an Schnittstellen besitzen.
3. Labortauglichkeit: Eine wichtige Voraussetzung für einen Demonstrator ist, dass
die Lokalisierungsinformationen von außen anpaßbar sind und dem Demonstrator
simulieren, er wäre auf der Strecke. Nur so kann man mit geringem Aufwand auch
das System an einem festen Ort außerhalb der Strecke vorführen.
4. Betriebssystem: Auf den Servern im Verkehrsmittel ist als Betriebssystem Linux
installiert. Somit müssen auch alle Module hierauf zugeschnitten sein.
5. Minimaler Datenaustausch: Möglichst viele der Informationen sollten auf dem
Fahrzeugserver vorhanden sein, um den Traffic mit dem Internet zu minimieren.
5.2. Analyse und Design
23
6. Perpektive: Für spätere Anwendungen (z.B. Flottenmanagement, Übersichtskarte
im Internet) ist es sinnvoll, den Aufenthaltsort des Fahrzeuges so zur Verfügung zu
haben, dass man über das Internet auf diese Information zugreifen kann.
5.2.2 Bildschirmübersicht
Für einen Nutzer, des obenbeschriebenen Systems wird also eine einfache Weboberfläche
gebraucht, die vom Aufbau her im Screendiagramm in Abbildung 5.2 gezeigt wird. Hier
ist wichtig, dass das Hauptfenster geöffnet bleibt und immer weiter die aktuellen POI anzeigt werden, während Informationen zu einem speziellen POI angezeigt werden. Es wird
also automatisch ein weiteres Fenster geöffnet, in dem die beschriebenen Informationen
zum ausgewählten POI angezeigt werden.
Abbildung 5.2: Screendiagramm TrainGuide
Abbildung 5.3 zeigt das schematische Screendiagramm für die Übersichtskarte. Ein Kreis
soll auf einer Karte den aktuellen Aufenthaltsort des Fahrzeuges anzeigen.
Abbildung 5.3: Screendiagramm Übersichtskarte
5.2.3 Programmablauf für den Nutzer
Der Programmablauf für den Nutzer sollte möglichst einfach sein. Wichtig ist hierbei, den
Traffic zu minimieren und die Einstellungen, die der Nutzer machen muss, sind möglichst
gering zu halten. Deshalb wird darauf verzichtet, ein Programm zu schreiben, das der
5.3. Programmaufbau
24
Nutzer auf seinem mobilen Endgerät installieren muss. Genauso gibt es vorerst kein Java
Applet, sondern eine einfach gehaltene HTML-Seite. Ein Applet kann aber später als eine
zweite Lösung zur Wahl angeboten werden.
Für den Nutzer im ÖPV soll der Ablauf wie folgend aussehen:
1. Der Nutzer verbindet sich mit dem Access Point im Verkehrsmittel und setzt alle
dazu notwendigen Parameter in seinen Netzwerkeinstellungen.
2. Sobald die Verbindung besteht, muss der Nutzer sich ggf. authentifizieren, um eine
Entgeltabrechnung zu ermöglichen.
3. Der Access Point sendet automatisch seine Startseite an den Browser des Nutzers.
Auf dieser Website ist ein Verweis auf „Ortsbezogene Dienste“ . Über diesen Link
gelangt der Nutzer zu TrainGuide.
4. In TrainGuide werden dem Nutzer Verweise auf in der Nähe befindliche POI angeboten.
5. Bei Interesse, kann der Nutzer einen Audiomodus anschalten. Das System spielt gespeicherte Audiodateien über den am nächsten liegenden POI ab. Über zwei Schaltflächen (Vor und Zurück), kann der Nutzer die letzten zwei gehörten Audiodateien
wiederholen, bzw. die aktuelle Audioinformation überspringen.
5.3 Programmaufbau
In diesem Kapitel soll nach und nach der Programmablauf für das Projektsystem entwickelt werden. Doch dazu sollte als Grundvoraussetzung die Art des Ortungssystems
ausgewählt werden.
5.3.1 Positioning
Die Entscheidung für die Positionierungsart fiel relativ schnell für ein satellitengestütztes
Ortungssystem. Da möglichst viele Informationen direkt auf dem Fahrzeugserver vorhanden sein sollen, ist es sinnvoll, die Lokalisierung direkt im Fahrzeug vorzunehmen.
Mit einem GPS-Gerät ist dies relativ einfach und ungebunden von Mobile Service Providern. Auch ist bezogen auf ein Fahrzeug, und somit mehrere Nutzer, die Investition in
ein GPS-Gerät vergleichbar niedrig, die Größe des Gerätes spielt hier kaum eine Rolle. Das Gerät ist je nach Hersteller etwa 5x5x5 cm groß, angebracht wird es am besten
witterungsgeschützt außen am Fahrzeugdach. Dort gibt es keine Abschattungen durch das
Fahrzeug selber. Problematisch sind allerdings Hochspannungsleitungen, die in Bereichen
von Kreuzungen durch die elektromagnetischen Felder laut einer Studie von T-Systems
25
5.3. Programmaufbau
Abbildung 5.4: Übersicht über Klassen und die zugehörigen Schnittstellen
zu Störungen führen können. Auch im Bahnhofsbereich, wenn keine Sichtverbindung
z.B. durch Dächer zu Satelliten möglich ist, ist eine Ortung teilweise erheblich beeinträchtigt. Diese stören in einem geringen Maße den Empfang des GPS-Gerätes. Da aber
der Aufenthaltsort bei relativ hohen Geschwindigkeiten nicht auf den Meter genau seien muss, ist dieses vernachlässigbar. Das Gerät wird z.B. über eine serielle Schnittstelle
mit dem Fahrzeugserver verbunden. Für den Demonstrator ist an dem Server ein Rechner angeschlossen, auf dem ein Emulator mit GPS-Daten läuft, die in der Darmstädter
Innenstadt aufgenommen wurden. Dieser Emulator ist ein Shellscript, das die Daten (im
NMEA-Protokoll) aus einer Textdatei ausliest und dann an der seriellen Schnittstelle ausgibt. Diese muss mit einem Nullmodemkabel mit der seriellen Schnittstelle des Rechners
verbunden werden, auf dem GPSD läuft.
Ausgelesen wird die serielle Schnittstelle von einem Programm mit dem Namen GPSD.
GPSD steht für GPS-Deamon1 und ist ein Programm, das unter der GNU General Public License (GPL) steht. Dieses Programm wertet das NMEA-Protokoll aus, und stellt
über einen Telnetport verschiedene Daten wie Geschwindigkeit in Knoten und die Position, dezimal im WGS84 Format, zur Verfügung. Somit sind diese Daten direkt dem
Fahrzeugserver, aber auch jedem anderen über Netz angeschlossenen Rechner bekannt.
5.3.2 Anwendungsarchitektur
Vom Design her gab es von Anfang an eine Vorraussetzung: Die Graphische Oberfläche
sollte genauso wie die Eingabe des Aufenthaltsortes als Adapter gestaltet werden, damit
diese leicht austauschbar sind. Die Eingabe wird durch GPSD adaptiert. Dieses verbindet
sich mit dem GPS-Gerät und empfängt von diesem die Daten im NMEA2 Format. Über
das Telnetprotokoll wird jetzt eine variable Schnittstelle geschaffen. Daraus folgt, dass
das GPS-Gerät nicht am selben Gerät angeschlossen sein muss, auf dem auch das System
LBS4FIBB läuft.
Bei der Oberfläche wird dies durch die Nutzung des Browsers in Verbindung mit HTML
erreicht. Die Verknüpfung der Website mit den Ergebnissen der Standorterkennung war
1
Weitere
Informationen
http://pygps.org/gpsd/gpsd.html
2
siehe Kapitel 3.1.2
dazu
unter
http://freshmeat.net/projects/gpsd/
und
5.3. Programmaufbau
26
anfangs ein Problem. An dieser Stelle der Planung wurden zwei Konzepte erstellt. Beide wurden nach obengenannten Kriterien bewertet und die besser zu den Anforderungen
passende realisiert.
Möglichkeit 1 - ohne Datenbank
Diese Möglichkeit kommt ohne eine Datenbank aus. Die einzelnen POI werden in einer
Textdatei gespeichert. In dieser Datei sind Koordinaten und der Dateiname eines dazugehörigen Shellscriptes zu jedem Punkt abgespeichert. Sobald das Fahrzeug in den definierten Radius eines Punktes fährt, wird diese Datei gestartet. Somit könnte man hiermit eine
HTML-Datei anpassen oder updaten. Eine weitere Methode muss aufgerufen werden, sobald der Radius des Punktes verlassen wird, um die Änderungen rückgängig zu machen.
Zur Bewertung ist zu sagen, dass diese Möglichkeit leichter zu realisieren ist, da auf eine Datenbank komplett verzichtet werden kann. Eine Installation auf einem System wäre
schneller möglich. Aber das System wird schwerer wartbar, da bei einer Änderung im
Extremfall alle Shellscriptdateien geändert werden müssen. Auch fehlt hier eine klare
Schnittstelle; es ist für externe Programme schwierig, auf den aktuellen Zustand der POI
zuzugreifen. Die Modularität des System wäre gefährdet. Auch die nach außen zur Internetseite geforderte klare Schnittstelle ist nicht vorhanden.
Möglichkeit 2 - mit Datenbank
Möglichkeit Nummer zwei hat eine Datenbank, die einmal zum Verwalten der POI benutzt
wird und zweitens zum Speichern der Ergebnisse von LBS4FIBB. Die Website greift
direkt auf die Datenbank zu. Damit ist die Datenbank klar die geforderte Schnittstelle, die
sehr flexibel mit anderen Programmen genutzt werden kann. Die Wartbarkeit und auch die
Möglichkeiten der Erweiterung der Datenbank sind relativ einfach, und damit fiel auch die
Entscheidung für Möglichkeit zwei. Die weiteren Einzelheiten dazu werden im folgenden
genauer beschrieben.
27
5.4. Die einzelnen fertigen Module
Abbildung 5.5: Möglichkeit 1
Abbildung 5.6: Möglichkeit 2
5.4 Die einzelnen fertigen Module
Als Teststrecke durch Darmstadt wurde die Straßenbahn Linie 3 ausgewählt. Diese Linie
führt an vielen unterschiedlichen, interessanten Punkten wie Hauptbahnhof, Orangerie,
Luisenplatz und dem Bessunger Schwimmbad vorbei.
Da dieses Projekt „LBS for FIBB“ Location Based Services für Fast Internet in Bus und
Bahn zur Verfügung stellen soll, ist der Name
LBS4FIBB
entstanden. Da sich unter diesem Namen ein möglicher Endnutzer aber möglicherweise
nichts vorstellen kann, ist später der Name
TrainGuide
für die Benutzeroberfläche eingeführt worden. Der Ablauf zwischen den Modulen wird
im Sequenzdiagramm in Abbildung 5.7 verdeutlicht. Hier wird noch einmal die zentrale
Rolle der Datenbank deutlich.
Abbildung 5.7: Sequenzdiagramm für LBS4FIBB und TrainGuide
28
5.4. Die einzelnen fertigen Module
5.4.1 Datenbank
Hierbei handelt es sich um eine MySQL-Datenbank, deren Vorteil ist, dass sie eine sehr
hohe Anzahl an Schnittstellen zu verschiedenen Programmen hat. Somit kann man per
PHP, mit C++, aber auch mit Java z.B. für ein Applet darauf zugreifen. Bei der Entscheidung für die verwendetet Datenbank stand die Modularität und Erweiterbarkeit des
Systems im Vordergrund.
Die Datenbank hat mehrere Aufgaben. Erstens dient sie zum Verwalten der verschiedenen
Points of Interest. Von jedem POI werden hier gespeichert:
Spaltenname
Typ
Beispiel
id
Name
Rechtswert
Hochwert
Radius
Link
Audiolink
Audiolaenge
int(11)
varchar(30)
double
double
int(11)
varchar(160)
varchar(150)
int(11)
1
Hauptbahnhof Darmstadt
3473578.97
5526320.26
800
www.bahn.de/....
bahnhofdarmstadt.mp3
55
„Rechtswert“ und „Hochwert“ sind Koordinaten im Gauß-Krüger-System (s. Kapitel 2.6).
Somit muss die Umrechnung in dieses System nur einmalig beim Eintragen in die Datenbank geschehen und nicht jedesmal zur Programmlaufzeit. Dies spart Rechenzeit.
Mit der Angabe „Radius“ wird festgelegt, ab welcher Entfernung (in Metern) der Punkt
angezeigt werden soll. Der Hauptbahnhof ist sicherlich interessanter als eine kleine Haltestelle, somit ist dort der Radius höher zu wählen.
„Link“ und “Audiolink“ geben die Positionen an, an denen weitere Informationen vorhanden sind. Beim Audiolink ist dies eine Audiodatei, die abgespielt werden kann. Unter
„Link“ wird ein Hyperlink zu einer Website mit weiteren Informationen angeboten. Diese
können lokal auf dem Fahrzeugserver, aber auch im Internet vorgehalten werden. „Audiolänge“ gibt die Länge der Audiodatei in Sekunden an.
Die zweite Aufgabe der Datenbank ist es, den aktuellen Zustand der Punkte zu verwalten.
Dazu gibt es weitere Felder in der gleichen Tabelle:
Spaltenname
Typ
Beispiel
status
zeit
naechster
int(11)
datetime
int(11)
2
2004-01-28 14:39:12
1
5.4. Die einzelnen fertigen Module
29
Unter „Status“ ist der aktuelle Zustand des POI gespeichert. Dabei bedeutet:
0 Verkehrsmittel befindet sich nicht im Radius des POI,
1 Verkehrsmittel fährt in den Radius des POI hinein,
2 Verkehrsmittel befindet sich im Radius des POI und,
3 Verkehrsmittel fährt aus dem Radius des POI heraus.
Abbildung 5.8: Mögliche Zustände eines POI
In der Variablen „Zeit“ wird gespeichert, wann zuletzt der Status gewechselt hat. Sie ist
am Anfang NULL. Somit kann über diese Variable sehr leicht abgefragt werden, ob und
wann das Verkehrsmittel sich zuletzt in dem Radius des POI befunden hat. Damit kann
im nachhinein die Strecke nachvollzogen werden. „Naechster“ ist auf 1 wenn dieser POI
gerade der dem Fahrzeug nächst gelegene Punkt ist. Dies wird für die Audioinformationen
benötigt.
5.4.2 LBS4FIBB
LBS4FIBB ist das Hauptmodul des Systems und in C++ programmiert. Es fragt nach einem Initialisierungsvorgang die Datenbank ab und speichert alle POI in einem Vector des
Typs „Streckenpunkte“, der durch die gleichnamige Klasse entsteht. Dies hat den Vor1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Streckenpunkt {
Streckenpunkt();
double hochwert;
double rechtswert;
double entfernung;
int radius;
//die vorgegebene Entfernung ab wann der
Punkt interessant ist
int id;
//die ID dieses Punktes aus der Datenbank
int status;
//2 wenn drin im Radius, 0 wenn draußen
int alterstatus; //zum vergleich
char name[30];
double entfernungberechnen(double hoch, double rechts);
int auslesen(int nr); //aus der Datenbank
int eintragenInDB(int gesamtstatus);
};
teil, dass die ganze Datenbank (DB) nur einmal abgefragt werden muss und der Traffic
zwischen DB und LBS4FIBB minimiert wird. Nun wird alle 2 Sekunden der aktuelle
5.4. Die einzelnen fertigen Module
30
Standort über Telnet bei GPSD abgefragt. Diese Koordinaten werden auch in das GaußKrüger-Koordinatensystem umgewandelt. Der Grund dafür ist, dass das Gauß-KrügerKoordinatensystem auf Rechtwinkligkeit beruht. Somit kann in diesem mit einer einfachen Dreiecksberechung in der Klasse „Streckenpunkte“ zu jedem einzelnen Punkt die
Entfernung berechnet werden:
1
double Streckenpunkt::entfernungberechnen(double hoch, double
rechts) {
2
entfernung=sqrt(pow((hoch-hochwert),2)+pow((rechts-rechtswert)
,2));
3
return entfernung;
4
5
}; //entfernungberechnen
Dies ist die direkte Anwendung des Satzes des Pythagoras:
Entf ernung =
q
Dif f erenz der Hochwerte2 + Dif f erenz der Rechtswerte2
Aus dem Ergebnis dieser Berechnung wird der Status für jeden Punkt festgelegt,
1
if (entfernung<radius)
{
2
if (alterstatus==0 or alterstatus==3) status=1; //
3
reinfahren
else status=2; //
4
5
}
6
else
7
if (alterstatus==2 or alterstatus ==1) status=3;//rausfahren
8
else status=0;
mit dem zur Zeit abgespeicherten Status verglichen und ggf. in der Datenbank geändert.
1
2
if (status!=alterstatus)
{
3
// Dann verändere die Eintragung in der Datenbank
4
MYSQL mysql;
5
mysql_init(&mysql);
6
if (!mysql_real_connect(&mysql,"localhost","lbs4","lbs4fibb","
streckenpunkte",0,NULL,0))
7
{
cerr <<"Verbindung fehlgeschlagen " << mysql_error(&mysql)
8
<< endl;
9
}
5.4. Die einzelnen fertigen Module
31
10
char sqlcommand[100];
11
sprintf(sqlcommand,"UPDATE punkte SET zeit=now(), status = %d
where id = %d ",status,id);
12
int a= mysql_query(&mysql,sqlcommand);
13
if (a!= 0)
14
{
15
cout << a ;
16
cerr << "Fehler in der Abfrage\n";
17
return -1;
18
};
19
alterstatus=status;
20
mysql_close(&mysql);
21
}
Klassendiagramme
Abbildung 5.9: Klassendiagramme von LBS4FIBB
Insgesamt besteht LBS4FIBB aus drei Klassen. Die Klasse „Streckenpunkt“ verwaltet
die POI. Für jeden Punkt in der Datenbank wird ein Objekt dieser Klasse erstellt und
über den Vector in der „Main“ verwaltet. In „Alterstatus“ steht immer der aktuelle Status, der auch in der Datenbank eingetragen ist. Der neue Status wird mit der Methode
„entfernungberechnen“, die als Parameter den aktuellen Standort bekommt, und dem Radius berechnet. Sobald Status und Alterstatus verschieden sind, muss der Eintrag in der
5.4. Die einzelnen fertigen Module
32
Datenbank geändert werden. Die Klasse „Streckenpunkt“ baut die Telnetverbindung zu
GPSD auf, fragt dort regelmäßig den aktuellen Aufenthaltsort ab und rechnet diesen ins
Gauß-Krüger-Format um.
Die Klasse „Main“ regelt den Ablauf. Sie kontrolliert am Anfang, ob neue POI vorhanden
sind und nimmt diese ggf. in die Datenbank mit auf. Danach liest die Klasse den Inhalt
der Datenbank in den Vector ein. Weiterhin gibt sie alle zwei Sekunden den Auftrag an
die Klasse „Standort“, die Position bei GPSD abzufragen und läßt zu jedem Punkt die
Entfernung berechnen. Abbildung 5.9 zeigt eine genauere Übersicht über die drei C++
Klassen und ihre Variablen.
5.4.3 TrainGuide
TrainGuide bezeichnet die Oberfläche (GUI) für den Benutzer im Zug und läßt sich in
zwei Teilen beschreiben. Zunächst hat der Nutzer eine Liste von Links, über die er sich
Informationen zu den in der Nähe befindlichen Punkten holen kann. Der zweite Teil ist
der Audiomodus. Hier kann der Nutzer sich Informationen zu dem nächsten POI vorlesen
lassen. Er bekommt also eine Art Stadtführung - Sightseeing Online.
Die Website (siehe Abbildung 5.10) TrainGuide ist unterteilt in 3 Frames und geschrieben in HTML und PHP. Im oberen Frame ist Platz für die Überschrift, im linken Frame
ist eine Übersicht über die in der Nähe befindlichen POI, und im mittleren ist Platz für
den Audiomodus (Stadtführung). Die Kombination aus HTML und PHP begründet sich
in der Tatsache, dass die Website für alle Browser nutzbar sein soll und es zu keinen Komplikationen mit Java kommen kann. Der Nachteil von HTML ist, dass der Server keine
Informationen pushen kann. Die Website muss somit selber regelmäßig die Datenbank
nach Änderungen überprüfen.
Dies funktioniert regelmäßig über einen refresh, der immer wieder dieselbe Seite aufruft,
und die Datenbank abfragt. Die wichtigsten Befehle dieses Frames (verweise.php) sind:
1
2
<meta http-equiv="refresh" content="2; URL=verweise.php"
[...]
3
if ($anzahl==0) print "Leider nichts in ihrer Nähe <br><br>";
4
else print "In Ihrer Nähe befindet sich: <br><br>";
5
$sql_show ="SELECT name, link FROM punkte where status =1 or
status=2;";
6
$res_show =mysql_query($sql_show) or die(mysql_error());
7
while($row=mysql_fetch_array($res_show))
8
{
9
$name = $row[’name’];
10
$link = $row[’link’];
5.4. Die einzelnen fertigen Module
11
print" <a href=$link target=’_blank’>[$name]</a> <br>";
12
}
33
Sobald ein Link angeklickt wird, geht ein neues Fenster mit der gewünschten Internetseite
auf. Die Seite TrainGuide bleibt also im Hintergrund erhalten.
Der Audiomodus ist ein Zusatzelement, das explizit gestartet werden muss. Für diesen
fragt die Website in der Datenbank ab, bei welchem Punkt unter „naechster“ der Eintrag
„1“ ist. Zu diesem ist die Entfernung am geringsten. Sollte zu diesem Punkt ein Audiolink
vorhanden sein, wird die zugehörige Datei direkt gestartet. Nach der in der Datenbank für
diese Datei abgespeicherten Zeit wird die Seite neu aufgerufen und wieder abgefragt, welcher POI jetzt am nächsten ist. Dabei werden die letzten beiden gespielten Audiodateien
als Parameter übergeben, damit die gleiche Datei nicht immer wieder abgespielt wird.
Sollte keine Datei vorhanden sein, dann wird nach einer gewissen Zeit die Abfrage erneut
durchgeführt, bis wieder neue Audioinformationen verfügbar sind.
Somit kann keine Datei zweimal hintereinander wiedergegeben werden. Es ist aber möglich, dass eine Datei übersprungen wird, da noch eine andere abgespielt wird, während
man an dem zugehörigen Punkt vorbeifährt. Dies ist nötig, damit die laufende Datei nicht
unterbrochen werden muss.
Die Audiodateien liegen auf dem Webserver. Der genaue Link und der Name der Dateien
ist in der Datenbank unter „Audiolink“ vorhanden. Dabei existiert jede Datei zweimal,
einmal als mp3 und einmal als wav-Datei, da es beim Testen mit dem Konquerer, einem
Browser unter Linux, mit manchen Einstellungen Probleme gab. Standardmäßig werden
die mp3-Dateien benutzt; sollte es Probleme geben, hat der Nutzer die Möglichkeit, zur
wav-Datei zu wechseln.
Abbildung 5.10: Startseite von TrainGuide
5.4. Die einzelnen fertigen Module
34
5.4.4 Administrationsseite für LBS4FIBB
Die Administrationsseite dient dazu, um neue Punkte in die Datenbank einzugeben, in
der die Punkte nur im Gauß-Krüger-Format stehen. Da die meisten Punkte im WGS84Format vorliegen, ist es angebracht, einem Administrator eine Möglichkeit anzubieten,
die Daten in WGS84 einzugeben. Dazu gibt es eine gesonderte Website (siehe Abbildung
5.11). Hier besteht die Möglichkeit, die Daten entweder im Grad- oder im Dezimalformat
einzutragen. Die Daten werden in einer zweiten Tabelle in der Datenbank gespeichert.
Bei jedem Start überprüft LBS4FIBB, ob neue Daten in dieser Tabelle sind. Diese Daten
werden dann umgerechnet ins Gauß-Krüger-Format und in der eigentlichen Tabelle der
Datenbank angefügt.
Abbildung 5.11: Adminseite für den FIBB
5.4.5 Übersichtskarte
Um bei Vorführungen des Systems die Bewegung durch die Stadt zu demonstrieren, ist
eine einfache Karte entstanden. Auf dieser Karte bewegt sich, je nach dem, was der GPSEmulator ausgibt, ein blauer Kreis. Dieser markiert, an welcher Stelle sich der Emulator
gerade befindet. Die Karte ist mit TCL/TK programmiert, da es relativ schnell ist und es
TCL/TK Interpreter sowohl für Linux als auch für Windows gibt. TCL ist eine Programmiersprache für Shellscripte, TK eine Erweiterung für Grafische Oberflächen, die man
hiermit sehr einfach und ohne großen Aufwand realisieren. Mit der TCL Erweiterung Expect kann man leicht eine Telnetverbindung aufbauen und Daten abfragen. Da die TK und
5.5. Standort bestimmen Ausblick für LBS4FIBB und TrainGuide
35
Expect Erweiterungen nur schwer gemeinsam laufen, ist das Programm in zwei Teile unterteilt. Ein Teil fragt per Telnet bei GPSD nach den aktuellen Koordinaten und gibt diese
als Ergebnis an den zweiten Teil weiter. Dieser ruft periodisch Teil eins auf, und rechnet
diese Koordinaten in Bildpunkte um. Mit den Bildpunkten setzte er dann einen Kreis auf
eine Karte, die aus einem Stadtplan von Darmstadt kopiert ist. Da die Karte nicht georeferenziert ist, funktioniert diese Umrechnung nur bei genau dieser einen Karte und damit
nur in Darmstadt.
5.5 Standort bestimmen Ausblick für LBS4FIBB und TrainGuide
LBS4FIBB mit der Oberfläche TrainGuide ist eine Entwicklung in genau die beschriebene Richtung. Als Erweiterung eines mobilen Internetanschlusses wird das System eine
Chance zur Akzeptanz haben. Aber man darf nicht vergessen, dass es bis jetzt nur ein
Demonstrator ist, dessen Hauptaufgabe es ist zu zeigen, dass LBS mit nicht allzu hohem
Aufwand als eine Erweiterung für ein System wie das „Fast Internet in Bahn und Bus“
möglich ist. Um es professionell anwenden zu können, ist über den vorliegenden Demonstrator hinaus noch weitere Entwicklungsarbeit zu leisten. Die hierzu notwendigen Schritte
möchte ich in diesem Kapitel noch kurz anreißen.
Mögliche Erweiterungen:
1. Grafische Gestaltung der Weboberfläche: Die Oberfläche muss von der Grafik
an das Corporate Design von T-Systems angepaßt werden. Diese Aufgabe wird von
Grafikern von T-Systems durchgeführt werden.
2. Java Applet als Oberfläche für den Nutzer: Bis jetzt gibt es nur eine HTML Seite.
Das hat den Grund, dass diese flexibler ist und von allen Browsern unterstützt wird.
Um das System für viele Fahrgäste in einem größeren Netzwerk nutzbar zu machen,
sollte es möglich sein, einem Nutzer auch Informationen pushen zu können. Das
hätte den Vorteil, das nicht jedes System regelmäßig eine Abfrage nach neuen POI
durchführen muss.
3. Aufteilung der Punkte der Datenbank in Regionen: Wenn die Anzahl der POI in
der Datenbank zu groß wird, um regelmäßig die Entfernung zu allen zu berechnen,
macht es Sinn, die Punkte in Regionen zu unterteilen. Dann muss nur noch die Entfernung zu dem Punkt mit dem höchsten Radius berechnet werden. Ist bei diesem
Punkt der Status=0 (also das Verkehrsmittel ist nicht im Radius des Punktes), muss
für keinen weiteren Punkt die Entfernung berechnet werden.
5.5. Standort bestimmen Ausblick für LBS4FIBB und TrainGuide
36
4. Variable Karte: Es wurde schon in Kapitel 5.4.5 angesprochen, dass die Karte
nicht flexibel genug ist. Eine neue flexiblere Version mit einem größeren Einzugsbereich wird benötigt.
5. Intelligente Umsteigeinformationen: Hierzu sind genaue Informationen über die
nächsten Bahnhöfe wichtig. Ein aktueller Abfahrtsplan, wie schon in TrainGuide
für den Darmstädter Hauptbahnhof vorhanden, ist hier ein erster Schritt. Aber auch
eine Reiseauskunft, die den aktuellen Zug mit einplant und möglichst aktuelle Informationen hat, ist hier von großem Vorteil. Gerade für Kunden, die die Strecken
nicht so genau kennen, wäre dies ein interessantes Angebot.
6. Fahrscheinkauf: Für spontan Reisende sicherlich interessant, da oft vor Abfahrt
des Zuges keine Zeit für den Fahrscheinkauf mehr vorhanden ist. In Fernverkehrszügen ist es zwar schon möglich, beim Zugbegleiter eine Karte zu kaufen, aber
dieser Service kostet auch eine sogenannte Bordgebühr.
6. Schlussbetrachtung
Eine Utopie aus dem Alltag :
Herr Krüger hat es mal wieder eilig. Er muss als unabhängiger Berater schnell und flexibel
auf die Wünsche seiner Auftraggeber reagieren. Ein wichtiger Kunde hat ihn angerufen
und braucht dringend seine Hilfe bei einem großen Projekt. Herr Krüger packt schnell
seine Sachen. Schon auf dem Weg zum Bahnhof verbindet er sich in der S-Bahn mit seinem PDA über das Bordnetz mit der Fahrplanauskunft und sucht sich eine Verbindung
von Frankfurt nach Hamburg aus. Im Zug angekommen, bucht er mit seinem Laptop eine
Fahrkarte zulasten seiner Firma - selbstverständlich Bargeldlos. Danach schreibt er seiner
Sekretärin eine E-Mail mit dem Inhalt, dass er am flogenden Tag nicht ins Büro kommen
wird. Nachdem der Schaffner sein digitales Ticket kontrolliert hat, macht Herr Krüger
es sich in seinem Sitz bequem, per Kopfhörer hört er ein paar Zahlen, Fakten und Geschichten über die Landschaft an, durch die er gerade fährt. Kurz wird er zwischendurch
gestört. Das Bordsystem teilt ihm über seinen Kopfhörer mit, dass er verspätungsbedingt
seinen geplanten Anschlußzug in Hannover nicht erreichen wird. Aber eine neue Verbindung wird ihm direkt auf seinem Bildschirm angezeigt. Kurz vor der Ankunft bucht Herr
Krüger sich noch ein Hotel in Bahnhofsnähe für die Nacht und reserviert einen Tisch im
gegenüberliegenden Restaurant, in dem er sich mit seinen Kunden zum Abendessen treffen will.
So oder so ähnlich könnte in ein paar Jahren eine Zugfahrt aussehen. Ortsbezogene Dienste werden durch den Vorreiter Mobilfunk fast so normal wie Telefongespräche sein. Auch
in Fahrzeugen des öffentlichen Verkehrs wird es oft Möglichkeiten geben, Location Based
Services zu nutzen. Aktuelle Fahrpläne oder auch Verbraucherhinweise, die mittelbar mit
38
dem Verkehrsmittel zu tun haben, werden wie selbstverständlich zur Verfügung stehen.
Einfache ortsbezogene Dienste, wie die Haltestellenansage im Nahverkehr, sind uns schon
seit mehreren Jahren ein bekanntes Serviceangebot auf unseren Fahrten. Weitere werden
sicher dazukommen, aber es stellt sich die Frage, ab wann es sich finanziell lohnt, solche
Dienste und die dazugehörige Hardware anzubieten. Meist will man als Anbieter solche
Services möglichst schnell in allen Verkehrsmitteln zur Verfügung stellen. Für die Darmstädter HEAG z.B. würde aber ein Monitorsystem nur in den Straßenbahnen pro Bahn
mindestens drei Monitore bedeuten. Bei 44 Zugeinheiten im gesamten Netz der HEAG
sind das immerhin schon 132 Monitore, an die hohe Anforderungen an Stabilität (Vandalismus!), Helligkeit und Kontraststärke gestellt wird. Dazu kommen Entwicklungskosten
und Wartung.
Eine hohe Akzeptanz werden ortsbezogene Dienste wohl als Mehrwert zu Internetanschlüssen in Verkehrsmitteln erreichen. An der Entwicklung im Flugverkehr, aber auch
bei der Bahn, kann man sehen, dass es vielen Reisenden ein Bedürfnis ist, regelmäßig
online sein zu können. Für viele (Buisness-) Kunden stellt es einen erheblichen Mehrwert
auf einer Reise dar, wenn sie während der Fahrt mit ihrem Laptop arbeiten und dabei
einen Internetanschluss nutzen können. Somit haben sie schon ein mobiles Endgerät angeschaltet und ins Bordnetzwerk integriert. Über gezielte Werbeeinnahmen durch LBS
kann dann zumindest ein Teil der Investitionskosten in ein solches Bordnetz refinanziert
werden.
In Hinblick auf die stürmischen Entwicklungen, die die Nutzung mobiler Endgeräte in
wenigen Jahren genommen hat, bedarf es kaum hellseherischer Fähigkeiten, um zu prognostizieren, dass das eingangs als utopisch bezeichnete Szenario - sofern es nicht schon
in Teilen existiert - in relativ naher Zukunft Teil unseres Alltages sein wird.
Bei aller Euphorie hinsichtlich der Zukunft der Informationstechnologie sollte aber nicht
unerwähnt bleiben, dass mit der allgegenwärtigen Verfügbarkeit von Informationen, die
durch bestehende oder künftig zu installierende Systeme bereitgestellt werden, auch Risiken und ggf. Gefahren verbunden sind oder sein können, die wir in ihrer Tragweite heute
vielleicht noch gar nicht abschließend beurteilen können. Diese können aus den verwendeten Funkübertragungssystemen (Strahlung), aber auch aus der Ortbarkeit der Personen
(Datenschutz) resultieren.
*****
Literatur
[Böhm03] Winfried Böhm. Handbuch der Navigation: Begriffe, Verfahren, Formeln.
BusseSeewald, Herford. 2003.
[LVG04] Landesamt für Vermessung und Geobasisinformation Rheinland Pfalz. GaußKrüger-Koordinaten. http://www.lverma.rlp.de/wissen.htm. April 2004.
[Hjel02] Johan Hjelm. Creating location services for the wireless web: professional
developer’s guide. John Wiley & Sons, Inc., New York. 2002.
[Oest98] Bernd Oestereich. Objektorientierte Softwareentwicklung: Analyse und Design
mit der Unified modeling language - 4. akualisierte Auflage. R. Oldenbourg
Verlag, München Wien. 1998.
[TeLe02] René Teichmann und Franz Lehner. Mobile Commerce: Strategien, Geschäftsmodelle, Fallstudien. Springer-Verlag, Berlin Heidelberg New York. 2002.
[TuPo04] Klaus Turowski und Key Pousttchi. Mobile Commerce Grundlagen und Techniken. Springer-Verlag, Berlin Heidelberg New York. 2004.
7. Anhang
Auf der hier beigefügten CD befindet sich der Komplette Sourcecode, der in Zusammenhang dieser Arbeit während meiner Praxisphase bei T-Systems entstanden ist. Weiterhin
ist auf der CD eine Installationanleitung für das System und die vorliegende Arbeit als
Datei enthalten.
41