thesis - LMU München
Transcription
thesis - LMU München
INSTITUT FÜR INFORMATIK DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN Diplomarbeit Konzeption und Implementierung einer Location-based Push-Architektur für mobile Navigationsdienste Matthias Röckl Aufgabensteller: Prof. Dr. Claudia Linnhoff-Popien Betreuer: Dr. Axel Küpper Georg Treu Christian Birle Abgabetermin: 20. Juni 2005 2 INSTITUT FÜR INFORMATIK DER LUDWIG–MAXIMILIANS–UNIVERSITÄT MÜNCHEN Diplomarbeit Konzeption und Implementierung einer Location-based Push-Architektur für mobile Navigationsdienste Matthias Röckl Aufgabensteller: Prof. Dr. Claudia Linnhoff-Popien Betreuer: Dr. Axel Küpper Georg Treu Christian Birle Abgabetermin: 20. Juni 2005 Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. München, den 20. Juni 2005 .......................................... (Unterschrift des Kandidaten) Zusammenfassung Auf dem Weg zur 3. Mobilfunkgeneration treten neben Sprachdiensten auch immer mehr Datendienste in den Vordergrund. Sie unterstützen den Menschen in vielen speziellen, aber auch alltäglichen Aufgaben. Eine dieser alltäglichen Aufgaben des Menschen, mit der er tagtäglich konfrontiert wird, ist die Navigation. Ihre Historie reicht weit in die menschliche Geschichte zurück. Die moderne Informationstechnik kann heutzutage tatkräftige Unterstützung für die Navigation bieten. Als Schlagwort ist an dieser Stelle der Location-based Service zu nennen, mit dessen Hilfe Ortsinformationen des Nutzers in den Dienst einfließen. Dies ermöglicht die Realisierung mobiler Navigationsdienste. Ziel dieser Arbeit ist die Konzeption und Implementierung eines mobilen Navigationsdienstes für Mountain-Bike-Touren. Mountain-Bike-Navigationsdienste unterscheiden sich durch einige Besonderheiten von Fahrzeug- oder Fußgängernavigationsdiensten und stellen deshalb eine interessante Herausforderung dar. Besonderer Fokus wird dabei auf die zugrunde liegende Architektur dieses Dienstes gelegt. Ein wichtiger Aspekt ist die Bereitstellung von Navigationsinformationen ohne explizite Anforderung des Nutzers, was zu Location-based Push-Services führt. Zur Umsetzung dieser Art mobiler Dienste wird in der Architektur auf unterschiedliche Verteilungen der Architektur eingegangen und eine Analyse der Vorund Nachteile durchgeführt. Resultat des Entwicklungsprozesses ist eine Architektur, die sich durch hohe Dynamik, große Flexibilität und breite Anwendbarkeit auszeichnet. Um die Funktionsfähigkeit des Navigationsdienstes und der zugrunde liegenden Architektur zu belegen, wurde im Rahmen dieser Arbeit ein Prototyp dieses Dienstes implementiert und getestet. Die erzielten Ergebnisse zeigen, dass diese Art von Diensten möglich sind und durch die entwickelte Architektur sehr komfortabel umgesetzt werden können. Unter anderem legt diese Arbeit also einen Grundstein für weitere Location-based Push-Services, die womöglich die zukünftige Entwicklung der lang ersehnten Killer ” Applikation“ vorantreiben werden. 2 Inhaltsverzeichnis Inhaltsverzeichnis i Abbildungsverzeichnis iv Tabellenverzeichnis vi 1 Motivation 1 1.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Mobile Navigationsdienste 4 2.1 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Navigationshistorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2 Menschliche Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3 Navigationsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Mobile Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1 Mobile Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2 Location-based Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3 Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.4 Routendienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Demonstrator: MoBiLe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3.1 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 2.3 3 Stand der Technik mobiler Navigationsdienste 3.1 24 Ortungssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.1 Cell Of Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.2 Enhanced Observed Time Difference . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.3 Global Positioning System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 i 3.2 3.3 3.4 4 Weitere Ortungsverfahren und Klassifikationen . . . . . . . . . . . . . . . . . . . 29 3.1.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Mobile Programmierplattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2.1 Symbian OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.2.2 J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Unterstützung für verteilte Push-Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.1 Push-Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.2 Location-based Push-Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Bestehende Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4.1 Forschungsprojekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4.2 Kommerzielle Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Architektur 46 4.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.1.1 Generelle Architekturkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.1.2 Modularisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.3 Schichtenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.1.4 Middleware Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.1 Dienstinitiierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.2 Initiierungsmiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.3 Dienstausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.2.4 Präsentationsmiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.2.5 Dienstpräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3.1 Entitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.3.2 Verteilungsalternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.3.3 Auswirkung auf mobile Navigationsdienste . . . . . . . . . . . . . . . . . . . . . 64 4.2 4.3 5 3.1.4 Implementierung 67 5.1 Ortungssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.2 Endgeräteplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.3 Weiterer Hard- und Softwareeinsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.4 Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.4.1 Inter-LBPS-Schichtenkommunikation . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4.2 Plattformunabhängigkeit der Schichten . . . . . . . . . . . . . . . . . . . . . . . 74 5.5 5.6 6 75 5.5.1 Ortsinformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.5.2 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.5.3 Dienstinitiierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.4 Initiierungsmiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.5.5 Navigationsdienst MoBiLe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.5.6 Präsentationsmiddleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.5.7 Dienstpräsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Konfigurationskomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Evaluierung 86 6.1 Evaluierung der Implementierung und Technologie . . . . . . . . . . . . . . . . . . . . . 86 6.1.1 Probleme von GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.1.2 Inhärente Probleme von J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.1.3 Probleme mobiler Endgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.1.4 Probleme beim Routeneinstieg . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.1.5 Probleme mit Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.1.6 Probleme beim Verlassen der Route . . . . . . . . . . . . . . . . . . . . . . . . . 89 Versuchsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.2 7 Umsetzung der LBPS-Schichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schlussfolgerung und Ausblick A Routendienst 93 97 A.1 Digitale geografische Datenbestände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 A.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 A.2.1 OpenMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 A.2.2 Routenerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 A.2.3 Routenbereitstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 A.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 A.3.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 A.3.2 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 A.3.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 A.3.4 RouteServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 A.4 Evaluierung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Literaturverzeichnis 107 Abbildungsverzeichnis 2.1 Pull- und Push-Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 Beispiele für Push/Pull-Services mit/ohne Ortsabhängigkeit . . . . . . . . . . . . . . . . . 13 2.3 Pfadnetzwerk und Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Rollen im Bereich der LBSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1 Ortung mittels Cell Identity (a) mit Laufzeitmessung (b) mit AoA (c) mit Laufzeitmessung und AoA (d) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2 Enhanced Observed Time Difference (E-OTD) . . . . . . . . . . . . . . . . . . . . . . . 26 3.3 Aufbau des GPS-Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4 Mobile Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.5 Überblick über die Java 2 Editionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.6 Mobile Plattform für Grafikdarstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.7 Garmin eTrex und Magellan SporTrak . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1 Klassifikation anhand Kohärenzkriterium . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2 Schichtenaufbau der LBPS-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3 Middleware Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.4 LBPS-Architektur mit mehreren Applikationen . . . . . . . . . . . . . . . . . . . . . . . 50 4.5 Aktionskreis um Aktionspunkt mit Aktionsradius r . . . . . . . . . . . . . . . . . . . . . 53 4.6 Genordeter Kartenausschnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.7 Gegenüberstellung lokaler und entfernter Dienstausführung bei Connectivity und (Pre-)Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.8 Netzlast der Luftschnittstelle bei lokaler oder verteilter Dienstausführung . . . . . . . . . 65 5.1 Fortuna Clip-On Bluetooth GPS Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.2 Nokia 6630 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3 Verteilungsalternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.4 Dynamic Connection Framework (DCF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.5 Vereinfachtes Klassendiagramm des DCF . . . . . . . . . . . . . . . . . . . . . . . . . . 74 iv 5.6 Überblick über Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.7 Klassendiagramm der eingesetzten Ortsinformationen . . . . . . . . . . . . . . . . . . . . 77 5.8 Dienstinitiierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.9 Ellipsoidischer Abstand der Punkte P1 und P2 . . . . . . . . . . . . . . . . . . . . . . . . 81 5.10 Abstand der Punkte P1 und P2 auf dem Längenkreis . . . . . . . . . . . . . . . . . . . . 82 5.11 Abstand der Punkte P1 und P2 auf dem Breitenkreis . . . . . . . . . . . . . . . . . . . . 83 5.12 Beispiele der Konfigurationsoberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.13 Konfigurationskomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.14 Zustandsdiagramm der Konfigurationsoberfläche . . . . . . . . . . . . . . . . . . . . . . 85 6.1 Mountain-Bike-Tour am Taubenberg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.1 Stark vereinfachter Aufbau des UMTS-Netzes (Release 5) . . . . . . . . . . . . . . . . . 94 A.1 Model-View-Controller (MVC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 A.2 MVC-Architektur des Routendienstes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 A.3 Screenshot der grafischen Oberfläche des Routendienstes . . . . . . . . . . . . . . . . . . 103 A.4 Spezifikation der Austrittsrichtung aus Aktionspunkt . . . . . . . . . . . . . . . . . . . . 104 Tabellenverzeichnis 3.1 Kommerzielle mobile Navigationsdienste . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.2 Eigenschaften kommerzieller mobiler Navigationsdienste . . . . . . . . . . . . . . . . . . 45 4.1 Darstellungsformen in allozentrischer/egozentrischer Perspektive . . . . . . . . . . . . . . 59 vi Kapitel 1 Motivation 1.1 Problembeschreibung Die Ära des Mobile Distributed Computing“ [SAW 94, Schi 95, BuTu , TavS 03] zeichnet sich durch ei” ne wachsende Anzahl mobiler, vernetzter Endgeräte aus. Diese Endgeräte können aufgrund der Mobilität überall mitgeführt werden und sind überall nutzbar. Daten können über Ad-hoc- oder Infrastrukturnetze, die auf verschiedensten Technologien basieren können, drahtlos ausgetauscht werden und sind dadurch an vielen Orten einsetzbar. Beispiele mobiler Endgeräte sind Mobiltelefone. Ursprünglich war ihre Aufgabe, Sprachdaten zwischen unterschiedlichen Geräten (wahlweise mobil oder stationär) zu übertragen. Auf dem Weg zur dritten Mobilfunkgeneration tritt neben der Nutzung von Sprachdiensten auch die Nutzung von Datendiensten in Erscheinung. Viele Mobiltelefone wurden deshalb bereits in ihrer Funktionalität stark erweitert, um die Voraussetzung für diese Dienste zu ermöglichen. So boten erste Mobiltelefone oft nur ein kleines, segmentbasiertes, einfarbiges Display zur Darstellung von alphanumerischen Zeichen und geringe Rechenleistung sowie wenig Speicher. Für die reine Nutzung von Sprachdiensten waren diese Endgeräte vollkommen ausreichend, doch leider auf derartige Dienste beschränkt. Moderne Mobiltelefone der heutigen Zeit verfügen hingegen oft über größere, grafische, mehrfarbige Displays, die aufwändige Darstellungen zulassen. Ermöglicht wird dies außerdem durch relativ leistungsstarke Prozessoren und verhältnismäßig großen Speicher. Desweiteren bieten sie Zugang zu drahtlosen Metropolitan Area Networks (MANs) wie es zum Beispiel durch das Universal Mobile Telecommunications System (UMTS) betrieben wird. Zusätzlich ermöglichen offene Plattformen die dynamische Integration von Softwarekomponenten von Drittanbietern. Dadurch können verschiedenste Dienste auf dem mobilen Endgerät angeboten werden, die durch die Vernetzung eine Vielzahl an Informationen bei der Ausführung heranziehen können. Mittels dieser Dienste ist es möglich, den Menschen in den unterschiedlichsten Lebenslagen zu unterstützen. Anwendungsgebiete sind zum Beispiel die Verwaltung von Terminen oder das Versenden und Empfangen von Nachrichten. Aber auch die Umsetzung komplexerer Dienste wie zum Beispiel Navigationsdienste werden möglich. Navigationsdienste unterstützen den Menschen bei der Wegfindung. Dabei werden vor allem zwei Verfahren der Dienstnutzung unterschieden. Diese sind die gewöhnliche Pull-Interaktion, bei der der Nutzer den Dienst aktiv anstößt, und die Push-Interaktion (vgl. [3gp d, FrZd 96, Pars 04]). Dabei wird der Dienst automatisch angestoßen, wenn ein Zustand erreicht wird, der das Zustellen von Navigationsinformationen nötig macht. Dieser Zustand kann zum Beispiel an einer Straßenkreuzung eintreten, falls der Nutzer einer totalen oder partiellen Ortsunkenntnis unterliegt. Durch das automatische Bereitstellen dieser Navigationsinformationen durch Navigationsdienste auf mobilen Endgeräten wird eine effiziente und vor allem effektive Bewegung des Menschen erleichtert. Ein Mitführen von Routenbeschreibungen, wie beispielsweise Landkarten, und eine Abbildung der daraus gewonnenen Informationen auf die Realität ist dabei überflüssig. Mobile Navigationsdienste treten bereits in 1 2 KAPITEL 1. MOTIVATION einigen Bereichen vermehrt in Erscheinung. Besonders ist hier die Kraftfahrzeugnavigation zu nennen, die in den letzten Jahren stark an Attraktivität gewonnen hat. Ein anderer Bereich, der bisher wenig Aufmerksamkeit erlangt hat, ist die Navigation von Fahrradfahrern. Entsprechende Routen verlaufen häufig in Regionen, die dem Fahrradfahrer wenig oder gar nicht bekannt sind. Bisher galt das Mitführen von physischen Routenbeschreibungen, meist in Form von Landkarten, als die einzige Möglichkeit, um sich zurecht zu finden. Mobile Navigationsdienste, die speziell auf dieses Anwendungsgebiet zugeschnitten sind, können den Nutzer in hohem Maße bei der Wegfindung unterstützen und bieten ihm daher einen interessanten Mehrwert. Durch die Push-Interaktion wird kein Eingriff des Nutzers mehr benötigt, um den Dienst anzustoßen. Eine automatische Bereitstellung der Navigationsinformationen trägt wesentlich zur effizienten Bewegung bei, da der Nutzer von der Entscheidungskompetenz über die Relevanz von Initiierungszuständen entlastet wird. Dies ist vor allem bei der Fahrradnavigation von Interesse, da hier eine Vielzahl an Zuständen, die eine Navigation nötig machen, auftreten können. Desweiteren ist bei der Fahrradnavigation der bereits hohe kognitive Aufwand für die Fortbewegung in Betracht zu ziehen. Dieser muss adäquat durch den mobilen Navigationsdienst umgesetzt werden. 1.2 Aufgabenstellung Ziel dieser Arbeit ist es, einen mobilen Navigationsdienst für Fahrradfahrer zu entwickeln. Im Speziellen sollen Mountain-Biker betrachtet werden, da diese sich durch einige Besonderheiten, wie stark fluktuierende Geschwindigkeiten, von normalen Fahrradfahrern differenzieren. Dadurch müssen neben den Problemen der herkömmlichen Fahrradnavigation auch die Besonderheiten im Bereich des Mountain-Bike-Sports betrachtet werden. Besonders von Interesse ist in dieser Arbeit die Architektur, die dem Navigationsdienst zugrunde liegt. Aufgrund der Push-Interaktion und des Bezugs auf Ortsinformationen des Dienstnutzers wird diese im Folgenden mit dem Begriff Location-based Push-Architektur bezeichnet. Um die Anwendbarkeit dieser Architektur zu demonstrieren, soll ein Prototyp des Mountain-Bike-Navigationsdienstes erstellt und unter realen Bedingungen getestet werden. 1.3 Aufbau der Arbeit Diese Arbeit gliedert sich in sieben Kapitel und einen Anhang. Das erste Kapitel liefert eine Motivation für diese Arbeit und eine kurze Zusammenfassung des Inhaltes. In Kapitel 2 wird detaillierter auf die Navigation eingegangen. Zu Beginn wird eine kurze Einführung in die Kunst der Navigation gegeben und anhand der Geschichte der Navigation deren Ursprung aufgezeigt. Neben der Beschreibung des menschlichen Navigationsprozesses werden wesentliche Probleme bei der Navigation für den Menschen angesprochen. Die moderne Informationstechnik kann einen entscheidenden Beitrag zur Lösung dieses Problems liefern. Im Folgenden wird deshalb auf mobile Navigationsdienste eingegangen. Diese werden der Obermenge der Location-based Services, im Speziellen den Location-based Push-Services, zugeordnet. Anschließend erfolgt eine detaillierte Analyse der mobilen Navigationsdienste. Hier stehen vor allem die Route als essentieller Bestandteil der Wegfindung und deren Operationalisierung in dieser Arbeit im Vordergrund. In diesem Zusammenhang ergibt sich die Notwendigkeit von Routendiensten, die darauf folgend kurz beschrieben werden. Schließlich endet dieses Kapitel mit der Anforderungsanalyse des speziellen Navigationsdienstes für Mountain-Biker. Dessen Konzeption und Implementierung wird in den nachfolgenden Kapiteln erörtert. Hier steht vor allem die Architektur, die diesem Dienst zugrunde liegt, im Vordergrund, da sie der wesentlichen Zielsetzung dieser Arbeit entspricht und die entscheidende Innovation liefert. Um den derzeitigen Stand der Technik und Forschung in Bezug auf Konzeption und Implementierung des Navigationsdienstes in Betracht zu ziehen, erfolgt in Kapitel 3 eine Übersicht über Technologien, Forschungsprojekte und bestehende Dienste, die sich in diesem Zusammenhang durch hohe Relevanz auszeichnen. Das Kapitel beginnt mit einigen ausgewählten Ortungsverfahren und deren Umsetzung in vorhandenen Systemen. Nachfolgend wird auf einige mobile Programmierplattformen eingegangen, mit deren 1.3. AUFBAU DER ARBEIT 3 Hilfe eine Implementierung des Navigationsdienstes ermöglicht wird. Dabei liegt der Fokus auf J2ME als modular aufgebaute, moderne, objektorientierte Laufzeitumgebung mit verschiedenen Erweiterungen, die die Arbeit auf dem mobilen Endgerät wesentlich erleichtern. Desweiteren beschreibt dieses Kapitel einige ausgewählte Forschungsprojekte, die ähnliche Dienste und Probleme behandeln und bei der Konzeption des Navigationsdienstes maßgeblich beteiligt waren. Das Kapitel endet mit einer Analyse bestehender kommerzieller Navigationsdienste aus verschiedenen Bereichen. Den Schwerpunkt dieser Arbeit stellt Kapitel 4 dar. Darin wird die Architektur des Navigationsdienstes sukzessiv erarbeitet. Vor allem der modulare Aufbau der Location-based Push-Architektur steht hier im Vordergrund. Der erste Teil dieses Kapitels ist deshalb einer möglichst detaillierten Analyse und Beschreibung der einzelnen Module gewidmet. Um sich nicht bereits im Vorhinein einzelnen zugrunde liegenden Technologien zu unterwerfen, erfolgt die Architekturkonzeption unabhängig von diesen Technologien. Die für die Realisierung eingesetzten Technologien kommen erst bei der Implementierung zum tragen und werden deshalb erst dort konkretisiert. Der zweite Teil dieses Kapitels behandelt die Verteilung der einzelnen Module auf Entitäten eines möglichst allgemeingültigen mobilen Systems. An der Wahl der optimalen Verteilung sind einige Einflussgrößen maßgeblich beteiligt. Diese werden dort genauer untersucht und die Vorund Nachteile einzelner Verteilungsalternativen betrachtet. Die gewonnen Resultate der Architekturkonzeption und Verteilungsanalyse stellen die Basis der in Kapitel 5 beschriebenen Implementierung des Mountain-Bike-Navigationsdienstes dar. Dieses Kapitel beginnt mit der Wahl der eingesetzten Technologien für Ortung, Programmierung und dazu nötigen Hardwarekomponenten. Danach erfolgt ein kurzer Einblick in einige Implementierungsdetails des Dienstes, die sich durch hohe Relevanz bzw. entscheidende Lösungsansätze auszeichnen. Im Besonderen ist hier wieder die Implementierung der Location-based Push-Architektur anzuführen. Hierfür strukturiert sich dieser Abschnitt durch die bereits angeführten Module der Architektur. Einige Diagramme veranschaulichen hierbei die komplexen Zusammenhänge. Eine Evaluierung der Implementierung schließt sich in Kapitel 6 an. Dabei wird auf Probleme bei der Implementierung und ersten Testversuchen des Prototyps eingegangen. Soweit möglich, werden Lösungsvorschläge für die erkannten Probleme angegeben. Einige anfängliche Probleme des Prototyp wurden im Laufe dieser Arbeit gelöst und in einer zweiten Testreihe nochmals evaluiert. Dieses Kapitel liefert dadurch wichtige Erkenntnisgewinne für die Umsetzung mobiler Navigationsdienste. Eine Zusammenfassung der Resultate dieser Arbeit erfolgt in Kapitel 7. Abschließend wird ein Ausblick für Erweiterungen des Navigationsdienstes und vor allem der Location-based Push-Architektur gegeben. Zur vollen Funktionsfähigkeit des Navigationsdienstes ist desweiteren ein Routendienst, der die Bereitstellung, Verwaltung und Generierung von Routen handhabt, nötig. Dieser wird im Anhang A beschrieben. Der Routendienst wurde nicht in den Hauptteil der Arbeit integriert, da er keine obligatorische Position in der Location-based Push-Architektur einnimmt und nur als Erweiterung des Navigationsdienstes für die komfortable Handhabung der Routen dient. In diesem Sinne stellt der Routendienst eine externe Komponente der Location-based Push-Architektur dar und wird deshalb erst im Anhang beschrieben. Der Anhang ist in ähnlicher Art und Weise aufgebaut wie der Hauptteil der Arbeit. Dementsprechend beginnt er mit einer Gegenüberstellung verschiedener digitaler Datenbestände für Pfadinformationen, die einen Basisbestandteil der Routenerzeugung einnehmen. Im Folgenden wird die Architektur des Routendienstes und der zugrunde liegenden Software beschrieben und anhand einiger Aspekte der Implementierung die Umsetzung erläutert. Einige Screenshots zeigen hierbei die grafische Benutzerschnittstelle der Routenerstellung. Schließlich endet der Anhang mit einer Evaluation des Routendienstes und einem kurzen Ausblick. Kapitel 2 Mobile Navigationsdienste 2.1 Navigation Der Begriff der Navigation ist im Allgemeinen jedem Menschen bekannt, doch was sich genau dahinter verbirgt, wird oft nur oberflächlich erkannt. Obwohl jeder Mensch tagtäglich die Navigation nutzt, um von Ort A zu Ort B zu gelangen, fällt es auf den ersten Blick schwer, die Navigation zu beschreiben oder sie zu erklären. Das erste Kapitel dieser Arbeit soll daher einen Einblick in die Kunst der Navigation bieten. Dazu ist der Anfang dieses Kapitels der Geschichte und dem allgemeinen Orientierungsproblem, das die Navigation nötig macht, gewidmet. Darauf folgend wird erläutert, inwiefern mobile Dienste die Navigation für den Menschen erleichtern können, und eine Beispielanwendung beschrieben, die den Einsatz und die Realisierbarkeit derartiger mobiler Navigationsdienste zeigen wird. 2.1.1 Navigationshistorie Erste Erscheinungen des Navigationsbegriffs traten bereits weit vor Christi Geburt auf. Hauptzweck war zu dieser Zeit die Orientierung zu Wasser (vgl. [Logs 92, wik ]. Auch der Begriff der Navigation ist in diesem Zusammenhang entstanden. Das Wort Navigation“ hat seinem Ursprung in der lateinischen Sprache ” und setzt sich aus den beiden Wörtern navis“ (Schiff) und agere“ (führen) zusammen. Unter Navigation ” ” verstand man demnach alles, was dazu nötig war, ein Schiff zu führen. Dazu zählte das richtige Setzen der Segel, das Umschiffen von Hindernissen und natürlich das zielgerichtete Fortbewegen auf See zur Erreichung des Zielhafens. Anfänglich orientierten sich die Seefahrer dazu an markanten Punkten an Land, den so genannten Landmarken, die sie vom Wasser aus erkennen konnten. Um sich auch auf offener See orientieren zu können, setzten sie später ein anderes Verfahren zur Positionsbestimmung ein. Dazu gingen sie von ihrem Heimathafen aus und bestimmten aus Bewegungsrichtung (z.B. ermittelt anhand von Himmelskörpern), Geschwindigkeit (z.B. ermittelt mit Hilfe eines Logs) und Zeitdauer ihre gegisste Position. Man nennt diese Art der Navigation, deren Ortung auf dem Ausgangsort, der Bewegungsrichtung und der zurückgelegten Strecke (berechnet aus Geschwindigkeit und Fahrzeit) aufbaut, Koppelnavigation oder engl. Dead Reckoning 1 . Die Koppelnavigation galt lange Zeit als die einzige Art der Navigation. Nachteil war die fehlende Genauigkeit der Positionsbestimmung. Ausschlaggebend für die teilweise sehr hohe Genauigkeitsbeeinträchtigung waren Akkumulationsfehler. Durch sie resultierten aus anfänglich geringen Messfehlern signifikante Abweichungen von der tatsächlichen Position zu späteren Zeitpunkten. Obwohl stetig Neuerungen die Messverfahren verbesserten, ließ die Genauigkeit dieser Technik viele Jahrhunderte sehr zu wünschen übrig. Eine entscheidende Entwicklung war die Erfindung des Magnetkompasses im 11. Jahrhundert in 1 Dead Reckoning ist eine Kurzform für Deduced Reckoning 4 2.1. NAVIGATION 5 China. Er ermöglichte eine weitaus genauere Ermittlung der Bewegungsrichtung und somit geringere Akkumulationsfehler. Allerdings wurde diese Genauigkeitsverbesserung nicht in der Nähe der Pole erreicht, da die magnetischen Pole von den geografischen Polen abweichen (Deklination) und dadurch das Ergebnis stark verfälscht wird. Nachdem für lange Zeit keine Genauigkeitssteigerung in der Koppelnavigation erreicht wurde, entwickelte sich im 17. Jahrhundert ein alternativer Lösungsansatz mit Hilfe der Lateration. Mit Lateration wird das Messen des Abstandes zu mehreren Referenzpunkten bezeichnet. Hilfswerkzeuge zur Messung des Abstandes waren zu dieser Zeit die Winkelmessinstrumente Oktant und Sextant. Mit Hilfe dieser Geräte war es möglich, den Winkel zwischen dem Horizont und einem Himmelskörper (z.b. Sonne, Mond, Sterne) zu messen und daraus den Abstand zum Zenitpunkt, auch Bildpunkt genannt (fiktiver Punkt auf der Erdoberfläche, auf dem der Himmelskörper senkrecht steht), zu berechnen. Anhand eines Nachschlagewerkes, dem so genannten Almanach, konnte man die Koordinaten des Zenitpunktes ablesen und so seine Position auf einer Kreislinie festlegen. Durch mehrmaliges Messen ließ sich so die aktuelle Position bestimmen. Die Lateration ebnete einige Jahrhunderte später auch den Weg zur Satellitennavigation. Nicht nur aufgrund der sehr viel genaueren Ortung, gilt die Satellitennavigation als eine der wichtigsten Errungenschaften der heutigen Navigation. Sie hat außerdem den entscheidenden Vorteil, dass sie bei richtiger Konstellation der Satelliten auf der ganzen Welt zu jeder Zeit mit einer relativ konstanten Fehlergröße verfügbar ist. Bekannte satellitenbasierte Ortungsverfahren sind das US-amerikanische Global Positioning Systems (GPS) [off a], das russische Global’naya Navigatsionnaya Sputnikovaya Sistema (GLONASS) [glo b] der ehemaligen UdSSR und das europäische Galileo [gal ]. Das derzeit am häufigsten eingesetzte System ist GPS. Eine genauere Betrachtung von GPS folgt in Kapitel 3.1. Wie diese Historie zeigte, ist die Navigation nichts neues in der Geschichte der Menschheit. Doch zeigt sie in der heutigen Zeit eine stetig wachsende Nachfrage innerhalb verschiedenster Anwendungsgebiete. Egal ob auf dem Boden, in der Luft oder zur See ist Mobilität ein entscheidendes Schlagwort unserer Zeit. Dabei bewegt sich der Mensch in den verschiedensten Arten fort. Er geht zu Fuß, fährt mit dem Auto, mit der Bahn, mit dem Schiff oder fliegt mit dem Flugzeug. Durch die erhöhte Unkenntnis über den aktuellen Aufenthaltsort und geografische Zusammenhänge erhält die Navigation einen erhöhten Stellenwert in seinem Leben. 2.1.2 Menschliche Navigation Nachdem nun die Geschichte und das stetige Interesse der Menschheit an der Navigation gezeigt wurden, bleibt die Frage offen, was Navigation überhaupt bedeutet. [Mont ] bezeichnet die Navigation als coordinated and goal-directed movement“. Dabei unterscheidet er strikt zwischen Lokomotion“ und ” ” Wegfindung“. Als Lokomotion (engl. Locomotion) wird die Bewegung bezeichnet, die sich aufgrund ” der Wahrnehmung des unmittelbaren Umfeldes intuitiv ergibt. Die Lokomotion ist demnach für die eigentliche Fortbewegung verantwortlich. Sie koordiniert die Bewegung, um das Gleichgewicht zu halten, zu beschleunigen und abzubremsen oder Hindernisse zu umgehen. Dabei werden aktive Bewegungsarten wie Gehen, Laufen oder Rennen über Mischformen wie Radfahren oder Autofahren bis hin zu passiven Bewegungsarten wie Zug- oder Busfahren unterstützt. Die einzelnen Bewegungsarten werden durch die Wahrnehmungen verschiedener Sensoren koordiniert. Für die Lokomotion trägt vor allem die Wahrnehmung von visuellen, akustischen, kinästhetischen und vestibulären Signalen durch die menschlichen Sinnesorgane dazu bei unbeschadet von A nach B zu gelangen. Die Reaktion auf diese Signale sorgt dafür, beim Gehen nicht zu stolpern oder beim Radfahren das Gleichgewicht halten zu können. Im Gegensatz zur Lokomotion, der intuitive Prozesse zugrunde liegen, zeichnet sich die Wegfindung (engl. Wayfinding) im Normalfall durch ein höheres Maß an Kognition aus. [Mont ] bezeichnet die Wegfindung als planning and decision-making activities that allow goal-directed locomotion coordinated to the di” stal as well as local surrounds“. Anders als die Lokomotion ist die Wegfindung nicht auf das unmittelbare Umfeld beschränkt. Die Wegfindung ist primär für die Planung und Entscheidung der Bewegung im weiteren Umfeld des Subjektes verantwortlich. Das weitere oder mittelbare Umfeld wird oft unter dem Begriff Large-scale environment“ benutzt. Es kann nicht direkt durch Sensoren wahrgenommen werden ” und benötigt daher Hintergrundinformationen. Diese Hintergrundinformationen sind zuvor angeeignetes Wissen wie zum Beispiel kognitive Karten [Tolm 48] (internes Wissen) oder physisches Kartenmaterial 6 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE (externes Wissen), sowie verschiedenste Arten von Routenbeschreibungen (intern sowie extern). All diese Informationen führen zum deklarativen Wissen, im Gegensatz zum nicht-deklarativen Wissen, welches zur Lokomotion eingesetzt wird. Deklaratives Wissen ist Wissen, dessen Inhalt eindeutig beschreibbar ist und dessen Verarbeitung kognitive Prozesse verlangt. Zum deklarativen Wissen zählt beispielsweise das Wissen über geografische Gegebenheiten oder Routenwissen. Aufgrund der kognitiven Prozesse in der Verarbeitung des deklarativen Wissens verlangt die Wegfindung einen erhöhten Grad an Aufmerksamkeit. Je nach Ausprägung des deklarativen Wissens kann der Grad der Aufmerksamkeit variieren. Kognitive Karten zeichnen sich beispielsweise durch ein relativ geringes Aufmerksamkeitsverlangen aus, da sie nur stark schematisierte, topologische Repräsentationen der realen Welt sind und somit unnötige Informationen ausblenden und sich auf relevante inhaltliche Zusammenhänge beschränken. Dagegen legt physisches Kartenmaterial im Normalfall höhere Aufmerksamkeit zugrunde. Vor allem wenn die Karte nicht orientiert ist, muss im Zuge der Navigation eine Umorientierung, d.h. eine Umsetzung der Richtungen der Karte auf die Richtungen der Realität erfolgen. Diese Umsetzung erzeugt eine Aufwandssteigerung der kognitiven Prozesse. Dies zeigt, dass der kognitive Aufwand, der durch die Wegfindung entsteht, abhängig von der subjektiven Qualität des Wissens ist (vgl. [BBKL ]). Ein zweites entscheidendes Problem ist natürlich, ob ein derartiges Wissen überhaupt verfügbar ist, bzw. verfügbar gemacht werden kann. An diesen zwei Punkten greift die moderne Informationstechnik ein. Durch sie ist es möglich, zu jeder Zeit an jedem Ort qualitativ hochwertige Informationen bereitzustellen. Sie bietet eine Lösung für das Wissensdefizit und eine Reduktion der kognitiven Prozesse durch qualitativ hochwertige, deklarative Informationen, die die Wegfindung betreffen. Diese Arbeit beschäftigt sich deshalb nur mit dem Problem der Wegfindung, die im Folgenden mit dem Wort Navigation“ gleichgesetzt wird. ” 2.1.3 Navigationsprozess Die Geschichte der Navigation hat bereits gezeigt, dass die verschiedenen Arten der Navigation sich größtenteils durch die Art ihrer Ortung unterscheiden. Beispiele hierfür sind die Sichtnavigation, die traditionelle Koppelnavigation oder die Satellitennavigation. Alle drei Arten unterscheiden sich wesentlich in der Art ihrer Ortung. Zwar ist die Ortung ein entscheidender Aspekt der Navigation, sie ist allerdings kein Synonym für die Navigation, obwohl dies häufig so verwendet wird. Innerhalb des Navigationsprozesses fallen aber weitere Schritte an, die für eine erfolgreiche Navigation unabdingbar sind. Einen Einstieg in den Navigationsprozess sollen die folgenden zwei Beispiele liefern: Auf dem Weg von A nach B kommt Person E auf ihrem Fahrrad an eine T-Kreuzung. Da sich E nicht auskennt, hält sie an und holt eine Straßenkarte der Region hervor. Darin sucht sie die Kreuzung, die sie anhand des Namens identifiziert. Um zu ihrem Ziel zu gelangen, muss E in die Hauptstraße einbiegen. E betrachtet die Straßennamen, erkennt die Hauptstraße und begibt sich in die Richtung ihres Ziels. Durch die schlechte Straßenbeschaffenheit verliert E das Gleichgeweicht auf ihrem Rad. Als ihr Unterbewusstsein bemerkt, dass sich ihr Schwerpunkt zu weit rechts befindet, wird ihr intuitiv klar, dass sie dem entgegenwirken muss. Dazu macht sie eine Ausgleichsbewegung und erlangt daraufhin langsam ihr Gleichgewicht wieder. Beide Beispiele beschreiben einen Navigationsprozess. Während sich das erste Beispiel auf die Wegfindung bezieht, behandelt das zweite Beispiel die Lokomotion. Beide Beispiele beschäftigen sich mit der grundlegenden Frage: Wo befinde ich mich?“ Eine Antwort dafür gibt die Ortung, die als Resultat Ortsin” formationen liefert. Anschließend, aber nicht zwingend nach jeder Ortung, stellt sich dann die Frage Wo ” muss ich hin?“ Zur Beantwortung muss die zukünftige Bewegungsrichtung bestimmt werden. Dies erfolgt durch die Routenführung. Letztlich stellt sich die Frage Wie setze ich dies in die Realität um?“ Dazu muss ” die zukünftige Bewegungsrichtung noch auf die reale Umgebung abgebildet werden. Dieses Kapitel befasst sich mit eben diesen Fragestellungen. Dazu erfolgt eine genauere Betrachtung des Navigationsprozesses und dessen Teilprozesse Ortung, Routenführung und Abbildung. 2.1. NAVIGATION 7 Ortung Als Ortung bezeichnet man allgemein die Bestimmung von Ortsinformationen. Eine der wichtigsten Ortsinformationen ist die Position. Unter Position (lat. positio = Stellung, Lage) einer Person oder eines Ge” genstandes versteht man die Stelle, an der sich die Person bzw. der Gegenstand befindet“ [wik ]. Durch die Position kann das Objekt in den geografischen Raum eingeordnet werden. Positionen können unterschiedliche Ausdehnungen und Formen besitzen und demnach ein einzelner Punkt bis hin zu einer weit ausgedehnten Fläche oder sogar ein Raum sein. Zur Operationalisierung von Positionen braucht man eine Beschreibung dieser Position. Um verschiedene Positionen zu vergleichen und mit diesen in eindeutiger Weise arbeiten zu können, muss diese Positionsbeschreibung an mindestens einen eindeutigen Punkt, einen Referenzpunkt, gebunden werden. Folglich kann die Position eines Objektes am Münchner Marienplatz beispielsweise mit am Münchner Rathaus“ ” beschrieben werden. Als Referenzpunkt wurde in diesem Fall das Rathaus von München gewählt, auf das eindeutig Bezug genommen werden kann. Allgemein sind Referenzpunkte reale oder fiktive Orte, die eine eindeutige Position im Raum einnehmen. Dazu müssen sie von anderen Orten unterscheidbar sein. Das Münchner Rathaus stellt einen eindeutigen realen Ort in der Münchner Innenstadt dar, der sich von anderen Orten eindeutig unterscheidet. Ein Beispiel für einen fiktiven Ort stellt der oben vorgestellte Zenitpunkt dar. Er ist der Ort auf der Erdoberfläche, auf dem zu einem bestimmten Zeitpunkt ein Himmelskörper senkrecht steht und ist dadurch eindeutig unterscheidbar von jedem anderen Ort. Ein weiterer wichtigerer eindeutiger Referenzpunkt ist der Masseschwerpunkt der Erde, das so genannte Geozentrum. Das World Geodetic System 1984 (WGS84)-Datum oder das European Terrestrial Reference System 1989 (ETRS89)-Datum mit dem Rotationsellipsoiden Geodetic Reference System 1980 (GRS80) nutzen als Referenzpunkt das Geozentrum der Erde (vgl. [wgs ]). Andere Beispiele, deren Referenzpunkt leicht vom Masseschwerpunkt der Erde verschoben ist, sind Datums 2 , die auf lokale Rotationsellipsoide aufbauen, wie der in Deutschland bekannte Bessel-Ellipsoid. Durch die Festlegung dieses Referenzpunktes ist es nun möglich, eine Position mit diesem Referenzpunkt gleichzusetzen. Natürlich ist die Ausdruckskraft einer derartigen Positionsbeschreibung noch sehr rudimentär. Was in vielen Fällen noch benötigt wird, ist die Möglichkeit, Entfernungs- und/oder Richtungsrelationen zu diesen Referenzpunkten angeben zu können. Ein vom Menschen oft verwendetes zweidimensionales Richtungsrelationensystem stellen die Ausdrücke vor“, rechts von“, hinter“ und links ” ” ” ” von“ dar. Durch sie lässt sich nun die bereits angeführte Position auf dem Marienplatz mit vor dem ” Münchner Rathaus“ ausdrücken. Derartige Relationen, die abhängig vom Betrachtungswinkel sind, gelten als egozentrisch. Im Gegensatz dazu sind allozentrische (oder geozentrische) Positionsbeschreibungen unabhängig vom Betrachtungswinkel, da sie zu einer allgemeingültigen Richtung referenziert sind (vgl. [Klat 04, Mont ]). Ein Beispiel hierfür ist das Relationensystem nördlich“, östlich“, südlich“, west” ” ” ” lich“. Obiges Beispiel mit allozentrischer Positionsbeschreibung lautet wie folgt: Person XY ist westlich ” vom Münchner Rathaus“. Für eine eindeutige Positionsbeschreibung muss an dieser Stelle noch der Abstand zwischen der Position und dem Referenzpunkt angeben werden. Im Bereich der Geodäsie werden Datums, durch die unter anderem Referenzpunkte spezifiziert werden, durch Koordinatensysteme erweitert, um die Relation zwischen Referenzpunkt und Position zu beschreiben. Zusammen ergibt sich das so genannte Koordinatenreferenzsystem [Nico 03]. Im Wesentlichen existieren zwei Arten von Koordinatensystemen in der dreidimensionalen Geodäsie: kartesische und ellipsoidische Koordinatensysteme (auch bekannt als geodätische Koordinatensysteme). In ellipsoidischen Koordinatensystemen werden Positionen durch so genannte LLA-Werte (Latitude-Longitude-Altitude-Werte) angegeben. Eine Position auf der Erde kann durch ihren Breitengrad und ihren Längengrad eindeutig bestimmt werden. Als Längengrade oder Längenkreise (oder Meridiane) werden hierbei die Kreise um die Erde durch beide Pole bezeichnet. Jeder Längenkreis hat daher den gleichen Umfang. Breitengrade oder Breitenkreise sind parallele Kreise zum Äquator. Sie haben im Unterschied zu den Längenkreisen unterschiedliche Umfänge. Sollen auch Positionen über- oder unterhalb der Erdoberfläche beschreibbar sein, muss zusätzlich der Abstand vom Referenzpunkt angegeben werden. LLA-Werte beschreiben genau diese Werte. Der Latitudenwert definiert den Breitengrad, auf dem sich die Position befindet, meist durch Angabe des Win2 geodätisches Datum, Mz. geodätische Datums 8 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE kels zwischen dem Äquator, dem Referenzpunkt und dem Breitengrad innerhalb eines Längenkreises. Der Longitudenwert definiert den Längengrad, auf dem sich die Position befindet, meist durch Angabe des Winkels zwischen einem Nullmeridian, dem Referenzpunkt und dem Längengrad innerhalb eines Breitengrades. Schließlich bestimmt die Altitude den Abstand zwischen der Position und dem Referenzpunkt. Durch diese drei Werte in Verbindung mit dem im Datum spezifizierten Referenzpunkt kann eine Position eindeutig beschrieben werden. In kartesischen Koordinatensystemen hingegen werden Koordinaten durch XYZ-Werte angegeben. Dies sind die Abstände zwischen dem Referenzpunkt und der Position entsprechend jeder Achse (X-, Y-, ZAchse) des dreidimensionalen Koordinatensystems. Die Positionsbeschreibungen zu Referenzpunkten wie Münchner Marienplatz“ werden oft als semantische ” Positionsbeschreibungen bezeichnet (vgl. [Roth 03]). Übliches Referenzsystem ist das bereits beschriebene Richtungsrelationensystem (vor, rechts von, hinter, links von). Demgegenüber werden Positionsbeschreibungen zu Referenzpunkten wie dem Geozentrum der Erde als physische Positionsbeschreibungen bezeichnet. Als Referenzsystem kommen hier meist Koordinatenreferenzsysteme zum Einsatz. Die vorangegangenen Absätze zeigten einen kurzen Einblick in die Geodäsie, die im Rahmen dieser Arbeit als Grundlage für das Verständnis örtlicher Zusammenhänge dienen soll. Für genauere Betrachtungen muss an dieser Stelle auf [geo 84, Küpp 05] verwiesen werden, da dies den Rahmen dieser Arbeit sprengen würde. Schließlich bleibt noch die Frage offen, wie nun die Relation zwischen der Position und dem Referenzpunkt bestimmt werden kann. Dazu existieren verschiedenste Verfahren basierend auf Abstands- und Winkelmessungen zwischen der Position und dem Referenzpunkt oder anderen fixen Punkten, deren Positionen bereits bekannt sind (vgl. [HiBo 01, Küpp 05]). Die Verfahren unterscheiden sich im Wesentlichen durch die Anzahl der nötigen Messungen und dem der Messung zu Grunde liegenden Observable“. Auf ei” ner zweidimensionalen Fläche sind beispielsweise drei Abstandsmessungen zwischen der Position und drei nicht-kollinearen fixen Punkten ausreichend, um die Position eindeutig zu bestimmen. Genauso möglich ist allerdings eine Winkelmessung zwischen Position und Referenzpunkt bezüglich einer Referenzrichtung und eine Abstandsmessung zwischen Position und Referenzpunkt (oder fixem Punkt). Die Messung kann dabei auf verschiedensten Signalen wie Radiowellen, Ultraschall, Lichtwellen, sowie kinästhetischen oder vestibulären Signalen basieren. Letztendlich wird aus dieser Messung auf verschiedenste Arten der Abstand oder die Richtung gewonnen. Beispielsweise kann der Abstand durch die Signalabschwächung, durch einfache Integration der Geschwindigkeit oder zweifache Integration der Beschleunigung nach der Zeit ermittelt werden. Neben der Position ist die Ausrichtung (oder Orientierung) eine zweite wichtige Art von Ortsinformation. Die Ausrichtung eines Objektes kann nur für Objekte, die eine Ausrichtung besitzen, angegeben werden. Der Mensch als Beispiel kann sich durch mehrere Ausrichtungen auszeichnen. Diese sind beispielsweise die Blickrichtung oder die Bewegungsrichtung, die nicht zwangsläufig gleichwertig sein müssen, jedoch bei Ungleichheit zu schweren Unfällen führen können. Zur Operationalisierung der Ausrichtung gibt es wie bei der Position verschiedene Beschreibungen. Basis ist wie bei der Position eine Referenzrichtung. Die Ausrichtung kann dann mittels des Winkels zwischen der Richtung und der Referenzrichtung beschrieben werden. Die Beschreibung einer Ausrichtung ist in der Regel allozentrisch oder egozentrisch zu einer anderen Ausrichtung, da eine egozentrische Beschreibung, die als Referenzrichtung eben diese Ausrichtung nutzt, immer einen Winkel von 0 Grad besäße (vgl. [Klat 04]). Eine Beschreibung der Bewegungsrichtung kann so zum Beispiel 30◦ gegenüber der allozentrischen Richtung Norden sein oder 215◦ gegenüber der egozentrischen Blickrichtung. Durch die Lokomotion verändern sich in der Regel die Ortsinformationen. Nimmt man alle Ortsinformationen zusammen und beschreibt dadurch einen Zustand, werden durch die Lokomotion Zustandsübergänge durchgeführt (vgl. [Kuip 00]). Dabei lösen bestimmte Zustände bzw. Zustandsübergänge die Routenführung aus. Etwas anschaulicher kann dies an der menschlichen Navigation gezeigt werden. Bewegt sich ein Mensch auf einem Straßennetzwerk und erreicht durch die Lokomotion die Kreuzung K1 aus südlicher Richtung, so kann sein Zustand durch die Ortung zum Beispiel durch (K1 , N ord) beschrieben werden, wobei K1 seine Position und N ord seine Bewegungsrichtung angibt. Da dieser Zustand für ihn die Frage Wo muss ich hin?“ aufwirft, wird daraufhin die Wegfindung angestoßen, die ihn wie ” im einleitenden Beispiel dazu bringt eine physische Karte aufzuschlagen und dort ausgehend von seinen derzeitigen Ortsinformationen den weiteren Routenverlauf zu studieren. Die Wegfindung kann aber auch aufgrund eines Zustandsüberganges angestoßen werden. Ein Beispiel hierfür ist, dass Zurücklegen einer 2.1. NAVIGATION 9 bestimmten Menge von Zustandsübergängen. Ausgehend von dieser Menge wird die Routenführung angestoßen. Die Ortung ist also nicht nur für die Bestimmung von Ortsinformationen verantwortlich, sondern übernimmt auch die Aufgabe bei Eintritt bestimmter Zustände bzw. Zustandsübergänge, die Routenführung anzustoßen. Routenführung Die Routenführung bestimmt dann anhand von Routeninformationen die in Zukunft einzuschlagende Richtung. [Pass 92] bezeichnet diesen Vorgang als Decision Making. Anhand der Route wird die Entscheidung über die zukünftige Bewegungsrichtung getroffen. Eine Route stellt zur aktuellen Position Informationen für den weiteren Routenverlauf bereit. Ist die aktuelle Position nicht in der Route spezifiziert, muss gegebenenfalls eine andere Route herangezogen werden, bzw. bestimmt werden. Eine übliche Routendarstellung für die menschlichen Navigation, ist die Integration in Landkarten. Als Ausgangspunkt dient eine isolierende, statische Projektion der Realität auf eine zweidimensionale Ebene (vgl. [Beck 02]). Eine der wichtigsten Projektionsart ist die Transversale Mercator Projektion, die z.B. beim UTM- und beim Gauß-Krüger-Koordinatensystem zum Einsatz kommt. Um eine möglichst originalgetreue Abbildung der Realität zu erzeugen, spielt neben der Wahl des Projektionsverfahrens der Karteninhalt eine entscheidende Rolle. Eine allumfassende Darstellung der Realität würde zwangsläufig zu einer Karte, die so groß ist wie die Realität selbst führen, wie es Jorge Luis Borges in Of Exactitude in Science“ ” [BoCa 46] anschaulich beschreibt. Es muss eine geeignete Selektion des Inhaltes vorgenommen werden. Welche Informationen in der Landkarte enthalten sind, ist wesentlich von der Art der Landkarte abhängig. Topografische Landkarten beispielsweise beschränken sich auf die Darstellung der natürlichen Erdoberfläche. Sie dienen als Basis für viele weitere Landkartenarten, die sich beispielsweise durch Hinzunahme der Landesgrenzen, Bebauungen oder klimatischer Aspekte auszeichnen. Schließlich wird basierend auf dieser verkleinerten und vereinfachten Abbildung der Realität die Route in Form von Wegstrecken innerhalb einer Landkarte dargestellt. Eine Wegstrecke ist hierbei ein Linienzug, der durch diverse Zwischenpunkte den Start- mit dem Zielpunkt verbindet, wobei Start- und Zielpunkt sowie Zwischenpunkte identisch sein können. Zusammen mit der zu Grunde liegenden Landkarte führt diese Wegstrecke zu einer vollwertigen Routenbeschreibung. Durch die Ortung kann die Position auf diesem Linienzug erkannt und anhand des weiteren Routenverlaufs die einzuschlagende Richtung bestimmt werden. Eine genauere Betrachtung von Routen erfolgt in Kapitel 2.2. Abbildung Schließlich muss eine Abbildung der aus dem Routenverlauf ersichtlichen zukünftigen Bewegungsrichtung in die Realität erfolgen. Je nach Art der Routenbeschreibung kann dieser Schritt des Navigationsprozesses trivial bis sehr komplex werden. Aus obiger Routenbeschreibung mittels einer Kartendarstellung kann die zukünftige Bewegungsrichtung anhand von Straßennamen erkannt und auf die Realität abgebildet werden. Dazu liest der Navigator aus der Karte ab, dass er in Richtung seines Ziels gelangt, wenn er an der nächsten Kreuzung in die Hauptstraße einbiegt. Mit diesem Wissen betrachtet er seine Umgebung, erkennt die Hauptstraße und kann so das aus der Routenbeschreibung erworbene Wissen auf die Realität abbilden. Anschließend folgt die eigentliche Umsetzung der zukünftigen Bewegungsrichtung durch die Lokomotion. [Pass 92] bezeichnet diesen letzten Schritt der Umsetzung als Decision Execution. Zusammenfassung Dieses Kapitel zeigte nun wie ein Navigationsprozess ablaufen kann. Dabei wurde eine Routenbeschreibung innerhalb einer Karte gewählt. Aber es existieren auch andere Routenbeschreibungen, die bei der menschlichen Navigation zum Einsatz kommen. Ein Beispiel sind imperative Routenbeschreibungen. Ein Ausschnitt einer imperativen Routenbeschreibung könnte folgendermaßen aussehen: ... dann gehe die ” 10 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE Hauptstraße Richtung Norden und biege die zweite mögliche Straße rechts ab. Anschließend musst du nach 250 Metern links abbiegen und ...“ . Dieses Beispiel zeigt bereits anschaulich, dass der Navigationsprozess sich als sehr komplex herausstellen kann. Erhält man eine derartige Routenbeschreibung, so stellt sich als erstes die Frage, wo überhaupt die Hauptstraße verläuft. Angenommen man erkennt dies anhand eines Straßenschildes, so stellt sich dann die Frage in welcher Richtung sich Norden befindet. Desweiteren ist von Interesse was eine mögliche Straße ist und wie weit 250 Meter sind. Wie man hier erkennt, kann ein derart kurzes Routenfragment bereits eine Vielzahl an Problemen hervorbringen, deren Lösung durch technische Unterstützung dem Menschen einen großen Mehrwert bieten kann. 2.2 Mobile Navigationsdienste 2.2.1 Mobile Dienste In der Ära des Ubiquitous Computing“ [Weis 91] ist der Mensch von einer Vielzahl an intelligenten ” Geräten umgeben, die ihm seinen Alltag erleichtern. Geräte wie Mobiltelefone, Personal Digital Assistants (PDAs) und Notebooks gehören in der heutigen Zeit zur ständigen Ausstattung vieler Menschen. Diese Geräte werden erweitert durch Desktop-PCs im Büro und zu Hause, intelligente Fahrzeuge oder sogar intelligenten Staub. All dies macht es möglich zu jeder Zeit an jedem Ort den Zugriff auf jegliche Informationen (z.B. Fahrpläne, Wettervorhersagen, Telefonnummern) und jegliche Anwendungen (z.B. Auktionen, Photoentwicklung, Kommunikationsverbindung) zu ermöglichen. Egal, ob zu Hause auf dem Desktop-PC oder unterwegs auf dem Mobiltelefon, können Informationen abgefragt oder Anwendungen genutzt werden (vgl. [SAW 94, Schi 95, BuTu , RuKr 03]). Diese Informationen und Anwendungen werden von Diensten (engl. Services) bereitgestellt. [Stra 03] definiert einen Dienst als eindeutig identifizierbare Instanz, die für die Beschaffung von Informationen oder ” für die Ausführung von Aktionen mit spezifischen Merkmalen verantwortlich ist“. Dabei kann zwischen Carrier Services und Highlevel Services unterschieden werden (vgl. [SLPR 03, Röck 03]). Carrier Services stellen im Wesentlichen Funktionen zur Datenübertragung bereit. Beispiele für Carrier Services sind der Short Message Service (SMS), der General Packet Radio Service (GPRS) oder auch diverse Datenübertragungsdienste für drahtgebundene Netze. Highlevel Services nutzen Carrier Services, um ihr Anwendungsoder Informationsangebot verfügbar zu machen. Beispiele für Highlevel Services sind Fahrplanauskunfts-, Photoentwicklungs- und Navigationsdienste. Sie stellen Highlevel-Informationen“ wie Ab- und Ankunfts” daten von Bussen, Flugzeugen, etc., Navigationsinformationen und die Funktion der Photoentwicklung (vgl. [Röck 03, SLPR 03]) bereit. Die Datenübertragung wird durch die Carrier Services übernommen. Diese Arbeit beschäftigt sich ausschließlich mit Highlevel Services und bezeichnet mit den Ausdrücken Dienst“ oder Service“ deshalb in der Regel Highlevel Services. ” ” Durch die Entwicklung von mobilen Endgeräten wie Mobiltelefonen, PDAs, Notebooks ist es nun möglich, diese Art von Diensten nicht nur zuhause oder im Büro zu nutzen, sondern an jedem beliebigen Ort. Dienste, die in dieser Weise genutzt werden können, nennt man mobile Dienste. Oft unterscheidet man hierbei noch zwischen Portabilität und echter Mobilität, wobei Portabilität einer nomadischer Dienstnutzung unterliegt, während echte Mobilität eine kontinuierliche Dienstnutzung garantiert. 2.2.2 Location-based Services Eine besondere Art der mobilen Highlevel Services sind so genannte Location-based Services (LBSs). Wie der Name bereits erahnen lässt, handelt es sich hierbei um Dienste, die eine erhöhte Aufmerksamkeit auf den örtlichen Kontext legen. In der Literatur findet man eine Vielzahl an Definitionen, die LBSs anhand verschiedenster Gesichtspunkte charakterisieren. Beispielsweise beschreibt die GSM Association LBSs als services that use the location of a target for adding value to the service“ [gsm 03]. In dieser Definition ” zeichnet sich ein LBS also dadurch aus, dass der Wert des Dienstes durch den Ort generiert wird. Fraglich ist an dieser Stelle, was der Wert eines Dienstes ist und wie der Ort diesen Wert beeinflusst. Das 3rd Generation Partnership Project (3GPP) definiert den LBS als a service provided by a service provider ” 2.2. MOBILE NAVIGATIONSDIENSTE 11 that utilizes the available location information of the terminal“ [3gp 04]. In dieser Definition sind LBSs Dienste, die sich Ortsinformationen des Endgerätes zunutze machen. Dabei werden ausschließlich Ortsinformationen des Endgerätes, auf dem der Dienst genutzt wird, in Betracht gezogen. Bevor nun eine Definition für LBSs gegeben werden kann, die die entscheidenden Aspekte dieser Arbeit beinhaltet, müssen noch einige grundsätzliche Fragestellungen im Umfeld von Diensten geklärt werden. Diese betreffen die Interaktion zwischen Dienstnutzer und Dienstanbieter. Pull-/Push-Interaktionsmuster Dienstnutzer und Dienstanbieter zeichnen sich durch unterschiedliche Informationsverteilungen aus. Der Dienstnutzer hat Interesse an Informationen des Dienstanbieters. Dazu tauschen Dienstnutzer und Dienstanbieter Nachrichten aus. Nach [Andr 91, Umar 97] wird eine Interaktion zwischen Dienstnutzer (als Client-Komponente) und Dienstanbieter (als Server-Komponente) durch eine vom Client initiierte Anfrage angestoßen. Bei Erhalt der Anfrage führt der Server den von ihm bereitgestellten Dienst aus und sendet daraufhin das Ergebnis des Dienstaufrufs als Antwort an den Client zurück. Diese Antwort kann entweder das Ergebnis des Dienstaufrufs oder eine Fehlermeldung wie Dienst derzeit nicht verfügbar“ ” sein. Meist handelt es sich dabei um eine synchrone Kommunikation, da der Client solange blockiert ist bis eine Antwort auf seine Anfrage eingetroffen ist. Im Normalfall erhält der Client auf seine Anfrage genau eine Antwort. In manchen Fällen ist es auch möglich, keine oder mehrere Antworten auf eine Anfrage zu bekommen. Dies soll hier aber nicht weiter behandelt werden. Dienste, die sich durch eine derartige Interaktion auszeichnen, nennt man Pull-Dienste (vgl. [3gp d, FrZd 96, Pars 04]). Charakteristisch für Pull-Dienste ist, dass eine Dienstausführung und die daraus resultierende Antwort des Anbieters grundsätzlich durch eine Anfrage des Nutzers initiiert werden. Demzufolge bezeichent [Andr 91] den Dienstnutzer als Triggering Process und den Dienstanbieter als Reactive Process, da der Dienstnutzer die Interaktion initiiert und der Dienstanbieter auf diese Initiierung reagiert. Der Nutzer nimmt also eine aktive Position in diesem Szenario ein. Er steuert aktiv die Ausführung des Dienstes an und erhält daraufhin eine entsprechende Antwort. Ein alltägliches Beispiel ist die Nutzung des World Wide Web (WWW) mit Hilfe der GET-Methode des Hyper Text Transfer Protocols (HTTP) [Fiel 99]. HTTP GET basiert auf dem so genannten Request-ResponseProtokoll. Das heißt, es wird eine Anfrage vom Dienstnutzer an den Dienstanbieter und daraufhin genau eine Antwort vom Dienstanbieter an den Dienstnutzer gesendet. In der Antwort ist in der Regel eine Webseite, ein Bild oder Musik enthalten. Für jede Antwort, die genau eine dieser Ressourcen enthält, muss eine explizite HTTP-Anfrage vom Nutzer an den Anbieter gestellt werden. Ein ähnliches Beispiel stellen Directory Services wie Telefonbuch- oder Fahrplan-Dienste dar. Durch eine Anfrage an einen Dienstanbieter, der solche Dienste bereitstellt, erhält man Telefonbucheinträge oder Informationen über Abfahrtszeiten. Integriert man in die Dienstausführung Ortsinformationen, so lassen sich zum Beispiel ortsabhängige Fahrplandienste realisieren, die als Ergebnis die Abfahrtszeiten der naheliegenden öffentlichen Verkehrsmittel liefern. Ergänzend hierzu ergeben sich so genannte Finder-Dienste. Unter Finder-Diensten versteht man Dienste, die die Suche nach bestimmten Örtlichkeiten erleichtern. Als bekanntes Beispiel gilt der Restaurant-Finder, mit dessen Hilfe das nächstgelegene Restaurant ausfindig gemacht werden kann. Eine wesentlich andere Interaktion erfolgt bei den so genannten Push-Diensten [3gp d]. Bei diesen Diensten wird die Ausführung des Dienstes durch ein Ereignis ausgelöst, das nicht einer expliziten Nutzeranfrage entspricht (vgl. [elb , FrZd 96]). Ereignisse in diesem Zusammenhang sind zum Beispiel konkrete Uhrzeiten, zu denen eine Dienstausführung angestoßen wird, oder die automatische Benachrichtigung bei Eintreffen einer Email. Meist werden derartige Dienste durch das Publish-Subscribe-Muster realisiert, d.h. der Nutzer stellt einmal eine Anfrage, registriert sich dadurch beim Dienstanbieter für ein bestimmtes Ereignis und erhält daraufhin bei jedem Eintreten des Ereignisses eine Antwort. Oft handelt es sich bei dieser Art von Diensten um eine asynchrone Kommunikation. Beispiele sind im Bereich der AbonnementServices zu finden. Hier registriert man sich für ein spezielles Thema, z.B. Aktienkurse, Nachrichten oder Wetterberichte, und erhält bei bestimmten Veränderungen des jeweiligen Themas eine Mitteilung auf sein Mobiltelefon. Ein weiteres Beispiel sind Email-Push-Dienste, die durch die Blackberry Push-Architektur [bla ] verwirklicht werden. Die Architektur sorgt dafür, dass bei Eintreffen einer neuen Email automatisch 12 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE eine Kopie dieser Email an das speziell dafür vorgesehene mobile Endgerät gesendet wird. Dadurch erhält der Nutzer stets ohne eigenes Zutun die neuesten Emails, was besonders für geschäftliche Anwendungszwecke vorteilhaft ist. Mit der Integration von Ortsinformationen in die Dienstausführung lassen sich zusätzliche ortsabhängige Themen anbieten. So ist es möglich, dass sich ein Nutzer über Veränderungen der Wetterlage informieren lässt. Interessante Veränderungen sind für ihn allerdings nur Wetterlageänderungen in einer gewissen Nähe zu ihm. Deshalb muss bei der Dienstausführung eine Selektion der Informationen anhand der aktuellen Position durchgeführt werden. Ein weiteres Beispiel stellt ein ortsbasierter Email-Push-Dienst dar. Die Emailzustellung wird hier nicht durch das Eintreffen der Email ausgelöst, sondern zusätzlich durch die örtliche Relevanz der Email. So werden Emails an die Firmenadresse bei örtlicher Nähe zum Büro automatisch zugestellt, Emails an die Privatadresse erhält der Nutzer nur zuhause. Ein anderes Beispiel findet man im Bereich des Mobile-Advertising (m-Advertising) [elb ]. M-Advertising bezeichnet Dienste, die Werbung mittels mobilen Endgeräten an potenzielle Kunden verteilen. Potenzielle Kunden im Bereich des direkten Vertriebs zeichnen sich unter anderem dadurch aus, dass sie sich in der Nähe des Verkaufsstandorts befinden. Bei m-Advertising-Diensten muss demnach eine ortsabhängige Initiierung erfolgen. Ein Beispieldienst könnte folgendermaßen ablaufen: Sobald der Nutzer in die Nähe des Verkaufsstandorts kommt und den m-Advertising-Dienst aktiviert hat, erhält er eine Werbebotschaft auf seinem Mobiltelefon. Zusätzlich ist in der Werbebotschaft ein Gutschein über 10 % Rabatt, um dem Nutzer den Dienst attraktiver zu machen (vgl. [elb ]). Dienstnutzer Dienstnutzer Dienstanbieter Dienstanbieter Pull Push Abbildung 2.1: Pull- und Push-Szenario Der wesentliche Unterschied zwischen Pull- und Push-Diensten besteht demnach darin, dass bei PullDiensten die Dienstausführung durch den Nutzer initiiert wird, wohingegen bei Push-Diensten der Dienstanbieter ohne Einwirkung des Nutzers die Dienstausführung anstößt. Der Nutzer nimmt also bei ersterem eher eine aktive Position ein, wohingegen er bei zweiterem eher als passiv charakterisiert werden kann. Ähnlich hierzu werden Push-Dienste auch oft als proaktiv, Pull-Dienste als reaktiv deklariert, wobei natürlich beide auf bestimmte Ereignisse reagieren. Wie die Beispiele bereits zeigten, kann die Aktion der Initiierung durch verschiedenste Ereignisse ausgelöst und an verschiedenste Bedingungen geknüpft werden. Derartige Konstrukte sind bereits im Datenbankbereich und im Bereich der kontextsensitiven Dienste vorhanden. Bei kontextsensitiven Diensten (vgl. hierzu [StLP 03, AAH+ 97, Stra 03, Schi 95, SAW 94, DeAb 99]) spricht man von Context-Triggered Actions [ChKo 00, SAW 94, Schi 95], d.h. die Aktionen werden aufgrund von Kontextveränderungen ausgelöst. Im Bereich der Location-based Services handelt es sich bei den Kontextveränderungen um Änderungen der Ortsinformationen. Aktionen, die auf derartige Veränderungen reagieren, werden deshalb als LocationTriggered Actions bezeichnet. Push-Dienste, deren Initiierung auf Location-Triggered Actions beruht, zählt man dementsprechend zu den Location-based Push-Services (LBPSs) (vgl. [PSM 01, Fuch 02]). Location-based Pull-Services reagieren im Gegensatz zu den Location-based Push-Services nicht auf Location-Triggered Actions, sondern werden durch den Nutzer initiiert. Die Ortsabhängigkeit fällt bei diesen Diensten in die Dienstausführung. Es gibt also zwei Bereiche, in denen Ortsinformationen Einfluss auf den Dienst haben können. Diese sind die Dienstinitiierung und die Dienstausführung. Während Pull-Services Ortsabhängigkeit nur in der Dienstausführung zulassen, besteht die Möglichkeit bei Push-Diensten Ortsinformationen in die Dienstinitiierung 13 2.2. MOBILE NAVIGATIONSDIENSTE und Dienstausführung einzubringen. Die Beispiele dieses Kapitels sind unter den Gesichtspunkten der Initiierung und Ausführung mit und ohne Ortsabhängigkeit in Abbildung 2.2 nochmals dargestellt. Initiation Execution Pull Conventional Push Location-based Push Conventional Execution Directory Services Abo-Services M-Advertising Restaurant Finder Weather Warning Service Navigation Service Location-based Execution Abbildung 2.2: Beispiele für Push/Pull-Services mit/ohne Ortsabhängigkeit Definition Mit dieser Erkenntnis kann nun in Anlehnung an [gsm 03, 3gp 04, Maea 04, RuKr 03] eine Definition für LBSs gegeben werden, die den hier geforderten Ansprüchen genügt: Ein Location-based Service ist ein Dienst, dessen Initiierung und/oder Ausführung Ortsinformationen relevanter Entitäten nutzt. Eine Entität wird in diesem Zusammenhang als relevant bzgl. einer Aufgabe bezeichnet, wenn ihr örtlicher Zustand den Ablauf der Aufgabe beeinflusst (vgl. [StLP 03]). Der örtliche Zustand einer Entität wird durch Ortsinformationen beschrieben und ist ein wesentlicher Bestandteil der Initiierung und/oder Ausführung des Dienstes. Angelehnt an Deys Definition von Kontext [DeAb 99] sind Ortsinformationen alle Informationen, die dazu genutzt werden können, um die örtliche Situation einer Entität zu beschreiben. Dazu zählen neben den bereits angesprochenen primären Ortsinformationen Position und Ausrichtung, sekundäre oder abgeleitete Ortsinformationen wie Geschwindigkeit und Beschleunigung (vgl. [Klat 04, KLEC 03]). Beispiele für LBSs findet man in der Verkehrstelematik, im Flottenmanagement und in der Logistik, im Bereich mobiler Spiele, im mobilen Marketing (mCommerce und mAdvertising), bei Mautsystemen und in einer Vielzahl weiterer Bereiche. Um einige konkrete Beispiele zu nennen, ist in Deutschland seit 2004 ein ortsbasiertes Mautsystem für Lastwagen in Funktion, das eine Gebührenerhebung abhängig von der tatsächlich erbrachten Fahrleistung ermöglicht (vgl. [tol ]). Ein anderes Beispiel ist der TAXI-Service des Mobilfunkanbieters O2 [o2 ]. Dieser verbindet einen Anruf an eine global gültige Telefonnummer direkt zu einer ortsnahen Taxizentrale. Ein Beispiel für ein mobiles Spiel ist das japanische Community-Spiel MOGI [mog ]. Jeder Spieler von MOGI muss innerhalb eines Stadtgebietes virtuelle Gegenstände finden. Ziel ist es bestimmte Kollektionen der Gegenstände zu sammeln. Auf dem Display des mobilen Endgerätes sehen die Spieler ihre eigene Position, die virtuellen Schätze, sowie die Positionen andere Mitspieler. Die Zahl der real eingesetzten LBSs zeigte in den vergangenen Jahren ein stetiges aber langsames Wachstum. Den Zusatz der Killer Applikation“, wie LBSs in der Literatur desöfteren betitelt werden, haben sie ” noch lange nicht erlangt. 2.2.3 Navigationsdienste Die in Abbildung 2.2 dargestellten Beispiele zeigen LBSs, die sich anhand der Ortsbasiertheit in Initiierung und Ausführung unterscheiden. Ein Beispiel für Dienste, die sich durch ortsbasierte Initiierung sowie ortsbasierte Ausführung auszeichnen können, sind Navigationsdienste. Navigationsdienste sind Dienste, die den Nutzer bei der Planung und Entscheidung für die zielgerichtete 14 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE Fortbewegung vor allem im mittelbaren Umfeld des Dienstnutzers unterstützen. Dazu stellen Navigationsdienste dem Nutzer Informationen bereit, mit deren Hilfe er von seinem Standort über eine bestimmte Route zu einem Zielort gelangt, so genannte Navigationsinformationen. Diese Informationen sollen das Unwissen des Dienstnutzers über seinen aktuellen Aufenthaltsort und den weiteren Routenverlauf kompensieren. Sie können in verschiedensten grafischen, textuellen oder verbalen Darstellungsformen dem Nutzer präsentiert werden. Im weiteren Sinne werden unter Navigationsdiensten auch Dienste verstanden, mit der Aufgabe dem Dienstnutzer Informationen über die verschiedenen Ziele und Routen zu diesen Zielen zur Verfügung zu stellen, sowie weiterführende Dienste, wie die Suche nach Points-Of-Interest (PoI) [PARA 02]. Navigationsdienste im weiteren Sinne beinhalten oft auch Funktionen, die eigentlich Routendiensten zugeschrieben werden. Dazu zählen Aufgaben wie die Betrachtung, die Bearbeitung und die Akquisition von Routen. Eine genauere Analyse von Routendiensten erfolgt später in diesem Kapitel. Aufgabe der Navigationsdienste im engeren Sinne ist es demnach, den Nutzer durch qualitativ hochwertige deklarative Navigationsinformationen bei der Wegfindung zu unterstützen. Ein Aspekt, um Navigationsinformationen als qualitativ hochwertig für das subjektive Empfinden einzustufen, ist die zeitliche Komponente des Auftretens der Navigationsinformationen. Navigationsinformationen sollten immer dann zugestellt werden, wenn der Nutzer den größtmöglichen Nutzen daraus ziehen kann. Dazu darf der Nutzer einerseits keiner ständigen Informationsflut ausgesetzt sein und andererseits nicht bei Bedarf nach Navigationsinformationen im Stich gelassen werden. Entscheidend für den richtigen Zeitpunkt der Zustellung sind die Ortsinformationen des Dienstnutzers. Navigationsinformationen sind dann sinnvoll, wenn sich der Nutzer an einer Position befindet, an der er eine Richtungsänderung durchführen muss, wobei alternative Richtungen möglich wären. In dieser Situation kann der Nutzer selbst die Dienstausführung starten und somit Navigationsinformationen aktiv anfordern. Der Nutzer tritt damit in die Rolle des Dienstinitiierers. Das Interaktionsmuster entspricht den Location-based Pull-Services. Der Nutzer fragt aktiv nach der Unterstützung durch den Navigationsdienst. Er wird den Dienst dann anstoßen, wenn er eine Entscheidung über seine weitere Bewegung treffen muss oder möchte. Innerhalb von Straßennetzen werden diese Zustände an Straßenkreuzungen eintreten. Um keinen Abbiegevorgang zu verpassen, muss er im Grunde genommen an jeder Straßenkreuzung die Dienstausführung anstoßen, obwohl viele dieser Straßenkreuzungen keine Änderung der Bewegungsrichtung nach sich ziehen. Der Dienst wird also weitaus öfter initiiert als dies nötig wäre. Aus der unnötigen Dienstinitiierung folgt die Zustellung von Navigationsinformationen, die keine Richtungsänderung beschreiben. Weitaus komplexer wird die Nutzerinitiierung außerhalb von Straßennetzen. Hier kann der Nutzer nicht mehr an seiner physischen Umgebung erkennen, wann eine Dienstinitiierung auszulösen ist. Vor allem für diese Umgebungen, aber auch für straßengebundene Umgebungen, ist der Einsatz von Dienstinitiierungen auch ohne Einwirkung des Nutzers unumgänglich. Dies führt zu Location-based PushServices. Die Location-Triggered Actions stoßen hierbei bei Eintreten von Zuständen, an denen eine Dienstnutzung als sinnvoll erscheint, die Dienstausführung an. Durch geschickte Wahl der Initiierungsvorschriften werden nur genau dann Navigationsinformationen zugestellt, wenn der Nutzer den größtmöglichen Nutzen daraus zieht. Das bedeutet, dass eine Dienstinitiierung genau dann durchgeführt wird, wenn der Nutzer eine Richtungsänderung einleiten muss, wobei eine alternative Richtung möglich wäre. Die Komplexität der automatischen Dienstinitiierung ergibt sich aus der Spezifikation der Initiierungsvorschrift. Diese kann sich vor allem bei Hinzunahme diverser Einflussgrößen und Verknüpfungen dieser Einflussgrößen stark verkomplizieren. Im Bereich der LBSs handelt es sich bei den maßgeblichen Einflussgrößen um Ortsinformationen. Prinzipiell können aber auch andere Informationen in der Dienstinitiierung beteiligt sein. Solange es jedoch nicht möglich ist, die Gedanken des Nutzers zu lesen, können die Initiierungsvorschriften keine Initiierung anhand der spontanen Bedürfnisse des Nutzers nach Navigationsinformationen durchführen. Deshalb sollte zusätzlich zum Push-Interaktionsmuster auch ein Pull-basierter Ansatz verwirklicht werden. Dadurch kann der Nutzer, wann immer er das Bedürfnis verspürt, Navigationsinformationen anzufordern, aktiv die Dienstinitiierung ansteuern. Desweiteren kann es vorkommen, dass eine automatische Initiierung nicht einsetzbar ist, zum Beispiel wenn keine Ortsinformationen des Nutzers zur Verfügung stehen. In diesem Fall muss es möglich, den Dienst durch den Nutzer zu initiieren. Pull-Interaktionen dieser Art werden derzeit von einigen kommerziellen mobilen Navigationsdiensten eingesetzt (z.B. von [b2m , o2 , jam ]). Diese Arbeit bezieht sich jedoch nur auf Location-based Push-Services. 2.2. MOBILE NAVIGATIONSDIENSTE 15 Ortsinformationen können aber nicht nur für die ortsabhängige Initiierung eingesetzt werden. Ursprünglich sind sie vor allem in der Dienstausführung von Interesse. Dienste wie der Restaurant-Finder, der TAXIService, der ortsbasierte Wetterwarndienst nutzen innerhalb der Dienstausführung, d.h. bei der eigentlichen Mehrwertgenerierung, Ortsinformationen, um den Dienst den örtlichen Nutzerbedürfnissen anzupassen (wie eben genannte Beispiele) oder gar eine ganz neue Art von Diensten anzubieten. Ein Dienst, der ohne Ortsinformationen in der Dienstausführung nicht denkbar ist, ist der Navigationsdienst. Erst durch die Möglichkeit Ortsinformationen innerhalb von Diensten zu nutzen, ergeben sich die Voraussetzungen für Navigationsdienste. Innerhalb der Ausführung von Navigationsdiensten werden Ortsinformationen dazu eingesetzt, die aktuelle Position des Nutzers festzustellen, um ihm anhand der Route Navigationsinformationen für seine zukünftige Bewegungsrichtung zu liefern. Gegebenenfalls können sich diese Ortsinformationen von den Ortsinformationen, die zur Initiierung nötig waren, unterscheiden. In der Navigation ist dies zum Beispiel dadurch gegeben, dass zur Initiierung hauptsächlich Positionsinformationen zum Einsatz kommen, die Ausführung aber zusätzliche Ortsinformationen wie Blickrichtung oder Bewegungsrichtung nutzen kann, um die Navigationsinformation daran anzupassen. Neben der zeitlichen Komponente, die für das subjektive Empfinden der Navigationsinformationen eine Rolle spielt, ist die inhaltliche Komponente der Information der zweite entscheidende Aspekt für qualitativ hochwertige Navigationsinformationen. Dies spiegelt sich in der Zeit der Aufnahme der Informationen und der Verarbeitungszeit wider (vgl. [BKK 01, Kray 03]). Die Aufnahmezeit ist das Zeitintervall, das der Nutzer benötigt, um die dargestellten Informationen zu erkennen und wahrzunehmen, und die Verarbeitungszeit entspricht dem Zeitintervall für das Verstehen der aufgenommen Informationen. Vergleicht man grafische, verbale und textuelle Navigationsinformationen anhand dieser Zeiten, wird folgendes Resultat erzielt. Die Aufnahmezeit für grafische Navigationsinformationen hängt stark vom Detailgrad der Grafik ab. Einfache Pfeildarstellungen, die aus einem einzigen Pfeil bestehen, können sehr schnell aufgenommen werden. Je mehr Informationen zusätzlich in der Grafik enthalten sind (Windrose, Straßennamen, Straßen, Geländeformen, etc), desto länger wird die Aufnahmezeit. Verbale und textuelle Navigationsinformationen haben eine relativ ähnliche Aufnahmezeit, beziehen sich aber auf unterschiedliche Sinne. Für sie gilt ebenfalls, dass die Aufnahmezeit steigt, je mehr Details enthalten sind. Die Verarbeitungszeit grafischer Navigationsinformationen hängt stark von den dargestellten Informationen ab und inwieweit der Nutzer mit der Informationsdarstellung vertraut ist. So kann ein durchschnittlicher Nutzer egozentrische Pfeildarstellungen zur Bewegungsrichtung leicht verarbeiten. In der allozentrischen Perspektive wird bei einem durchschnittlichen Nutzer jedoch weit mehr an Verarbeitungszeit benötigt. Für textuelle und verbale Navigationsinformationen hängt die Verarbeitungszeit ebenso wesentlich von der Perspektive ab. Durch die egozentrische Perspektive referenziert zur Bewegungsrichtung des Nutzers kann die Verarbeitungszeit im Gegensatz zur allozentrischen Perspektive signifikant reduziert werden. Welche der Darstellungsformen die geringsten Aufnahme- und Verarbeitungszeiten aufweist, hängt stark vom Kontext des Einsatzes ab. Vor allem die Art der Fortbewegung, die Fähigkeiten und Einschränkungen des Nutzers und äußere Einflüsse, wie die Sonneneinstrahlung auf das Display oder die Geräuschkulisse spielen eine entscheidende Rolle in der Bewertung. Insgesamt gilt: Je hochwertiger die Navigationsinformationen sind, desto geringer ist die Aufnahmezeit und die Verarbeitungszeit für den Nutzer. Diese Zeiten können natürlich von Nutzer zu Nutzer bzw. von Kontext zu Kontext unterschiedlich ausfallen. Zur Bereitstellung der Navigationsinformationen übernehmen Navigationsdienste die Teilprozesse Ortung, Routenführung und Abbildung der Wegfindung. Teilergebnisse (z.B. Ortsinformationen der Ortung) sind dabei für den Nutzer nicht von Interesse. Ihn interessiert letztendlich nur das Gesamtergebnis aller drei Teilprozesse, die Navigationsinformation. Manche Navigationsdienste lassen einzelne Teilprozesse der Navigation außen vor. Diese müssen dann vom Nutzer übernommen werden. Wird beispielsweise keine Ortung implementiert, muss der Nutzer manuell Ortsinformationen in die Navigation einbringen. Andere Navigationsdienste (besser als Ortungsdienst bezeichnet) liefern nur Ortsinformationen, die der Nutzer dann für die Routenführung und Umsetzung einsetzen kann. Dazu benutzt er zum Beispiel eine physische Karte und bestimmt aus den Ortsinformationen die in Zukunft einzuschlagende Richtung. Auch der letzte Teilprozess der Navigation, die Abbildung der zukünftigen Bewegungsrichtung auf die umgebende Realität, wird von vielen Navigationsdiensten kaum oder gar nicht realisiert. Oft werden dem Nutzer nur abstrakte Routeninformationen präsentiert, deren Abbildung in die Realität von ihm selbst übernommen werden muss. Ein wesentlicher Bestandteil der Wegfindung, der innerhalb aller drei Teilprozesse in verschiedenen For- 16 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE men zum Einsatz kommt, sind Routen. Obwohl der Begriff der Route jedem bekannt sein dürfte, werden darunter oft die unterschiedlichsten Dinge verstanden. Im Folgenden wird deshalb anhand einer abstrakten Routenbeschreibung (angelehnt an [Klip 03]) der Begriff der Route definiert. Routenbeschreibungen Im vorigen Kapitel wurde bereits eine Routenbeschreibung basierend auf einer Landkarte angesprochen. Während diese Darstellung für den Menschen gut verständlich und praktisch einsetzbar ist, können Routendienste und Navigationsdienste mit dieser Darstellung vorerst wenig anfangen. Ist es aber möglich aus dem Kartenmaterial eindeutige Positionsinformationen entnehmen zu können (z.B. durch georeferenziertes Kartenmaterial) sind die Routeninformationen auch für Routen- und Navigationsdienste nutzbar (vgl. Anhang A). Die für die Navigation wesentlichen Inhalte von Karten (als Abbildung der Realität) sind Pfade. Nach [Mont ] sind Pfade lineare, physische Gegebenheiten, die zur Fortbewegung genutzt werden. Dazu zählen Wege, Straßen, Autobahnen, etc. Pfade sind ungebunden und besitzen keinen festen Anfangsbzw. Endpunkt. Demgegenüber definiert [Mont ] Routen als lineare Bewegungsmuster. Diese Bewegungsmuster können mit den Pfaden übereinstimmen, müssen aber nicht. Routen sind gebunden und besitzen einen Anfangs- (Start) und einen Endpunkt (Ziel). Durch Aneinanderreihen von Pfaden erhält man ein Pfadnetzwerk (vgl. [Klip 03]). Alle Punkte dieses Pfadnetzwerkes, an denen sich mindestens drei Pfade berühren, nennt man Kreuzungspunkte. Verläuft eine Route über einen Kreuzungspunkt, so wird dieser Kreuzungspunkt als Entscheidungspunkt (oder Decision Points (DP) [Klip 03] oder Place [WKBH 00]) bezeichnet. Entscheidungspunkte entsprechen also den Punkten der Route, an denen eine Richtungsänderung möglich ist, ohne das Pfadnetzwerk zu verlassen. [Klip 03] unterscheidet desweiteren Entscheidungspunkte daran, ob an ihnen eine Richtungsänderung durchgeführt wird (DP + ) oder nicht (DP − ). DP + -Entscheidungspunkte werden in dieser Arbeit als Aktionspunkte bezeichnet. Die Menge der Aktionspunkte ist eine Teilmenge der Menge der Entscheidungspunkte. Eine Route ergibt sich demnach aus einer geordneten Liste an Entscheidungspunkten DP , wobei jedes Element aus DP = {dp1 , ..., dpn } einen eindeutigen Identifikator und eine Menge an möglichen Richtungen {d1 , ..., dk } mit k > 2 definiert. Für jeden Entscheidungspunkt steht zusätzlich die Richtung do ∈ {f1 , ..., dk }, mit der der Entscheidungspunkt verlassen wird, fest. Die Liste A ⊂ DP der Aktionspunkte erhält man durch Selektion der Liste aller Entscheidungspunkte mit der Selektionsvorschrift di 6= do , wobei di ∈ {d1 , ..., dk } die Richtung spezifiziert, mit der der Entscheidungspunkt betreten wird. Abbildung 2.3 zeigt ein Pfadnetzwerk mit einer darauf definierten Route. P1 stellt den Startpunkt, P11 den Zielpunkt der Route dar. Das Pfadnetzwerk enthält 8 Kreuzungspunkte (P2 , P3 , P4 , P6 , P7 , P8 , P9 und P11 ), wobei von diesen 8 Kreuzungspunkten 4 Entscheidungspunkte (P2 , P3 , P8 und P7 ) sind. Die 4 Entscheidungspunkte beinhalten 3 Aktionspunkte (P2 , P8 und P7 ). Prinzipiell sind nur Aktionspunkte maßgeblich für die Navigation, da diese die relevanten Richtungsänderungen enthalten. Unterstützend können natürlich auch alle Entscheidungspunkte herangezogen werden. Eine ausreichende Routenbeschreibung innerhalb eines Pfadnetzwerkes wird demnach durch eine geordnete Liste von Aktionspunkten erreicht. Für jeden Aktionspunkt muss dabei die Position bekannt sein und ein Hinweis auf die Erreichung des nächsten Aktionspunktes vorliegen. Dieser Hinweis kann verschiedenste Formen annehmen. Eine Möglichkeit ist die Angabe der Richtung do , die die Richtung des Austritts aus dem Aktionspunkt spezifiziert. Die Richtungsangabe gibt dabei nicht zwingend die Richtung des nächsten Aktionspunktes an, sie bestimmt nur die Richtung, die zum nächsten Aktionspunkt führt. Führt die Richtung beispielsweise auf eine gebogene Straße ohne weitere Aktionspunkte, so ist die Richtung des nächsten Aktionspunktes ungleich der Richtungsangabe, die der aktuelle Aktionspunkt liefert (vgl. Aktionspunkt P2 in Abb. 2.3). Die Angabe der Richtung kann sowohl in allozentrischer oder in egozentrischer Perspektive geschehen. Bei Annahme einer genordeten Abbildung 2.3 wäre eine allozentrische Richtungsangabe zum Beispiel die Richtung Norden“. Eine egozentrische Richtungsangabe ” zur Bewegungsrichtung als Referenzrichtung stellt zum Beispiel die Richtung Links“ dar. Möglich wären ” hier natürlich auch Winkelangaben zwischen einer allozentrischen oder egozentrischen Referenzrichtung 17 2.2. MOBILE NAVIGATIONSDIENSTE P0 P1 P2 P5 P6 P7 P10 P11 P3 P4 P8 P9 P12 Abbildung 2.3: Pfadnetzwerk und Route und der Austrittsrichtung (vgl. [RöLa 02]). Anzumerken ist hierzu noch, dass Aktionspunkte nicht zwingend Richtungsangaben als Hinweise liefern müssen. Denkbar ist zum Beispiel auch, jeden Aktionspunkt mit einer bildlichen Darstellung des nächsten Aktionspunktes auszustatten. Dadurch erhält man eine Abfolge von Bildern, die die Route beschreibt. Derartige Beschreibungen findet man beispielsweise in Schatzkarten. Aktionspunkte fallen hier ausschließlich auf Landmarken, wie Berge, Gewässer oder Palmen. Rollen Im Bereich der LBSs und im Speziellen bei Navigationsdiensten als ein Repräsentator für LBSs werden von den beteiligten Parteien verschiedene Rollen angenommen. Rollen beschreiben in diesem Zusammenhang the named specific behavior of an entity participating in a particular context“ [uml 03]. This allows crea” ” ting a special perspective on business process“ [CST 04]. Eine Rolle beschreibt demnach ein bestimmtes Verhalten einer Entität innerhalb eines Geschäftsprozesses. Zwei Rollen traten bereits vermehrt in dieser Arbeit auf. Diese sind der Dienstnutzer und der Dienstanbieter. In deren Umfeld existieren aber noch einige weitere Rollen wie zum Beispiel Inhalteanbieter verschiedenster Inhalte, Location Provider, Zielobjekte oder Netzbetreiber (vgl. [gsm 03]). Abbildung 2.4 zeigt diese Rollen und ihre Verbindung mit dem LBS bzw. Navigationsdienst. Dienstnutzer und Dienstanbieter In jedem Dienstumfeld treten mindestens zwei Rollen hervor. Diese sind der Dienstanbieter (Service Provider), der den LBS bereitstellt und der Dienstnutzer (Requestor), der den angebotenen Dienst nutzt. Dabei herrscht zwischen Dienstnutzer und Dienstanbieter eine unterschiedliche Informationsverteilung in Bezug auf die zu bewältigende Aufgabe. Der Dienstnutzer hat wenig oder kein Wissen über seine aktuelle Position und den Routenverlauf und braucht deshalb Unterstützung durch den Navigationsdienst. Der Dienstanbieter hingegen kann dem Nutzer abhängig von seiner aktuellen Position Navigationsinformationen liefern, die ihm die Wegfindung entlang einer Route erleichtern. 18 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE Requestor Location Technology Provider LBS Map Server Feature Server Target Location Provider Service Provider Route Server Content Provider Abbildung 2.4: Rollen im Bereich der LBSs Inhalteanbieter Um den LBS anbieten zu können, sind oft neben den eigentlichen Ortsinformationen weitere Informationen nötig. Sie werden durch Dienste der so genannten Inhalteanbieter (Content Provider) bereitgestellt. Beispiele für derartige Dienste sind nach [Maea 04] Directory Services (z.B. Point-Of-Interest-Informationen), Location Utility Services (z.B. (Reverse) Geocoding), Route Services (Routenbeschreibungen) und Presentation Services (z.B. Kartenmaterial). Alle diese Beispiele zeichnen sich dadurch aus, dass sie in irgendeiner Art und Weise in Bezug zu Ortsinformationen stehen. Inhalte können aber auch komplett frei von Ortsinformationen sein. So stellen zum Beispiel Aktienkurse, Telefonnmmern oder Produktkataloge ortsunabhängige Inhalte dar. Insgesamt gibt es ein breites Spektrum an Inhalten, die für LBSs von Interesse sind. Inhalteanbieter für Navigationsdienste sind zum Beispiel Wettervorhersagedienste oder Directory Services und der Routendienst mit dem wichtigsten Inhalt, nämlich der Route. Location Provider Die Entität, deren Ortsinformationen für den LBS als relevant gelten, nimmt die Rolle eines Zielobjektes (Target) an. Bezogen auf eine Dienstnutzung kann es ein oder mehrere Zielobjekte geben, je nach Art und Konfiguration des LBS. Im Falle von Navigationsdiensten gibt es nur ein Zielobjekt, welches in der Regel mit der Entität des Dienstnutzers übereinstimmt. Verantwortlich für die Technologie der Ortung ist der so genannte Location Technology Provider. Um die Ortsinformationen eines Zielobjektes zu bestimmen, gibt es verschiedenste Verfahren. Je nach Ortungsverfahren verfügt nach einer erfolgreichen Ortung entweder der Location Technology Provider oder das Zielobjekt über die Ortsinformationen (vgl. dazu netz- und endgerätebasierte Ortungsverfahren). Deshalb werden diese beiden Rollen zusammen durch den Location Provider repräsentiert. Der Location Provider stellt demnach Ortsinformationen in einem bestimmten Koordinatenreferenzsystem mit einer bestimmten Genauigkeit und Präzision und einer bestimmten Verzögerung zur Verfügung. Da in dieser Arbeit nicht auf die spezifischen Eigenheiten der Ortungsverfahren eingegangen wird, stellt der Location Provider die entscheidende Rolle für die Bestimmung der Ortsinformationen dar. Die Zusammensetzung ergibt sich implizit durch das eingesetzte Ortungsverfahren. Für eine genauere Analyse des Ortungsverfahrens müssen die Rollen Location Technology Provider und Target detaillierter untersucht werden, um deren Einfluss auf den Geschäftsprozess der Navigation zu konkretisieren. 2.2. MOBILE NAVIGATIONSDIENSTE 19 Netzbetreiber Die letzte Rolle, aber keinesfalls weniger wichtig, ist der Netzbetreiber (Network Operator). Der Netzbetreiber ist verantwortlich für die Kommunikation zwischen den beteiligten Rollen. Dabei betreibt er drahtlose sowie drahtgebunde Netze, die auf verschiedensten Technologien basieren können. 2.2.4 Routendienste In Verbindung mit Navigationsdiensten ist noch eine weitere Art von Diensten von Interesse. Diese wird oft als Teil des Navigationsdienstes gesehen, soll aber in dieser Arbeit aufgrund der Aufgabendivergenz getrennt betrachtet werden. Dabei handelt es sich um Routendienste, die die zur Navigation nötigen Routen bereitstellen. Navigationsdienste der Wegfindung sind zwingend an Routen gebunden und setzen sie als Basiskonstrukt ein. Jedoch benötigen reine Navigationsdienste keinerlei Funktionalität zur Verwaltung, Bearbeitung und Erstellung von Routen. Diese Aufgabe wird durch Routendienste erfüllt. Um für den Navigationsdienst zugreifbar zu sein, werden Routen vom Routendienst an einer Schnittstelle bereitgestellt. Je nach Anwendungszweck können Routen unterschiedlich beschrieben werden. Beispielsweise können sie, wie bereits dargestellt, aus einer geordneten Liste von Aktionspunkten bestehen. Neben diesem Beispiel gibt es eine Vielzahl weiterer alternativer Beschreibungsformen. Diese Routenbeschreibungen können entweder statisch abgelegt werden, oder sie werden dynamisch bei jeder Abfrage generiert. Während statische Routen einmal definiert werden und dann für längere Zeit im Routendienst verweilen, werden dynamische Routen bei jeder Anfrage neu erstellt. Sollen dynamische Routen vom Routendienst angefordert werden, muss die Anfrage Informationen über den Verlauf der Route enthalten. Zumindest müssen Start- und Zielpunkt festgelegt werden. Im Normalfall gibt es eine Vielzahl an Routen, die zwischen Start- und Zielpunkt liegen. Deshalb müssen zusätzlich zur Angabe von Start- und Zielpunkt noch weitere Einschränkungen getroffen werden, um eine eindeutige Route liefern zu können. Diese Einschränkungen können zum Beispiel Wegpunkte darstellen. Wegpunkte definieren Punkte, die auf der Route zwischen Start- und Zielpunkt liegen müssen. Zur dynamischen Generierung der Route muss der Routendienst diese Wegpunkte in die Routenbestimmung mit einbeziehen. Oft liefert die Angabe von Wegpunkten aber immer noch keine eindeutige Route. Andere oder zusätzliche Einschränkungen sind Angaben zur Länge der Route. Dadurch kann zum Beispiel spezifiziert werden, dass die Route zwischen 20 und 30 Kilometer lang sein soll, oder dass aus der Menge aller Routen, die den Startmit dem Zielpunkt verbinden (und ggf. Wegpunkte), die Route ausgewählt werden soll, die die kürzeste Länge besitzt. Für die direkte Bestimmung von Routen mit der kürzesten Länge werden in Pfadnetzwerken oft Algorithmen zum Beispiel von Dijkstra oder Bellmann-Ford eingesetzt (vgl. [Maea 04]). Neben den Einschränkungen der Länge der Route, existieren noch einige weitere Parameter, die zur Auswahl eingesetzt werden können. Diese sind beispielsweise die Fahrzeit (z.B. schnellste Route), die Pfadcharakteristika (z.B. Feldwege, Radwege), die Routenumgebung (z.B. im Wald, schöne Aussicht), Eingrenzung von Regionen (z.B. nur in Bayern), etc. Eine letztendliche Auswahl kann auch durch den Dienstnutzer selbst erfolgen, der sich durch die gezielte Wahl einer Route aus der Menge aller möglichen Routen die favorisierte Route aussucht. Für die dynamische Generierung von Routen innerhalb eines Pfadnetzwerkes werden hohe Anforderungen an die zugrunde liegenden Daten über das Pfadnetzwerk gestellt. Die Informationen zu allen möglichen Pfaden mit deren genauer Position und Eigenschaften wie Einbahnstraße, Autobahn, etc. müssen stets korrekt und aktuell sein. Derartige Daten werden zum Beispiel von der Firma NAVTEQ [nav ] vertrieben und in vielen derzeitigen Navigationsdiensten eingesetzt. Statische Routen werden einmal generiert und werden dann vom Routendienst über längere Zeit zur Verfügung gestellt. Ihre Start- und Zielpunkte, Wegpunkte, Länge, Pfadcharakteristika, etc. sind während ihrer ganzen Lebenszeit fest und können nicht verändert werden. Meist entspricht eine statische Route den Anforderungen einer Vielzahl an Nutzern. Beispiele sind Stadtbesichtigungsrouten oder Radtouren. Routendienste für statische Routen brauchen neben der Funktion Routen zu verwalten, auch die Möglichkeit Routen zu erstellen. Dies kann auf verschiedenste Arten geschehen. Bietet der Routendienst auch die Funktion der dynamischen Routengenerierung an, können dynamisch generierte Routen beispielsweise in statische Routen umgewandelt werden, um langfristig zur Verfügung zu stehen. Eine andere Möglichkeit 20 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE ist, eine grafische Routenerstellung zu ermöglichen. Durch die sequentielle Wahl von Aktionspunkten innerhalb eines Kartenausschnitts, kann so eine Route generiert werden. Eine weitere Möglichkeit stellt die automatische Erzeugung durch Befahren der Route dar. Hierbei wird die Route durch eine stetige Ortung bei der Bewegung erzeugt. Wie bereits beschrieben werden Routendienste oft in Navigationsdienste integriert. Prinzipiell sind Routendienst und Navigationsdienst aber nicht fest miteinander gekoppelt. Das heißt einerseits, dass es Routendienste ohne Navigationsdienste geben kann und andererseits Navigationsdienste ohne Routendienste. So kommen zum Beispiel Navigationsdienste, die nicht auf die Wegfindung, sondern auf die Lokomotion ausgerichtet sind, ohne Routendienste aus. Demgegenüber kann ein Routendienst allein zur Speicherung und Verwaltung von Routen genutzt werden und dadurch keine Inhalte für Navigationsdienste liefern. Navigationsdienst und Routendienst stellen demnach zwei vollkommen unterschiedliche Diensttypen dar. Während der Navigationsdienst den Nutzer bei der Wegfindung unterstützt, ist die Funktion des Routendienstes, die Verwaltung, Bearbeitung und Erstellung von Routen. Dementsprechend können Navigations- und Routendienste auf dem selben Gerät oder aber auch auf unterschiedlichen Geräten angesiedelt werden. Läuft der Routendienst auf dem selben Gerät wie der Navigationsdienst, so spricht man von Onboard-Lösungen (vgl. [Nieb 04, Zieg 04, Hell 04, act ]). Läuft der Routendienst andererseits auf einem anderen Gerät spricht man von einer so genannten Offboard-Lösung. Diese Begriffe werden in der Literatur aber auch in anderen Zusammenhängen genutzt. Der Begriff On/Offboard wird zum Beispiel in [PARA 02] verwendet, um die Verteiltheit von einzelnen Komponenten des Navigationsdienstes auf Geräte auszudrücken. In dieser Arbeit werden die Begriffe Onboard/Offboard im Zusammenhang mit der Verteiltheit von Navigationsdienst und Routendienst verwendet. 2.3 Demonstrator: MoBiLe Im Rahmen dieser Arbeit soll ein Prototyp eines mobilen Navigationsdienstes angefertigt werden. Als Anwendungsgebiet soll das Mountain-Biken dienen. Der Prototyp des Mountain Bike Leaders (MoBiLe) muss deshalb die Besonderheiten des Mountain-Bike-Sports speziell in Betracht ziehen. Dazu gehört vor allem der Betrieb auf kleinen Straßen, Feldwegen und Trampelpfaden“ innerhalb bergiger Regionen und ” große Schwankungen in der Fortbewegungsgeschwindigkeit. Diese Punkte unterscheideen den MoBiLe wesentlich von der Fußgängernavigation oder der Fahrzeugnavigation. Dieses Kapitel geht zu allererst auf einige Use-Cases ein, die Anwendungsfälle des Systems demonstrieren sollen und Einfluss auf die folgenden Kapitel haben. Danach werden aus diesen Use-Cases funktionale sowie nicht-funktionale Anforderungen an das System abgeleitet. 2.3.1 Anwendungsfälle Use Case 1: Routenerstellung Routen, die beim Mountain-Biken Anwendung finden, sind in der Regel statisch. Zur Erstellung dieser Routen soll es möglich sein, zuhause auf einem stationären Gerät mit großem Display und guten Eingabemöglichkeiten Routen grafisch zu generieren. Dazu präsentiert der Routendienst dem Nutzer einen Kartenausschnitt, dessen Darstellungsbereich, Größe und Vergrößerungsfaktor frei gewählt werden können. Zusätzlich bietet ihm der Routendienst die Möglichkeit, Aktionspunkte durch Mausklicks zu setzen und die dort durchzuführenden Richtungsänderungen zu adjustieren. Ein zweites Fenster zeigt ihm die Aktionspunkte und die Richtungsänderungen in der Reihenfolge der Generierung. Innerhalb dieses Fensters ist es möglich, einzelne Aktionspunkte wieder zu löschen oder deren Richtungsänderung zu verändern. Wurden alle Aktionspunkte erfolgreich gesetzt, kann die Route im System abgelegt werden. Innerhalb dieses Vorgangs kann der Nutzer zusätzliche Annotationen wie Name oder Schwierigkeitsgrad an die Route anhängen. Durch das Speichern der Route, kann diese später wieder geladen und weiter bearbeitet werden. Schließlich ist die Route durch die Veröffentlichung für den Navigationsdienst abrufbar. 2.3. DEMONSTRATOR: MOBILE 21 Use Case 2: Routenauswahl Durch Starten des Navigationsdienstes auf dem mobilen Endgerät, wird dem Nutzer eine grafische Oberfläche angezeigt, in der er die wesentlichen Einstellungen vornehmen und die Navigation starten kann. Ein Konfigurationspunkt ist die Auswahl der Route. Zur Routensuche kann der Nutzer die Charakteristika für die gewünschte Route spezifizieren. Diese sind mindestens der Name der Route, die Region, der Schwierigkeitsgrad und die Länge (absolut oder Intervallangabe). Weitere Charakteristika können Erstellungsdatum der Routen, Aktualität der Routen (z.B. die innerhalb eines bestimmten Zeitraumes bereits genutzt wurden), oder Nähe zum Aufenthaltsort sein. Wird ein Charakteristikum nicht belegt, so wird dieses nicht zur Auswahl herangezogen. Das bedeutet, falls keine Einschränkungen zur Route gemacht wurden, werden alle verfügbaren Routen angezeigt. Zu jeder Route können weitere Informationen eingeblendet werden. Diese Informationen beinhalten mindestens die Gesamtlänge der Route, den Abfahrtsort, den Schwierigkeitsgrad und die zu bewältigenden Höhenmeter. Nach der Routenauswahl kann die Navigation direkt gestartet werden. Zuvor kann der Nutzer aber noch in den Einstellungen die favorisierte Darstellungsform wählen und andere Konfigurationen des MoBiLe durchführen. Use Case 3: Navigation Durch Starten der Navigation wird der Nutzer zur Bestätigung der Route und der damit verbundenen Ortung aufgefordert. Erklärt er sich damit einverstanden, wird die Ortung aktiviert und bei Erreichen des Abfahrtsortes eine erste Navigationsinformation präsentiert. Diese kann aufgrund verschiedener Einflussfaktoren (Verfügbarkeit von Ortsinformationen, Verbindungsgeschwindigkeit, Nutzerpräferenzen, etc.) unterschiedlich ausfallen. Mögliche Darstellungsformen sind verbale, textuelle oder grafische Präsentationen. Folgt der Nutzer dieser Navigationsinformation, wird er bei Erreichen des nächsten Aktionspunktes automatisch über die Richtungsänderung informiert. Diese Navigationsinformation muss zum richtigen Zeitpunkt dem Nutzer zugestellt werden und soll sich durch geringe Aufnahme- und Verarbeitungszeit auszeichnen. Das Erreichen des Ziels wird durch eine letzte Meldung bekannt gegeben, bevor sich die Navigation beendet. 2.3.2 Anforderungen Funktionale Anforderungen Funktionale Anforderungen ergeben sich aus den oben genannten Anwendungsfällen. Im Wesentlichen sind diese die Routenerstellung, die Routenauswahl und die Navigation. Während die Routenerstellung vom Routendienst bereitgestellt wird, werden Routenauswahl und Navigation vom Navigationsdienst dem Nutzer zur Verfügung gestellt. Obwohl die Routenauswahl im Grunde genommen alleine vom Routendienst abhängt, soll diese vom Navigationsdienst angeboten werden, der die Routen dann vom Routendienst bezieht. Dies hat folgende Gründe. Der Navigationsdienst verfügt im Gegensatz zum Routendienst über nutzerspezifische Daten für die Routenauswahl, die nicht direkt an den Routendienst weitergeleitet werden sollten. Dabei handelt es sich zum Beispiel um die Position des Nutzers, die zur Auswahl herangezogen werden kann. Außerdem kann der Navigationsdienst in Verbindung zu mehreren Routendiensten stehen, um sein Angebot zu erweitern. Für den Nutzer bleiben so die Anzahl und Funktionalitätsunterschiede der Routendienste verschattet. Die funktionalen Anforderungen der drei Anwendungsfälle Routenerstellung, Routenauswahl sowie der Navigation sind im Folgenden stichpunktartig zusammengefasst. Sie definieren die Funktionalität, die durch das System bereitgestellt werden soll. Use Case 1: Routenerstellung • Grafische Präsentation von Kartenmaterial in verschiedenen Vergrößerungen • Definition von Aktionspunkten (Position und Richtungsänderung) auf Kartenhintergrund 22 KAPITEL 2. MOBILE NAVIGATIONSDIENSTE • Löschen von Aktionspunkten • Ändern von Aktionspunkten (Richtungsänderung) • Annotation von Informationen wie Name, Schwierigkeitsgrad, Gesamtlänge oder Höhenmeter • Persistentes Ablegen von Routen • Laden bestehender Routen und Anzeige vor Kartenhintergrund • Bereitstellen der Routen für Navigation Use Case 2: Routenauswahl • Selektion der Routen anhand vordefinierter Charakteristika • Detaillierte Anzeige von Routenannotationen • Auswahl einer Route Use Case 3: Navigation • Start- und Unterbrechungsmöglichkeit der Navigation • Einstellung von favorisierten Darstellungsformen • Frühzeitige automatische Benachrichtigung über bevorstehende Richtungsänderung an Aktionspunkten • Geringe Aufnahme- und Verarbeitungszeiten der Navigationsinformationen • Wiederholung von verpassten Navigationsinformationen • Benachrichtigung bei Erreichen des Ziels Nicht-funktionale Anforderungen Nicht-funktionale Anforderungen geben Eigenschaften und Einschränkungen bezüglich der Leistung, Qualität oder Einflussfaktoren technischer, normativer oder kultureller Art. Dabei beziehen sie sich nicht auf einzelne Funktionen, sondern auf die Funktionalität des kompletten Systems. Im Folgenden werden einige nicht-funktionale Anforderungen an den MoBiLe-Service aufgezählt und kurz beschrieben: Nutzbarkeit (Usability) • Die Bedienung der grafischen Oberfläche soll einfach und klar verständlich sein. Dies gilt sowohl auf dem stationären wie auf dem mobilen Gerät. Vor allem auf dem mobilen Endgerät muss auf die Einschränkungen wie dem kleinen Display und den beschränkten Eingabemöglichkeiten geachtet werden. Dazu muss eine intuitive Menüführung existieren, die die Navigation durch die Menüs anhand weniger Tastendrücke erlaubt. • Einstellungen, die über längere Zeit konstant bleiben, sollen persistent gespeichert werden, um nicht jedes mal erneut eingegeben werden zu müssen. • Darstellungen auf dem mobilen Endgerät, wie zum Beispiel Navigationsinformationen, sollen ohne Scrollen erkennbar sein. Außerdem sollen sie klar und intuitiv verständlich sein. 2.3. DEMONSTRATOR: MOBILE 23 Reaktionszeit • Das gesamte System soll geringen Reaktionszeiten unterliegen. Dies betrifft die Subsysteme, sowie die Kommunikationsstruktur zum Datenaustausch zwischen den Subsystemen. Vor allem in der Navigation führen lange Reaktionszeiten zu einer Verfälschung des Ergebnisses. Ressourcenverbrauch • Das mobile Endgerät unterliegt beschränkten Ressourcen bezüglich des Speicherplatzes und der Rechenleistung. Auf dem Endgerät muss deshalb sparsam mit diesen Ressourcen umgegangen werden und wenn möglich eine Auslagerung der Daten, bzw. Berechnungen, erfolgen. • Die WAN-Verbindungen zwischen mobilem Endgerät und Infrastruktur sind meist teuer in der Nutzung. Deshalb soll das System sparsam im Einsatz dieser Verbindungen umgehen. • Der Nutzer besitzt ebenfalls nur eine beschränkte Ressourcenkapazität für die Aufnahme und Verarbeitung von Informationen (kognitive Ressourcen) [BKK 01]. Alle dem Nutzer präsentierten Informationen sollen deshalb so wenig kognitive Ressourcen verbrauchen wie möglich. Erweiterbarkeit/Substituierbarkeit • Einzelne Teile des Gesamtsystems sollen leicht ersetzbar sein. So soll zum Beispiel leicht ein anderes Ortungsverfahren verwendet oder sogar eine andere Applikation innerhalb des LBPSs verwirklicht werden können. Selbiges gilt für neue Darstellungsformen. Um Abhängigkeiten zu vermeiden, ist eine geringe Kopplung zwischen Subsystemen nötig. • Außerdem müssen feste Schnittstellen zwischen Subsystemen bestehen, um diese einfach ersetzen bzw. erweitern zu können. Praktikabilität • Um MoBiLe real einsetzen zu können, dürfen nur existierende Technologien eingesetzt werden. Dies gilt vor allem für Ortungsverfahren und Kommunikationsverbindungen. Kapitel 3 Stand der Technik mobiler Navigationsdienste Dieses Kapitel ist dem Stand der Technik und Forschung im Bereich der mobilen Navigationsdienste gewidmet. Um einen Überblick über die bestehenden Technologien, sowie bereits existierende Systeme und Konzepte zu geben, wurden einige Beispiele ausgewählt, an denen Funktionsweisen, Unterschiede, Vorund Nachteile sowie Praktikabilität diskutiert werden. Natürlich ist dies keine vollständige Liste, sondern beschränkt sich auf die Beispiele, die sich als sehr repräsentativ herausgestellt haben oder sich durch hohe Relevanz für diese Arbeit auszeichnen. Das Kapitel beginnt mit verschiedenen Techniken der Ortung und deren Umsetzung in bestehenden Ortungssystemen. Anschließend folgt eine Einführung und Gegenüberstellung offener mobiler Plattformen und deren Unterstützung für Anforderungen des MoBiLe-Service. Bevor das Kapitel mit einer Beschreibung existierender kommerzieller Navigationssysteme endet, werden einige Forschungsprojekte vorgestellt, die sich mit Themen im Bereich der Navigationsdienste auseinandersetzen. 3.1 Ortungssysteme Dieses Kapitel gibt einen Einblick in bestehende Ortungssysteme, die zum Zeitpunkt dieser Arbeit mögliche Lösungen für die Bestimmung von Ortsinformationen darstellen. Dazu wird das Kapitel nur kurz auf den Aufbau, die Funktionsweise und Zweckmäßigkeit dieser Systeme im Bereich der mobilen Navigation eingehen. Für eine genauere Betrachtung wird auf [gsm 03, DFGS 05, Küpp 05, LPKü 04] verwiesen. 3.1.1 Cell Of Origin Durch den Aufbau des GSM-Netzes seit Anfang der 90er Jahre besitzt die Bundesrepublik Deutschland heute eine fast flächendeckende Infrastruktur an Basisstationen (vgl. [gsm ]), die es an beinahe jedem Ort ermöglicht, Telefonate zu führen oder Daten auszutauschen. Dazu muss sich der Nutzer in unmittelbarer Nähe zu einer dieser Basisstationen befinden. Jeder Basisstation kann durch ihren Betreiber eine eindeutige Position zugeordnet werden. Ist der Nutzer an dieser Basisstation eingebucht“, so kann seine Position mit ” einer Genauigkeit von der maximalen Reichweite der Basisstation, d.h. dem Radius der Zelle, berechnet werden. Dieses Verfahren, in dem die Position des Nutzers mit der Position der eingebuchten Zelle gleichgesetzt wird, nennt man Cell of Origin oder Cell Identity (vgl. Abb. 3.1 a). Die Genauigkeit der Positionsbestimmung hängt damit von der Größe der Zelle ab. Eine Zelle des GSMNetzes hat einen maximalen Radius von 35 Kilometern. Damit kann eine Genauigkeit von schlechtestenfalls 35 Kilometern erlangt werden. Wenn überhaupt, sind derart große Zellen nur in sehr ländlichen Regio24 25 3.1. ORTUNGSSYSTEME a) b) c) d) Abbildung 3.1: Ortung mittels Cell Identity (a) mit Laufzeitmessung (b) mit AoA (c) mit Laufzeitmessung und AoA (d) nen zu finden. Innerhalb von Städten kann in der Regel eine Genauigkeit bis zu 250 Meter erzielt werden. Dadurch ist in städtischen Gebieten bereits durch dieses einfache Verfahren eine relativ exakte Ortung möglich. Der Einsatzort des MoBiLe ist aber eher in ländlichen Regionen mit wenig Basisstationen zu sehen. Dadurch können in der Regel nur noch Genauigkeiten im Kilometerbereich erzielt werden. Dies reicht keinesfalls für die hier angestrebte Navigation aus. Eine Möglichkeit um die Genauigkeit des CoO-Verfahrens zu verbessern, ist die Betrachtung des Winkels zwischen Nutzer und Basisstation. Derartige Verfahren sind auch unter dem Namen Angle of Arrival (AoA) bekannt. In Verbindung mit dem CoO-Verfahren, kann dadurch der Aufenthaltsort des Nutzers weiter eingeschränkt werden. Das AoA-Verfahren kann auch in GSM-Netzen eingesetzt werden, da hier meist statt omnidirektionalen Antennen sektorisierte Antennen verwendet werden. Diese strahlen nur einen bestimmten Sektor aus und sind deshalb nur innerhalb dieses Sektors empfangbar. Kommen sektorisierte Antennen bei der Positionsbestimmung zum Einsatz, so kann die Position des Nutzers auf diesen Sektor eingeschränkt werden (vgl. Abb. 3.1 c). Im GSM-Netz kann bei der Positionsbestimmung mittels Cell Identity und sektorisierten Antennen eine Genauigkeitssteigerung erzielt werden. Für den Einsatz in Navigationsdiensten ist aber auch diese Genauigkeit noch nicht akzeptabel. Ein anderes Vorgehen, um den Aufenthaltsort des Nutzers innerhalb einer Zelle einzugrenzen, ist der Einsatz von Laufzeitmessungen. Hier wird durch Messung der Signallaufzeit zwischen Sender und Empfänger versucht, Rückschlüsse auf dessen Position ziehen zu können. In Verbindung mit CoO-Verfahren erhält man somit einen Ring um die Basisstation, in dem sich der Nutzer aufhält (vgl. Abb. 3.1 b). Im GSM-Netz ist eine ungefähre Signallaufzeit durch den Timing Advance (TA) bestimmbar. Der TA wurde eingeführt, um die Signalverzögerung bei der Datenübertragung zu kompensieren, kann bei der Positionsbestimmung mit dem CoO-Verfahren aber genutzt werden, um den Aufenthaltsort des Nutzers weiter einzuschränken. Der TA ist in 63 diskrete Werte quantisiert, die bei einer maximalen Zellgröße von 35 km eine Breite von ca. 500 Metern aufweisen. Dadurch kann die Position des Nutzers auf einem Ring um die Basisstation mit einer Breite von ca. 500 Metern bestimmt werden. Je weiter sich der Nutzer von der Basisstation wegbewegt, desto ungenauer wird die Positionsbestimmung, da sich die Aufenthaltsfläche des Nutzers vergrößert. Für die Anwendung in Navigationsdiensten für ländliche Regionen stellt dieses Verfahren deshalb keine akzeptable Lösung dar. Der Problematik der Laufzeitmessung, kann durch den Einsatz des AoA-Verfahrens entgegengewirkt werden. Durch Abstands- und Winkelmessung zugleich wird der Aufenthaltsort des Nutzers auf ein Ringsegment reduziert (vgl. Abb. 3.1 d). Dadurch kann bei der Anwendung im GSM-Netz je nach Grad der Antennensektorisierung die Genauigkeit weiter gesteigert werden. Obwohl diese beiden Erweiterungen des 26 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE CoO-Verfahrens die Genauigkeit der Positionsbestimmung stark verbessern, reicht dies für den MoBiLeService nicht aus. Vor allem ist es nicht möglich, eine konstante Genauigkeit anzugeben, da die Genauigkeit des Verfahrens mit höherer Entfernung zur Basisstation zunimmt. 3.1.2 Enhanced Observed Time Difference Ein Verfahren, das dieser Problematik weniger stark ausgesetzt ist, ist das Enhanced Observed Time Difference (E-OTD) Verfahren. Es ermittelt die Position anhand der hyperbolischen Trilateration. Ähnlich wie bereits beschrieben basiert E-OTD auf der Messung von Signallaufzeiten. Jedoch steht hier nicht die Signalverzögerung zwischen Senden und Empfangen im Vordergrund, sondern die Differenz zwischen dem Empfangen von zwei Signalen, die von unterschiedlichen Basisstationen gleichzeitig ausgesandt werden. Vorteilhaft ist an dieser Strategie, dass die Basisstationen und das zu positionierende Endgerät nicht zeitlich synchronisiert sein müssen. Es reicht aus, wenn die Basisstationen untereinander synchronisiert sind bzw. die Asynchronität ermittelbar ist. Abbildung 3.2: Enhanced Observed Time Difference (E-OTD) Im praktischen Einsatz funktioniert das E-OTD-Verfahren folgendermaßen. Das Endgerät misst die Zeitdifferenz zwischen dem Eintreffen der Signale zweier Basisstationen. Durch Hinzunahme des Gangunterschieds der Uhren der beiden Basisstationen, der von der Location Measurement Unit (LMU) geliefert wird, kann nun die Position auf einer Hyperbel, die zwischen den beiden Basisstationen verläuft, berechnet werden (vgl. Abb. 3.2). Wird dieser Vorgang zu einer dritten Basisstation wiederholt, schneiden sich die Hyperbeln in einem Punkt, welcher der Position des Endgerätes entspricht. Mittels des E-OTD-Verfahrens können Genauigkeiten unter 100 Metern erzielt werden. Leider setzt das Verfahren einerseits eine Erweiterung des Endgerätes und andererseits der bestehenden Infrastruktur (Integration von LMUs) voraus, was hierzulande noch nicht geschehen ist. Außerdem sind zur Positionsbestimmung mindestens drei Basisstationen notwendig, in deren Empfangsbereich sich das Endgerät während der Positionsbestimmung befindet. In städtischen Regionen stellt dies kein ernsthaftes Problem dar. In ländlichen Regionen ist eine derartige Konstellation jedoch oft rar. Aus diesen Gründen ist die Positionsbestimmung mittels E-OTD leider nicht wie gewünscht einsatzfähig und kommt deshalb für Navigationsdienste nicht in Frage. 3.1. ORTUNGSSYSTEME 3.1.3 27 Global Positioning System Das Global Positioning System (GPS) [off b, hof 93, Logs 92, kow , Zogg 02], das auch als NAVigation System with Time And Ranging (NAVSTAR) bekannt ist, ist ein satellitengestütztes Ortungssystem des Departments of Defense (DoD) der USA. Es wurde ab den 70er Jahren für den militärischen Gebrauch entwickelt, ist aber seit den 80er Jahren auch für den zivilen Gebrauch, jedoch nur unter Einschränkungen, zugelassen. Die zivile Nutzung beschränkt sich auf den so genannten Standard Positioning Service (SPS). Für die militärische Nutzung existiert zusätzlich der Precise Positioning Service (PPS), der eine wesentlich höhere Genauigkeit als der SPS aufweist, aber nur durch militärische Empfangsgeräte wahrgenommen wird. Die Positionsbestimmung bei GPS basiert auf der satellitenbasierten Trilateration, also der Abstandsmessung zu mindestens drei Satelliten, deren Position im Raum eindeutig bestimmbar ist. Zur letztendlichen Positionsbestimmung ist ein vierter Satellit notwendig, um den Gangunterschied zwischen den Uhren der Satelliten und des Empfängers auszugleichen. GPS setzt sich aus drei Segmenten zusammen: dem Nutzersegment (User Segment), dem Raumsegment (Space Segment) und dem Kontroll- und Steuerungssegment (Control Segment). Das Raumsegment besteht zum Zeitpunkt dieser Arbeit aus 29 Satelliten (vgl. [off b]). Prinzipiell reichen aber schon 24 Satelliten aus, um das System ordnungsgemäß zu betreiben. Jeweils vier Satelliten befinden sich auf einem der sechs kreisförmigen Medium Earth Orbits (MEO). Jeder dieser Orbits hat einen Inklinationswinkel von 55 ◦ und ist um 60 ◦ zu seinen Nachbarorbits versetzt. Der Radius des Orbits beträgt 26.560 km. Folglich beträgt der Abstand eines Satelliten zur Erdoberfläche 20.200 km und jeder Satellit braucht dadurch knapp 12 Stunden, um die Erde zu umrunden. Jeder der derzeit 17 Typ-II- und Typ-IIA-Satelliten ist mit zwei Cäsium- und zwei Rubidium-Atomuhren ausgestattet. Die neueren Satelliten des Typs-IIR (derzeit 12) haben drei Rubidium-Atomuhren. Durch die äußerst exakten Uhren kann die Laufzeit eines elektromagnetischen Signals, welches von den Satelliten ausgestrahlt und vom GPS-Empfänger wahrgenommen wird, gemessen werden. Da die Geschwindigkeit des Signals relativ genau bestimmbar ist (annähernd Lichtgeschwindigkeit), wird eine Berechnung des Abstandes zwischen Satellit und Empfänger möglich. Dazu sendet jeder Satellit auf der L1- (1575,42 MHz) und der L2-Frequenz (1227,60 MHz) ein elektromagnetisches Signal aus. Die L2-Frequenz wird ausschließlich für PPS genutzt. Die L1-Frequenz wird sowohl für PPS als auch für SPS eingesetzt. Der Mehrfachzugriff der 29 Satelliten auf die L1- bzw. L2-Trägerfrequenz erfolgt mittels Code Division Multiple Access (CDMA). Um einerseits die Signale unterschiedlicher Satelliten und andererseits überlagerte Signale, die durch die Mehrwegeausbreitung entstanden sind, exakt trennen zu können, werden als Pseudo-Random-Noise-Codes (PRN-Codes) Gold-Codes eingesetzt, da diese sowohl eine gute Kreuzkorrelation als auch eine gute Autokorrelation aufweisen. Die PRN-Codes für SPS sind auch unter dem Namen Coarse Acquisition Code (C/A-Code) bekannt und haben je eine Länge von 1023 Chips. Der C/A-Code wird mit einer Datenrate von 1,023 MBit/s übertragen und wiederholt sich so jede Millisekunde. Der P-Code (Code des PPS) hat eine Länge von über 2 · 1014 Chips und wird mit einer Datenrate von 10,23 MBit/s übertragen. Folglich liegt die Wiederholungsrate des P-Codes bei ca. 266 Tagen. Die Daten, die mittels dieser Codes gespreizt werden, sind unter anderem Uhrenkorrekturwerte, genauere Informationen zu den Bahndaten des sendenden Satelliten (Ephemeriden) und grobe Informationen zu den Bahndaten aller Satelliten (Almanach). Diese Nutzdaten werden mit einer Datenrate von 50 Bit/s gesendet. Insgesamt werden also die Nutzdaten eines Satelliten mit dem PRN-Code gespreizt und dann auf die L1Trägerwelle mittels Quadrature Phase Shift Keying (QPSK) aufmoduliert. Das übertragende Signal enthält damit die in Abbildung 3.3 dargestellten Informationen. Das Nutzersegment beinhaltet alle Empfangsgeräte sowohl für SPS als auch für PPS. Empfangsgeräte unterscheiden sich einerseits durch ihre Ausmaße, Funktionalität, Ausstattung, Leistungsaufnahme, etc., andererseits haben verschiedene Geräte auch meist Unterschiede in der Genauigkeit und der Präzision der Positionsbestimmung, der Verzögerung für die erste Positionsbestimmung (Time-To-First-Fix (TTFF)), der minimalen Empfangsstärke, der Anzahl der parallel empfangbaren Satelliten, etc. Um nun die Entfernung zwischen Satellit und Empfänger im SPS zu bestimmen, muss die Zeitdifferenz zwischen Senden und Empfangen des Signals berechnet werden, um daraus Rückschlüsse auf den Abstand führen zu können. Das Signal trifft aufgrund der endlichen Signalausbreitungsgeschwindigkeit mit einer 28 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE Nutzdaten x dBm Gespreiztes Signal y dBm Moduliertes Signal z dBm Abbildung 3.3: Aufbau des GPS-Signals bestimmten Verzögerung beim Empfänger ein. Durch die gute Kreuzkorrelation der PRN-Codes kann aus dem Signal eindeutig das spezielle Signal des sendenden Satelliten herausgefiltert werden. Durch die gute Autokorrelation der PRN-Codes kann die Verzögerung des Signaleintreffens bestimmt werden. Je nachdem, wie genau der Prozess der Autokorrelation durchgeführt werden kann, variiert die Genauigkeit der Positionsbestimmung. Arbeitet der Prozess beispielsweise nur auf ganze Chiplängen, kann eine maximale Genauigkeit von ca. 300 Metern (∼ = Lichtgeschwindigkeit (≈ 3 · 105 m/ms) · Zeitdauer eines Chips 1 ( 1023 ms)) erreicht werden. Dies entspricht der Länge eines einzelnen Chips. Gängige GPS-Empfänger führen den Autokorrelationsprozess auf Bruchteile von Chips aus und können so wesentlich höhere Genauigkeiten erreichen. Zusätzlich kann zur Positionsbestimmung die Phasenverschiebung des modulierten Signals herangezogen werden, um die Genauigkeit weiter zu steigern. Aus dem Resultat dieses Prozesses, den so genannten Pseudo Ranges zu mindestens drei Satelliten, muss nun die Position des Empfängers bestimmt werden. Dazu sind weitere Informationen nötig, die in den Nutzdaten enthalten sind. Diese sind die Uhrenkorrekturwerte, die Ephemeriden und der Almanach. Unter Berücksichtigung dieser Nutzdaten kann aus den Pseudo Ranges die reale Position des Nutzers bestimmt werden. Das Kontroll- und Steuerungssegment besteht aus einer Master Control Station in Colorado, USA, und vier weiteren Monitorstationen auf Hawaii, den Ascension Islands, Diego Garcia und Kwajalein. Die Monitorstationen erheben Messdaten und senden sie an die Master Control Station, die diese Daten auswertet, gegebenenfalls Fehlfunktionen feststellt und dann Korrekturdaten mit Hilfe der Monitorstationen an die Satelliten sendet. DGPS Das Signal, das von den Satelliten ausgestrahlt wird, muss auf dem Weg zur Erde verschiedene Luftschichten durchqueren. Durch die ionosphärische und troposphärische Refraktion wird das Signal je nach Grad der Ionisierung unterschiedlich stark abgebremst und abgelenkt. Dem Signal kann deshalb keine konstante Geschwindigkeit und zurückgelegte Distanz zugeordnet werden. Durch differentielle Korrektur wird versucht, diese Unterschiede durch Korrekturwerte auszugleichen. Dazu werden Abweichungen der Messwerte von realen Positionen anderer Empfänger benutzt. Je nachdem, ob die Korrekturdaten von Bodenstationen oder Satelliten gesendet werden, spricht man von Land-based DGPS oder Satellite Based Augmentation System (SBAS). Existierende SBAS sind das Wide Area Augmentation System (WAAS), das speziell auf Nordamerika ausgerichtet ist, der European Geostationary Navigation Overlay Service (EGNOS) innerhalb Europas und das japanische Multifunctional Transport Satellite-based Augmentation System (MSAS). A-GPS Das eintreffende Signal kann vom Empfänger auf drei verschiedenen Ebenen betrachtet werden (vgl. Abb. 3.3). Während das gespreizte Signal bereits bei einer Signalstärke von y dBm entspreizt werden kann, 3.1. ORTUNGSSYSTEME 29 sind Nutzdaten erst ab einer Signalstärke von x dBm 1 erkennbar. Außerdem ist die Übertragungsrate der Nutzdaten mit 50 Bit/s sehr gering und eine sequenzielle Übertragung aller Nutzdaten würde deshalb bis zu 12,5 Minuten in Anspruch nehmen. An diesen beiden Problemen greift das so genannte Assisted-GPS (A-GPS) an. Durch das Bereitstellen von Assistenzdaten, die im Wesentlichen die Nutzdaten enthalten, werden folgende Vorteile erzielt (vgl. [glo a, Chun 03]: 1. Die TTFF wird drastisch herabgesetzt, da die Nutzdaten nicht über die Satelliten übertragen werden müssen und weitere Informationen wie Näherungswerte der aktuellen Position bereits erste Anhaltspunkte für den First Fix“ geben. ” 2. Die Verfügbarkeit des Systems wird erhöht, da bereits eine Signalstärke von y dBm ausreicht, um das Signal zu entspreizen. Eine Dekodierung der Nutzdaten ist dazu nicht mehr nötig. 3. Die Genauigkeit der Positionsbestimmung wird verbessert, da auch Satelliten zur Positionsbestimmung herangezogen werden können, die ohne Assistenzdaten nicht nutzbar wären. 4. Der Energieverbrauch kann verringert werden, da Assistenzdaten nicht dekodiert werden müssen und die rechenintensive TTFF herabgesetzt wird. In den Assistenzdaten sind unter anderem die Ephemeriden, Doppler-Frequenzen, Uhrzeit und Näherungswerte der aktuellen Position enthalten. Sie können beispielsweise über Kanäle der Mobilkommunikationsnetze (z.B. SMS-Broadcast, GPRS, etc.) oder spezielle Broadcastnetze bereitgestellt werden. Über diese Kanäle werden sie vom Endgerät empfangen und zur Positionsberechnung eingesetzt. Alternativ zu diesem Verfahren, bekannt als mobile-based A-GPS, kann die Positionsberechnung auch extern, z.B. in der Mobilkommunikationsinfrastruktur, durchgeführt werden. Dieses Verfahren ist bekannt als mobile-assisted A-GPS und hat den Vorteil, dass komplexe Operationen der Positionsberechnung nicht mehr auf dem Endgerät stattfinden und dadurch vor allem der Energieverbrauch weiter sinkt. Nachteilig ist, dass keine autonome Positionsbestimmung auf dem GPS-Empfänger mehr möglich ist. 3.1.4 Weitere Ortungsverfahren und Klassifikationen Die hier vorgestellten Ortungsverfahren stellen nur eine repräsentative Teilmenge aller Ortungsverfahren dar. Weitere Ortungsverfahren sind zum Beispiel Uplink Time Difference of Arrival (UL-TDoA), Observed Time Difference of Arrival (OTDoA), Fingerprinting (z.B. mit Wireless LAN), Scene Analysis, Proximity Sensing (z.B. mit RFID-Tags) oder auch Kombinationen dieser Verfahren. Kategorien dieser Ortungsverfahren lassen sich anhand verschiedenster Gesichtspunkte bilden. Beispielsweise werden Ortungsverfahren prinzipiell nach ihrer Anwendbarkeit innerhalb (Indoor) und außerhalb (Outdoor) von Gebäuden unterschieden. Ein Beispiel für Outdoor-Ortungsverfahren ist das herkömmliche GPS. Ein Indoor-Verfahren wird zum Beispiel bei der Ortung mittels RFID-Tags eingesetzt. Einige Ortungsverfahren können aber sowohl innerhalb als auch außerhalb von Gebäuden eingesetzt werden. Dazu zählen (bis zu einem gewissen Maße) Ortungsverfahren von Mobilfunknetzen oder A-GPS. Die Differenzierung von Indoor- und Outdoor-Ortungsverfahren hängt wesentlich vom eingesetzten Observable (vgl. Kapitel 2.1) ab. Beispiele für Observables sind Ultraschall- oder Infrarotwellen, Signale des Mobilfunks (z.B. aus GSM oder UMTS) oder Signale des 2,4 GHz ISM-Bandes (z.B. Wireless LAN oder Bluetooth). Je nach Wellenlänge werden diese Signale von festen Gegenständen unterschiedlich stark reflektiert und können so mehr oder weniger weit in Gebäude eindringen. Infrarotwellen werden zum Beispiel von festen Gegenständen vollständig reflektiert, Funkwellen des 2,4 GHz ISM-Bandes hingegen können feste Gegenstände teilweise durchdringen. Desweiteren unterscheiden sich die verschiedenen Ortungsverfahren in der Art, wie die Signale zur Bestimmung der Ortsinformationen eingesetzt werden. Eine einfache Art basiert auf der Signalabschwächung. Die Entscheidungsregel, ob ein Signal empfangbar ist oder nicht, reicht hier aus, um die ungefähre Position zu bestimmen. Dieses Art wird beispielsweise beim CoO-Verfahren eingesetzt. Desweiteren kann dabei der Grad der Signalabschwächung bei der Bestimmung der Ortsinformationen herangezogen werden. Meist ist diese Art aufgrund der Mehrwegeausbreitung nicht sinnvoll einsetzbar. Eine weitere Möglichkeit ist die 1 Die Werte für x und y sind von Empfänger zu Empfänger unterschiedlich und wurden deshalb durch Variablen ausgedrückt 30 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE Laufzeitmessung bzw. Laufzeitunterschiedsmessung des Signals. Letzteres wird beispielsweise bei E-OTD eingesetzt. Diese Art des Signaleinsatzes kann für unterschiedliche Methodiken der Ortung verwendet werden. Hier sind vor allem die Trilateration, die zum Beispiel bei GPS eingesetzt wird, und die Triangulation, die Winkelberechnungen zur Bestimmung der Ortsinformationen heranzieht, zu nennen. Eine weitere Unterteilung kann anhand der Verteilung von Sender und Empfänger des Observables erfolgen. Sendet beispielsweise das Zielobjekt (vgl. Kapitel 2.2) ein Signal aus und der Location Technology Provider empfängt das Signal und bestimmt darauf den Ort des Zielobjektes, so spricht man von einem netzbasierten Ortungsverfahren. Sendet hingegen der Location Technology Provider das Signal aus und das Zielobjekt empfängt das Signal und wertet es aus, so handelt es sich um ein endgerätebasiertes Ortungsverfahren. GPS ist deshalb zu den endgerätebasierten Ortungsverfahren zu zählen, da das Signal nicht vom Zielobjekt ausgesendet wird. Stattdessen empfängt das Zielobjekt das Signal und bestimmt daraus die nötigen Ortsinformationen. Das CoO-Verfahren in GSM ist demgegenüber ein netzbasiertes Ortungsverfahren, da das für die Ortung genutzte Signal vom Zielobjekt (= mobiles Endgerät) gesendet wird und von der Basisstation (bzw. deren Backoffice), die die Ortungstechnologie bereitstellt, empfangen wird. Dort erfolgt auch die Bestimmung der Ortsinformationen. Problem der netzbasierten Ortungsverfahren ist, dass Ortsinformationen des Zielobjektes nicht durch das Zielobjekt bestimmt werden und so ein Missbrauch dieser Informationen stattfinden könnte. Anders ist dies bei den endgerätebasierten Ortungsverfahren, da hier das Zielobjekt seine Ortsinformationen selbst bestimmt und so über den weiteren Gebrauch selbst entscheiden kann. An dieser Stelle kann eine weitere Unterscheidung getroffen werden. Empfängt das Zielobjekt bei endgerätebasierter Ortung das Ortungssignal, leitet die gewonnen Informationen aber an den Location Technology Provider weiter, um diese Informationen auszuwerten, so spricht man von endgeräteassistierenden Ortungsverfahren, da diese zwar das Signal empfangen, aber keine Auswertung durchführen. Diese Art der Ortung findet beispielsweise bei mobile-assisted A-GPS statt. Analoges gilt für den netzbasierten Fall. Diese Konstellation tritt jedoch in der Regel nicht ein. 3.1.5 Zusammenfassung Zusammenfassend kann gesagt werden, dass derzeit nur GPS und dessen Erweiterungen eine adäquate Positionsbestimmung für Navigationsdienste liefern können. Dies liegt hauptsächlich an der sehr guten und recht konstanten Genauigkeit, der globalen Verfügbarkeit und der Möglichkeit Positionen im dreidimensionalen Raum zu bestimmen. Letzteres kann vor allem bei Navigationsdiensten eine entscheidende Rolle spielen. Neben GPS wird in den nächsten Jahren das ebenfalls satellitenbasierte Ortungssystem Galileo [gal , Simo 05] aufgebaut. Das Raumsegment wird aus zusätzlichen 30 Satelliten bestehen, verteilt auf drei Orbits in einer Höhe von 23.200 Kilometern. Diese strahlen Signale auf Frequenzen des E- und L-Bandes aus. Der Signalaufbau ist ähnlich zu GPS. Wesentliche Vorzüge von Galileo im Gegensatz zu GPS werden die Dienstgarantien und die Abrechnungsmöglichkeit sein. Eines der entscheidenden Argumente für Galileo war aber sicherlich, die Monopolstellung von GPS zu brechen. Erste funktionsfähige Versionen des Galileo-Systems werden voraussichtlich im Jahr 2008 einsetzbar sein. 3.2 Mobile Programmierplattformen Mobile Dienste zeichnen sich durch die Nutzbarkeit auf mobilen Endgeräten aus. Dazu muss das Endgerät bestimmte Eigenschaften besitzen, die es dem Dienst zur Verfügung stellt. Diese sind Ein- und Ausgabemöglichkeiten zur Kommunikation mit dem Nutzer, Sende- und Empfangseinheiten zur Kommunikation mit anderen Systemen, die Fähigkeit komplexe Programme auszuführen, etc. Um diese Eigenschaften des Endgerätes für den Dienst zu nutzen, muss es Zugriffsmöglichkeiten darauf geben. Offene Plattformen auf dem Endgerät ermöglichen diesen Zugriff für Anwendungen von Drittanbietern. 3.2. MOBILE PROGRAMMIERPLATTFORMEN 31 Applikation (z.B. MoBiLe) Laufzeitumgebung (z.B. Java) Betriebssystem (z.B. Symbian) Hardware (z.B. ARM) Abbildung 3.4: Mobile Plattform Im Wesentlichen ist eine Plattform auf einem mobilen Endgerät, wie in Abbildung 3.4 dargestelllt, aufgebaut. Basis ist die Hardware, die sich aus einer Recheneinheit, persistentem sowie volatilem Speicher, Ein- und Ausgabegeräten, Sende- und Empfangseinheiten, etc. zusammensetzt. So gut wie jedes mobile Endgerät verfügt über diese Bauteile. Die Ausprägung und Anzahl der Bauteile ist aber von Gerät zu Gerät unterschiedlich. PDAs beispielsweise verfügen meist über einen für ihre Größe relativ leistungsstarken Prozessor und entsprechendem Speicher. Das Display zeichnet sich oft durch hohe Farbtiefe und gleichzeitiger Eingabemöglichkeit durch Berührung aus (Touch-Screen). Als Sende- und Empfangseinheit dient häufig lediglich eine Dockingstation, sowie eine Infrarot- und Bluetooth-Funkeinheit. Mobiltelefone hingegen haben derzeit noch einen weniger rechenstarken Prozessor mit weniger Speicher, kleinere Farbdisplays und eine ITU-T One-Hand-Tastatur. Dazu kommen in der Regel mehrere Sendeund Empfangseinrichtungen für Personal Area Networks (PAN) wie Bluetooth oder Infrarot, Local Area Networks (LAN) wie IEEE802.11 und Metropolitan Area Networks (MAN) wie GSM oder UMTS mit verschiedensten Frequenzen. Wie man sieht, gibt es bereits große Unterschiede bei den Mobiltelefonen bezüglich deren Eigenschaften und Fähigkeiten. Durch Bezeichnungen wie Smartphone wird deshalb versucht, Kategorien innerhalb der Klasse der Mobiltelefone zu bilden. Leider sind derartige Bezeichnungen nur schlecht gegeneinander abgegrenzt. Aufgrund der rasanten Entwicklung in diesem Bereich wird sich auch in Zukunft diese Klasse durch wachsende Heterogenität auszeichnen. Der Zugriff auf die Endgeräteeigenschaften wird durch das Betriebssystem geregelt. Viele Betriebssysteme für mobile Endgeräte sind dabei so konzipiert, dass sie auf verschiedenste Hardware aufsetzen können und eine Abstraktionsschicht für darüber liegende Schichten bilden. Frühere, aber auch der Großteil der heutigen mobilen Endgeräte nutzen proprietäre geschlossene Betriebssysteme. Dadurch ist es nicht möglich, Anwendungen in das System zu integrieren, auszuführen oder Änderungen durchzuführen ohne tiefe Eingriffe in das System. Oft muss sogar das komplette Betriebssystem ersetzt werden. Entwicklungen der letzten Jahre brachten allerdings einige offene 2 Betriebssysteme hervor. Dazu zählen Palm OS, Windows CE, Symbian OS und möglicherweise in der Zukunft auch (Embedded) Linux (vgl. [VAL+ 01]). Diese Betriebssysteme lassen es zu, Anwendungen von Drittanbietern zu integrieren und auszuführen. Auf das Betriebssystem Symbian OS wird nachfolgend detaillierter eingegangen. Die Laufzeitumgebung ist ein weiteres Abstraktionslevel von mobilen Plattformen. Laufzeitumgebungen existieren meist für verschiedene Betriebssysteme und stellen eine betriebssystemunabhängige Funktionsmenge bereit. Diese kann durch Anwendungen von Drittanbietern genutzt werden. Ein Beispiel einer Laufzeitumgebung für mobile Endgeräte ist Java2 Microedition (J2ME). Auf J2ME wird später in diesem Kapitel genauer eingegangen. 3.2.1 Symbian OS Aus der Heterogenität der kleinen mobilen Endgeräte heraus, entwickelt die Firma Symbian [sym ] (entstanden aus Ericsson, Nokia, Motorola, Psion) seit 1998 ein Betriebssystem namens Symbian OS für eben diese Endgeräte. Es basiert auf dem Betriebssystem EPOC, welches von Psion für Handhelds entwickelt 2 offen“ bezeichnet hier nicht open-source, sondern dass eine API und Integrationsmöglichkeit für Anwendungen existiert ” 32 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE wurde. Durch Anpassung und Weiterentwicklung entstand daraus Symbian OS. Derzeit existiert Version 9 des Betriebssystems und die Anzahl der mit Symbian OS ausgestatteten Mobiltelefone beläuft sich auf derzeit 23 Modelle. Es wird aber prognostiziert, dass die Anzahl der mit Symbian OS betriebenen Mobiltelefone in Zukunft weiter ansteigen wird. [sym ] beschreibt sein Betriebssystem als “advanced, open, standard operating system [...] for data-enabled mobile phones“. Es ist speziell für ubiquitäre, kleine, mobile Endgeräte entworfen worden, die sich durch temporäre Netzverbindungen und Heterogenität auszeichnen und die Integration von Applikationen von Drittanbietern erlauben sollen. Symbian ist ein sehr robustes 32-Bit Multithreaded-Multitasking-Realtime-Betriebssystem. Es ist größtenteils in objektorientiertem C++ geschrieben und stellt eine native API in C++ bereit. Dadurch ist es möglich, sehr effiziente Applikationen zu schreiben. Gegenüber Laufzeitumgebungen bietet die native API einen höheren Funktionsumfang und direkten Zugriff auf Ressourcen. Symbian OS stellt daher ein sehr umfangreiches, fortschrittliches, offenes Betriebssystem dar, das Drittanbietern ein breites Spektrum an Anwendungen ermöglicht. 3.2.2 J2ME Neben der nativen API stellt Symbian OS derzeit auch eine Laufzeitumgebung für J2ME bereit. Die J2ME-Laufzeitumgebung wird aber auch von einigen anderen offenen Betriebssystemen und sogar von proprietären Betriebssystemen der meisten Hersteller angeboten. J2ME ist eine der drei existierenden Editionen der Java2 Plattform (vgl. [jav , Stra 05] und Abb. 3.5): • Java2 Standard Edition (J2SE): J2SE stellt eine Laufzeitumgebung mit einer Menge an APIs für Desktop-Applikationen zur Verfügung. Desweiteren wird eine Kernmenge an Funktionen für alle anderen Editionen definiert. • Java2 Enterprise Edition (J2EE): J2EE erweitert J2SE um eine skalierbare, transaktionsorientierte und datenbankbezogene Funktionsmenge für Enterprise-Applikationen. • Java2 Micro Edition (J2ME): J2ME definiert mehrere Laufzeitumgebungen und APIs für kleine, ressourcenbeschränkte Endgeräte wie PDAs, Mobiltelefone, Set-top-Boxen, etc. Optionale Pakete Optionale Pakete Optionale Pakete J2EE JVM J2SE Personal Profile Optionale Pakete Foundation Profile MIDP CDC JVM CLDC JVM KVM J2ME Abbildung 3.5: Überblick über die Java 2 Editionen Grundlage jeder Java-Edition ist die Virtual Machine (VM). Im Zusammenhang mit J2ME sind zwei Ausprägungen von VMs von Bedeutung. Dabei handelt es sich um die klassische Java VM (JVM) und die 3.2. MOBILE PROGRAMMIERPLATTFORMEN 33 KVM. Das K“ der KVM deutet auf den Speicherverbrauch hin, der sich im Kilobytebereich bewegt. ” Abhängig von der Geräteart benötigt sie derzeit gerade einmal einen Speicherplatz von 50-80 Kilobyte. Aufgrund der Inhomogenität der kleinen Endgeräte, setzt sich J2ME aus drei einzelnen modularen Elementen zusammen. Diese sind die so genannten Configurations, Profiles und optionale Pakete. Configurations spezifizieren die Basisfunktionalität für eine bezüglich bestimmter Eigenschaften homogene Menge von Endgeräten. Diese Eigenschaften beinhalten die Größe des Speichers, Netzwerkverbindungen, Displaygröße und Eingabemöglichkeiten. Die Funktionalität der Configurations setzt sich aus der Funktionalität der VM und der Basisbibliotheken zusammen. Derzeit existiert im Bereich der KVM nur eine Configuration, die so genannte Connected Limited Device Configuration (CLDC). Für höherwertige Geräte mit klassischer JVM gibt es außerdem noch die Connected Device Configuration (CDC). Zu diesen Geräten zählen hauptsächlich PDAs oder Set-Top-Boxen. Geräte mit KVM sind hingegen meist höheren Restriktionen unterlegen. Dabei handelt es sich zum Beispiel um Mobiltelefone. Derzeit existieren zwei Versionen der CLDC. Diese sind CLDC 1.0 [cld a] und CLDC 1.1 [cld b]. Die minimalen Anforderungen an das Endgerät für CLDC 1.0 sind im Folgenden aufgelistet: • 160-512 Kilobyte Speicher (volatil sowie persistent) • Verschiedene Netzwerkverbindungen, oft drahtlos & nicht verlässlich • 96 x 54 Pixel Display mit 1 Bit Farbtiefe • ITU-T Onehand-Tastatur oder Touch-Screen Der Funktionsumfang, der durch CLDC bereitgestellt wird, ist eingeschränkt gegenüber dem Funktionsumfang in J2SE. Diese Beschränkungen beruhen einerseits auf den restriktiven Ressourcen der kleinen Endgeräte und andererseits auf Sicherheitsaspekten. Die wichtigsten Einschränkungen der CLDC 1.0 sind im Folgenden aufgelistet: • Keine Fließkommazahlenunterstützung • Beschränkte Fehlerbehandlung für Run-time-Errors • Kein Java Native Interface • Keine nutzerspezifischen ClassLoader • Keine Reflection API • Keine Objektserialisierung • Keine Weak-References Im Dezember 2002 wurde eine neue Version der CLDC (CLDC 1.1) veröffentlicht, die durch den JSR-139 spezifiziert wird. Die wesentlichen Neuerungen in CLDC 1.1 sind: • Fließkommazahlenunterstützung • Unterstützung von Weak-References Hauptsächlich aufgrund der Fließkommaarithmetik haben sich die Anforderungen an den minimalen Speicherplatz von 160 auf 192 Kilobyte erhöht. Aufsetzend auf die Funktionalität der Configurations, erweitern die Profiles die Laufzeitumgebung um eine Menge an High-Level-Funktionen wie das Life-Cycle-Management, das User Interface (UI) und den Zugriff auf gerätespezifische Funktionen. Ein Profile kann nur in Verbindung mit einer bestimmten Configuration genutzt werden. Beispiele für ein Profile für CDC sind das Foundation Profile und das darauf aufsetzende Personal Profile. Ein entsprechendes Profile für CLDC ist das Mobile Information Device Profile (MIDP). MIDP existiert derzeit in zwei Versionen, MIDP 1.0 [mid a] und MIDP 2.0 [mid b]. MIDP setzt als UI das speziell auf kleine Endgeräte mit wenig Rechenleistung ausgerichtete Liquid Crystal Display UI (LCDUI) ein. Als Verbindungsprotokoll ist in MIDP 1.0 nur HTTP obligatorisch. Seit November 2002 existiert eine neue Version von MIDP (MIDP 2.0). Sie unterscheidet sich im Wesentlichen von MIDP 1.0 durch folgende Punkte: 34 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE • Neues Verbindungsprotokoll: HTTPS • MIDP Media API • Game API • Push Registry • Zugriff auf Record-Stores anderer MIDlets • Over-The-Air User Initiated Provisioning • PKI-Unterstützung Anwendungen in J2ME unter CLDC und MIDP werden in so genannten MIDlets verfasst. MIDlets ähneln dem Konzept der Applets, die bereits in J2SE eingesetzt wurden. Wesentliche Unterschiede ergeben sich in der Art des UI. Während J2SE auf das Abstract Window Toolkit (AWT) und Swing setzt, nutzt J2ME das LCDUI, welches eine geringe Teilmenge der Funktionalität von AWT und Swing umsetzt. Dadurch ist es aber besonders für mobile Endgeräte mit hohen Ressourcenbeschränkungen geeignet. Ein weiterer Punkt, in dem sich J2ME von J2SE unterscheidet, ist der Zugriff auf Netzwerkverbindungen. In J2SE stehen hierfür verschiedenste Klassen aus den Packages java.io und java.lang zur Verfügung. Um eine spezielle Netzwerkverbindung zu initialisieren, wird ein entsprechendes Objekt erzeugt. Aufgrund der hohen Heterogenität der mobilen Endgeräte bezüglich der Netzverbindungen ist dieser Ansatz in J2ME nicht sinnvoll umsetzbar. Deshalb wurde in J2ME ein neuer Ansatz entwickelt, der nicht dieser Problematik unterliegt. Dies ist das so genannte Generic Connection Framework (GCF). Die Initialisierung jeder Netzwerkverbindung erfolgt über die Klasse Connector. Anhand der angegebenen Adresse und der Verfügbarkeit von Low-Level“-Netzwerkverbindungen (je nach Endgerätefunktionalität) ” wählt das GCF die entsprechende Connection-Klasse aus. Durch die Hinzunahme weiterer Verbindungstypen und der entsprechenden Connection-Klasse kann das GCF leicht erweitert werden. Aufbauend auf das Profile gibt es eine Menge optionaler Pakete. Welche Pakete verfügbar sind, hängt im Wesentlichen von der Ausstattung des Endgerätes ab. Besitzt das Endgerät zum Beispiel eine BluetoothSchnittstelle und das Betriebssystem ermöglicht den Zugriff auf diese Schnittstelle, kann das Paket Java APIs for Bluetooth Wireless Technology (JABWT) [jab ] als optionales Paket integriert werden. JABWT JABWT stellt eine API für die Geräte- und Dienstsuche, das Gerätemanagement und die Gerätekommunikation bereit. Für die Geräte- und Dienstsuche dient der so genannte DiscoveryAgent, der mittels Callback-Funktion über gefundene Geräte und Dienste informiert. Mit Hilfe des Gerätemanagements können Statusabfragen und Konfigurationen der eigenen Bluetooth-Schnittstelle sowie entfernter Bluetooth-Geräte durchgeführt werden. Konfigurationsmöglichkeiten beziehen sich auf die Authentifizierung, Autorisierung und Verschlüsselung. Statusabfragen können für die maximale Anzahl paralleler Verbindungen, Adressen, Sichtbarkeit für andere Geräte, Versionen, etc. erfolgen. Die Gerätekommunikation basiert auf dem Logical Link Control and Adaptation Layer Protocol (L2CAP). Um dieses innerhalb von J2ME wie gewohnt zu nutzen, werden durch JABWT eine Menge neuer Verbindungsprotokolle in das GCF eingefügt. Diese stellen Client- sowie Serverfunktionalitäten zur Verfügung. JABWT wird derzeit von einigen wenigen Mobiltelefonen angeboten. Die Zahl der JABWT-unterstützenden Geräte steigt aber stetig an. LAPI Vor allem für den Einsatz in LBSs existiert ein optionales Paket, das die Verwendung von Ortsinformationen erleichtern soll. Dieses Paket ist die Location API (LAPI) [lap 03]. Die LAPI wurde konzipiert, um innerhalb eines MIDlets leichten Zugriff auf Ortsinformationen des Endgerätes zu erlangen. Dabei ist das eingesetzte Ortungsverfahren unerheblich. Die zentrale Komponente der LAPI ist der LocationProvider. Ein Objekt vom Typ LocationProvider liefert eine bestimmte Art von Ortsinformationen. Bei der Anforderung von Ortsinformationen können durch die Spezifikation von Kriterien (Criteria) die Genauigkeit, der Energieverbrauch, die entstehenden Kosten, etc. der Positionsbestimmung eingeschränkt werden. Der LocationProvider 35 3.2. MOBILE PROGRAMMIERPLATTFORMEN ist eine abstrakte Klasse, die eine Menge abstrakter und nicht-abstrakter Methoden besitzt. Eine nichtabstrakte Methode ist beispielsweise getInstance, mit der eine Instanz eines LocationProviders angefordert wird, die bestimmte Kriterien erfüllt. Außerdem kann durch die nicht-abstrakte Methode addProximityListener eine automatische Benachrichtigung bei Erreichen einer bestimmten Nähe zu einer festen Koordinate hinzugefügt werden. Abstrakte Methoden sind unter anderem getLocation, um die aktuelle Position abzufragen, getState, um den aktuellen Zustand des LocationProviders zu bestimmen, und setLocationListener, um den LocationProvider für periodischen Aktualisierungen zu konfigurieren. Letztere liefert Ortsinformationen asynchron über ein Callback-Verfahren. Dazu wird der setLocationListener-Methode als Parameter ein Objekt vom Typ LocationListener angehängt. Nach Ablauf des Zeitintervalls erfolgt eine Aktualisierung der Ortsinformationen, indem die Methode locationUpdated auf diesem Objekt aufgerufen wird. Ähnliches gilt für die oben erwähnte Registrierung der ProximityListener. Hier wird automatich die Methode proximityEvent des ProximityListeners bei örtlicher Nähe zu einer festen Referenzkoordinate aufgerufen. Die Nähe wird durch die Angabe des Abstandes zwischen aktueller Koordinate und Refernzkoordinate in Metern spezifiziert. Eine derartige Ereignissteuerung könnte für den MoBiLe-Service eingesetzt werden. Dadurch würde ein Ereignis ausgelöst, sobald sich der Nutzer in die Nähe eines Aktionspunktes bewegt, und daraufhin eine Navigationsinformation bereitgestellt. Probleme für den MoBiLeService ergeben sich durch die stark schwankenden Geschwindigkeiten des Nutzers. Eine optimale Wahl der Abstandsangabe ist hierbei schwer möglich. Eine Lösung, die den Anforderungen des MoBiLe-Service entspricht, wird in Kapitel 4 vorgestellt. Um die LAPI für den Gebrauch mit einem externen GPS-Empfänger einzusetzen, muss ein LocationProvider, der die Anbindung an den GPS-Empfänger verwaltet und Ortsinformationen in die gewünschte Form bringt, abgeleitet werden. Hierbei erfolgt durch die LAPI leider keine Unterstützung. Insgesamt ergäbe die Erweiterung der LAPI für den MoBiLe-Service einen erheblichen Aufwand, der in keiner Relation zum erbrachten Mehrwert steht. Außerdem wird die LAPI derzeit leider nur von wenigen Endgeräten unterstützt. Um den Demonstrator ohne komplexe Veränderungen auf verschiedenen Endgeräten betreiben zu können, wurde die LAPI deshalb und aus den oben genannten Gründen in dieser Arbeit nicht eingesetzt. Application TinyLine SVG M3G OpenGL ES Graphics Engine MMAPI SVGAPI MIDP CLDC KVM Abbildung 3.6: Mobile Plattform für Grafikdarstellung MMAPI Auch für die Arbeit mit Multimediainhalten stellt J2ME standardmäßige, sowie erweiterte Unterstützung durch optionale Pakete, bereit. Während MIDP 1.0 nur die Darstellung von Bildern ermöglicht, erweitert MDIP 2.0 die Medienfähigkeit um die Funktion zum Abspielen von Audiodateien. Die Unterstützung weiterer Medien und erhöhte Funktionalität liefert das optionale Paket Mobile Media API (MMAPI) [mma ]. Die MMAPI besteht im Wesentlichen aus vier Komponenten. Diese sind Manager, Player, Control und DataSource. Mit diesen Komponenten kann unabhängig von der Art des Mediums gearbeitet werden. Egal ob es sich um Audiodateien im WAV- oder MP3-Format, Rastergrafikdateien im JPEG- oder GIF-Format oder Videodateien im MPEG- oder AVI-Format handelt, bietet die MMAPI identische Zugriffsmethoden. Dadurch ist der Zugriff auf die Medien unabhängig vom zugrunde liegenden 36 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE Endgerät, das verschiedenste Medientypen unterstützen kann. SVG-APIs Zur Unterstützung von Vektorgrafikdateien gibt es ein optionales Paket namens Scalable 2D Vector Graphics API (SVGAPI) [svg ]. Damit ist es möglich, Vektorgrafiken im SVG-Tiny-Format des W3C [Ande 03a] auf dem Display von mobilen Endgeräten anzuzeigen. SVG Tiny (SVGT) ist eines der beiden Mobile Profiles [Ande 03a] des SVG 1.1 Standards [Ande 03b] und speziell auf ressourcenbeschränkte mobile Endgeräte ausgerichtet. Grafiken im SVG-Format sind besonders gut geeignet zur Darstellung von grafischen Objekten, die sich hauptsächlich aus Linien zusammensetzen wie zum Beispiel einfache Landkarten (vgl. [Wald 03]). Vorteile gegenüber Rastergrafiken bestehen in der guten Skalierbarkeit, dem geringen Speicherplatzverbrauch, der einfachen Transformation der Objekte und dem einfachen Zugriff auf Objekte (vgl. [Beck 02]). Derzeit wird SVGAPI nur von einigen wenigen mobilen Endgeräten unterstützt. Eine Möglichkeit, um SVG-Grafiken auch auf anderen Endgeräten darstellen zu können, wird durch das Projekt TinyLine SVG [tin ] erreicht. TinyLine SVG bietet eine Highlevel- sowie Lowlevel-API zum Erstellen, Bearbeiten und Darstellen von SVG-Grafiken. Dazu benötigt TinyLine SVG mindestens MIDP 2.0. Voraussichtlich werden Vektorgrafiken aufgrund der oben genannten Vorteile in Zukunft vermehrt im Bereich der mobilen Endgeräte eingesetzt. Ein Einsatzzweck könnte zum Beispiel die grafische Präsentation von Navigationsinformationen sein. M3GAPI Zur Unterstützung von dreidimensionalen Grafikobjekten existiert das optionale Paket Mobile 3D Graphics API (M3GAPI) [m3g ]. Die M3GAPI kann in zwei verschiedenen Modi genutzt werden. Diese sind der Retained Mode und der Immediate Mode. Im Retained Mode steht eine Highlevel-API zur Verfügung, mit der auf einfache Weise mit 3D-Grafikobjekten, virtuellen Kameras und Licht gearbeitet werden kann. Der Immediate Mode stellt eine Lowlevel-API bereit und ermöglicht so das direkte Zeichnen von 3D-Objekten. Der Immediate Mode ist auf OpenGL ES [ope a] angepasst, welches auf Endgeräte mit speziellem Grafikprozessor ausgerichtet ist. Der Mascot-Capsule [mas ] ist ein Grafikprozessor, der bereits in einigen Mobiltelefonen zu finden ist. Zusammen mit OpenGL ES oder MMAPI ermöglicht dieser bereits relativ aufwändige 3D-Darstellungen. Derzeit verfügen bereits auf einigen Mobiltelefonen über die M3GAPI. Einen Überblick über die vorgestellten APIs zur Unterstützung grafischer Medien zeigt Abbildung 3.6. 3.2.3 Zusammenfassung Diese kurze Einführung in J2ME zeigte die wesentlichen Eigenschaften und Neuerungen gegenüber J2SE, sowie einige für Navigationsdienste relevante Punkte. Für eine genauere Betrachtung von J2ME wird auf [jav , Schm 04, Stra 05] verwiesen. Gegenüber Anwendungen für die native Schnittstelle von Symbian OS zeigen sich Anwendungen für J2ME wesentlich ineffizienter und dadurch langsamer in der Ausführung. Auch der Funktionsumfang von J2ME ist meist eingeschränkt gegenüber Symbian OS. Jedoch glänzt J2ME bis auf wenige Ausnahmen durch seine Plattformunabhängigkeit und seine bereits sehr gute Unterstützung in vielen Bereichen. Daher bietet J2ME eine gegenüber Symbian OS nicht zu vernachlässigende mobile Programmierplattform, die sicherlich auch in Zukunft vermehrt zum Einsatz kommen wird. 3.3 Unterstützung für verteilte Push-Dienste Der Navigationsdienst, der in dieser Arbeit entwickelt wird, soll in Form eines LBPSs realisiert werden. Für den Fall eines verteilten LBPSs müssen zwischen den verteilten Komponenten Protokolle eingesetzt werden, die dieses Pushing unterstützen. Hierzu gibt es einige Protokolle, die vorzugsweise im Bereich des Mobilfunks zum Einsatz kommen. Desweiteren existieren einige Protokolle der Anwendungsschicht, die 3.3. UNTERSTÜTZUNG FÜR VERTEILTE PUSH-DIENSTE 37 spezielle für den Austausch von Ortsinformationen entwickelt wurden und zumindest partiell die Kommunikation zwischen verteilten Komponenten von LBPSs in Betracht ziehen. Im Folgenden wird eine kurze Einführung in diese Protokolle gegeben. 3.3.1 Push-Protokolle SMS Der Short Message Service (SMS) [3gp c] ist Anfang der 90er Jahre entstanden und heutzutage der meist gebrauchteste Dienst zum Austausch von Kurznachrichten im Mobilfunknetz. Die Übertragung von SMSNachrichten erfolgt über Signalisierungskanäle. Die Zustellung von Nachrichten wird durch das SMS Center (SMSC) geregelt und wird durch Pushing realisiert. D.h. dass SMS-Nachrichten nicht vom Nutzer abgerufen werden, sondern bei Verfügbarkeit automatisch zugestellt werden. Diese Art der Datenübertragung könnte prinzipiell auch für die Kommunikation in der verteilten Varianten des LBPSs eingesetzt werden. Vorteile sind nach [Tosi 03] die Standardisierung und die gute Unterstützung auch beim Roaming in Fremdnetze. Nachteile sind jedoch, dass eine SMS-Nachricht nur 160 alphanumerische Zeichen enthalten kann. Es ist daher keine akzeptable Übertragung von Bildern, Audio und Video möglich. Da diese Medien aber bei der Realisierung des MoBiLe-Service zum Einsatz kommen, stellt SMS kein anwendbares Protokoll für die verteilte Kommunikation bei LBPSs dar. MMS Im Gegensatz zu SMS stellt der Multimedia Messaging Service (MMS) die Möglichkeit bereit, verschiedenste Medien zu übertragen. MMS gilt als Nachfolger von SMS und hat eine ähnliche Funktionsweise. Die Zustellung der Nachrichten erfolgt durch das MMS Center (MMSC) und Nachrichten werden ebenfalls nicht explizit vom Nutzer abgefragt, sondern durch einen Push-Mechanismus dem Nutzer zur Verfügung gestellt. Die Übertragung von MMS-Nachrichten basiert jedoch nicht wie SMS auf der Nutzung von Signalisierungskanälen. MMS-Nachrichten werden in der Regel mittels des Wireless Application Protocol (WAP) [wap a] übertragen. Zu übertragende Medien können Text, Grafiken (z.B. im GIF- oder PNG-Format), Audio (z.B. im MIDI-Format) oder Video (z.B. im H.263- oder MPEG4-Format) sein. Da gegenüber SMS MMS bisher weniger gut unterstützt wird und ernsthafte Probleme in der Kompatibilität hat, ist MMS für die Realisierung des MoBiLe-Service kein anwendbares Protokoll für die verteilte Kommunikation. WAP Push Eine dritte Alternative steht durch WAP Push [wap b] zur Verfügung. WAP Push ist ein speziell für PushDienste vorgesehenes Konzept von WAP. Die WAP Push Architektur besteht im Wesentlichen aus zwei Komponenten. Diese sind der Push Initiator (PI) und der Push Proxy Gateway (PPG). Der PI ist dafür zuständig, den Push-Vorgang anzustoßen. Der PPG übertragt daraufhin den Inhalt mittels des Push OverThe-Air Protocol an das mobile Endgerät. PI und PPG kommunizieren über das Push Access Protocol (PAP). Das PAP wird in einen HTTP1.1 POST-Aufruf eingebettet. Die eigentliche Nachricht, die aus einem Service Indicator (SI) oder einem Service Load (SL) bestehen kann, wird ebenfalls in diesen Aufruf integriert. Der SI ist dafür zuständig, dem Nutzer eine kurze Botschaft und einen Verweis auf weiterführende Informationen zu überbringen. SL kann hingegen dazu eingesetzt werden, automatisch weiterführende Informationen auf das Endgerät zu laden und dort anzuzeigen. Ein beispielhafter HTTP1.1 POST-Aufruf zwischen PI und PPG ist im Folgenden gegeben: 2 POST / HTTP/1.1 Host: localhost Content-Type: multipart/related; boundary=asdlfkjiurw; type="application/xml" 4 --asdlfkjiurw 38 6 8 10 12 14 16 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE Content-Type: application/xml <?xml version="1.0"?> <!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP 1.0//EN" "http://www.wapforum.org/DTD/pap_1.0.dtd"> <pap productname="Testgateway"> <push-message push-id="[email protected]"> <address address-value="WAPPUSH=127.0.0.1/[email protected]" /> </push-message> </pap> --asdlfkjiurw Content-Type: text/vnd.wap.si 18 20 22 24 26 28 <?xml version="1.0"?> <!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN" "http://www.wapforum.org/DTD/si.dtd"> <si> <indication href="http://www.waptest.de/wml/pap/message.wml" si-id="[email protected]"> Sie haben eine neue Nachricht! </indication> </si> --asdlfkjiurw-- Ein Endgerät mit der IP 127.0.0.1 würde daraufhin in geräteabhängiger Form den Text Sie haben eine neue ” Nachricht!“ darstellen und auf den Link http : //www.waptest.de/wml/pap/message.wml verweisen. Diese Art des Pushings ermöglicht einen weitaus höheren Funktionsumfang als die oben beschriebenen Verfahren mittels SMS oder MMS, ist aber wesentlich komplexer in der Handhabung und Implementierung. Desweiteren lässt WAP Push nach [Tosi 03, PSM 01] keine echte Integration in Internetdienste zu und unterliegt einigen Einschränkungen die durch zukünftige Technologien wesentlich verbessert werden. SIP Eine sehr innovative Push-Technologie ist durch das Session Initiation Protocol (SIP) [iet 99] einsetzbar. SIP ist ein Signalisierungsprotokoll der Anwendungsschicht, um Sitzungen zwischen zwei oder mehr Teilnehmern zu erzeugen,zu modifizieren und zu beenden. Die Sitzungen beinhalten Internet Multimediakonferenzen, Internet-Sprachdienste und die Verteilung multimedialer Inhalte. Wesentliche Komponenten der SIP-Architektur sind der SIP Proxy und der SIP User Agent (SIP UA). SIP-Nachrichten haben einen ähnlichen Aufbau wie HTTP-Nachrichten und sind ebenfalls textbasiert. SIP ist aber keinesfalls eine Erweiterung von HTTP. Transportprotokoll kann sowohl TCP als auch UDP sein. SIP-Methoden sind zum Beispiel INVITE, ACK und REGISTER. Erweiterungen von SIP definieren zusätzliche Methoden. [Tosi 03, PSM 01] beschreiben wie eine Architektur für das Pushing mittels SIP aussehen und funktionieren kann. Die Architekturen erfüllen die Anforderungen der 3GPP Push-Services (vgl. [3gp d, 3gp e]. SIP wird derzeit von Endgeräten und Infrastrukturkomponenten nur rudimentär unterstützt und ist deshalb nur erschwert einsetzbar. Zukünftig wird die Nutzung voraussichtlich jedoch viele Vorteile bringen und die Voraussetzungen für LBPSs weitestgehend erfüllen (vgl. hierzu auch Kapitel 7). 3.3.2 Location-based Push-Protokolle MLP Das Mobile Location Protocol (MLP) [mlp ] ist ein XML-basiertes, erweiterbares Protokoll der Anwendungsschicht. MLP standardisiert den Austausch von Ortsinformationen zwischen dem Location Provider und dem Dienstanbieter, der mit Hilfe dieser Ortsinformationen den Dienst bereitstellt. Das Protokoll ist 3.4. BESTEHENDE NAVIGATIONSDIENSTE 39 unabhängig von der zugrunde liegenden Netzwerktechnologie und deshalb vielseitig einsetzbar. MLP ist dreischichtig aufgebaut. Bei den Schichten handelt es sich um das Transport Layer, das Element Layer und das Service Layer. Das Transport Layer ist für den Transport des XML-Inhaltes zuständig. Der Standard schlägt hierfür Protokolle wie HTTP, WSP oder SOAP vor. Das Element Layer definiert allgemeine Elemente, die im Service Layer eingesetzt werden können. Schließlich definiert das Service Layer eine Menge an Übertragungarten für den Ortsinformationsaustausch. Beispiele hierfür sind der Standard Location Immediate Service (SLIS), der Standard Location Reporting Service (SLRS) und der Triggered Location Reporting Service (TLRS). Jeder dieser Übertragungsarten spezifiziert eine bestimmte Semantik in der Art der Kommunikation und eine Menge an Parametern für diesen Datenaustausch. Der SLIS kann für die Abfrage von Ortsinformationen von einem oder mehreren Zielobjekten genutzt werden. Er definiert drei Methoden, die dies verwirklichen sollen. Wichtige Parameter sind eindeutige Identifikatoren für das Zielobjekt, Zeitstempel, geforderte Genauigkeiten sowie natürlich die eigentliche Ortsinformation in einem bestimmten Datum und mit einer bestimmten Genauigkeit. Der SLRS wird nicht für die Abfrage von Ortsinformationen eingesetzt. Hier informiert das Zielobjekt selbstständig den Dienstanbieter über die aktuellen Ortsinformationen. Dazu wird nur eine Methode definiert, die als Parameter im Wesentlichen die Ortsinformation und einen Zeitstempel enthält. Der TLRS kann dazu eingesetzt werden, um Ortsinformationen über ein Zielobjekt bei Eintritt bestimmter Ereignisse zu erhalten. Derzeit ist das einzige Ereignis der Ablauf eines Zeitintervalls. Für die Zukunft sollen aber auch Ereignisse bei Betreten oder Verlassen von Zonen und andere Ereignisse möglich sein. Parameter für die fünf definierten Methoden sind zum Beispiel eindeutige Identifikatoren der Zielobjekte, Zeitstempel, Gültigkeitszeiträume, geforderte Genauigkeiten, etc. Um MLP für den MoBiLe-Service einzusetzen, sind grundlegende Erweiterungen durchzuführen, die den Rahmen dieser Arbeit sprengen würden. Desweiteren ist die Datenmenge, die aus der Signalisierung entsteht, aufgrund der XML-Basis erheblich und würde so zu hohen Kosten und Verzögerungen führen. Geopriv Das Geopriv-Protokoll [geo 04] ist für den sicheren Austausch von Ortsinformationen zwischen dem Zielobjekt und dem Dienstanbieter entwickelt worden. Besonders im Vordergrund stehen in diesem Protokoll sicherheitskritische Aspekte für verschiedenste Location-based Services, wie Navigationsdienste oder Notfalldienste. Ein wesentliches Element der Geopriv-Protokolls ist das Location Object (LO). Das LO enthält die Ortsinformationen des Zielobjektes, ein Identifikator (oder Pseudonym) für das Zielobjekt, Zeitstempel und sicherheitsrelevante Informationen. Aufgrund von zeitlichen Restriktionen in dieser Arbeit wird innerhalb des MoBiLe-Service eine sicherheitskritische Betrachtung des Dienstes vorerst vernachlässigt. Der Einsatz von Geopriv ergibt deshalb keinen großen Mehrwert für diese Arbeit und wird darum vermieden. Für zukünftige Versionen des Demonstrators ist der Einsatz jedoch durchaus möglich. 3.4 Bestehende Navigationsdienste 3.4.1 Forschungsprojekte Die letzten Jahre brachten im Bereich der mobilen Navigationsdienste einige interessante Forschungsprojekte hervor. Während spezielle Navigationsdienste für Mountain-Biker bisher noch nicht betrachtet wurden, trat vermehrt eine andere Art mobiler Navigationsdienste in den Vordergrund. Dabei handelt es sich um mobile Touristenführer (Tour Guides). Sie basieren auf einer ähnlichen Zielsetzung wie der MoBiLe-Service. Informationen über Forschungsprojekte in diesen Bereichen liefern neben den einzelnen Forschungsgruppen auch [BCK 04, KrBa 03, ChKo 00]. 40 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE Cyberguide Cyberguide [LKAA 96, AAH+ 97] ist einer der ersten mobilen Navigationsdienste. Entwickelt wurde er von der Future Computing Environment (FCE) Gruppe am Georgia Institute of Technology. Seine Entstehung geht auf Forschungsaktivitäten im Bereich kontextsensitiver Dienste zurück, wobei bei Cyberguide nur Ortsinformationen als Kontextinformationen genutzt werden. Cyberguide besteht aus vier einzelnen unabhängigen Komponenten: das Kartensystem, das Informationssystem, das Ortungssystem und das Kommunikationssystem. Das Kartensystem generiert Karten mit Hilfe des Informationssystems. Die Position des Nutzers wird durch das Ortungssystem geliefert und ebenfalls in der Karte dargestellt. Bei Bedarf kann die Nutzerposition mittels Pushing bei einer Positionsveränderung automatisch in der Karte aktualisiert werden. Das Informationssystem liefert Beschreibungen zu PoIs. Über das Kommunikationssystem können Nachrichten ausgetauscht oder hinterlassen werden. Das Kommunikationssystem bietet auch die Möglichkeit, Nachrichten für alle registrierten Nutzer zu hinterlassen. Das Ortungsverfahren liefert Ortsinformationen mit Hilfe von GPS oder an der Zimmerdecke montierten Infrarotsendern für den Betrieb innerhalb von Gebäuden. Da das System nur bedingt Zugriff auf externe Informationen hat (nur durch lokale PANs), müssen alle für die Navigation nötigen Informationen lokal auf dem Endgerät verfügbar sein. Dies schränkt die Erweiterbarkeit und Funktionalität des Systems stark ein. Da das System keinerlei Routenwissen besitzt, kann eigentlich nicht von einem vollwertigen Navigationsdienst im Sinne dieser Arbeit gesprochen werden. Die eigentliche Routenführung wird vollständig auf den Nutzer übertragen. Der einzige Vorteil für den Nutzer ist die automatische Positionsbestimmung und deren Anzeige in der Karte. Eine Bezeichnung als Kartendienst mit Ortungsfunktion trifft die Funktionalität des Cyberguides besser als die Bezeichnung als Navigationsdienst. GUIDE GUIDE [CDMF 00, CDM+ 00] ist ein Forschungsprojekt der Universität Lancaster. Ein Prototyp wurde innerhalb Lancaster als mobiler Touristenführer eingesetzt. Der Dienst wird lokal auf einem Tablet-PC oder PDA ausgeführt. Alle Informationen wie Ortsinformationen, PoI-Informationen oder Öffnungszeiten von Museen, Kirchen, etc. werden durch WLAN-Netze auf das mobile Endgerät übertragen. Nachteil dieses Verfahrens sind die hohen Kosten und der hohe Aufwand zur Bereitstellung einer flächendeckenden WLAN-Infrastruktur. Durch Caching auf dem mobilen Endgerät ist auch ein eingeschränkter Betrieb ohne WLAN-Verbindung möglich. Dies setzt aber eine geschickte Prognose der in Zukunft benötigten Informationen voraus. Zur Präsentation dienen ausschließlich Kartenausschnitte, die an die aktuelle Position angepasst sind. LoL@ LoL@: Local Location Assistant [PKK , PUM 02, UPNM ] ist ein Projekt des Forschungszentrums Telekommunikation Wien mit dem Ziel der Entwicklung eines mobilen elektronischen Touristenführers für die Wiener Innenstadt. LoL@ stellt dazu eine Menge vordefinierter Routen und die Möglichkeit, eigene Routen zu planen, bereit. Neben der Navigation zwischen einzelnen PoIs und der Navigation von einem beliebigen Standort zum Anfang der Route, kann der Nutzer detaillierte Informationen zu den PoIs abfragen. LoL@ ist in einer 3-Tier-Struktur konzipiert, die die Präsentation und einen Teil der Dienstlogik auf dem Endgerät implementiert, während der Großteil der Dienstlogik in der Infrastruktur liegt. Der Datenbestand wird durch verschiedenste Datenbanken und durch das vom 3GPP spezifizierte Gateway Mobile Location Center (GMLC) [3gp a] geliefert. Über das GMLC können Ortsinformationen des Nutzers abgefragt werden. Das GMLC abstrahiert das eingesetzte Ortungsverfahren, das durch einen hybriden Ansatz aus GPS und Cell-Id realisiert wird. LoL@ wurde größtenteils in Java implementiert und nutzt HTTP als Verbindungsprotokoll, in dem die Medien in HTML oder WML eingebettet sind. Zur Präsentation dient in erster 3.4. BESTEHENDE NAVIGATIONSDIENSTE 41 Linie der Browser auf dem mobilen Endgerät, der Karteninhalte mit der eingezeichneten Route und zusätzlichen PoI-Informationen anzeigt. Im Gegensatz zu LoL@ soll der MoBiLe-Service dieser Arbeit nicht auf die Kartendarstellung fokussiert sein, sondern eine Vielzahl verschiedener Präsentationsformen unterstützen. Die Kartendarstellung tritt dabei eher in den Hintergrund, da sie für den Nutzer einen hohen kognitiven Aufwand mit sich bringt und nur bedingt für die Mountain-Bike-Navigation geeignet ist. Zusätzlich wird in LoL@ ein push-basierter Ansatz angedacht (vgl. [PSM 01]). Hierfür wird das GMLC dazu veranlasst periodische Ortsinformationen an den Navigationsdienst zu senden. Dieser überprüft dann, ob eine relevante Änderung der Ortsinformationen stattgefunden hat. Falls ja, wird eine Karte mit der aktuellen Position an das mobile Endgerät gesendet. Dieser Ansatz unterliegt dem Problem, dass die Prüfung, ob es sich um eine relevante Veränderung der Ortsinformationen handelt, nicht an der Stelle durchgeführt wird, an der die Ortsinformationen generiert werden. Dadurch müssen in erster Linie sehr viele Daten übertragen werden und außerdem kann es vorkommen, dass Ortsinformationen übertragen werden, die keine für die Dienstausführung relevanten Änderungen enthalten. Sinnvoll wäre deshalb die Prüfung in Richtung der Generierung der Ortsinformationen zu verlagern. Deep Map Das Projekt Deep Map [MaZi 00, Mala 99, Kray 03] des European Media Lab ist ein mobiler Touristenführer der Stadt Heidelberg. Deep Map bietet dem Nutzer unter anderem Dienste wie Routenplanung, Navigation oder Hotelbuchung an. Der Fokus fällt dabei vor allem auf die Nutzerinteraktion (z.B. durch den Einsatz multilingualer Spracheingabemöglichkeiten) und die Informationsbereitstellung durch verschiedenste Datenbanken. Die Architektur von Deep Map basiert auf einem Multiagentensystem. Deep Map betrachtet dabei zwei Nutzungsvarianten, die die Verteiltheit der Agenten bestimmen. Diese sind der web-basierte Touristenführer für zuhause (Routenplanung, virtuelle Stadtbesichtigung, etc.) und der mobile Touristenführer für unterwegs (Navigation, Bereitstellung diverser Informationen). Dazu sind die Agenten sowohl auf dem mobilen Endgerät als auch auf stationären Rechnern lauffähig und interagieren über den Remote Procedure Call (RPC) oder die Middleware CORBA. Die Deep Map Architektur kann in drei Schichten eingeteilt werden, die aus verschiedensten Agenten aufgebaut sind. Diese Schichten sind das Interface-Layer für die Interaktion mit dem Nutzer, das CognitiveLayer für die Aufbereitung der Nutzerinteraktion und das Knowledge-Layer für die Verwaltung und Bereitstellung verschiedenster Informationen. Einer der wichtigsten Agenten ist der SISTO-Agent (vgl. [Kray 03]). Der SISTO-Agent übernimmt die zentrale Stelle des Gesamtsystems. Er ist verantwortlich für das Routenmanagement, das (Reverse-)Geocoding, die Navigation, die Ortung, die Karteninteraktionen, die Informationsakquisition und viele weitere Aufgaben. Für die Ortung wird ein dreistufiger Ansatz genutzt, der zuerst prüft ob Ortsinformationen geliefert werden können, gegebenenfalls dann den Cache nach zwischengespeicherten Ortsinformationen befragt und falls nötig Ortsinformationen von Sensoren anfordert. Dieser Ansatz ist für eine pull-basierte Lösung konzipiert. Eine push-basierte Lösung wird durch die Integration von Location-Triggered Actions verwirklicht. Für diese ist sowohl das Betreten sowie das Verlassen von Regionen als Initiierungsvorschrift angedacht. Zusätzlich können Time-Triggered Actions und eine Kombination, so genannte Spatio-Temporal-Triggered Actions, eingesetzt werden. Eine genauere Betrachtung der Initiierungsvorschriften, sowie der dafür vorgesehenen Agenten, erfolgt leider nicht. Durch Time-Triggered Actions und die Auswertung von Ortsinformationen wird in Deep Map versucht, die derzeitigen Bewegungsgründe des Nutzers zu bestimmen (z.B. Einkaufsbummel, Stadtbesichtigung). Diese Art der Ortung greift weit in die Privatsphäre des Nutzers ein und muss deshalb mit höchster Vorsicht behandelt werden. Innerhalb des Prototyps von Deep Map kommunizieren verteilte Agenten über WLAN oder GSM. Die Ortung erfolgt in der Regel über (D-)GPS. Für die mobile Nutzung wird ein Wearable Computer“ eingesetzt, ” der unter anderem aus einem Farbdisplay und einem Headset besteht. Ein Einsatz für herkömmliche mobile Endgeräte ist nicht vorgesehen. 42 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE Zusammenfassung Leider unterliegen die meisten dieser Forschungsprojekte veralteten Annahmen. Eine oft gemachte Annahme ist zum Beispiel, die Funktionsunfähigkeit von GPS innerhalb von Gebäuden. Moderne GPSEmpfänger und vor allem A-GPS-Empfänger zeigen aber, dass eine Ortung mit GPS nicht nur unter freiem Himmel stattfinden kann. GPS-Empfänger der nächsten Generation werden voraussichtlich sehr verlässliche Ortsinformationen auch innerhalb von Gebäuden und sogar unter der Erde liefern können (vgl. [glo a, sir ]). Eine andere Annahme der Ortung ist, dass GPS-Empfänger unhandliche externe Geräte sind, die zur Ortung ständig mitgeführt werden müssen. Heutige externe GPS-Empfänger haben jedoch nur noch Ausmaße von wenigen Zentimetern oder sind sogar in andere Geräte vollständig integriert. Aufgrund sicherheitspolitischer Anforderungen in den USA (E-911), Japan und Europa (E-112) kann sogar erwartet werden, dass in Zukunft in einem Großteil der Mobiltelefone GPS-Empfänger integriert sein werden. Einige Forschungsprojekte gehen von total unzuverlässigen MAN-Verbindungen aus. Die moderne Technik zeigt aber, dass diese Verbindungen bereits ein hohes Maß an Zuverlässigkeit liefern. Die Netzabdeckung innerhalb Deutschlands ist bereits nahe 100 Prozent (vgl. [gsm ]) und auch Regionen, die ursprünglich keine Netzabdeckung erhalten sollten, werden immer geringer. Als Beispiel kann die Luftfahrt genannt werden. Voraussichtlich wird hier in wenigen Jahren auch innerhalb von Flugzeugen der Zugriff auf MANs möglich sein. Eine weitere Einschränkung der Forschungsprojekte ist, dass sie nicht auf die Anforderungen des MoBiLeServices ausgerichtet sind. Nur wenige gehen zum Beispiel auf die stark fluktuierende Geschwindigkeit oder auf geringe Aufnahme- und Verarbeitungszeiten ein. Deshalb stellen die vorgestellten Projekte keine adäquate Lösung für den MoBiLe-Service dar. 3.4.2 Kommerzielle Navigationsdienste Neben diesen Forschungsprojekten brachten die letzten Jahre einige kommerzielle Navigationsdienste hervor. Besonders bekannt sind Navigationsgeräte für PKWs. Diese werden in der Regel fest in die Fahrzeuge eingebaut und erfüllen nur den Zweck der Navigation. Ein weiteres Beispiel für Navigationsdienste, welche ebenfalls auf speziell dafür konzipierten Geräten genutzt werden, sind mobile Navigationsgeräte der Firma Garmin oder Magellan. Sie sind hauptsächlich für sportliche Anwender wie zum Beispiel Wanderer konzipiert. In letzter Zeit wurden ebenfalls einige Navigationsdienste auf den Markt gebracht, die nicht nur auf speziell dafür ausgerichteten Geräten ausgeführt werden können. Geräte dieser Dienste sind zum Beispiel Mobiltelefone oder PDAs. Das folgende Kapitel zeigt einige dieser kommerziellen Navigationsdienste im Detail. Navigationsdienste für dedizierte Geräte Fahrzeugnavigationsgeräte Fahrzeugnavigationsgeräte sind dedizierte Geräte für die Navigation von Fahrzeugen. Ihre Aufgabe ist es, den Fahrzeugführer durch Navigationsinformationen bei der Wegfindung zu unterstützen. Die ersten Fahrzeugnavigationssysteme in Deutschland wurden von Bosch und Philipps Mitte der 80er Jahre entwickelt (vgl. [Czom 00]. Heutzutage gibt es eine Vielzahl von Navigationsgeräten verschiedenster Anbieter. Oft werden sie bereits bei der Fahrzeugproduktion integriert. Die Ortung des Fahrzeugs erfolgt durch GPS. Da viele GPS-Empfänger aber derzeit noch keine verlässlichen Ortsinformationen innerhalb von Tunnels oder in anderen empfangsschwachen Gebieten liefern, wird das Ortungssystem meist durch weitere Sensorinformationen unterstützt. Diese werden zum Beispiel durch Radsensoren, durch das Tachosignal, durch einen traditionellen Kompass oder einen Kreiselkompass geliefert. Durch ein erweitertes Kalman-Filter können aus den unabhängig generierten Sensorinformationen die benötigten reliablen Ortsinformationen erzeugt werden. Fahrzeugnavigationssysteme beherrschen meist eine Präsentation von Navigationsinformationen mit Pfeilen, die durch die Angabe von Straßennamen und Entfernungen erweitert werden. Um den Fahrzeugführer nicht unnötig abzulenken, ist in der Regel auch eine verbale Präsentation möglich. Zusätzlich bieten einige 3.4. BESTEHENDE NAVIGATIONSDIENSTE 43 Systeme eine Kartendarstellung an, die sich dynamisch mit der Bewegung verändert. Routendienste für die Berechnung dynamisch generierter Routen sind bereits in den Navigationsgeräten integriert (Onboard-Navigation). Die dazu nötigen Pfadinformationen befinden sich meist auf einer austauschbaren CD-ROM. Das Datenformat ist in der Regel im so genannten Geographic Data File (GDF) Format [gdf 96] und wird zum Beispiel von NAVTEQ [nav ] geliefert. Dynamische Verkehrsinformationen werden bei vielen Geräten über den Radio Data System Traffic Message Channel (RDS TMC-Kanal) in die Routenberechnung mit einbezogen. Leider sind derartige Systeme nur als bedingt mobil anzusehen, da sie nur eine Mobilität in Verbindung mit dem Fahrzeug liefern. Sie können überall dort genutzt werden, wo eine Bewegung des Fahrzeugs möglich ist. Erste Systeme, die ein einfaches Entfernen des Navigationssystems aus dem Fahrzeug erlauben, werden derzeit entwickelt. Eine Anwendung der Fahrzeugnavigationsgeräte ist aufgrund der unterschiedlichen Anforderungen und Eigenschaften für den MoBiLe-Service nicht denkbar. Mobile Navigationsgeräte Dedizierte echt-mobile“ Geräte zur Navigation zeichnen sich dadurch aus, ” dass sie speziell für die mobile Navigation angefertigt wurden und nur zur Navigation genutzt werden können. Hersteller sind zum Beispiel Garmin [gar ] oder Magellan [mag ] (vgl. Abb. 3.7). Die Geräte verfügen über einen integrierten (D-)GPS-Empfänger und ein Display. Durch eine drahtgebundene Kommunikationsmöglichkeit lassen sich Routen in einem proprietären Datenformat auf das Endgerät laden. Durch den integrierten GPS-Empfänger kann die Position innerhalb der Route bestimmt werden und dadurch der zukünftige Routenverlauf auf dem Display (z.B. in Pfeildarstellung) angezeigt werden. Zusätzliches Kartenmaterial ermöglicht eine Kartendarstellung. Abbildung 3.7: Garmin eTrex und Magellan SporTrak Durch ständige Ortung ist es außerdem möglich, Routen während der Bewegung aufzuzeichnen und diese später wieder zu verwenden oder auf ein anderes Gerät zu übertragen. Zudem sind diese Geräte je nach Anwendungszweck mit zusätzlichen Funktionen wie einem Kompass, einem Terminplaner oder Taschenrechner ausgestattet. Normalerweise besitzen sie aber keine drahtlose Kommunikationsmöglichkeit und erlauben deshalb während des mobilen Einsatzes keine Aktualisierung des Datenbestandes und keine Beachtung dynamischer Informationen (z.B. Verkehrsinformationen). Geräte, wie der Garmin eTrex oder der Magellan SporTrak, werden in heutiger Zeit vermehrt für das Mountain-Biken eingesetzt. Nachteilig ist aber, dass sie meist einer sehr rigiden Navigation unterliegen und deshalb keine Anpassung an verschiedene Transportarten erfolgen kann. Anforderungen des MoBiLeService werden nur bedingt umgesetzt. Dedizierte Navigationsgeräte haben außerdem einen weiteren Nachteil. Aufgrund der Tatsache, dass viele Mountain-Biker für den Notfall ihr Mobiltelefon mitführen, müssen bei der Navigation durch dedizierte Navigationsgeräte zwei Geräte transportiert werden, obwohl im Grunde genommen heutige Mobiltelefone alle Anforderungen für Navigationsdienste erfüllen. Navigationsdienste für Mobiltelefone werden deshalb im folgenden Kapitel genauer betrachtet. 44 KAPITEL 3. STAND DER TECHNIK MOBILER NAVIGATIONSDIENSTE Navigationsdienste für Mobiltelefone/PDAs Moderne Mobiltelefone zeichnen sich gegenüber ihren Vorgängern durch höhere Rechenleistung, mehr Speicher, längere Akkulaufzeiten, etc. aus. Vor allem aber bieten sie eine immer größere Unterstützung zur Integration für Anwendungen von Drittanbietern. Derzeit sind bereits einige Navigationsdienste für PDAs oder Mobiltelefone auf dem Markt, die sich mehr oder weniger stark unterscheiden. Die bekanntesten Repräsentanten sind NavMe von b2motion, ActivePilot von Falk/Jentro, Mobile Navigator von Wayfinder, Mobile 2005 von Route66 und Mobile 5 von TomTom (zur Übersicht vgl. [Zieg 04, Nieb 04, Hell 04] und Tabelle 3.1 / 3.2). Name NavMe ActivePilot Mobile Navigator Mobile 2005 Mobile 5 Hersteller b2motion Falk/Jentro Wayfinder Route 66 TomTom Plattform J2ME J2ME mit CLDC1.0, MIDP2.0, JABWT, (LAPI) Symbian Symbian S60 Symbian S60 oder Windows Mobile Tabelle 3.1: Kommerzielle mobile Navigationsdienste Der NavMe [b2m ] ist ein Navigationsdienst von b2motion für Mobiltelefone und PDAs. Der Navigationsdienst läuft im Gegensatz zum Routendienst vollständig lokal auf dem mobilen Endgerät. Dies entspricht einer Offboard-Lösung. Der Routendienst liefert dynamisch generierte Routen, deren Pfade von Webraska [web ] geliefert werden. Zur Routenabfrage können PoIs aus 41 Rubriken (z.B. Tankstellen, Flughäfen, Raststätten) verwendet werden. Die letzten fünf Routen können lokal als statische Routen gespeichert werden. Zur Abfrage der Route wird entweder GPRS oder UMTS eingesetzt. Leider kann der Navigationsdienst nur über das spezielle GPS-Empfangsmodul eine automatische Ortung durchführen. Das GPSEmpfangsmodul kann aber nur bei Festeinbau in Fahrzeuge genutzt werden. Daraus ergibt sich eine pullbasierte Navigationslösung außerhalb von Fahrzeugen. Bei der Nutzung innerhalb von Fahrzeugen können über das Autoradio dynamische Verkehrsinformationen über den RDS TMC-Kanal empfangen und in die Routenwahl einbezogen werden. Der ActivePilot [act ] von Falk/Jentro ist ein auf J2ME mit CLDC 1.0, MIDP 2.0 und JABWT aufbauender Navigationsdienst. Insgesamt (Code + Bilder/Sprachdaten) hat er eine Größe von ca. 750 Kilobyte und kann zum Beispiel per GPRS auf das mobile Endgerät übertragen werden. Mit einem einfachen GPSEmpfänger mit Bluetooth-Schnittstelle kann über JABWT auf Ortsinformationen zurückgegriffen werden. Der Navigationsdienst befindet sich komplett auf dem mobilen Endgerät, der Routendienst auf einem stationären Rechner (Offboard-Lösung). Der Routendienst liefert dynamisch generierte Routen, deren Pfade von NAVTEQ [nav ] geliefert werden. Wie bei NavMe kann die Routenabfrage PoIs enthalten. Durch die Routenabfrage wird aber keine komplette Route zum Navigationsdienst auf dem mobilen Endgerät übertragen, sondern immer nur Routensegmente. Diese werden jeweils dynamisch unter Einbeziehung von Verkehrsinformationen generiert. So ist gewährleistet, dass die Routensegmente an die aktuelle Verkehrslage angepasst sind. Ausschlaggebend ist an dieser Stelle natürlich die Länge der Routensegmente. Zur Präsentation der Navigationsinformationen setzt der ActivePilot sowohl Sprache als auch eine 2D-Pfeildarstellung (mit Zusatzinformationen) und seit der aktuellen Version auch eine 2D-Karte ein. Der Navigationsdienst Mobile Navigator [mob ] von Wayfinder hat einen ähnlichen Funktionsumfang wie der ActivePilot, basiert aber auf Symbian OS. Zusätzliche Funktionen sind die geschwindigkeitsabhängige Kartenvergrößerung und die Möglichkeit Kartenmaterial bereits vor Routenantritt auf das mobile Endgerät zu laden. Das Kartenmaterial kann zum Beispiel von einem stationären Rechner über eine Dockingstation oder mittels Bluetooth auf das mobile Endgerät übertragen werden. Dadurch spart sich der Nutzer Gebühren bei der Routenauswahl, da das Kartenmaterial nicht über die GPRS-Verbindung übertragen werden muss. Im Navigationsdienst Mobile 2005 [rou ] von Route 66 wurde eine Onboard-Lösung realisiert. Auf dem mobilen Endgerät ist deshalb neben dem Navigationsdienst auch ein Routendienst integriert. Für die Speicherung aller Pfadinformationen für Deutschlands Straßen sowie 700.000 PoIs ist ein Speicherplatz von 256 Megabyte nötig. Die Daten stammen von NAVTEQ. Derzeit können nur Mobiltelefone mit einer extra 45 3.4. BESTEHENDE NAVIGATIONSDIENSTE Name NavMe On-/Offboard Offboard Kommunikation GPRS/UMTS ActivePilot Offboard GPRS/UMTS Mobile Navigator Offboard GSM/GPRS Mobile 2005 Onboard − (GPRS) Mobile 5 Onboard − Präsentation 2D-Pfeil+ 2D-Karte Sprache 2D-Pfeil+ 2D-Karte Sprache 2D-Pfeil 2D-Karte Sprache 2D-Pfeil+ 2D-Karte Pseudo-3D Sprache 2D-Pfeil+ 2D-Karte Pseudo-3D Tabelle 3.2: Eigenschaften kommerzieller mobiler Navigationsdienste Speicherkarte derart viel Speicherplatz aufbringen. Mobile 2005 ist auf Mobiltelefonen mit Symbian Serie 60 ausführbar und beherrscht als Darstellungsformen zusätzlich zu der bereits genannten Pfeildarstellung und Sprachausgabe auch die Möglichkeit Pseudo-3D-Karten darzustellen. Dabei kann der Blickwinkel frei gewählt werden. Dynamische Verkehrsinformationen können via GPRS in die Routenberechnung integriert werden. Der Navigationsdienst Mobile 5 [tom ] von TomTom ist ähnlich aufgebaut wie der Mobile 2005. Er setzt ebenfalls auf die Onboard-Lösung und benötigt dazu auch eine mindestens 256 Megabyte große Speicherkarte. Mobile 5 kann auf Mobiltelefonen mit Symbian Serie 60 und Windows Mobile eingesetzt werden. Außerdem besitzt Mobile 5 eine spezielle Option für Radfahrer, die die Routengenerierung an die Anforderungen der Radfahrer anpasst. Die oben beschriebenen mobilen Navigationsdienste für Mobiltelefone/PDAs zeigen bereits eine große Funktionsvielfalt. Keines dieser Systeme beachtet aber die Anforderungen an den MoBiLe-Service. Manche Navigationsdienste ermöglichen zwar die Wahl des Transportmittels, verändern hierbei aber nur die Routengenerierung. Einflüsse anderer Transportmittel ergeben sich aber nicht nur bei der Routengenerierung, sondern auch innerhalb des eigentlichen Navigationsprozesses. Dies wird leider von keinem der genannten Navigationsdienste berücksichtigt. Kapitel 4 Architektur Das Kapitel Architektur“ behandelt die Konzeption des Location-based Push-Services. Aufgrund des Um” fangs und der Komplexität des Gesamtsystems ist die Umsetzung in die Realität nicht als trivial anzusehen und benötigt deshalb eine detaillierte Planung der Architektur. Ziel dieses Kapitels ist es den Aufbau des Systems mit all seinen Subsystemen, Abhängigkeiten der einzelnen Subsysteme, sowie Verteilung der Subsysteme auf Hardwareentitäten, zu beschreiben. Außerdem soll vermittelt werden, wieso ein derartiger Aufbau Sinn macht und wie sich einzelne Entscheidungen begründen lassen. 4.1 Aufbau Eine Architektur beschreibt den strukturellen Aufbau eines Gesamtsystems. Während das Bauingenieurwesen sich um den Aufbau von Gebäuden, Straßen, etc. kümmert, ist die Aufgabe der Softwarearchitektur die Konzeption eines komplexen Softwaresystems. Ein wesentlicher Schritt Softwaresysteme (aber auch Systeme anderer Bereich) zu strukturieren, in einzelne Konzepte zu gliedern (vgl. [Dijk 76]) und sie so begreifbar zu machen, ist die Klassifikation des Systems anhand bestimmter Klassifikationskriterien. Dieser Vorgang wird auch als Modularisierung bezeichnet und kann auf verschiedensten Abstraktionsstufen erfolgen (vgl. [PCW 84]). 4.1.1 Generelle Architekturkonzepte Auf einer hohen Abstraktionsstufe ist ein grundlegendes Klassifikationskriterium die Kohärenz. Dadurch werden Module des Softwaresystems anhand ihrer semantisch-inhaltlichen Zusammengehörigkeit in Module eingeteilt. Nachfolgend werden angelehnt an [PCW 84, GaSh 93, MTSM 03] einige allgemeine Architekturkonzepte für diese Module kurz beschrieben. Einer der wichtigsten Gründe für die Modularisierung und die daraus entstehenden Module ist als Se” paration of Concerns“ [Dijk 76] bekannt. Die Modularisierung soll dazu dienen, ein komplexes, schwer verständliches Gesamtsystem in einzelne einfacher verständliche Module aufzuspalten. Ziel ist es demnach, leicht verständliche Module zu schaffen, die unabhängig von anderen Modulen begreifbar sind (vgl. [PCW 84]). Dazu ist eine geringe Kopplung zwischen den Modulen nötig. Eine geringe Kopplung wird durch die Minimierung der Abhängigkeiten zwischen den einzelnen Modulen erzeugt. Abhängigkeiten entstehen, wenn ein Modul über ein gewisses Grundwissen hinaus auf Wissen eines anderen Moduls angewiesen ist. Das Ergebnis der Modularisierung ist demnach optimal, wenn daraus eine Menge an stark kohärenten Modulen mit geringer Kopplung resultiert. Ein Vorteil der Modularisierung ist die Wiederverwendbarkeit der Module. Wiederverwendbarkeit bedeutet hierbei, dass einzelne Module innerhalb eines anderen Kontextes wieder eingesetzt werden können. Dadurch wird eine Minimierung redundanter Funktionalität erzeugt. Außerdem wird die Fehlerrate gesenkt 46 47 4.1. AUFBAU und Konsistenz gewahrt. In direktem Zusammenhang mit der Wiederverwendbarkeit steht die Erweiterbarkeit. Durch die Modularisierung können Module nicht nur leicht wiederverwendet werden, sondern auch einfacher erweitert werden. Die Erweiterung der Funktionalität eines Moduls muss dadurch bei mehrfachem Auftreten nur einmal durchgeführt werden. Wieder wird die Fehlerrate gesenkt und Konsistenz gewahrt. Außerdem können bei Einhaltung der ursprünglichen Schnittstellen keine intermodularen Fehler durch die Erweiterung entstehen. Ebenfalls in direktem Zusammenhang steht der Vorteil der Substituierbarkeit. Durch den modularen Aufbau können einzelne Module einfach ersetzt werden. Bedingung hierfür ist die Einhaltung der Schnittstellen des ursprünglichen Moduls. Die Substituierbarkeit führt zu einer einfachen Anpassung des Gesamtsystems durch das Ersetzen einzelner Module. Dies führt zu einer hohen Flexibilität des Gesamtsystems. Durch Komposition einzelner Module kann das Gesamtsystem sehr flexibel an Veränderungen angepasst werden. Anpassung betrifft dabei nicht das Gesamtsystem, sondern nur einzelne Module. Aus der Flexibilität folgt außerdem eine einfache Reaktion auf Fehler, die meist nur einzelne Module betreffen. Fehler innerhalb von Modulen können durch die Modularisierung einfacher gefunden und behoben werden. Die Modularisierung führt demnach auch zu einer verbesserten Wartbarkeit und Verlässlichkeit des Gesamtsystems. Um einzelne Module nicht im Vorhinein an spezielle Plattformen zu binden, ist eine plattformunabhängige Umsetzung sinnvoll. So kann erst zu einem späterem Zeitpunkt oder gar zur Laufzeit entschieden werden, auf welcher Plattform das Modul ausgeführt werden soll. 4.1.2 Modularisierung Betrachtet man für die Modularisierung den in Kapitel 2.1 beschriebenen Navigationsprozess, so ergeben sich hieraus drei funktionale Module. Ein Modul ist zuständig für die Ortung und Initiierung der Routenführung. Anhand der durch die Ortung gelieferten Ortsinformationen muss geprüft werden, ob eine Routenführung angestoßen werden soll. Dieses Modul wird im Folgenden mit Dienstinitiierung bezeichnet. Das zweite Modul ist für die Routenführung. Die Routenführung ist für die Generierung von Navigationsinformationen verantwortlich. Dazu wird aus einer Menge deklarativen Wissens (Routenwissen, Ortsinformationen des Nutzers, Nutzereigenschaften oder andere Kontextinformationen) eine Navigationsinformation generiert, die dem Nutzer die zum Zeitpunkt der Ausführung bestmögliche Orientierungshilfe bereitstellt. Dieses Modul wird im Folgenden mit Dienstausführung bezeichnet. Schließlich präsentiert ein drittes Modul die oben generierte Navigationsinformation dem Nutzer. Um sie dem Nutzer zu übermitteln, muss sie in eine geeignete Form gebracht werden. Verschiedenste grafische oder verbale Darstellungen sind Beispiele derartiger Präsentationsformen. Ziel ist, dem Nutzer die Information in einer Form zu übermitteln, die am bestmöglichen seinen derzeitigen Anforderungen entspricht. Dieses Modul wird im Folgenden mit Dienstpräsentation bezeichnet. Die Dienstinitiierung (Service Initiation), Dienstausführung (Service Application) und Dienstpräsentation (Service Presentation) stellen die essentiellen Bestandteile der LBPS-Architektur dar (vgl. Abb. 4.1). Service Initiation Service Application Service Presentation Abbildung 4.1: Klassifikation anhand Kohärenzkriterium Vorteil des Aufbaus ist die strikte Modularisierung der Teilbausteine. Während sich die Dienstinitiierung nur darum kümmert, den Dienst zum bestmöglichen Zeitpunkt anzustoßen, ist die Dienstausführung alleine für die Informationsgenerierung verantwortlich. Die Vermittlung der generierten Information übernimmt ausschließlich die Dienstpräsentation. Aus diesem Aufbau resultiert eine leichte Substituierbarkeit, 48 KAPITEL 4. ARCHITEKTUR Erweiterbarkeit, Wartbarkeit der einzelnen Module, sowie hohe Flexibilität des Gesamtsystems. 4.1.3 Schichtenstruktur Wie man bereits erkennen kann, ist es möglich, zwischen den einzelnen Modulen Abhängigkeitsrelationen anzugeben. Die Dienstinitiierung nutzt die Dienstausführung zur Generierung des Mehrwertes, und die Dienstausführung nutzt die Dienstpräsentation, um dem Nutzer das Ergebnis zu übermitteln. Diese Abhängigkeit beschreibt die reguläre Abhängigkeitsstruktur der Module. In Einzelfällen kann es auch vorkommen, dass Abhängigkeiten entgegengesetzt ihrer ursprünglichen Richtung eintreten. So zum Beispiel, wenn die Dienstpräsentation eine bestimmte Information nicht verarbeiten kann und deshalb die Dienstausführung nutzt, um alternative Informationen zu erhalten, oder die Dienstausführung die Dienstinitiierung nutzt, um die Initiierungsvorschrift zu ändern. Es existiert jedoch keine direkte gegenseitige Abhängigkeit zwischen Dienstpräsentation und Dienstinitiierung. Letztes Element in der beschriebenen Abhängigkeitsstruktur ist der Nutzer selbst. Er wartet während der Dienstnutzung darauf, dass ihm Informationen zugestellt werden. Diese Aufgabe übernimmt die Dienstpräsentation. Sie nutzt die menschliche Wahrnehmung, um dem Nutzer die Informationen zu vermitteln, die er sich durch die Dienstnutzung erhofft. Ein derartiges Konzept, in dem einzelne Module in einem gerichteten, linearen Abhängigkeitsverhältnis stehen, führt zu einer Schichtenstruktur (vgl. Abb. 4.2 und [BMR+ 96]). Eine Schicht (engl. Layer) in ihrer ursprünglichen Form ist ein logischer Baustein, der einen Dienst einer darunter liegenden Schicht nutzt, um so einen Dienst der darüber liegenden Schicht anzubieten (vgl. [GaSh 93]). Presentation Application Initiation Abbildung 4.2: Schichtenaufbau der LBPS-Architektur Diese Sichtweise bezieht sich jedoch auf Pull-Dienste. Im Gegensatz dazu nutzen Push-Dienste, wie in Kapitel 2.2 beschrieben, den Dienst einer darüber liegenden Schicht, um einen Dienst der darunter liegenden Schicht anzubieten. Im Fall der Navigationsdienste nutzt die Schicht der Dienstinitiierung die Schicht der Dienstausführung und diese dann die Dienstpräsentation, um letztendlich mit Hilfe der menschlichen Wahrnehmung dem Nutzer die Navigationsinformation zu übermitteln. 4.1.4 Middleware Integration Im vorigen Kapitel wurde bereits beschrieben, dass innerhalb der Dienstpräsentation verschiedenste Präsentationsformen zum tragen kommen können. Für die Navigation stehen hier zum Beispiel eine grafische Pfeildarstellung, eine grafische Landkartendarstellung oder eine verbale Richtungsangabe zur Verfügung. Die Schicht der Dienstpräsentation unterteilt sich deshalb in verschiedene unabhängige Präsentatoren, die spezifische Präsentationsformen verwirklichen. Mehrere Präsentatoren können dabei parallel existieren. Innerhalb des Navigationsdienstes können dadurch grafische Richtungsanweisungen durch kongruente verbale Anweisungen unterstützt werden. 49 4.1. AUFBAU Gleiches gilt für die Dienstinitiierung. Hier können diverse Initiatoren parallel existieren. Beispiele sind positionsabhängige Initiatoren oder Initiatoren, die zusätzlich zu positionsabhängigen auch richtungsabhängige Initiierungsvorschriften verwalten können. Desweiteren können verschiedene Initiatoren mit unterschiedlichen Genauigkeiten und Verzögerungen arbeiten oder bestimmte Initiatoren nur für spezifische Personengruppen einsetzbar sein. Möglich wäre an dieser Stelle natürlich auch die Initiierung bezüglich jeglicher anderer Kontextinformation, wie Zeit, Wetter oder Ortskenntnis des Nutzers. Diese Art von Kontextinformationen soll hier allerdings nicht im Vordergrund stehen. Abbildung 4.3 a) zeigt eine Applikation mit drei Präsentatoren und drei Initiatoren. Allgemein besteht zwischen Präsentatoren, Applikation und Initiator eine n:1:m-Beziehung. Darunter wird verstanden, dass die Navigationsapplikation n Präsentatoren und m Initiatoren hat. Aufgrund des Abhängigkeitsverhältnisses zwischen Dienstausführungsschicht und Dienstpräsentationsschicht muss die Dienstausführungsschicht wissen, welche Präsentatoren verfügbar sind, welche Eigenschaften diese besitzen und wie sie angesprochen werden. All diese Informationen bzw. Funktionen müssen innerhalb der Dienstausführungsschicht verfügbar sein. Bei einer großen Anzahl an Präsentatoren erhöht sich der Aufwand für den Zugriff auf die Dienstpräsentationsschicht innerhalb der Dienstausführungsschicht deshalb enorm. Äquivalentes gilt für die Dienstinitiierungsschicht. Um Initiierungsvorschriften in den Initiatoren zu ändern, greift die Dienstausführungsschicht entgegen der eigentlichen Abhängigkeitsstruktur auf die Dienstinitiierungsschicht zu. Dazu braucht die Dienstausführungsschicht Kenntnis über alle verfügbaren Initiatoren, deren Eigenschaften und deren Zugriffsmöglichkeiten. Wie bei der Dienstpräsentationsschicht kann bei einer Vielzahl an Initiatoren ein enormer Aufwand für den Zugriff auf die Dienstinitiierungsschicht innerhalb der Dienstausführungsschicht entstehen. a) b) Presentation Presentation Presentation Presentation Presentation Presentation Presentation Middleware Application Application Initiation Middleware Initiation Initiation Initiation Initiation Initiation Initiation Abbildung 4.3: Middleware Integration Zur Lösung dieses Problems dienen zwei zusätzliche Schichten, die als Middleware fungieren. Die Initiierungsmiddleware (Initiation Middleware) liegt zwischen Dienstinitiierungsschicht und Dienstausführungsschicht und abstrahiert über die verschiedenen Initiatoren. Die Präsentationsmiddleware (Presentation Middleware) liegt zwischen Dienstausführungsschicht und Dienstpräsentationsschicht und abstrahiert verschiedene Präsentatoren (vgl. Abb. 4.3 b). Aufgabe der Präsentationsmiddleware ist es, der Dienstausführungsschicht eine einheitliche Schnittstelle für die Präsentation von Nutzerinformationen zu liefern. Die Kenntnis über entsprechende Präsentatoren ist in der Präsentationsmiddleware gekapselt. Sie weiß, welche Präsentatoren derzeit verfügbar sind, welche Präsentationsformen diese darstellen können, welche sonstigen Restriktionen zu beachten sind und wie auf die Präsentatoren zugegriffen werden kann. Die von der Dienstausführungsschicht übermittelten Navigationsinformationen werden durch die Präsentationsmiddleware für die jeweilige Präsentationsform angepasst und anschließend an die entsprechenden Präsentatoren übermittelt. Werden von der Dienstausführungsschicht Initiierungsvorschriften, die die Dienstausführung auslösen sollen, generiert, müssen diese an die entsprechenden Initiatoren verteilt werden. Diese Aufgabe übernimmt die Initiierungsmiddleware. Sie nimmt Initiierungsvorschriften entgegen, passt sie gegebenenfalls den zuständigen Initiatoren an und übermittelt sie schließlich an diese. Dazu hat sie Kenntnis über alle 50 KAPITEL 4. ARCHITEKTUR verfügbaren Initiatoren, deren Fähigkeiten, Eigenschaften und deren Zugriffsmöglichkeiten. Ein weiterer Vorteil, der sich aus der Integration der Middlewareschichten ergibt, wird bei der Erweiterung der Dienstausführungsschicht sichtbar. Prinzipiell ist diese nicht an Navigationsapplikationen gebunden. Es ist ebenso gut möglich, andere Applikationen in der Dienstausführungsschicht zu platzieren. Denkbar sind hier Dienste, wie der in Kapitel 2.2 vorgestellte ortsbasierte Email-Push-Dienst, der Emails nur bei örtlicher Relevanz zustellt. Initiierungsvorschriften für einen derartigen Dienst müssten dann zum Beispiel die Position des Büros spezifizieren und der entsprechende Initiator so die Dienstausführung bei örtlicher Nähe zum Büro anstoßen. Die Applikation selektiert daraufhin alle Emails, die an die Firmenadresse gerichtet sind und teilt diese dem Nutzer mittels eines entsprechenden Präsentators mit. Insgesamt ergibt sich so eine n:k:m-Beziehung zwischen Initiatoren, Applikationen und Präsentatoren. Abbildung 4.4 zeigt zwei Applikationen, für deren Initiierung drei Initiatoren bereit stehen und deren Präsentation durch drei Präsentatoren ermöglicht wird. Presentation Presentation Presentation Presentation Middleware Application Application Initiation Middleware Initiation Initiation Initiation Abbildung 4.4: LBPS-Architektur mit mehreren Applikationen Diese Arbeit fokussiert Applikationen für die Navigation. Die Fähigkeit, andere Dienste wie den ortsbasierten Email-Push-Dienst auf einfache Art und Weise zu integrieren, zeigt aber, dass dieser Aufbau nicht zwingend auf Navigationsdienste beschränkt ist, sondern ebenso eine Vielzahl anderer Push-Dienste mit Hilfe der Architektur realisierbar ist. 4.2 Schichtenmodell Dieses Kapitel beschreibt detailliert die im vorigen Kapitel identifizierten Schichten Dienstinitiierung, Initiierungsmiddleware, Dienstausführung, Präsentationsmiddleware und Dienstpräsentation in Hinblick auf Navigationsdienste. Dabei soll hier nicht auf spezielle Ausprägungen der einzelnen Schichten eingegangen werden, sondern allgemein die Funktionsweise der Schichten erörtert werden. Eine Betrachtung spezieller Initiatoren, Präsentatoren, etc. folgt in Kapitel 5, in dem die Implementierung des Demonstrators beschrieben wird. 4.2.1 Dienstinitiierung Wie bereits in vorigem Kapitel erwähnt wurde, ist die Dienstinitiierungsschicht die unterste Schicht dieses Schichtenmodells und verantwortlich dafür, die Dienstausführung anzustoßen. Entscheidende Fragestellungen sind, was eine Dienstinitiierung ausmacht und wann diese durchzuführen ist. Ausschlaggebend sind auf der einen Seite die in den Initiierungsvorschriften spezifizierten Anforderungen der Dienstausführung, d.h. in diesem Fall der Navigationsapplikation, und andererseits die realen Gegenwerte dieser Anforderungen. Die realen Werte werden durch physische oder logische Sensoren erfasst. Sensoren liefern zu bestimmten 4.2. SCHICHTENMODELL 51 Zeitpunkten oder kontinuierlich Messwerte. Im Rahmen dieser Arbeit werden diskrete Zeitpunkte vorausgesetzt, an denen Messwerte aktualisiert werden. Dies ist keine Beschränkung der Allgemeinheit, da eine Diskretierung bei kontinuierlichen Aktualisierungen durch Abtastung des Messwertes zu diskreten Zeitpunkten erreicht werden kann. Die gemessenen Werte stehen dann den Anforderungen für die Initiierung der Applikation gegenüber. Durch die Auswertung der Initiierungsvorschrift und der Messwerte wird bestimmt, ob die Dienstausführung initiiert werden soll oder nicht. Hierbei besteht eine enge Kopplung zwischen Sensoren und der Komponente, die die Auswertung der Initiierungsvorschriften durchführt. Andere Ansätze sehen an dieser Stelle eine sehr lose Kopplung und separieren die Auswertungskomponente von den Sensoren. In diesem Zuge erfolgt eine Integration der Auswertungskomponente in die Dienstausführungsschicht mit dem Resultat, dass bei einer hohen Aktualisierungsfrequenz der Sensorinformationen, diese in häufigen Abständen zur Auswertungskomponente befördert werden müssen. Dadurch entsteht ein reger Informationsaustausch zwischen dem Sensormodul und der Dienstausführungsschicht, die nun für die Auswertung zuständig ist. Oft ist ein intermodularer Informationsaustausch aber mit Kosten verbunden und sollte deshalb vermieden werden. Wird ein Informationsaustausch bei jeder Aktualisierung von Sensorinformationen angestoßen, ist dies oft unnötig, da die Informationen nie zum Einsatz kommen, bzw. aus der Auswertung keine Dienstinitiierung erfolgt. Um dem entgegenzuwirken, wurden einige Strategien entwickelt, die diesen Informationsaustausch optimieren [LeRo 00, KüTr 05]. Im Bereich der Location-based Services sind diese Strategien unter Location-Update-Strategien bekannt. Einige Beispiele sind zeitbasierte, distanzbasierte oder zonenbasierte Location-Update-Strategien. Sie bewirken, dass der Informationensaustausch zwischen den Modulen nicht mehr bei jeder Aktualisierung erfolgt, sondern nur noch wenn bestimmte Zeitpunkte erreicht werden, wenn sich die Position um eine bestimmte Distanz verändert hat oder wenn eine Zone betreten oder verlassen wird. Dadurch wird versucht, nur noch Sensorinformationen zur Dienstausführungsschicht zu befördern, aus denen nach der Auswertung eine Dienstausführung resultiert. Diese Arbeit versucht der Problematik aus dem Weg zu gehen, indem die Auswertungskomponente an die Sensoren gekoppelt wird. Durch die enge Kopplung entfällt die Problematik des unnötigen intermodularen Informationsaustausches, da sich der Informationsaustausch zwischen Sensoren und Auswertungskomponente nur innerhalb der Dienstinitiierungsschicht vollzieht (intramodularer Informationsaustausch). Alle Aktualisierungen von Sensorinformationen werden an die Auswertungskomponente geliefert, die sich wie die Sensoren innerhalb der Dienstinitiierungsschicht befindet. Folgt aus der Auswertung eine Dienstinitiierung, wird die Dienstausführungsschicht mittels einer Initiierungsnachricht darüber informiert. Dieser Vorgang reduziert den intermodularen Informationsaustausch auf das Nötigste. Durch diese Art der Initiierung ergibt sich ein weiterer Vorteil. Wird die Dienstausführung ohne Nutzung von Ortsinformationen durchgeführt (z.B. ortsbasierter Email-Push-Dienst), werden zwischen den Sensoren und der Dienstausführung keinerlei Ortsinformationen ausgetauscht. Bei einer Dienstinitiierung innerhalb der Dienstausführungsschicht würden Ortsinformationen in die Dienstausführungsschicht befördert, um den Dienst gegebenenfalls anzustoßen. Diese würden aber nicht bei der Dienstausführung eingesetzt, was zu einem unnötigen Informationsaustausch führen würde. Diese Art von Diensten fallen in die Kategorie Location-based Push - Conventional Execution (vgl. Kapitel 2.2). Für diese Kategorie optimiert der hier verfolgte Ansatz zudem die Menge an ausgetauschten Ortsinformationen. Einen ähnlichen Aufbau verfolgt auch das Spatial Subscription Model von [CCR 03]. Dort werden Spatial Predicates an so genannte Mobile Location Agents gesendet und von diesen ausgewertet. Mobile Location Agents stellen im Kontext dieser Arbeit Initiatoren dar. Werden die registrierten Prädikate erfüllt, so erfolgt eine Benachrichtigung. Dies entspricht der Dienstinitiierung, die im Rahmen dieser Arbeit eingesetzt wird. Leider sind in [CCR 03] derzeit nur distanz- und zonenbasierte Spatial Predicates möglich, welche zur Realisierung des MoBiLe-Service nicht ausreichen. Eine Analyse der Initiierungsvorschriften des MoBiLe-Service wird im Folgenden behandelt. Trigger Initiierungsvorschriften spezifizieren Anforderungen für die Initiierung des Dienstes. Eine einfache Anforderungen für die Initiierung des Navigationsdienstes ist das Überlagern der Nutzerposition mit einem Aktionspunkt. Reale Messgrößen für die Nutzerposition können beispielsweise durch einen GPS-Empfänger 52 KAPITEL 4. ARCHITEKTUR erzeugt werden. GPS-Empfänger führen in der Regel periodische Aktualisierungen, zum Beispiel in Sekundenintervallen, durch. Durch die Bewegung des Dienstnutzers verändert sich dessen Position bis die Anforderungen der Dienstinitiierung mit der gemessenen Position übereinstimmen. Durch die Auswertung der Initiierungsvorschrift und der Messwerte wird diese Konstellation automatisch erkannt und die Navigationsapplikation ohne Zutun des Nutzers angestoßen. Derart einfache Anforderungen werden zum Beispiel in [Brow ] in Form von Notes eingesetzt. Durch Notes werden sowohl Initiierungsvorschriften als auch Messgrößen definiert. Dazu werden wie bei den Spatial Predicates von [CCR 03] Key-Value-Paare eingesetzt. Der Key gibt die Art der Messgröße und der Value den Wert an, den diese Messgröße annimmt oder annehmen soll. Die Dienstinitiierung wird ausgelöst, wenn gemessene Key-Value-Paare mit den Key-Value-Paaren der Initiierungsvorschrift übereinstimmen. Genauer gesagt, muss für jedes Feld F innerhalb eines Notes N, das den selben Namen wie eine Messgröße besitzt, der Wert von F mit dem Wert des entsprechenden Messwertes übereinstimmen. Eine Übereinstimmung resultiert bei Gleichheit der beiden Werte oder falls der Messwert innerhalb des in der Initiierungsvorschrift spezifizierten Intervalls liegt. Der Dienstinitiierungsnachricht werden zusätzlich alle Key-Value-Paare angehängt, die bei der Übereinstimmung nicht eingesetzt wurden. Ein Note der Initiierungsvorschrift kann damit wie folgt aussehen (Beispiel aus [Brow ]): <location> Westgate <temperature> 10..30 <body> This is the Westgate Stehen dieser Initiierungsvorschrift die folgenden Messwerte gegenüber: <location> Westgate <temperature> 25 wird die Dienstinitiierung mit diesem Key-Value-Paar ausgelöst: <body> This is the Westgate [Brow ]s Notes fanden in zahlreichen Projekten Anwendung, die sich von Touristenführern über ökologische bis hin zu archäologischen Anwendungen erstreckten. [Brow ] sieht in dieser einfachen Art der Dienstinitiierung bereits ein sehr breites Feld an Anwendungsgebieten. Probleme bei der Beschreibung von Initiierungsvorschriften mit Key-Value-Paaren treten jedoch auf, wenn man komplexe Initiierungsvorschriften definieren will. Derartige komplexe Anforderungen können bei Navigationsdiensten auftreten. Es ist nämlich nicht praktikabel, nur bei einer exakten Übereinstimmung der Nutzerposition mit dem Aktionspunkt den Dienst zu initiieren. Ein wesentlicher Nachteil ist, dass sich der Nutzer, um eine Navigationsinformation zu erhalten, genau auf den definierten Aktionspunkt bewegen muss, was vor allem auch wegen der Ungenauigkeit der Messwerte in der Realität (vgl. Kapitel 3.1) schwer realisierbar ist. Desweiteren besitzt dieser Ansatz auch eine beschränkte Sinnhaftigkeit, da eine Navigationsinformation nicht erst genau an der Stelle des Aktionspunktes nötig ist, sondern bereits in einem gewissen Abstand davor, um vom Nutzer noch rechtzeitig wahrgenommen und umgesetzt werden zu können. Der Aktionspunkt muss also um einen Aktionskreis erweitert werden (vgl. Abb. 4.5). Befindet sich die Nutzerposition innerhalb dieses Aktionskreises, d.h. ist der Abstand zwischen Nutzerposition und Aktionspunkt unterhalb eines bestimmten Schwellwertes, muss der Dienst initiiert werden. Dies kann durch Key-Value-Paare nur bedingt umgesetzt werden. Problem ist, dass ein Key-Value-Paar nur eine Messgröße mit einem bestimmten Wert oder Intervall spezifizieren kann. Zur Spezifikation von Aktionskreisen müssen innerhalb einer Anforderungsspezifikation mehrere Messgrößen in Betracht gezogen werden. Entscheidend ist der Abstand zum Aktionskreismittelpunkt, d.h. die Relation zwischen Abstand auf der x-Achse und dem Abstand auf der y-Achse. Dazu müssen neben Vergleichsoperationen mathematische Operationen auf die Messgrößen anwendbar sein. Durch das Zulassen mehrerer Messgrößen und mathematischer Operationen innerhalb einer Anforderungsspezifikation wird eine stärkere Ausdruckskraft erreicht. Der Aktionskreis mit dem Radius r um den Ursprung könnte so mittels folgendem Ausdruck dargestellt werden (x bzw. y stellen den Abstand bzgl. der x- bzw. y-Achse zwischen Nutzer und Aktionskreismittelpunkt innerhalb eines kartesischen 2D-Koordinatensystems dar): x2 + y 2 ≤ r2 53 4.2. SCHICHTENMODELL r Abbildung 4.5: Aktionskreis um Aktionspunkt mit Aktionsradius r Jedoch stellt sich die Frage, wie groß der Radius r gewählt werden muss. Bei genauerer Betrachtung stellt man fest, dass eine Vielzahl an Parametern für die Bestimmung des Radius herangezogen werden muss. [ZiAr 02] nennt unter anderem das physische Befinden des Nutzers (abhängig von Alter, Fitness, etc.), das Wetter (z.B. Regen, Schnee, Nebel), die Ortskenntnis des Nutzers, Umgebungsstruktur (z.B. bergig oder flach, bebaut oder unbebaut) und die Steigung der Umgebung. Neben all diesen Einflussparametern, gibt es eine noch nicht genannte Einflussgröße, die vor allem beim Mountain-Biken von Interesse ist. Dies ist die Geschwindigkeit des Nutzers. Mountain-Biker sind stark fluktuierenden Geschwindigkeiten ausgesetzt. Bergauf bewegen sie sich zeitweise mit weniger als 3 Stundenkilometern, bergab hingegen können über 60 Stundenkilometer erreicht werden. Die Dauer bis zum Erreichen des Aktionspunktes kann bei einem Radius von 5 Metern also zwischen 0,6 und 12 Sekunden annehmen. Während 0,6 Sekunden zur Wahrnehmung und Umsetzung der Richtungsänderung in den meisten Fällen zu kurz sein dürfte, sind 12 Sekunden dafür zu lange. t sei im Folgenden der Wert, der eine adäquate Dauer für die Wahrnehmung und Umsetzung der Richtungsänderung repräsentiert. Die Lösung des Problems ist, den Radius des Aktionskreises an die Fahrgeschwindigkeit v anzupassen. Folgender logischer Ausdruck setzt dies um: x2 + y 2 ≤ (t · v)2 Der Ausdruck beschreibt einen Kreis, dessen Radius abhängig von der Geschwindigkeit v ist. Er macht es möglich, dass die Informationen über die Richtungsänderung zu einem Zeitpunkt zugestellt werden, der dem Nutzer den für ihn besten Nutzen bietet. In diesem Fall sind dies t Sekunden vor Erreichen des Aktionspunktes. Nach Auflösen von x und y erhält man letztendlich den logischen Ausdruck, der den Anforderungen des MoBiLe-Service entspricht: (ux − ax )2 + (uy − ay )2 ≤ (t · v)2 Die Position des Aktionspunktes a wird hier durch (ax , ay ) und die Position des Nutzer durch (ux , uy ) beschrieben. Befindet sich der Nutzer außerhalb des Aktionskreises, so liefert die Auswertung, dass der Ausdruck nicht wahr ist. Wenn der Nutzer innerhalb des Aktionskreises ist, wird der Ausdruck als wahr ausgewertet. Doch zu welchem Zeitpunkt muss der logische Ausdruck überhaupt ausgewertet werden? Eine Veränderung der Auswertung kann nur bei einer Veränderung der Initiierungsvorschrift oder der Messwerte eintreten. In diesem Szenario kann davon ausgegangen werden, dass die Initiierungsvorschrift relativ statisch ist und die Messwerte demgegenüber häufigeren Änderungen unterliegen. Deshalb spielt die Veränderung der Messwerte die entscheidende Rolle für den Zeitpunkt der Auswertung. [Brow ] bezeichnet diesen Fall, in dem sich Messwerte wesentlich häufiger ändern als die Initiierungsvorschrift, als Information Filtering im Gegensatz zu Information Retrieval. Wie bereits beschrieben, werden Messwerte durch Sensoren generiert. Sie werden zu diskreten Zeitpunkten von den Sensoren zur Verfügung gestellt. Eine vereinfachende Annahme dieser Arbeit ist, dass alle nötigen Messwerte gleichzeitig bereitgestellt werden. Zu diesen Zeitpunkten kann eine Änderung bei der Auswertung des logischen Ausdrucks eintreten und dadurch eine Dienstinitiierung nötig werden. Folglich kann jede Veränderung von Messwerten eine Veränderung des Auswertungsergebnisses nach sich ziehen. Deshalb müsste nach jeder Veränderung eines Messwertes der logische Ausdruck ausgewertet werden. Jedoch muss 54 KAPITEL 4. ARCHITEKTUR nicht jede Veränderung von Messwerten für die Auswertung relevant sein. So sind zum Beispiel in obiger Initiierungsvorschrift Sensoren vertreten, die Positions-, Geschwindigkeits- und Richtungsinformationen liefern. Eine Veränderung von Richtungsinformationen zieht in Anbetracht des MoBiLe-Service keinerlei relevanter Ereignisse nach sich und ist nicht im logischen Ausdruck enthalten. Für die Auswertung muss eine Veränderung der Richtungsinformation nicht beachtet werden. Die Geschwindigkeit hingegen ist Bestandteil des logischen Ausdrucks. Eine Veränderung stellt aber für die Auswertung keine aktive Rolle dar, da eine Veränderung der Geschwindigkeit des Dienstnutzers bei Navigationsdiensten in der Regel keine direkten Auswirkungen auf die Dienstinitiierung hat. Ganz anders ist es bei den Positionsinformationen. Verändert sich die Position des Nutzers, so kann es sein, dass er sich in den Aktionskreis bewegt hat und der Dienst deshalb initiiert werden muss. Folglich muss nach einer Aktualisierung der Positionsinformationen die Initiierungsvorschrift ausgewertet und darauf gegebenenfalls der Dienst initiiert werden. Für Dienste der Kategorie Location-based Push - Conventional Execution (vgl. Kapitel 2.2) sind dann zur Dienstausführung keine weiteren Ortsinformationen mehr nötig. Für die Kategorie Location-based Push Location-based Execution werden zur Dienstausführung jedoch Ortsinformationen benötigt. Diese müssen nicht zwingend mit den Ortsinformationen, die für die Initiierung verantwortlich waren, übereinstimmen. Werden sie aber von den Sensoren der Dienstinitiierung bereitgestellt, können sie von diesen abgefragt oder analog zu [Brow ] bei der Dienstinitiierung mitgeliefert werden. [Brow ] liefert bei der Dienstinitiierung alle Key-Value-Paare mit, die für die Übereinstimmung der Initiierungsvorschrift mit den Messgrößen nicht nötig waren. Problem dieses Ansatzes ist aber, dass manche Dienste genau die Werte benötigen, die bei der Übereinstimmung relevant waren. Dies gilt vor allem bei komplexeren Bedingungen, bei denen nicht direkt klar ist, welcher genaue Messwert die Übereinstimmung ausgelöst hat. Außerdem liefern Sensoren, wie GPS-Empfänger, eine Vielzahl an Messwerten (vgl. Kap. 3.1), von denen nur ein Bruchteil für die Dienstausführung von Interesse ist. Als sinnvoll stellt sich an dieser Stelle deshalb eine detaillierte Angabe aller Messgrößen, die für die Dienstausführung benötigt werden, heraus. Diese werden dann an die Initiierungsnachricht angehängt und sind so bei jeder Dienstausführung verfügbar. Die in den letzten Absätzen definierten Aspekte für die Dienstinitiierung sind auch unter dem Begriff Trigger ([Brow , HLP , SAW 94]) bekannt. ECA-Regeln Desweiteren braucht man einen Mechanismus, der das abstrakte Konstrukt des Triggers operationalisierbar macht. Die Ausdruckskraft von Key-Value-Paaren reicht an dieser Stelle nicht aus. Auch die in XML serialisierten Kontext-Trigger aus [SMLP ] sind für diesen Anwendungszweck nur bedingt geeignet, da ihnen die Möglichkeit fehlt, relevante Messgrößen für den Auswertungszeitpunkt zu spezifizieren, und Aktionen nicht an Trigger gebunden sind. Ein Mechanismus aus einem ganz anderen Bereich sind ECA-Regeln [sql 99, HLP ]. ECA-Regeln stammen aus dem Bereich der Datenbanken und beschreiben Ereignisse (Events), bei deren Eintreten eine Bedingung (Condition) ausgewertet und dann gegebenenfalls eine Aktion (Action) ausgeführt wird. ECARegeln bestehen demnach aus drei Teilen: den Ereignissen, der Bedingung und den Aktionen. Während die Bedingung nur einmal auftritt, können Ereignisse und Aktionen in beliebiger Anzahl enthalten sein. Ereignisse definieren die Menge an Messwerten, die bei einer Aktualisierung eine Auswertung der Bedingung nötig machen. Das heißt, dass sobald eine Aktualisierung der Messwerte erfolgt ist und der Messwert ein Element der Ereignismenge ist, die Bedingung ausgewertet werden muss. Im Normalfall, jedoch nicht zwingend, sind diese Messwerte als freie Variable in der Bedingung enthalten. So zum Beispiel bei der Navigation: Wird eine Aktualisierung der Positionsinformationen durch den Sensor gemeldet, so wird in der Bedingung geprüft, ob die Position innerhalb des Aktionskreises liegt. Desweiteren muss in einer ECA-Regel die Bedingung angegeben werden, die maßgeblich für das Auslösen der Aktion ist. Bedingungen werden hier durch logische Ausdrücke operationalisiert, die Variablen für Messwerte besitzen. Jeder Variablen muss daher ein Typ zugeordnet werden, der dem Typ eines Messwertes entspricht. Liefert ein GPS-Empfänger Latitudenwerte im WGS84-Format und die Bedingung enthält eine Variable mit eben diesem Typ, so muss die Variable in Folge der Auswertung durch den gelieferten Messwert ersetzt werden. Desweiteren können innerhalb des logischen Ausdrucks mathematische Standardoperationen, wie die Addition, Subtraktion, Multiplikation und Division, und Vergleichsoperato- 4.2. SCHICHTENMODELL 55 ren, wie =, ! =, <, <=, > und >=, genutzt werden. Hilfreich sind außerdem weitere Operationen wie Potenzieren und Radizieren, sowie trigonometrische Funktionen (Sinus, Kosinus, Tangens, Arcus-Sinus, Arcus-Kosinus, Arcus-Tangens). Zur Verknüpfung einzelner logischer Ausdrücke sind Boole’sche Operatoren (AND, OR, NOT) sinnvoll. Die Auswertung der logischen Ausdrücke liefert entweder true oder false. Eine gültige Bedingung ist beispielsweise N OT (3 + 5/2 < sqrt(33 )) Die Auswertung dieser Bedingung ergibt stets true. Eine Bedingung, die für den Demonstrator in Frage kommt, ist die oben definierte Bedingung: (ux − ax )2 + (uy − ay )2 < (t · v)2 Durch die Möglichkeit Bedingungen durch derartige Ausdrücke zu spezifizieren, lassen sich allerdings weit mehr als diese Bedingung angeben. Einige Beispiele hierfür folgen später in dieser Arbeit. Wurde eine Bedingung ausgewertet, muss danach geprüft werden, ob das Ergebnis eine Aktion nach sich zieht. Dabei muss für jede Aktion festgelegt werden, ob sie bei einer wahren oder unwahren Bedingung ausgeführt werden soll, und ob sie nur ein einziges Mal ausgeführt werden soll oder bei jeder Auswertung mit diesem Resultat. Aktionen stellen in diesem Anwendungsszenario Dienstinitiierungen dar. So wird zum Beispiel bei Eintreten obiger Bedingung (mit einem fest definierten Aktionspunkt) der MoBiLe-Service angestoßen. Gegebenenfalls benötigt dieser aber zur Ausführung Ortsinformationen des Dienstnutzers. Diese können entweder von den Sensoren ex post abgefragt werden oder bereits bei der Dienstinitiierung mitgeliefert werden. Dazu muss es Aktionen geben, die es ermöglichen, eine Reihe von Messwerten an die Dienstinitiierungsnachricht anzuhängen. Dass eine derartige Initiierung durchgeführt werden muss und welche Messwerte angehängt werden sollen, muss in der jeweiligen ECA-Regel verankert werden. Die zu Beginn dieses Kapitels vorgestellten Location-Updates, die keine Dienste initiieren, sondern eine Aktualisierung von Sensorinformationen vornehmen, können ebenfalls mit ECA-Regeln spezifiziert werden. Oben aufgeführte Beispiele für Location-Updates sind simple, zeitbasierte/periodische, distanzbasierte oder zonenbasierte Location-Updates. All diese Strategien sind auch auf ECA-Regeln abbildbar. So nutzen simple Location-Updates, die bei jeder Veränderung der Sensorinformationen eine Aktualisierung anstoßen, Positionsinformationen als Ereignisse der ECA-Regeln. Die Bedingung ist grundsätzlich wahr und als Aktion wird eine Dienstinitiierung mit angehängten Positionsinformationen spezifiziert. Folglich wird bei jeder Aktualisierung der Sensorinformationen die Aktion, d.h. das Location-Update, ausgelöst. Anders ist es bei den zeitbasierten/periodischen Triggern. Hier basiert das Ereignis nicht mehr auf Positionsinformationen, sondern auf Zeitinformationen. Durch Bedingungen werden Zeitpunkte bzw. Zeitintervalle, bei denen Location-Updates durchzuführen sind, festgelegt. An die Aktionen werden wieder Positionsinformationen angehängt. Distanzbasierte Trigger sind ähnlich zu den zeitbasierten/periodischen Triggern. Jedoch beinhalten Ereignisse hier Positionsinformationen und die in den Bedingungen spezifizierten Intervalle beziehen sich auf Positionsinformationen und sind dementsprechend Distanzen. Verändern sich Positionsinformationen um bestimmte Distanzen, so wird das Location-Update ausgelöst. Hier muss es innerhalb der ECA-Regeln die Möglichkeit geben, auf Messwerte der letzten Aktion zugreifen zu können. Dies könnte zum Beispiel innerhalb einer Aktion abgebildet werden, die die letzten Messwerte speichert und für zukünftige Bedingungen verfügbar macht. [KüTr 05] geben schließlich noch zonenbasierte Trigger an. Die Ereignisse dieser Trigger basieren ebenfalls auf Positionsinformationen, Bedingungen hingegen definieren feste Zonen. Befinden sich die Positionsinformationen innerhalb dieser Zone, wird das Location-Update initiiert. Zonenbasierte Trigger lassen sich also ebenfalls mit ECA-Regeln geeignet darstellen. 4.2.2 Initiierungsmiddleware Um einerseits von der Dienstausführungsschicht generierte Trigger an adäquate Initiatoren zu verteilen und andererseits Dienstinitiierungen entgegenzunehmen und dann die Dienstausführung anzustoßen, wurde zwischen Dienstinitiierungsschicht und Dienstausführungsschicht eine Middlewareschicht integriert, die Applikationen der Dienstausführungsschicht einen transparenten Zugriff auf die Initiatoren ermöglicht. 56 KAPITEL 4. ARCHITEKTUR Gleiches gilt für den Zugriff von Initiatoren der Dienstinitiierungsschicht auf die entsprechende Applikation. Die Initiierungsmiddleware übernimmt demnach die Kommunikation zwischen Dienstinitiierung und Dienstausführung. Dazu kennt sie alle Initiatoren, deren Fähigkeiten und Schnittstellen. Will eine Applikation einen Trigger setzen, so übergibt sie den Trigger an die Initiierungsmiddleware, welche dann nach einem entsprechenden Initiator sucht und bei erfolgreicher Suche den Trigger an den Initiator weiterleitet. Gegebenenfalls kann der Trigger auch entsprechend angepasst werden, um von einem Initiator angenommen zu werden. So ist es zum Beispiel denkbar, dass der Trigger Positionsinformationen im Gauß-Krüger-Format enthält, es aber nur einen Initiator für Positionsinformationen im WGS84Format gibt. Die Initiierungsmiddleware kann dann eine Umrechnung der Gauß-Krüger-Koordinaten in WGS84-Koordinaten durchführen. Sind bei der Dienstinitiierung Messwerte in einem bestimmten Format enthalten, zur Dienstausführung werden diese jedoch in einem anderen Format erwartet, so können sie (falls möglich) ebenfalls in der Initiierungsmiddleware in das benötigte Format transformiert werden. 4.2.3 Dienstausführung Die Dienstausführung ist für die eigentliche Mehrwertgenerierung verantwortlich. Sie kapselt die Dienstlogik und ist deshalb spezialisiert auf einen Geschäftsprozess. Bei der Dienstausführung wird aus einer Menge an Eingabewerten ein Ausgabewert erzeugt und mittels der Dienstpräsentation dem Nutzer übermittelt. Angestoßen wird die Dienstausführung durch die Dienstinitiierung. Bei richtiger Wahl der Trigger sorgt die Dienstinitiierung dafür, dass ein Dienst zum richtigen Zeitpunkt ausgeführt wird, was im Grunde genommen schon einen deutlichen Mehrwert gegenüber der manuellen Dienstinitiierung durch den Nutzer bei Pull-Diensten erzeugt. Eine Applikation, die hier im Vordergrund stehen soll, ist die Navigationsapplikation. Sie übernimmt die Aufgabe, dem Nutzer Navigationsinformationen zur Wegfindung bereitzustellen. Genau genommen übernimmt sie den Teilprozess Routenführung“. Dazu bestimmt sie aus den aktuellen Ortsinformationen und ” der zugrunde liegenden Route die im Moment der Ausführung einzuschlagende Richtung. Damit dies an den richtigen Positionen geschieht, setzt die Navigationsapplikation entsprechende Trigger, die relevante Anforderungen für die Dienstinitiierung spezifizieren, in der Dienstinitiierungsschicht ab, um dann im richtigen Augenblick tätig zu werden. Wie diese Trigger erzeugt werden, soll im Folgenden behandelt werden. Triggergenerierung In Kapitel 2.1 wurde bereits auf Routen eingegangen. Routen dienen als essentieller Eingabewert für die Mehrwertgenerierung in Navigationsdiensten der Wegfindung. Während Navigationsdienste der Lokomotion nicht zwingend Routen als Basis der Mehrwertgenerierung benötigen, kann ein Navigationsdienst für die Wegfindung nur mittels Routen ordnungsgemäß funktionieren. Routen werden von Routendiensten erzeugt, verwaltet und bereitgestellt. Der im Rahmen dieser Arbeit konzipierte und implementierte Routendienst ist im Anhang A beschrieben. Er liefert an einer wohldefinierten Schnittstelle Routenbeschreibungen in der Form einer geordneten Liste von Aktionspunkten, wobei jeder Aktionspunkt seine Koordinaten und die Austrittsrichtung (vgl. Kapitel 2.1) kennt. Ausgehend von der Routenbeschreibung, genauer gesagt von der geordneten Liste von Aktionspunkten, werden die zu erzeugenden Trigger in der Form von ECA-Regeln abgeleitet. Wie Bedingungen dieser Trigger aufgebaut sein können, wurde bereits in vorigem Kapitel angesprochen. Da das Betreten eines Aktionskreises nur durch die Veränderung des eigenen Standortes geschehen kann (oder das Verändern des Aktionskreises, was vorerst ausgeschlossen wird), sind Ereignisse der ECA-Regeln Positionsveränderungen. Als Aktion wird die Dienstinitiierung genutzt. Nachdem für jeden Aktionspunkt ein geeigneter Trigger erzeugt wurde, werden diese mittels der Initiierungsmiddleware an die Dienstinitiierungsschicht übergeben. Dieser Vorgang kann entweder vollständig in einem Zug geschehen oder es wird nur ein einzelner Trigger oder eine Teilmenge an Triggern sukzessiv 4.2. SCHICHTENMODELL 57 übertragen. Letzteres hat den Vorteil, dass die Menge der (quasi-)parallel auszuwertenden Trigger in der Dienstinitiierungsschicht besser gesteuert werden kann. Je nach Bedarf kann zum Beispiel nur der nächste Trigger aus der Liste der Aktionspunkte in die Dienstinitiierungsschicht eingefügt werden. Zu Beginn der Route ist demnach nur der Trigger des ersten Aktionspunktes vorhanden, bei Erreichen dieses Aktionspunktes wird dann der entsprechende Trigger durch den Trigger des in der Route folgenden Aktionspunktes ersetzt. Dadurch muss stets nur ein Trigger ausgewertet werden. Natürlich ist es auch möglich, anstatt einzelner Trigger, Teilmengen der Trigger in die Dienstinitiierungsschicht einzufügen. Sinnvoll wäre hier zum Beispiel, die n nächsten Trigger der Route zu wählen, um resistent gegen Verzögerungen innerhalb des Systems zu sein und ein Überspringen einzelner Trigger zu ermöglichen. Nachteil dieses Verfahrens ist der erhöhte Verwaltungsaufwand und Signalisierungsverkehr, der durch die vermehrt auftretenden Nachrichten zum Setzen neuer Trigger zwischen Dienstausführungsschicht und Dienstinitiierungsschicht entsteht. Routenführung Nachdem die Trigger in der Dienstinitiierungsschicht eingefügt wurden, ist der Dienst bereit zur Ausführung. Kommt es zur Dienstausführung, kann anhand der ID des Triggers, der die Dienstausführung angestoßen hat, dieser eindeutig identifiziert werden. Durch die ID kann die Navigationsapplikation daraufhin feststellen, an welchem Aktionspunkt der Route sich der Dienstnutzer befindet, und die entsprechende Navigationsinformation generieren. Hat die Navigationsapplikation die Route lokal vorliegen, so erhält sie die entsprechende Richtungsänderung durch Suche des Aktionspunktes in der Routenbeschreibung. Verbleibt die Route innerhalb des Routendienstes, muss dieser kontaktiert werden, um die Richtungsänderung für diesen Aktionspunkt zu erhalten. Ergebnis ist in beiden Fällen ein Hinweis auf die weiterführende Route. Dieser kann, wie bereits in Kapitel 2.2 dargestellt, zum Beispiel in Form der allozentrischen Austrittsrichtung aus dem Aktionspunkt vorliegen. Der im Anhang A beschriebene Routendienst liefert derartige Hinweise in Form einer Winkelangabe zum geografischen Norden als Referenzrichtung. Abbildung Diese Winkelangabe liefert zwar einen eindeutigen Hinweis auf die weiterführende Route, ist aber für den Menschen schwer in die Realität umzusetzen. Die Abbildung als Teilprozess der Navigation erleichtert dem Menschen die Umsetzung in die Realität. Eine weitere Aufgabe der Navigationsdienste ist daher diese Abbildung. Dazu wird die abstrakte Information, die aus der Routenbeschreibung gewonnen wurde, in eine Information abgebildet, die dem Nutzer präsentiert und leicht von ihm umgesetzt werden kann. Daraus ergeben sich zwei Betrachtungen der Abbildung. Erstere bezieht sich auf technische Gegebenheiten. Hierunter fällt vor allem welche Präsentationsformen überhaupt technisch möglich sind und wie diese am besten innerhalb eines Mediums aufbereitet werden. Die zweite Betrchtung bezieht sich auf die Reduktion des kognitiven Aufwandes. Dazu zählt die Wahl der Darstellungsform, die für den Nutzer leicht aufzunehmen und zu verarbeiten ist, und die Aufbereitung des Inhaltes. Die Aufgabe der Abbildung übernimmt sowohl die Dienstausführung, wie auch die Präsentationsmiddleware. Da die Präsentationsmiddleware Kenntnis über alle verfügbaren Präsentatoren und deren Eigenschaften besitzt, übernimmt diese Schicht die Abbildung anhand technischer Gegebenheiten. Die Abbildung anhand des kognitiven Aufwandes wird in der Dienstausführungsschicht durchgeführt. Da es sich meist um spezifische Applikationen handelt, die für ihren Geschäftsprozess spezifische Darstellungsformen besitzen, kann diese Abbildung nur innerhalb der Dienstausführungsschicht durchgeführt werden. Für die Abbildung ist Detailwissen notwendig, welches nicht innerhalb anderer Schichten verfügbar ist und aufgrund der Menge, Komplexität und womöglich Vertraulichkeit auch nicht verfügbar gemacht werden kann. Zum Beispiel hat eine Navigationsapplikation wesentlich andere kognitive Einflussfaktoren als der bereits erwähnte ortsbasierte Email-Push-Service. Während in der Navigationsapplikation versucht wird, eine Darstellung zu wählen, deren Inhalt wenig kognitiven Aufwand für den Nutzer bedeutet, ist bei der ortsbasierten EmailPush-Applikation eine Beachtung des kognitiven Aufwandes relativ unwichtig. Darstellungsformen, die im Bereich der Navigationsapplikation einen hohen Stellenwert besitzen, sind grafische (Kartenausschnitte oder Pfeildarstellungen), textuelle und verbale Darstellungen von Richtungsände- 58 KAPITEL 4. ARCHITEKTUR rungen. Diese unterscheiden sich mehr oder weniger stark durch den bei der Wahrnehmung entstehenden kognitiven Aufwand. Dieser Aufwand resultiert aus der Aufnahme und der Verarbeitung der Navigationsinformation. Verschiedene Darstellungsformen erzeugen unterschiedlich lange Aufnahme- und Verarbeitungszeiten. Diese sind jedoch von einer Vielzahl an Einflussgrößen abhängig. Darunter fallen zum Beispiel die Art der Fortbewegung, die Fähigkeiten und Einschränkungen des Nutzers und äußere Einflüsse, wie die Sonneneinstrahlung auf das Display oder die Geräuschkulisse. Nicht zu vergessen sind allerdings auch grundlegende Einflussgrößen, wie das Vorhandensein von Informationen, die für eine spezifische Darstellung nötig sind, oder Präferenzen des Nutzers. Stehen beispielsweise keine Umgebungsinformationen zur Verfügung, ist eine Kartendarstellung nicht möglich. Kann der Nutzer selbst zwischen den angebotenen Darstellungsformen wählen, so sollte die Darstellungsform auf dessen Präferenzen abgestimmt werden. Wenn der Nutzer beispielsweise eine Darstellung mittels eines Kartenausschnitts vorzieht, da er dadurch zusätzliche Hintergrundinformationen über den Aktionspunkt erfährt, so sollte die Navigationsapplikation natürlich diese Darstellungsform wählen. Die Darstellung ist jedoch nicht zwingend an eine einzige Form gebunden. So kann zum Beispiel die verbale Darstellung durch eine grafische Pfeildarstellung unterstützt werden, wie es bei Fahrzeugnavigationssystemen meist der Fall ist. Bei jeder Darstellungsform sind desweiteren zwei Perspektiven möglich. Diese sind die allozentrische und die egozentrische Perspektive (vgl. Kapitel 2.1). Wurde die Dienstausführung ohne weitere Messwerte angestoßen, so ist die allozentrische Perspektive obligatorisch, da keine Referenzrichtung des Nutzers verfügbar ist und deshalb nur eine allgemeingültige Referenzrichtung, wie zum Beispiel der geografische Norden, anwendbar ist. Eine allozentrische Navigationsinformation ist zum Beispiel ein Kartenausschnitt wie in Abbildung 4.6c), in dessen Mittelpunkt sich der Aktionspunkt befindet und auf dem die einzuschlagende Richtung markiert wurde. Durch die Dienstpräsentation erhält der Nutzer den Kartenausschnitt. Um die Navigationsanweisung aus dem Kartenausschnitt (roter Pfeil) umzusetzen, muss er die dargestellte Richtungsänderung physisch oder logisch umorientieren. Physische Umorientierung bezeichnet in diesem Zusammenhang das oft beobachtbare Drehen des Kartenausschnitts bis der Kartennorden physisch gegen den geografischen Norden zeigt und dadurch die Navigationsanweisung direkt umsetzbar wird. Logisch bedeutet in diesem Zusammenhang, dass die einzuschlagende Richtung aus der wahrgenommenen mentalen Karte entnommen wird. b) a) c) N N N + = Abbildung 4.6: Genordeter Kartenausschnitt Zur Minimierung der Verarbeitungszeit sollte deshalb bereits in der Navigationsapplikation eine Umorientierung erfolgen. Dazu muss die aktuelle Blickrichtung des Nutzers bei Betreten des Aktionskreises bekannt sein. Da die Blickrichtung des Nutzers mit derzeitiger Technik schwer ermittelbar ist, wird diese durch die meist ähnliche Bewegungsrichtung ersetzt. Um stets Kenntnis über die aktuelle Bewegungsrichtung beim Eintreten in den Aktionskreis zu besitzen, wird diese in die Dienstinitiierungsaktion integriert. Dadurch wird die aktuelle Bewegungsrichtung an jede Dienstinitiierung angehängt und die Navigationsapplikation davon informiert. Mit Hilfe der aktuellen Bewegungsrichtung kann nun zum Beispiel ein allozentrischer Kartenausschnitt in einen egozentrischen Kartenausschnitt transformiert werden, der nicht mehr nach Norden ausgerichtet, sondern an die Bewegungsrichtung des Nutzers angepasst ist. Dadurch kann der Nutzer die aufgezeigte 59 4.2. SCHICHTENMODELL Richtungsänderung direkt in die Realität umsetzen und muss nicht mehr aufwändig eine Umorientierung der Karte durchführen. In diesem Kapitel wurden nun vier verschiedene Darstellungsformen (Karten-, Pfeil-, verbale und textuelle Darstellung) vorgestellt, die jeweils mit allozentrischer oder egozentrischer Perspektive präsentiert werden können (vgl. Tabelle 4.2.3). Basis all dieser Darstellungen ist die Richtungsänderung, die an diesem Aktionspunkt durchgeführt werden muss. Für eine einfache textuelle und verbale Darstellung in allozentrischer Perspektive ist diese Richtungsänderung als Information ausreichend. Navigationsinformationen wie An der nächsten Möglichkeit Richtung Osten abbiegen“ können durch einfache Quantisierung ” der Richtungsänderung in die Richtungssektoren {N orden, Osten, S üden, W esten} und bereits vordefinierte Text- oder Sprachkonstrukte generiert werden. Sollen detailliertere oder durch Umgebungswissen angereicherte Navigationsinformationen erzeugt werden, müssen zusätzliche Informationen zum Beispiel von Directory Services [Maea 04] integriert werden. Resultat sind Navigationsinformationen wie An der ” nächsten Abzweigung Richtung Osten in die Hauptstraße einbiegen“. Ähnliches gilt für die Pfeil- und Kartendarstellung, die sich im Wesentlichen durch das eingefügte Um- Kartendarstellung Pfeildarstellung Verbale Darstellung Textuelle Darstellung Allozentrisch Karte mit Norden als Referenzrichtung Pfeil mit Norden als Referenzrichtung An der nächsten Möglichkeit ” Richtung Osten abbiegen“ An der nächsten Möglichkeit ” Richtung Osten abbiegen“ Egozentrisch Karte mit Bewegungsrichtung als Referenzrichtung Pfeil mit Bewegungsrichtung als Referenzrichtung An der nächsten Möglichkeit ” rechts abbiegen“ An der nächsten Möglichkeit ” rechts abbiegen“ Tabelle 4.1: Darstellungsformen in allozentrischer/egozentrischer Perspektive gebungswissen unterscheiden. Pfeildarstellungen werden meist nur um Namen bestimmter Landmarken erweitert. Obiges Beispiel würde in der Pfeildarstellung durch einen nach rechts gerichteten Pfeil, gegebenenfalls durch die Aufschrift Hauptstraße“, dargestellt. Zusätzlich muss ein Hinweis auf die Allozentrik ” zum Beispiel durch den Buchstaben N“ für den geografischen Norden am oberen Bildrand erfolgen (vgl. ” Abb. 4.6b). Im Unterschied dazu enthält die Kartendarstellung weitere Umgebungsinformationen, wie politische Grenzen, Bepflanzung oder Pfadnetzwerke (vgl. Abb. 4.6a). Diese Daten können in grafischer Form zum Beispiel von Presentation Services [Maea 04] erlangt werden. Basierend auf dieser Grundlage fügt man die Richtungsänderung in der Form der Pfeildarstellung hinzu (vgl. Abb. 4.6b) und erhält die gewünschte Kartendarstellung (vgl. 4.6c). Für die egozentrische Darstellung muss eine Richtungsanpassung der allozentrischen Richtung auf die egozentrische Richtung erfolgen. Für die textuelle und verbale Darstellung bedeutet dies, dass die Richtungsinformation (in obigem Beispiel Osten“) in eine der egozentrischen Perspektive entsprechende Rich” tungsinformation transformiert werden muss. Bewegt sich der Nutzer Richtung Norden, so ergibt sich für obiges Beispiel die Navigationsinformation Die nächste Möglichkeit rechts abbiegen“. ” Ähnliches gilt für die grafische Repräsentation mittels Landkarten oder Pfeilen. Die Richtungsinformation ist hier durch die Richtung der Grafik gegeben. Eine Anpassung an die egozentrische Richtung erfolgt durch Drehen der Grafik bis die egozentrische Richtung nach oben zeigt. Die hier angeführten Präsentationsformen sind nicht zwangsläufig vollständig, geben aber die in der Navigation typischen Präsentationsformen wieder. 4.2.4 Präsentationsmiddleware Die durch die Dienstausführung generierten Darstellungen müssen daraufhin dem Nutzer präsentiert werden. Dazu besitzt ein Nutzer einen oder mehrere Präsentatoren, die die Präsentation eines oder mehrerer Darstellungsmedien übernehmen. Damit sich die Dienstausführungsschicht nicht mit dem Zugriff und der 60 KAPITEL 4. ARCHITEKTUR Verwaltung von diversen heterogenen Präsentatoren auseinandersetzen muss, wurde zwischen der Dienstausführungs- und Dienstpräsentationsschicht eine Middleware eingefügt, die den Applikationen der Dienstausführungsschicht einen transparenten Zugriff auf die Präsentatoren ermöglicht. Innerhalb der Präsentationsmiddleware erfolgt die Abbildung anhand technischer Gegebenheiten. Dazu spielen vor allem die Verfügbarkeit von Präsentatoren mit bestimmten Eigenschaften und die Verbindungscharakteristika eine entscheidende Rolle. Übergibt eine Applikation eine Menge an Darstellungen an die Präsentationsmiddleware, wird überprüft, welche Präsentatoren verfügbar sind und ob diese die übergebenen Darstellungen unterstützen. Gegebenenfalls kann eine Transformation in einen anderen Medientyp erfolgen. Grundsätzlich ist dies nur innerhalb einer Darstellungsform möglich. In manchen Fällen kann auch eine Transformation zwischen Darstellungsformen erfolgen. So kann zum Beispiel eine textuelle Darstellung gegebenenfalls in eine verbale Darstellung überführt werden. In der Regel ist es aber nicht möglich, verbale Darstellungen in Kartendarstellungen zu transformieren, da für die Kartendarstellung weitere Informationen nötig sind. Innerhalb einer Darstellungsform ist eine Transformation zwischen Medientypen in der Regel möglich. Wird zum Beispiel eine verbale Darstellung im WAV-Format übergeben und es existiert nur ein Präsentator für Medien im MP3-Format, so kann in der Präsentationsmiddleware eine Konvertierung von WAV nach MP3 erfolgen. Neben der Transformation zwischen verschiedenen Medientypen, kann in der Präsentationsmiddleware auch eine Transformation innerhalb eines Medientyps erfolgen. Dies kann zum Beispiel dazu eingesetzt werden, um eine Datenkompression - gegebenenfalls unter Qualitätsverlust - durchzuführen. Dies ist vor allem sinnvoll, falls die Verbindung mit dem Initiator eine geringe Datenrate vorweist oder ihre Benutzung mit hohen Kosten verbunden ist. Für die verbale Darstellung im MP3-Format kann im Zuge der Anpassung beispielsweise eine Verringerung der Bitrate oder eine Kanalbündelung von Stereo auf Mono durchgeführt werden. Eine weitere Aufgabe der Präsentationsmiddleware ist die Anpassung der Medien an die Eigenschaften der Präsentatoren. Eigenschaften der grafischen Darstellung sind beispielsweise die Größe des Displays, die Auflösung, sowie die Farbtiefe (vgl. [BKKW ]). Die Präsentationsmiddleware ist dafür verantwortlich, das Medium anhand dieser Eigenschaften anzupassen. Hierfür muss das grafische Medium skaliert und an die darstellbare Auflösung und Farbtiefe angepasst werden. 4.2.5 Dienstpräsentation Durch die Verteilung der Medien an die entsprechenden Präsentatoren, erreicht das darzustellende Medium letztendlich die Dienstpräsentationsschicht. Diese ist zuständig für die Präsentation der Medien. Wie bereits beschrieben, sind grundlegende Präsentationsformen die verbale, die textuelle und die grafische Präsentation. Die Medien einer Präsentationsform können desweiteren verschiedenste Medientypen besitzen. Medientypen für die grafische Darstellung sind unter anderem Bitmap (BMP), Portable Network Graphics (PNG), Joint Photographic Expert Group (JPG), Graphics Interchange Format (GIF) oder Scalable Vector Graphics (SVG). Während manche Initiatoren Medien in verschiedenen Medientypen darstellen können, sind andere Initiatoren auf einen Medientyp beschränkt. Kann ein Initiator deshalb das ihm zugesandte Medium nicht darstellen, so muss er die fehlgeschlagene Präsentation mit einer negativen Quittung bestätigen. Ist er hingegen fähig das Medium erfolgreich zu präsentieren, wird dieses vom Nutzer wahrgenommen und entsprechend interpretiert. 4.3 Verteilung Das in vorherigem Kapitel vorgestellte Schichtenmodell untergliedert LBPSs in fünf logische Schichten. Logische Schichten unterteilen ein Softwaresystem in logische Teilkomponenten. Aufbauend auf diesen Schichten erfolgt nun eine Betrachtung der physischen Verteilung. Werden logische Schichten auf physi- 4.3. VERTEILUNG 61 sche Entitäten 1 verteilt, so spricht man von physischen Schichten (engl. Tiers) (vgl. [Warr 99]). Mögliche bzw. unmögliche Verteilungen und Vor- und Nachteile einzelner Verteilungen werden in diesem Kapitel behandelt. Um die bereits vorgestellten Schichten auf Entitäten des Systems zu verteilen, muss zuallererst eine Bestandsaufnahme der zur Verfügung stehenden Entitäten erfolgen. Da die Architektur des Location-based Push-Services und dessen Verteilung frei von der zugrunde liegende Technologie (z.B. Mobilfunkgeneration) entwickelt werden soll, werden in diesem Kapitel keine technologiespezifischen Eigenheiten des Systems und dessen Entitäten betrachtet. An dieser Stelle ist deshalb eine allgemeine Betrachtung der im Bereich der LBPSs relevanten Entitäten ausreichend. 4.3.1 Entitäten Da die Dienstnutzung des mobilen Navigationsdienstes in der Regel von einem mobilen Endgerät aus durchgeführt wird, stellt das mobile Endgerät eine erste Hardwareentität dar. Mobile Endgeräte sind bestimmten Spezifika und Restriktionen, die aus ihrer Mobilität resultieren, unterlegen. Im Zeitalter des Mobile Distributed Computing“ [SAW 94, Schi 95, BuTu , TavS 03] sind mobile Endgeräte meist über ” die Luftschnittstelle mit einer Infrastruktur verbunden, die wiederum aus mehreren einzelnen Entitäten bestehen kann. Sie werden unter dem Begriff Infrastruktur zusammengefasst. Im Wesentlichen werden hier also mobile Endgeräte und die Infrastruktur unterschieden. Mobiles Endgerät Ein mobiles Endgerät ist ein Gerät, dessen Funktionsfähigkeit nicht von stationären Gegebenheiten wie Stromanschluss oder Netzwerkanschluss abhängt und deren Ausmaße und Gewicht einen einfachen Ortswechsel zulassen. Deshalb ist es möglich, das Gerät überall mitzuführen und überall zu nutzen. Im Gegensatz zu portablen Endgeräten ist die Funktionsfähigkeit auch während der Bewegung gegeben. Beispiele für mobile Endgeräte sind Mobiltelefone, PDAs und eingeschränkt auch Notebooks. Aus dem Nichtvorhandensein des stationären Stromanschlusses und den Einschränkungen bezüglich Ausmaße und Gewicht unterliegen mobile Endgeräte in der Regel einer geringeren Rechenleistung als die korrespondierenden stationären Endgeräte. Selbiges gilt für den volatilen sowie persistenten Speicher. Die geringen Ausmaße des mobilen Endgerätes erlauben außerdem keine komfortablen Ein- und Ausgabemöglichkeiten. Eingabemöglichkeiten ergeben sich meist nur durch eine ITU-T One-Hand-Tastatur oder ein Touchscreen. Zur Ausgabe stehen meist kleine Displays und einfache Lautsprecher zur Verfügung. Die drahtlosen Kommunikationsverbindungen zu MANs sind in der Regel teuer in der Benutzung, unterliegen meist niedrigeren Datenraten als die drahtgebundenen Netze und gelten als unverlässlich (vgl. [BuTu , BCK 04, BKK 01, RuKr 03]). Die rasante Entwicklung im Bereich der mobilen Endgeräte liefert zwar ständige Neuerungen und Verbesserungen, um diesen Einschränkungen entgegenzuwirken, jedoch können sie in naher Zukunft wohl nicht gänzlich eliminiert werden. Infrastruktur Durch die Kommunikationsmöglichkeit über drahtlose Netze wird der Austausch von Daten mit anderen mobilen Endgeräten (Ad-Hoc-Netze) oder einer Infrastruktur (Infrastrukturnetze) ermöglicht. Ersteres ist in dieser Arbeit weniger von Interesse. Stattdessen spielen Infrastrukturnetze eine entscheidende Rolle für die Verteilung der LBPS-Schichten. Komponenten der Infrastruktur unterliegen nicht den für mobile Endgeräte inhärenten Einschränkungen. So sind Kommunikationsverbindungen innerhalb der Infrastruktur meist drahtgebunden und deshalb kostengünstiger, verlässlicher, schneller und leichter erweiterbar als 1 Entitäten bezeichnen in dieser Arbeit physische Einheiten, die die Ausführung bestimmter Prozesse zulassen. Eine Entität kann sich aus einer oder mehreren Hardwarekomponenten zusammensetzen. Beispiel für eine Entität ist ein mobiles Endgerät, aber auch ein Rechnercluster. 62 KAPITEL 4. ARCHITEKTUR drahtlose Verbindungen. Desweiteren sind die Rechenleistung und der verfügbare Speicher von Infrastrukturkomponenten wesentlich leichter skalierbar als bei mobilen Endgeräten und Ausmaße und Gewicht der Geräte sind unerheblich. 4.3.2 Verteilungsalternativen Mittels der Kommunikationsmöglichkeit der mobilen Endgeräte mit Entitäten der Infrastruktur kann ein Outsourcing einzelner Dienstschichten über Gerätegrenzen hinweg erfolgen. Es stellt sich die Frage, welche Dienstschichten ein Outsourcing erlauben und welche Konstellationen Sinn machen. Die Dienstpräsentation muss sich immer auf der Entität befinden, auf der auch die jeweilige Ausgabemöglichkeit vorhanden ist. Bei mobilen Navigationsdiensten ist dies das mobile Endgerät. Ähnliches gilt für die Dienstinitiierung. Diese befindet sich auf der Entität, auf der die Sensorinformationen zur Verfügung stehen. Bei einer netzwerkbasierten Ortung liegt die Dienstinitiierung demnach auf einer Entität der Infrastruktur und bei einer endgerätebasierten Ortung (wie GPS) befindet sie sich auf dem mobilen Endgerät. Werden mehrere Initiatoren parallel genutzt, ist es auch möglich, dass sich eine Teilmenge der Initiatoren auf dem Endgerät und der Rest in der Infrastruktur befindet. Die restlichen drei Schichten Initiierungsmiddleware, Dienstausführung und Präsentationsmiddleware sind im Gegensatz zu den restlichen Schichten nicht an feste Ein- oder Ausgabemöglichkeiten gebunden. Dadurch wird ein Outsourcing in die Infrastruktur möglich. Welche Einflussfaktoren ein Outsourcing rechtfertigen oder widerlegen, wird im Folgenden erläutert. Einflussfaktoren auf Verteilung Ein großes Problem des Distributed Computing“ ist die Verteiltheit von Informationen. Während in ” früheren Zeiten alle zur Dienstausführung nutzbaren Informationen lokal auf der Entität, auf der die Dienstausführung stattfindet, vorhanden waren, ist beim Distributed Computing“ ein weitaus größerer Horizont ” der Informationsbeschaffung heranzuziehen. Informationen sind nicht mehr nur lokal abrufbar, sondern können auf der ganzen Welt verteilt und von dort abrufbar sein. Einer der wichtigsten Schritte, der die Verfügbarkeit von Informationen entscheidend gefördert hat, ist die Entwicklung des Internets. Durch das Internet ist es möglich geworden, eine Vielzahl an Informationen weltweit zu nutzen. Durch die Entwicklung des Mobile Distributed Computing“ [SAW 94, Schi 95] kommt zu diesen fest ” verdrahteten Rechnern eine Menge mobiler Endgeräte, die sich durch drahtlose Verbindungen in das Netz eingliedern. Die Gesamtheit der Informationsbeschaffer und -nutzer wird dadurch signifikant erweitert. Eine Problematik für die Anbindung an das Informationsnetz“ ist die drahtlose Verbindung. Drahtlose ” Verbindungen unterliegen, wie bereits beschrieben, geringeren Datenraten, eingeschränkter Verfügbarkeit und beschränkter Verlässlichkeit. Außerdem sind sie oft teuer in der Nutzung. Zur Lösung dieses Problems kann ein Ansatz verwendet werden, der in vielen Fällen zum Einsatz kommt, bei denen Informationen lokal verfügbar gemacht werden müssen, wodurch Kosten (wie Netzlast, monetäre Nutzungskosten) entstehen. Dieser Ansatz ist das Caching bzw. Precaching. Caching bezeichnet den Vorgang, Informationen lokal zwischenzuspeichern, um sie bei einer erneuten Verwendung nicht wieder beschaffen zu müssen. Precaching bezeichnet den Vorgang, Informationen vor der eigentlichen Nutzung lokal verfügbar zu machen. So kann einer später teuren oder unmöglichen Informationsbeschaffung vorgebeugt werden. (Pre-)Caching ist jedoch nur in eingeschränktem Maße einsetzbar. Es muss dazu bekannt sein, welche Informationen in Zukunft benötigt werden. Je nach Art der Anwendung und Information ist dies mehr oder weniger gut möglich. In einem Großteil der Fälle ist es jedoch überhaupt nicht möglich. Soll ein Dienst zum Beispiel die Sonnentage für den nächsten Monat (pre-)cachen, so stellt dies voraussichtlich ein ernsthaftes Problem dar. Soll der Dienst allerdings nur die Stunden von Sonnenaufgang bis Sonnenuntergang (pre-)cachen, so ist dies ohne große Einschränkungen möglich. Zusammenfassend kann gesagt werden, dass die lokale Verfügbarkeit von verteilten Informationen im Mobile Distributed Computing zwei Faktoren determinieren. Diese sind die stetige Anbindung an das Infor” mationsnetz“ (im Folgenden als Connectivity bezeichnet) und das (Pre-)Caching. Ist keines der beiden 63 4.3. VERTEILUNG gegeben, so ist eine lokale Nutzung von nicht-lokalen Informationen nicht möglich. Ist keine akzeptable Connectivity gegeben, (Pre-)Caching jedoch möglich, so können Informationen vorab lokal verfügbar gemacht werden und sind so bei späterem Gebrauch direkt nutzbar. Ist allerdings Connectivity gegeben, (Pre-)Caching jedoch nicht möglich, so können Informationen bei Gebrauch direkt aus dem Informati” onsnetz“ beschafft werden. Ist sowohl Connectivity als auch Precaching möglich, so kann in jedem Fall auf Informationen zurückgegriffen werden, egal ob diese erst bei Gebrauch oder bereits zuvor beschafft werden. Bezüglich der Frage der Verteilung der Dienstausführung ergibt sich dadurch folgende Situation. Innerhalb der Dienstausführungsschicht wird aus einer Menge an Informationen ein wie auch immer gearteter Mehrwert erzeugt. Alle Informationen müssen dazu der Dienstausführungsschicht zur Verfügung stehen. Ist gute Connectivity gegeben, so kann die Dienstausführungsschicht alle Informationen bei Gebrauch direkt anfordern. Würde in diesem Fall die Dienstausführung auf dem mobilen Endgerät erfolgen, so müssten alle Informationen über die Luftschnittstelle übertragen werden, um von ihrem ursprünglichen Ort auf das mobile Endgerät zu gelangen. Bei einer großen Anzahl an Informationen können dadurch hohe Kosten entstehen. Außerdem werden zur Dienstausführung oft hohe Anforderungen an Rechenleistung und Speicherplatz gestellt, die auf dem mobilen Endgerät nicht erfüllt werden können. Wird die Dienstausführung jedoch innerhalb der Infrastruktur durchgeführt, kann ein Großteil der zur Ausführung nötigen Informationen direkt über drahtgebundene Verbindungen übertragen werden. Außerdem können die Anforderungen an Rechenleistung und Speicherplatz in der Infrastruktur leichter erfüllt werden als auf dem mobilen Endgerät. Lassen die Informationen andererseits ein (Pre-)Caching zu, so können die zur Ausführung nötigen Informationen bereits frühzeitig verfügbar gemacht werden. Für die lokale Dienstausführung auf dem mobilen Endgerät hat dies zur Folge, dass auch bei einer Trennung der Connectivity die Dienstausführung durchgeführt werden kann, da die Informationen bereits zuvor durch (Pre-)Caching auf das mobile Endgerät gebracht wurden. Dadurch erfährt der Dienst eine gewisse Autonomie. Er ist nicht mehr abhängig vom Informationsnetz“ und wird dadurch nicht mehr durch die Connectivity und Ausfällen innerhalb des In” ” formationsnetzes“ beeinflusst. Nachteil der lokalen Dienstausführung ist neben der beschränkten Rechenleistung der Speicherplatzverbrauch, der für das (Pre-)Caching benötigt wird. Zusammenfassend lässt sich sagen, dass bei ausreichender Connectivity ein Outsourcing der Dienstausführungsschicht in die Infrastruktur sinnvoller erscheint als eine lokale Dienstausführung auf dem mobilen Endgerät. Wird von den Informationen ein (Pre-)Caching ermöglicht, scheint eine lokale Dienstausführung sinnvoller (vgl. Abb. 4.7). Bei ausreichender Connectivity und der Möglichkeit des (Pre-)Cachings kann sowohl die lokale wie die entfernte Dienstausführung oder eine Kombination beider eingesetzt werden. Connectivity vs. (Pre-)Caching Connectivity Remote (Pre-)Caching Local Abbildung 4.7: Gegenüberstellung lokaler und entfernter Dienstausführung bei Connectivity und (Pre-)Caching Um Dienste innerhalb des in Abbildung 4.7 dargestellten Diagramms einordnen zu können, müssen speziell für diese Dienste die Ausprägungen von Connectivity und (Pre-)Caching betrachtet werden. Ob eine 64 KAPITEL 4. ARCHITEKTUR Connectivity als ausreichend deklarierbar ist, entscheidet die Art des Dienstes. Ausreichend heißt dabei keinesfalls, dass Informationen überall verfügbar sein müssen. Ausreichend bedeutet in diesem Zusammenhang bloß, dass die Informationen immer dann verfügbar sein müssen, wenn sie gerade gebraucht werden. Der bereits desöfteren erwähnte ortsbasierte Email-Push-Dienst, der Emails entsprechend ihrer örtlichen Relevanz (Büro oder zuhause) zustellt, braucht keine Informationen zu empfangenen Emails, wenn der Nutzer sich nicht an den wohldefinierten Orten befindet. Sind an den diesen Orten die Informationen zugänglich, ist dies vollkommend ausreichend. Ein (Pre-)Caching der Informationen wird möglich, wenn einerseits die Informationen dies zulassen und andererseits das mobile Endgerät dies zulässt. Dazu muss es vor allem genug Speicherplatz zur Speicherung der Informationen bereitstellen. Informationen, die (Pre-)Caching zulassen, müssen vorhersehbar sein. Die einfachste Form vorhersehbarer Informationen sind statische Informationen. Statische Informationen zeichnen sich dadurch aus, dass sie über ihre ganze Gültigkeitsdauer konstant sind. Beispiele sind das Geburtsdatum einer Person, Positionen von Landmarken oder Postleitzahlen eines Postleitzahlenbereichs. Diese können bereits weit im Voraus auf dem mobilen Endgerät durch (Pre-)Caching verfügbar gemacht werden. Nicht-statische Informationen, die aber trotzdem vorhersehbar sind, sind Informationen, deren Werte sich nach einem vorhersehbaren Muster verändern. Beispiele sind Sonnenauf- und Sonnenuntergangszeitpunkte oder die Anzahl der Tage eines Jahres. Die dritte Möglichkeit vorhersehbarer Informationen, sind Informationen die eine mehr oder weniger verlässliche Schätzung zulassen. Dazu zählen zum Beispiel die Verkehrsunfälle innerhalb eines Jahres oder die Niederschlagsmenge im Monat Juli. Aus Betrachtungen der Vergangenheit lassen sich hier Schätzungen über das Verhalten in der Zukunft abgeben. Meist sind diese Werte allerdings nur im Kollektiv gültig. Anders ist dies bei nicht-vorhersehbaren Informationen. Für diese kann kein Wert in der Zukunft angegeben werden, weil sie sich nicht-deterministisch verändern und keine Schätzungen zulassen. Beispiele derartiger Informationen sind präzise Wetterinformationen, längerfristige Verkehrsflussinformationen oder Aktienkurse. Für derartige Informationen ist kein (Pre-)Caching möglich. Ähnliche Resultate liefern auch [HLP , CDMF 00, PARA 02] in ihren Arbeiten. Nach [HLP ] ist ein Outsourcing der Dienstausführung sinnvoll, wenn nicht alle Informationen lokal verfügbar sind, Daten sich häufig nichtdeterministisch ändern und nicht genügend Rechenleistung und Speicherplatz auf dem mobilen Endgerät verfügbar ist. [CDMF 00] stellt ein Outsourcing als sinnvoll dar, wenn das Endgerät nicht über genügend Speicherplatz verfügt, um alle nötigen Informationen zu speichern und wenn verteilte unvorhersehbare Informationen zur Dienstausführung nötig sind. Nach [PARA 02] sprechen vor allem die Notwendigkeit von aktuellen Informationen und die Beschränktheit der Rechenleistung und des Speicherplatzes auf dem mobilen Endgerät für das Outsourcing der Dienstausführung, wohingegen die Autonomie und die eingeschränkte Connectivity an eine lokale Dienstausführung appellieren. In [HLP ] wird zudem noch ein weiterer Grund genannt, der für ein Outsourcing der Dienstausführungsschicht spricht. Dies ist die einfache Anpassbarkeit der ausgelagerten Schichten. [HLP ] nennt hier die Adaption an verschiedene Ausprägungen terminalseitiger Schichten, die aus der Heterogenität der Endgeräte entsteht. Allgemeiner kann hier gesagt werden, dass eine Veränderung in einer ausgelagerten Schicht viel einfacher vollzogen werden kann als bei einer terminalbasierten Schicht, da eine ausgelagerte Schicht nur einmal (ggf. mehrmals bei Replikation), eine terminalbasierte Schicht jedoch für jedes Terminal geändert werden muss. 4.3.3 Auswirkung auf mobile Navigationsdienste Betrachtet man nun das (Pre-)Caching der Informationen, die bei einem Navigationsdienst zum Einsatz kommen, stellt man fest, dass (Pre-)Caching von einigen Annahmen abhängt. Die wichtigsten Informationen im Bereich der Navigationsdienste sind Routeninformationen. Diese können unterschiedliche Formen annehmen (vgl. Kapitel 2.2) und unterschiedlich kodiert werden, müssen aber in jedem Fall bei den Navigationsdiensten der Wegfindung vorhanden sein. Unterstellt man dem Nutzer ein deterministisches Bewegungsmuster entlang der vorgegebenen Route, so kann die Route als statische Information angesehen werden und ein (Pre-Caching) wird möglich. Kommerzielle Dienste wie der NavMe oder der Mobile Navigator nutzen dies aus und laden alle Routeninformationen beim Start des Dienstes auf das mobile Endgerät. Der ActivePilot nutzt zwar ebenfalls (Pre-)Caching, 65 4.3. VERTEILUNG lädt beim Start des Dienstes aber nur das erste Routensegment auf das mobile Endgerät. Nähert sich der Nutzer dem Ende des Routensegments, wird automatisch das nächste Routensegment geladen. Um bei einer leichten Routenabweichung noch Informationen liefern zu können, werden anstatt der direkten Routeninformationen meist korridorbasierte Routeninformationen, die zusätzlich das unmittelbare Umfeld der Route beinhalten, eingesetzt. Die in Kapitel 3.4 vorgestellten dedizierten Navigationsgeräte, sowie der Mobile 5 und der Mobile 2005, die eine On-Board-Lösung für die Navigation nutzen, gehen diesen Schritt noch weiter und führen ein (Pre-)Caching aller zur Routenberechnung nötigen Informationen über Städte, Straßen, etc. durch. Der nötige Speicherplatz derartiger Dienste erhöht sich dadurch enorm im Gegensatz zu den Navigationsdiensten, die ausschließlich ein (Pre-)Caching der Routeninformationen durchführen. Für nicht vorhersehbare Informationen, für die kein (Pre-)Caching möglich ist, nutzen einige Dienste zusätzlich die Connectivity zu Informationsnetzen“, um diese Informationen verfügbar zu machen. Fahrzeugnavigationssysteme ” hören dazu den RDS TMC-Kanal nach Verkehrsinformationen ab. Andere nutzen Mobilkommunikationsnetze, um Verkehrsinformationen zu erhalten. Der Großteil der beschriebenen Dienste geht dabei von einer unzureichenden Connectivity aus und nutzt deshalb soweit möglich (Pre-)Caching für die Informationsbeschaffung. Geht man von einer ausreichenden Connectivity aus und nutzt (Pre-)Caching nur bedingt, so resultiert aus dem Outsourcing der Dienstausführungsschicht eine höhere Netzlast zwischen Dienstinitiierung, Dienstausführung und Dienstpräsentation. Demgegenüber reduziert die Informationsbeschaffung die Netzlast der drahtlosen Netze, da Informationen nicht mehr über die Luftschnittstelle übertragen werden müssen. Werden beispielsweise zur Generierung von Navigationsinformationen neben der Route alternative Routenvorschläge, Wetterinformationen, Sonnenauf- und Sonnenuntergangszeiten, Einkehrmöglichkeiten oder Verkehrsinformationen herangezogen, so müssen all diese Informationen bei einer terminalbasierten Dienstausführung über die Luftschnittstelle übertragen werden. Letztendlich ist das Resultat nach der Mehrwertgenerierung zum Beispiel ein einziger Pfeil, der dem Nutzer sagt, in welche Richtung er nun abbiegen soll. Je mehr Informationen zur Generierung der Navigationsinformation nötig sind, desto höher wird der Verkehr über die Luftschnittstelle (Over-The-Air-Traffic (OTA-Traffic)). OTA-Traffic Local Remote Menge nicht-lokaler Informationen Abbildung 4.8: Netzlast der Luftschnittstelle bei lokaler oder verteilter Dienstausführung Wird im Gegensatz dazu die Dienstausführungsschicht in die Infrastruktur ausgelagert und die gleiche Menge an nicht-lokalen Informationen für die gleiche Navigationsinformation wie bei der lokalen Variante eingesetzt, so muss nur die Navigationsinformation, d.h. der Pfeil, über die Luftschnittstelle übertragen werden. Da die zur Generierung der Navigationsinformation nötigen Informationen nicht über die Luftschnittstelle übertragen werden, ist der OTA-Traffic unabhängig von der Anzahl der nötigen Informationen. Abbildung 4.8 zeigt, dass bei einer niedrigen Menge nicht-lokaler Informationen bei lokaler Dienstausführung weniger Informationen über die Luftschnittstelle übertragen werden müssen als bei der verteilten Variante. Dies ist der Fall solange die Datengröße der nicht-lokalen Informationen die Datengröße der Navigationsinformation nicht übersteigt. Sobald dies aber geschieht, wird bei der verteilten Variante 66 KAPITEL 4. ARCHITEKTUR weniger OTA-Traffic verursacht als bei der lokalen Variante. Je mehr nicht-lokale Informationen benötigt werden, desto größer wird diese Differenz. Je nach Menge nicht-lokaler Informationen muss hier also entschieden werden, welche Verteilungsalternative sich als sinnvoller erweist. Kapitel 5 Implementierung Im Rahmen dieser Arbeit wurde der in Kapitel 2.3 beschriebene MoBiLe-Service in die Realität umgesetzt. Das Grundgerüst des Dienstes basiert auf den bereits beschriebenen Location-based Push-Services und der in Kapitel 4 vorgestellten Architektur für derartige Dienste. Aus den zur Auswahl stehenden Technologien für Ortung und Programmierung (vgl. Kapitel 3) wurden adäquate Technologien und deren unterstützende Hardware ausgewählt, die für den MoBiLe-Service am geeignetsten erschienen. Außerdem musste eine Wahl der Verteilung der einzelnen physischen LBPS-Schichten auf Entitäten erfolgen. Der Anfang dieses Kapitels ist diesen Entscheidungsfindungen gewidmet. Der darauf folgende Teil beschreibt wichtige Aspekte der Implementierung. Leider würde eine vollständige Abhandlung aller Implementierungsdetails den Rahmen dieser Arbeit sprengen. Deshalb werden nur einzelne Aspekte, die sich durch hohe Relevanz oder entscheidende Lösungsansätze auszeichnen, hier vorgestellt. 5.1 Ortungssystem Kapitel 3.1 zeigte bereits einige Ortungssysteme und deren Vor- und Nachteile. Aus den dort genannten Argumenten, wie hohe Verfügbarkeit im ländlichen Bereich und hohe und relativ konstante Genauigkeit, fiel die Entscheidung auf GPS. Dem Problem von GPS bezüglich der langen TTFF könnte mit A-GPS entgegengewirkt werden, wurde hier aber aufgrund des eingeschränkten zeitlichen Rahmens nicht umgesetzt. Da es sich bei GPS um ein endgerätebasiertes Ortungsverfahren handelt, erfolgt die Bestimmung der Ortsinformationen auf dem mobilen Endgeräte. Bei der verteilten Variante des MoBiLe-Service hat diese Art der Ortung den Nachteil, dass Signalisierungsdaten und gegebenenfalls Ortsinformationen über die Luftschnittstelle übertragen werden müssen. Dies wird in der Architektur aber relativ effizient umgesetzt und verursacht so keine unnötigen Kosten. Kriterien für die Wahl des GPS-Empfängers waren: • Mobilität, d.h. keine Abhängigkeit von einer stationären Stromversorgung, externen Antenne oder anderen Sensoren 1 • Kompatibilität mit dem Mobiltelefon (am besten durch drahtlose Verbindung) • hohe Genauigkeit von ca. 10 Metern • lange Akkulaufzeit (mind. 6 Stunden) • A-GPS- und D-GPS-Funktionalität für evtl. spätere Integration 1 Obwohl viele GPS-Empfänger dies erfüllen, ist Mobilität keine zwingende Anforderung an GPS-Empfänger. Gegenbeispiele hierfür liefern z.B. GPS-Empfänger für die Vermessung oder GPS-Empfänger für die Fahrzeugnavigation 67 68 KAPITEL 5. IMPLEMENTIERUNG Fortuna Clip-On Bluetooth GPS Receiver Ein GPS-Empfänger, der all diese Anforderungen erfüllt, ist der Fortuna Clip-On Bluetooth GPS Receiver [for ]. Er ist ein mobiler GPS-Empfänger, der Ortsinformationen mittels des Bluetooth Serial Port Profile (SPP) im NMEA0183-Format (Protokoll wird nachfolgend erläutert) übertragt. Der GPS-Empfänger arbeitet mit dem SiRF Star Ile/LP und SiRF Xtrac Chipsatz [sir ]. Er ist batteriebetrieben und hat eine Laufzeit von ca. 8 Stunden. Durch seine geringe Größe (vgl. Abb. 5.1) lässt er sich leicht verstauen und ist deshalb bestens geeignet, um ihn überall mitzuführen. Abbildung 5.1: Fortuna Clip-On Bluetooth GPS Receiver Durch die Erweiterung mit dem SiRF Xtrac Chipsatz kann er in zwei Modi betrieben werden. Diese sind der Standard Modus (ST) und der SiRF Xtrac (XT) Modus. Durch den Betrieb im XT-Modus kann eine wesentlich exaktere Positionsbestimmung durchgeführt werden. Diese ist sogar in weniger empfangsstarken Umgebungen möglich. Dadurch wird eine Ortung innerhalb von Gebäuden oder im Wald durchführbar. Gegenüber dem ST-Modus reduziert der XT-Modus außerdem die Startzeiten. Im ST-Modus benötigt der GPS-Empfänger durchschnittlich 0,1 Sekunden für die Wiederaufnahme der Positionierung bei kurzzeitigem Verbindungsabbruch, 8 Sekunden für den Heißstart, 38 Sekunden für den Warmstart und 45 Sekunden für den Kaltstart. Im XT-Modus werden diese Werte um einige Sekunden verringert. NMEA0183 Der Datenaustausch mit dem GPS-Empfänger basiert auf dem National Marine Electronics Association (NMEA) [nme ] Protokoll. Das NMEA Protokoll wurde für den Datenaustausch zwischen verschiedensten elektronischen Geräten (wie z.B. Mess-, Auswertungs-, Kontrollgeräte) der Marine entwickelt. Es kann für 1-zu-1 oder 1-zu-n Verbindungen eingesetzt werden und spezifiziert Richtlinien sowohl für die Ebene der Bitübertragung als auch der Nutzdatenübertragung. Die Übertragung erfolgt seriell und asynchron. Zur Synchronisation wird jedem Zeichen - kodiert mittels 8-Bit ASCII - ein Startbit (0) vorangestellt und ein Stopbit (1) angehängt. Heutzutage wird meist der NMEA-0183 Standard in der Version 2.x angewendet, der auf dem EIA-422-Protokoll basiert und in der Regel den Datenaustausch mit einer Rate von 4800 Baud vollzieht. Das neuere NMEA-2000 Protokoll beherrscht bereits Raten bis zu 38.400 Baud. Auf Nutzdatenebene werden die Informationen in der Form von Datensätzen (Sentences) übertragen. Meist werden Gruppen von Datensätzen mit einer Rate von einem Hertz vom GPS-Empfänger gesendet. Datensätze beginnen grundsätzlich mit dem Zeichen $, gefolgt von einer zweistelligen Sender-ID und einer dreistelligen Satz-ID. Jeder Datensatz wird durch die beiden Zeichen Carriage-Return (CR) und LineFeed (LF) beendet. Dazwischen befinden sich die einzelnen mit Komma getrennten Informationen des Datensatzes. Welche Informationen im Datensatz enthalten sind, ist abhängig von der Art des Datensatzes. Durch den NMEA Standard sind einerseits feste Datensatzformate definiert, andererseits können aber auch proprietäre Formate eingesetzt werden. Feste Datensätze im Bereich der Ortung sind beispielsweise der Recommended Minimum Specific GPS/TRANSIT Data (RMC), Global Positioning System Fix Data (GGA) 5.2. ENDGERÄTEPLATTFORM 69 und Actual track made good and speed over ground (VTG). Ein RMC-Datensatz des Fortuna Clip-On Bluetooth GPS-Empfängers hat zum Beispiel folgende Gestalt: $GPRMC,101907.583,A,4806.4273,N,01135.9562,E,0.37,61.05,180305,,,A*51 Wobei die einzelnen Teildatensätze folgende Bedeutung haben: • GP = Sender-ID (=GPS) • RMC = Satz-ID • 101907.583 = UTC-Zeit (10:19:07 Uhr) • A = Status (A=Active, V=Void/Error) • 4806.4273 = Latitude (48◦ 6, 42730 ) • N = Lat-Hemisphäre (N=North, S=South) • 01135.9562 = Longitude (11◦ 35, 95620 ) • E = Lon-Hemisphäre (E=East, W=West) • 0.37 = Geschwindigkeit über der Erdoberfläche in Knoten pro Stunde • 61.05 = Kurs über der Erdoberfläche (rechtsweisende Gradangabe) • 180305 = Datum (18.03.05) • = magnetische Deklination in Grad • = Richtung der magnetischen Deklination • A = Modus (A=Autonomous, D=Differential, E=Estimated, N=Not-Valid, S=Simulator (erst ab Version 2.3) • *51 = Prüfsumme Enthält ein Teildatensatz keinen Wert, wird er einfach frei gelassen. Resultat sind zwei aufeinander folgende Kommas (siehe Beispiel: magnetische Deklination). Die Prüfsumme, bestehend aus zwei Hexadezimalzahlen, ergibt sich aus einer Exclusive OR (XOR) Operation über alle Zeichen, ausgenommen von $ und *. Maximal kann ein Datensatz eine Länge von 82 Zeichen (inklusive $ und CR/LF) besitzen. Der Fortuna Clip-On Bluetooth GPS-Empfänger liefert standardmäßig mit einer Frequenz von einem Hertz die Datensätze GGA, GSA, RMC und VTG. Alle 5 Sekunden kommen ein oder mehrere GSV-Datensätze hinzu. 5.2 Endgeräteplattform Als Endgerät kommen bei der Umsetzung des MoBiLe-Service prinzipiell PDAs oder jegliche Art von Mobiltelefonen in Frage. Entscheidend bei der Wahl der Hardware waren folgende Voraussetzungen: • Mobilität, d.h. keine Abhängigkeit von stationärer Stromversorgung, etc. • Kommunikationsmöglichkeit zu drahtlosen Infrastruktur-MANs, z.B. durch GSM, GPRS oder UMTS • Kommunikationsmöglichkeit zu drahtlosen PANs (vor allem Bluetooth zur Kommunikation mit dem GPS-Empfänger) • lange Akkulaufzeiten im ständigen Betrieb (mind. 6 Stunden) • Eingabemöglichkeiten, z.B. über ITU-T-Onehand-Tastatur oder Touchscreen • Ausgabemöglichkeiten für: 70 KAPITEL 5. IMPLEMENTIERUNG – grafische Informationen: über Display mit mindestens 150x100 Pixel – verbale Informationen: über Lautsprecher oder drahtgebundene/drahtlose Kopfhörer Für die auf der Hardware zur Verfügung gestellte Programmierplattform sind folgende Voraussetzungen maßgebend: • Integrationsmöglichkeit von Drittanbieteranwendungen • Unterstützung der von der Hardware bereitgestellten Kommunikations-, Ein- und Ausgabemöglichkeiten • Unterstützung von Fließkommazahlen v.a. für Umgang mit Positionsinformationen • wenig Speicher- und Energieverbrauch Sinnvoll ist desweiteren, wenn bereits kompilierter Code sowohl auf der Plattform des mobilen Endgerätes als auch auf der Plattform der Infrastrukturkomponente ausführbar ist. Dadurch kann kompilierter Code sowohl auf dem mobilen Endgerät als auf der Plattform der Infrastrukturkomponente ausgeführt werden. Dies ist vor allem zur Realisierung verschiedener Verteilungsalternativen sinnvoll. Bei einer Veränderung der Verteilung muss dadurch keine Anpassung und Neukompilation des Quellcodes erfolgen. Die Entscheidung der Programmierplattform fiel vor allem wegen der zugrunde liegenden Plattformunabhängigkeit auf J2ME. Auch wenn hier Effizienzeinbußen in Kauf genommen werden müssen, überwiegen die Vorteile, die sich durch J2ME ergeben. J2MEs CLDC 1.0, das sich durch ein optionales Paket zur Emulation von Fließkommazahlen erweitern lässt, litt dadurch an enormen Effizienzeinbußen. Innerhalb der Configurations fiel daher die Wahl auf CLDC 1.1. Im Bereich der Profiles fiel die Wahl auf MIDP 2.0, da sich dieses durch eine bessere Medienunterstützung gegenüber MIDP 1.0 auszeichnet. Da CLDC 1.1 keine Unterstützung für BluetoothVerbindungen liefert, diese aber zur Anbindung des GPS-Empfängers obligatorisch sind, wird zusätzlich JABWT benötigt. Bei der Wahl des mobilen Endgerätes fiel die Entscheidung auf ein Mobiltelefon, da diese standardmäßig über eine WAN-Verbindung verfügen. Außerdem ist die Marktpenetration von Mobiltelefonen wesentlich höher als bei PDAs. Mobiltelefone bieten den Vorteil, dass auf Mountain-Bike-Touren kein zusätzliches Gerät mitgeführt werden muss. Unter anderem sind Mobiltelefone, die sowohl CLDC 1.1, MIDP 2.0 und JABWT bereitstellen, als auch die oben genannten Prämissen an die Hardware erfüllen, das Siemens S65 und das Nokia 6630. Leider wurde im praktischen Einsatz festgestellt, dass das Siemens S65 erhebliche Fehler und Spezifikationsabweichungen in der Bluetooth-Implementierung aufweist (vgl. Kapitel 6.1.3). Diese treten nicht nur in Verbindung mit J2ME auf, sondern auch bei der gewöhnlichen Nutzung. Eine Erneuerung der Firmware stellte sich für das zugrunde liegende Gerät als nicht trivial heraus und wurde deshalb vermieden. Als mobiles Endgerät wurde daher das Nokia 6630 eingesetzt (vgl. Abb. 5.2). Abbildung 5.2: Nokia 6630 71 5.3. WEITERER HARD- UND SOFTWAREEINSATZ Das Nokia 6630 ist das erste Serie 60 WCDMA/EDGE Mobiltelefon von Nokia (vgl. [for 04, nok ]). Es läuft unter Symbian OS 8.0a und stellt J2ME mit CLDC 1.1, MIDP 2.0, JTWI 1.0, WMA, MMAPI, JABWT, Nokia UI API, FileConnection/PIM API und M3GAPI bereit. Auf WANs kann mittels GSM, GPRS, EGPRS und WCDMA über die Frequenzen 900, 1800 und 1900 MHz zugegriffen werden. Im Bereich der PANs verfügt es über eine Bluetooth-Schnittstelle. Das Display des Nokia 6630 hat eine Auflösung von 176x208 Pixel mit 65.000 Farben. Auf dem Display und mittels des eingebauten Lautsprechers oder Headsets lassen sich verschiedenste Medien wie Grafiken im PNG-Format, Töne im MIDI-, WAV-, MP3-Format, etc. und Videos im H.263-, MPEG4- und Realvideo-Format darstellen. Durch diese Eigenschaften, die kompakten Ausmaße, das relativ geringe Gewicht und ausreichende Akkulaufzeit eignet sich das Nokia 6630 gut für die Realisierung des MoBiLe-Service. Bis auf die teilweise sehr lange Start- und Reaktionszeit des Betriebssystems und der darauf installierten Applikationen, verhielt sich das Nokia 6630 während der ganzen Arbeit entsprechend der Erwartungen und Spezifikationen. 5.3 Weiterer Hard- und Softwareeinsatz Die Entwicklung des Demonstrators erfolgte unter MacOSX 10.2.8 auf einem Apple ibook2 mit der Entwicklungsumgebung Eclipse 3.0 M4 und Suns Java 1.4.1 01. Leider stellte sich heraus, dass derzeit unter MacOSX 10.2.8 die Unterstützung für J2ME sehr rudimentär ist und nur unter erhöhtem Arbeitseinsatz durchgeführt werden konnte. So mussten zum Beispiel die CLDC- und MIDP-Bibliotheken im Zuge der Anpassung komplett neu übersetzt werden. In den letzten Monaten traten aber einige Projekte in Erscheinung, die eine Entwicklung von J2ME unter MacOSX vorantreiben wollen. Als Application Server in der Infrastruktur kam ein Intel Pentium III mit 512 MB RAM zum Einsatz. Die Wahl des Betriebssystems fiel auf FreeBSD (Release 5.3). FreeBSD ist ein freies open-source Betriebssystem und hat seinen Ursprung in 4.4BSD. Besonders bekannt ist FreeBSD für seine Schnelligkeit, Stabilität und vor allem Sicherheit. Kontinuierliche Updates machen FreeBSD zu einem der sichersten und leistungsfähigsten Betriebssysteme. Es eignet sich deshalb hervorragend für die Nutzung als Webserver oder Application Server. In der verteilten Ausführung des MoBiLe-Service wurden die MoBiLe-Applikation sowie die beiden Middlewareschichten auf diesem System betrieben. 5.4 Verteilung a) b) Presentation Mobile Device Presentation MW Mobile Device Application Presentation MW Application Server Initiation MW Initiation Presentation Application Initiation MW Mobile Device Initiation Abbildung 5.3: Verteilungsalternativen Für die Verteilung der Dienstschichten ergeben sich aus Kapitel 4.3 zwei sinnvolle Verteilungsalternativen. Ist ausreichende Connectivity gegeben, so kann eine verteilte Schichtenstruktur gewählt werden (vgl. 72 KAPITEL 5. IMPLEMENTIERUNG Abb. 5.3b). Ist die Connectivity nicht ausreichend, ein (Pre-)Caching aber möglich, ist eine lokale Dienstausführung vorzuziehen (vgl. Abb. 5.3a). In der Implementierung sollen beide Ansätze umgesetzt werden. Die beiden Ansätze sollen allerdings nicht durch zwei vollkommen getrennte Implementierungen realisiert werden. Dazu müssen einerseits die Implementierung der LBPS-Schichten und andererseits die Implementierung der Kommunikation zwischen den Schichten dies unterstützen. 5.4.1 Inter-LBPS-Schichtenkommunikation Zwei benachbarte Schichten können entweder innerhalb eines Systems (mobiles Endgerät oder Infrastruktur) oder auf getrennten Systemen angesiedelt werden. Damit diese Schichten innerhalb eines Systems oder über Systemgrenzen hinaus Daten austauschen können, müssen die Schichten durch ein dynamisches Verbindungskonstrukt interagieren. Native Methodenaufrufe sind hierfür nicht geeignet, da sie nur Methodenaufrufe innerhalb eines Systems zulassen. Socketverbindungen sind prinzipiell gut geeignet, um Daten zwischen unterschiedlichen Systemen auszutauschen. Leider ist eine Verknüpfung mittels Socketverbindungen auf mobilen Endgeräten derzeitig nur unter Einbezug der Infrastruktur möglich (vgl. Kapitel 6.1.2). Schicht A DCF Stub A Native Socket Native Socket Stub B Schicht B Abbildung 5.4: Dynamic Connection Framework (DCF) Deshalb wurde in diesem Zusammenhang eine Kombination aus nativen Methodenaufrufen und Methodenaufrufen über Socketverbindungen gewählt. Jedoch war ein Ziel, keine Codeanpassung für diese zwei unterschiedlichen Arten des Methodenaufrufs durchführen zu müssen. Realisiert wurde dies durch einen aus dem Bereich der Middleware bekannten Ansatz, die so genannten Stubs. Stubs verschatten den eigentlichen Methodenaufruf. Innerhalb der einzelnen Schichten erscheint ein Methodenaufruf als einfacher nativer Methodenaufruf. Wie er jedoch in der Realität umgesetzt wird, bleibt dort verborgen. Die Stubs stellen alle Methoden der korrespondierenden Schicht zur Verfügung. Der Stub verhält sich also so, als wäre er die korrespondierende Schicht. Wird eine Methode innerhalb des Stubs aufgerufen, prüft dieser, ob die korrespondierende Schicht lokal oder entfernt verfügbar ist, und ruft dann entsprechend dieser Gegebenheit die Methode auf der korrespondierenden Schicht auf. Dazu bleibt bei lokaler Verfügbarkeit der native Methodenaufruf erhalten, bei entfernter Verfügbarkeit wird der Methodenaufruf über eine Socketverbindung realisiert. Da über die Socketverbindung kein direkter nativer Methodenaufruf in der korrespondierenden Schicht durchgeführt werden kann, verfügt die korrespondierende Schicht bei Verteiltheit über einen äquivalenten Stub, der aus den über die Socketverbindung empfangenen Daten wieder native Methodenaufrufe generiert. Abbildung 5.4 zeigt das dynamische Verbindungskonstrukt (DCF) für die zwei Schichten A und B. Prinzipiell ist das DCF-Konstrukt nicht an diese zwei Verbindungstypen 5.4. VERTEILUNG 73 gebunden, sondern kann durch die Integration verschiedenster Verbindungstypen beliebig erweitert werden. Für die Kompatibilität zweier Schichten müssen diese ein gemeinsames Verständnis über die zwischen ihnen ausgetauschten Nachrichten (vgl. [VHT ]) besitzen. Dieses gemeinsame Verständnis bezieht sich auf die Signatur, die Semantik und das Protokoll. Unter Signatur versteht man das gemeinsame Verständnis bezüglich der Syntax. Ein syntaktisch gemeinsames Verständnis wird in der Regel durch die Einführung von Interfaces erzielt. Interfaces beschreiben die von einer Komponente verstandenen Ausdrücke auf der Ebene der Signatur. Sie definieren also die Syntax aller Ausdrücke, die von einer Komponente verstanden werden. Ein gemeinsames Verständnis auf der Ebene der Semantik wird dadurch erreicht, dass alle beteiligten Komponenten den Ausdrücken die gleiche Bedeutung zumessen. Durch die Angabe von Typen innerhalb eines Interfaces wird ein gewisser Grad an Semantik für das gemeinsame Verständnis spezifiziert. So kann einem Parameter namens Position“, der noch keinerlei semantische Information enthält, durch die Angabe ” des Typs WGS84Position“ die Bedeutung einer Positionsinformation georeferenziert zum WGS84-Datum ” zugeordnet werden. Eine weitere Spezifikation auf der Ebene der Semantik wurde an dieser Stelle nicht weiter fortgeführt. Auf der Ebene des Protokolls muss ein gemeinsames Verständnis über die Reihenfolge der Ausdrücke erreicht werden. Angaben zur Reihenfolge von Parametern sind in den Interfaces enthalten. Die Reihenfolge der einzelnen Methodenaufrufe wurde in der Implementierung nicht weiter beachtet, da es sich um eine (beinahe) zustandslose Kommunikation handelt und so Reihenfolgen von Methodenaufrufen keine Rolle spielen. Ein großer Teil der Kompatibilitätsspezifikation wird demnach bereits durch Interfaces abgedeckt. Deshalb wurden bei der Implementierung ausschließlich Interfaces für das gemeinsame Verständnis spezifiziert. Ein Interface, welches das Verständnis der Dienstinitiierungschicht bzw. ihres Stubs für native Methodenaufrufe beschreibt, ist im Folgenden gegeben (in Form eines Java-Interfaces): 2 4 public interface InitiationInterface { void setTriggers(ECARule[] triggers); void deleteTriggers(TID[] tIDs); } Entsprechend dieses Interfaces versteht die Dienstinitiierungsschicht bzw. deren nativer Stub zwei Methodenaufrufe namens setTriggers und deleteTriggers. Wobei setTriggers nachfolgend ein Array aus einzelnen ECA-Regeln vom Typ ECARule erwartet und deleteTriggers ein Array aus Trigger-IDs vom Typ TID. Durch die Spezifikation dieser Interfaces und der Implementierung des Interfaces durch die entsprechende Klasse bzw. die korrespondierenden Stubs des DCF wird Kompatibilität gewahrt. Ein Klassendiagramm des DCF, das die Interfaces zweier Schichten enthält, ist in Abbildung 5.5 dargestellt. Für die Methodenaufrufe über die Socketverbindung wurde ein proprietäres Übertragungsprotokoll 2 verwendet. Standardisierte Protokolle wie HTTP oder SMTP zeigten für diese Anwendung einen zu großen Signalisierungsoverhead und wurden deshalb nicht eingesetzt. Das hier eingesetzte Übertragungsprotokoll besteht im Wesentlichen aus dem in UTF-8 kodierten Methodennamen und den aneinander gereihten Parametern. Als Transportprotokoll wurde TCP eingesetzt. Während bei nativen Methodenaufrufen in Java Objekte wie ECARule oder TID direkt (bzw. Zeiger auf diese Objekte wegen Call-By-Value-Parameterübergabe) übergeben werden, kann diese Art der Parameterübergabe nicht für die Socketverbindung eingesetzt werden, da durch die verteilten Systeme kein Shared-Memory vorhanden ist. Zur Übergabe der Parameter müssen diese in eine serialisierte Form gebracht und in dieser Form an den Empfänger übertragen werden. Aufgrund der Tatsache, dass J2ME mit CLDC derzeit keine Objektserialisierung unterstützt, können nur primitive Datentypen (wie z.B. int, double oder char) oder Objekte, die ausschließlich öffentlich zugängliche primitive Datentypen (wie z.B. Arrays über primitive Datentypen, Wrapper-Klassen) oder serialisierbare Objekte enthalten, übertragen werden. Die Methoden zur Übertragung primitiver Datentypen und Character-Arrays werden von 2 Das Übertragungsprotokoll definiert die Form, in der Daten übertragen werden, und ist von [VHT ]s Protokollebene zu unterscheiden 74 KAPITEL 5. IMPLEMENTIERUNG Abbildung 5.5: Vereinfachtes Klassendiagramm des DCF J2ME zur Verfügung gestellt. Zu implementieren war in diesem Zusammenhang deshalb nur noch die Objektserialisierung, die Objekte auf primitive Datentypen abbildet. Dazu wurden jeder Klasse, die über die Socketverbindung übertragen werden muss, die Methoden serialize und deserialize hinzugefügt, um die Objekte der Klasse serialisieren und deserialisieren zu können. Zur Serialisierung werden alle Instanzvariablen des Objektes sowie in manchen Fällen Zusatzinformationen serialisiert. Handelt es sich dabei ausschließlich um primitive Datentypen, so ist die Serialisierung damit abgeschlossen, und die primitiven Datentypen können übertragen werden. Sind in den Instanzvariablen aber Objekte enthalten (diese müssen nach obiger Bedingung serialisierbar sein), so muss ein weiterer Rekursionsschritt ausgelöst werden, der die Serialisierung der Objekte durchführt. Allgemein muss der Caller-Stub für Socketverbindungen so nur die Methode serialize auf das zu übergebende Objekt aufrufen und der Callee-Stub mittels der Methode deserialize das Objekt aus dem empfangenen Datenstrom wieder aufbauen. Dadurch wurde ein kongruentes Konstrukt zur Objektserialisierung in J2SE geschaffen. 5.4.2 Plattformunabhängigkeit der Schichten Nachdem nun die Kompatibilität zwischen den einzelnen Schichten betrachtet wurde, muss desweiteren die Kompatibilität zu den darunter liegenden Schichten der Plattform analysiert werden (vgl. Abb. 5.5. UMSETZUNG DER LBPS-SCHICHTEN 75 3.4). Je nach Verteilung der Schichten verändert sich die darunter liegende Programmierplattform. Lokale Schichten nutzen J2ME, Schichten in der Infrastruktur J2SE (vgl. Kapitel 3.2). Ein dynamischer Ansatz, der abhängig von der zugrunde liegenden Verteilung die Kommunikation anpasst, wie bei der InterLBPS-Schichtenkommunikation, ist bei der Inter-Plattform-Schichtenkommunikation“ nur sehr umständ” lich realisierbar. Da beide Plattformen sich im Grunde genommen sehr ähnlich sind und eine gemeinsame Funktionsschnittmenge besitzen, die einen großen Teil der Basisfunktionalität enthält und von beiden Plattformen unterstützt wird, wurde in der Implementierung der LBPS-Schichten versucht, sich auf diese Funktionsschnittmenge zu beschränken. Bis auf die Klassen, die für die Netz- (java.net) und IOVerbindungen (java.io) zuständig sind gelang dies ohne großen Aufwand. Das Problem der Netz- und IOVerbindungsklassen wurde durch die Integration eines Adapterpaketes [me4 ] seitens der J2SE-Plattform, das eine Transformation der J2ME-Verbindungsklassen auf die J2SE-Verbindungsklassen durchführt, gelöst. Dadurch war es möglich, alle LBPS-Schichten auf der J2ME- oder der J2SE-Umgebung auszuführen. 5.5 Umsetzung der LBPS-Schichten Dieses Kapitel zeigt einige Implementierungsdetails der LBPS-Schichten Dienstinitiierung, Initiierungsmiddleware, Dienstausführung, Präsentationsmiddleware und Dienstpräsentation. In der Schicht der Dienstausführung dient die MoBiLe-Applikation der eigentlichen Mehrwertgenerierung des Mountain-Bike-Navigationsdienstes. Für die entsprechenden Klassen wurde der Namensraum de.vpe.mobile.application gewählt. Die Dienstinitiierung, die Initiierungsmiddleware, die Präsentationsmiddleware und die Dienstpräsentation stellen die Location-based Push-Architektur dar, die der MoBiLe-Applikation die Push-Funktionalität zur Verfügung stellt. Die Klassen dieser Schichten sind folgenden Namensräumen zugeordnet: de.vpe.lbps.initiation, de.vpe.lbps.initiationmiddleware, de.vpe.lbps.presentationmiddleware und de.vpe.lbps.presentation. Dabei gibt es einige Konstrukte, die innerhalb mehrerer Schichten auftreten. Dazu gehören zum Beispiel die Klassen, die zur Beschreibung von Ortsinformationen dienen oder das Konzept der ECA-Regeln. Ihre Pakete wurden unter dem Namensraum de.vpe.lbps.shared zusammengefasst (vgl. Abb. 5.6. Im Folgenden wird kurz auf die Implementierung der einzelnen Schichten eingegangen. Da eine vollständige Abhandlung aller Implementierungsdetails den Rahmen dieser Arbeit sprengen würde, würden nur einige Aspekte aufgegriffen, die die Funktionsweise des Demonstrators veranschaulichen sollen. Eine Gliederung erfolgt anhand der einzelnen Schichten des Dienstes. Dabei werden einige Implementierungsdetails aus dem Paket de.vpe.lbps.shared aufgrund der Relevanz innerhalb mehrerer Schichten der Beschreibung der einzelnen Schichten vorangestellt. 5.5.1 Ortsinformationen Da der Fortuna Clip-On Bluetooth GPS Receiver wie die meisten handelsüblichen GPS-Empfänger standardmäßig Positionsinformationen im WGS84-Datum ausdrückt und keine weiteren Datums notwendig waren, wurde ausschließlich dieses Datum mit dem entsprechenden Format zur Kodierung von Positionsinformationen genutzt. Aufgrund der zeitlichen Restriktionen dieser Arbeit wurden nur zweidimensionale Positionsinformationen auf der Erdoberfläche und keine Informationen zur Hemisphäre eingesetzt. Zur Bestimmung der Bewegungsrichtung wurde neben der Position die Richtung als zweite primäre Ortsinformation benutzt. Schließlich kam für die frühzeitige Dienstinitiierung, abhängig von der Geschwindigkeit des Nutzers, die sekundäre Ortsinformation Geschwindigkeit hinzu. Für die Implementierung ergaben sich demnach drei verschiedene Ortsinformationen, wobei Latitude und Longitude der Position durch zwei getrennte Klassen behandelt wurden (vgl. Abb. 5.7. 76 KAPITEL 5. IMPLEMENTIERUNG Abbildung 5.6: Überblick über Paketstruktur 5.5.2 Trigger Wichtige Softwarebausteine, die vor allem für die Dienstinitiierung von Interesse sind, sind die in Kapitel 4.2 vorgestellten Trigger. Wie bereits beschrieben, kann eine Operationalisierung durch ECA-Regeln erfolgen. Diese wurden auch für den Demonstrator gewählt. Im Speziellen handelt es sich hierbei um Locationbased ECA-Regeln. Im Gegensatz zu allgemeinen ECA-Regeln, sind Location-based ECA-Regeln auf die ortsabhängige Initiierung ausgerichtet. Allgemein bestehen ECA-Regeln aus einer Menge von Ereignissen, einer Bedingung und einer Menge von Aktionen. Für Location-based ECA-Regeln stellen Ereignisse jegliche Art von Ortsinformationen dar und Bedingungen können als freie Variablen lediglich Variablen von der Typklasse der Ortsinformationen enthalten. Aktionen sind zuständig für die eigentliche Initiierung des Dienstes und können zusätzlich Ortsinformationen enthalten. Jede ECA-Regel muss mindestens diese drei Elemente besitzen. Da sich Trigger von Dienst zu Dienst unterscheiden können und auch innerhalb eines Dienstes unterschiedliche Trigger zur Anwendung kommen können, müssen diese dynamisch konfigurierbar sein. Das bedeutet, dass sie nicht durch ein festes Konstrukt umsetzbar sind, sondern die Ereignisse, Bedingungen und Aktionen für jeden Trigger frei definiert werden können. In vielen Fällen, jedoch nicht zwingend, werden diese Trigger innerhalb der Dienstausführungsschicht generiert. Diese hat meist alle nötigen Informationen, die für die Generierung der Trigger notwendig sind. Sie weiß, welche Ereignisse für die Auswertung relevant sind, wie die Bedingung gestaltet sein muss und welche Form die Aktionen haben müssen. All diese Informationen sind zur Generierung der Trigger wichtig und müssen innerhalb der ECA-Regeln dynamisch konfigurierbar sein. Eine sinnvolle Lösung zur Implementierung dieser ECA-Regeln ist deshalb, alle Informationen und Funktionen für den Trigger innerhalb des Triggers zu kapseln und eine Zugriffsmethode, z.B. updateSpatialInformation(SpatialInformation[] si), zu definieren, die dem Trigger neue Ortsinformationen übergibt. Der Trigger überprüft dann selbstständig, ob die neuen Ortsinformationen eine Auswertung der Bedingung nötig machen. Falls ja, wird die Bedingung ausgewertet und gegebenenfalls eine Aktion ausgelöst. Der Initiator hat so nur die Aufgabe, bei Verfügbarkeit neuer Ortsinformationen die up- 5.5. UMSETZUNG DER LBPS-SCHICHTEN 77 Abbildung 5.7: Klassendiagramm der eingesetzten Ortsinformationen dateSpatialInformation-Methode des Triggers aufzurufen. Alle restlichen Schritte übernimmt der Trigger selbst. Dadurch sind alle für diesen Trigger relevanten Informationen und Funktionen innerhalb des Triggers gekapselt und der Initiator benötigt kein Wissen über die Trigger außer deren standardisierte Zugriffsmethode. Da der Classloader von J2ME nur das Laden von Klassen zulässt, die zum Installationszeitpunkt in der MIDlet-Suite enthalten sind (vgl. Kapitel 3.2), müssen alle für die Anwendung nötigen ECA-Regeln bereits zum Installationszeitpunkt existieren. Dies führt auf den ersten Blick zu einer starken Einschränkung der Anwendbarkeit, vor allem in Bezug auf eine Vielzahl verschiedener LBPSs. Bereits zum Installationszeitpunkt muss bekannt sein, welche Art von Triggern jemals innerhalb des Systems eingesetzt werden, um sie alle in der MIDlet-Suite zu integrieren. Lösung dieses Problems stellt eine generische ECA-Regel dar, deren Ausprägungen sich nur durch die Belegung der Instanzvariablen unterscheidet. Diese generische ECA-Regel kann bereits zum Installationszeitpunkt in die MIDlet-Suite integriert werden. Einzelne Ausprägungen der ECA-Regeln ergeben sich dann durch Belegung der Instanzvariablen. Die generische ECA-Regel muss als Instanzvariablen mindestens die dynamisch konfigurierbaren Elemente Ereignisse, Bedingung und Aktionen enthalten. Erweiterte ECA-Regeln können natürlich weitere Konfigurationsmöglichkeiten unterstützen, wie die Spezifikation von Gedächtnisstufen oder Detriggering (vgl. [Brow ]). In der Implementierung dieser Arbeit wurde aber nur die einfache Variante der generischen ECA-Regel eingesetzt, da diese die Funktionsfähigkeit bereits ausreichend demonstriert. Bei der Anwendung der Location-based Push-Architektur unter Verteiltheit, müssen Objekte der ECARegeln über Systemgrenzen hinaus übertragen werden. Dazu ist eine Serialisierung einzelner ECA-Regeln nötig. Wie bereits oben beschrieben, wird nur eine Objektserialisierung von Objekten, die ausschließlich serialisierbare Instanzvariablen enthalten, unterstützt. Dazu müssen alle Instanzvariablen aus primitiven Datentypen, bzw. aus serialisierbaren Objekten bestehen. Da Ereignisse nur beschreiben, welchen Typ die Ortsinformationen haben müssen, die die Auswertung der Bedingung nötig machen, reicht hier eine Angabe der oben beschriebenen Typklasse der Ortsinformation aus. Sie bestehen demnach aus einer Menge an Ortsinformationstypen. Ortsinformationstypen enthalten nur ihren Namen, der als String (bzw. Array aus Charactern) serialisierbar ist. Um die Bedingung in eine serialisierbare Form zu bringen, wurde eine String-Repräsentation der Bedingung gewählt. Zur Auswertung dient eine Java-Bibliothek namens JEPLite (Java Expression Parser Lite) [Kola ]. Obwohl diese für J2SE konzipiert wurde, war eine Anpassung an J2ME unter Verlust einer geringen Funktionsmenge möglich. JEPLite ist eine vereinfachte Version von JEP [Funk ]. JEPLite stellt einen etwas geringeren Funktionsumfang als JEP bereit, zeigt sich deshalb aber effizienter in der Auswertung und geringer in der Größe, was sich positiv auf die Anwendung auf mobilen Endgeräten auswirkt. JEP sowie JEPLite stellen Funktionen zum Parsen und Auswerten von mathematischen Ausdrücken innerhalb von Strings zur Verfügung. Diese Ausdrücke können mathematische Operatoren wie die Addition, Substrakti- 78 KAPITEL 5. IMPLEMENTIERUNG on, Multiplikation und Division, sowie die Potenz-, Wurzel- und Modulo-Funktion enthalten. Desweiteren können Boole’sche Operatoren, wie das Boole’sche AND, das Boole’sche OR und das Boole’sche NOT und mathematische Konstanten wie Pi und die Euler’sche Zahl genutzt werden. Nach der Anpassung auf J2ME blieben außerdem noch die trigonometrischen Funktionen Sinus, Kosinus und Tangens bestehen. Mit dem gelieferten Funktionsumfang ließen sich alle für dieses Anwendungsszenario nötigen Bedingungen umsetzen. Aktionen stehen in zwei Varianten zur Verfügung, die für das Anwendungsszenario ausreichend sind. Diese sind InitiateAction und InitiatePiggyBackingDataAction. Während erstere ausschließlich zur reinen Dienstinitiierung gedacht ist, lässt die InitiatePiggyBackingDataAction das Anhängen von Ortsinformationen zu. Die Ortsinformationen werden dann, falls verfügbar, an die Initiierungsnachricht angehängt. Durch das hier beschriebene Konzept der ECA-Regeln konnten alle Anforderungen wie gewünscht umgesetzt werden. Durch seine Dynamik ermöglicht dieser Ansatz hierüber hinaus sogar einen Einsatz in weitaus mehr Anwendungen als nur dem MoBiLe-Service. 5.5.3 Dienstinitiierung Die Dienstinitiierungsschicht ist zuständig für die Anwendung der oben beschriebenen ECA-Regeln. Ausreichend für die Implementierung des MoBiLe-Service ist vorerst ein einziger Initiator für Ortsinformationen, die durch den GPS-Empfänger geliefert werden. Dazu erhält der Initiator periodisch Ortsinformationen vom GPS-Empfänger durch eine Callback-Operation mit einer ähnlichen Umsetzung wie in der LAPI (vgl. Kapitel 3.2). Zwischen Initiator und GPS-Empfänger dient ein Parser zur Generierung der Ortsinformationsobjekte. Der Parser extrahiert dazu die Position (Latitude und Longitude), die Bewegungsrichtung und die Geschwindigkeit aus dem RMC- und dem VTG-Datensatz des NMEA-Protokolls und baut daraus oben beschriebene Ortsinformationsobjekte auf. Wurden dem Initiator bereits Trigger zugeteilt, so ruft dieser bei jeder Aktualisierung der Ortsinformationen die updateSpatialInformation-Methode jedes einzelnen Triggers auf. Der Trigger wertet dann, wenn es sich um eine relevante Ortsinformation handelt, die Bedingung aus und sucht entsprechende Aktionen. Eine direkte Ausführung der Aktionen soll innerhalb des Triggers nicht möglich sein, da dieser ansonsten Kenntnis über die korrespondierende Initiierungsmiddleware benötigen würde, diese aber dem Trigger verborgen bleiben soll. Deshalb gibt der Trigger durch den Aufruf der updateSpatialInformation-Methode alle durchzuführenden Aktionen zurück, die dann vom Initiator ausgeführt werden. Abbildung 5.8 zeigt das vereinfachte Klassendiagramm der Dienstinitiierungsschicht. 5.5.4 Initiierungsmiddleware In der Initiierungsmiddleware wird der gegenseitige Zugriff der Dienstinitiierungsschicht und der Dienstausführungsschicht verwaltet. Der Verbindungsaufbau wird dabei von der Dienstausführungsschicht angestoßen. Im Normalfall wird eine Applikation zu Beginn einer Interaktion die zur Initiierung nötigen Trigger in der Dienstinitiierungsschicht anmelden. Deshalb übergibt sie die nötigen Trigger an die Initiierungsmiddleware, welche Kenntnis über alle derzeit zur Verfügung stehenden Initiatoren besitzt. Jeder Initiator muss sich dazu bei der Initiierungsmiddleware registrieren. Bestandteil der Anmeldung ist die Menge an Ortsinformationen, die dieser Initiator durch Sensoren verwaltet. Die Initiierungsmiddleware legt die Informationen zu den Sensoren und zur Verbindung mit dem Initiator in einer geeigneten Speicherstruktur ab, um so bei Bedarf darauf zurückgreifen zu können. Will nun eine Applikation Trigger auf Initiatoren verteilen und übergibt sie in diesem Schritt an die Initiierungsmiddleware, so sucht diese nach geeigneten Initiatoren in der Menge aller registrierten Initiatoren. Ist die Suche erfolgreich, übergibt sie dem jeweiligen Initiator über die abgespeicherte Verbindung den oder die Trigger. Falls für einen Trigger kein entsprechender Initiator verfügbar ist, erhält die Applikation eine negative Quittung. Bei einer späteren Initiierung ruft der Initiator die Methode initiate mit seiner ID, der ID des gefeuerten Triggers und angehängten Ortsinformationen im Falle der InitiatePiggyBackingDataAction 5.5. UMSETZUNG DER LBPS-SCHICHTEN 79 Abbildung 5.8: Dienstinitiierung auf. Die Initiierungsmiddleware leitet die Initiierung dann an die entsprechende Applikation weiter. 5.5.5 Navigationsdienst MoBiLe Die Dienstausführungsschicht stellt in dieser Arbeit die MoBiLe-Applikation dar. Sie entspricht dem Kern des MoBiLe-Service und ist somit für die eigentliche Navigation verantwortlich. Ohne große Anpassung lässt die Implementierung aber auch andere LBPSs parallel zum MoBiLe-Service zu. Derartige Dienste können zum Beispiel der ortsabhängige Email-Push-Dienst sein. Dieser wird aber im Folgenden nicht weiter behandelt. Darstellungsformen Die MoBiLe-Applikation generiert Navigationsinformationen, die sich durch qualitativ hochwertigen Informationsgehalt auszeichnen, und so vom Nutzer einen möglichst geringen kognitiven Aufwand verlangen. Eine diesen Anforderungen entsprechende Darstellung ist die egozentrische Pfeildarstellung. Sie besteht aus einem einzigen Pfeil und keinen Informationen über ortsnahe Landmarken wie die Kartendarstellung. Dadurch ist sie nur in einem äußerst geringen Umfeld gültig, zeichnet sich aber demgegenüber dadurch aus, dass sie keinerlei unnötigen Informationsgehalt enthält. Durch die Egozentrik referenziert zur Bewegungsrichtung muss der Nutzer keine Umorientierung der Darstellung durchführen. Grundsätzlich stehen der Applikation durch die Routenbeschreibung aber nur allozentrische Routeninformationen zur Verfügung. Zur Transformation der allozentrischen Darstellung in die egozentrische Darstellung muss die Applikation Kenntnis über die aktuelle Bewegungsrichtung des Nutzers besitzen. Ist diese nicht verfügbar, wird keine Transformation durchgeführt, dafür aber die Allozentrik in der Darstellung markiert. Problem aller grafischen Darstellungen ist, dass sie zur Wahrnehmung die Aufmerksamkeit des mensch- 80 KAPITEL 5. IMPLEMENTIERUNG lichen Sehsinnes benötigen. Während dies bei geringen Geschwindigkeiten (z.B. bei Fußgängern) kein Problem darstellt, kann eine ausschließlich visuelle Wahrnehmung bei hohen Geschwindigkeiten meist nicht angewendet werden, da der Sehsinn bereits für die Koordination der Bewegung benötigt wird. Deshalb setzt die Applikation eine weitere Darstellungsform ein, die auf ein anderes menschliches Sinnesorgan gerichtet ist. Zusätzlich zur visuellen Wahrnehmung wird die akustische Wahrnehmung genutzt. Dazu generiert die Applikation eine verbale Darstellung der Navigationsinformation. Sie beinhaltet ausschließlich egozentrische Navigationsinformationen (referenziert zur Bewegungsrichtung). Dafür wurde die einzuschlagende egozentrische Richtung in zwei Bereiche quantisiert. Der rechtsweisende Bereich deckt das Intervall 1◦ − 179◦ und der linksweisende Bereich das Intervall 181◦ − 359◦ gegenüber der Bewegungsrichtung ab. Die verbale Darstellung präsentiert eine gröbere Navigationsinformation als die korrespondierende grafische Darstellung, ermöglicht aber eine Wahrnehmung der Navigationsinformation ohne Gebrauch der visuellen Sinnesorgane, die bereits für die Bewegung benötigt werden. Die verbale Darstellung gilt eher als unterstützend, während die grafische Darstellung als primäre Darstellungsform gilt. Routen Die entscheidende Information, die zur Generierung der Navigationsinformation dient, ist die Route. Die Operationalisierung der Route basiert auf der in Kapitel 2.2 vorgestellten Routenbeschreibung mittels Aktionspunkten. Dementsprechend besteht eine Route aus einer geordneten Liste aus Aktionspunkten. Jeder Aktionspunkt besitzt eine Position und eine an diesem Aktionspunkt einzuschlagende Richtung. Zusätzlich muss es die Möglichkeit geben, Routen durch Beschreibungen wie Name der Route, Schwierigkeitsgrad, Länge der Route, zu überwindende Höhenmeter, etc. zu annotieren. Da Art und Menge dieser Annotationen sich von Route zu Route unterscheiden können, wurde hier eine Klasse (de.vpe.lbps.shared.route.RouteProperty) geschaffen, die beliebige Key-Value-Paare enthalten kann. Jeder Route können beliebig viele dieser RoutePropertys angehängt werden. Die ebenfalls in der Route enthaltenen Aktionspunkte werden durch die oben genannten Positionsinformationen beschrieben. Außerdem besitzen sie eine Richtungsinformation, um die einzuschlagende Richtung zu deklarieren. Routeninformationen werden von Routendiensten bereitgestellt. Die Implementierung eines einfachen Routendienstes, der eine grafische Routenerstellung zulässt, ist im Anhang A beschrieben. Dieser Routendienst stellt entweder komplette Routen, die Annotationen von Routen oder die Aktionspunkte von Routen an einer wohldefinierten Schnittstelle bereit. Diese können vom Navigationsdienst dort abgerufen werden. Generierung der Initiierungsvorschrift Zu Beginn einer Navigation generiert die Navigationsapplikation aus den Aktionspunkten der Route die oben beschriebenen ECA-Regeln. Pro Aktionspunkt wird eine ECA-Regel erzeugt. Da für die Navigation relevante Zustände nur durch eine Positionsveränderung eintreten können, sind Ereignisse jeder ECARegel vom Typ Latitude und Longitude. Die Bedingung, die bei Eintritt des Ereignisses ausgewertet werden soll, entspricht im Grunde genommen der Bedingung, die bereits in Kapitel 4.2 erarbeitet wurde: (ux − ax )2 + (uy − ay )2 ≤ (t · v)2 Für t zeigte sich in der Realität ein Wert von 4 Sekunden als ausreichend lang, um die Navigationsinformation aufzunehmen und zu verarbeiten, und andererseits als kurz genug, um Zweideutigkeiten in der Wegewahl zu vermeiden. Die praktische Nutzung des Fortuna Clip-On Bluetooth GPS Receivers zeigte, dass eine Abweichung der realen Position und der gemessenen Position von bis zu ∼ 10 Metern erreicht wird. Um dieser Ungenauigkeit entgegenzuwirken, musste der Radius des Aktionskreises um diese 10 Meter erweitert werden. In der Bedingung wurde dies durch Hinzunahme einer Konstanten in die Radiusberechnung erreicht: (ux − ax )2 + (uy − ay )2 ≤ (4 · v + 10)2 5.5. UMSETZUNG DER LBPS-SCHICHTEN 81 Abbildung 5.9: Ellipsoidischer Abstand der Punkte P1 und P2 Diese Bedingung bezieht sich jedoch auf ein kartesisches, ebenes Koordinatensystem. Zur Berechnung des Abstandes auf einer Ellipsoidenoberfläche 3 muss in der Betrachtung die Oberflächenkrümmung hinzugezogen werden (vgl. Abb. 5.9). Positionsinformationen stehen durch den Fortuna Clip-On Bluetooth GPS Receiver in Form von LLA-Werten zum WGS84-Datum, d.h. in ellipsoidischen Koordinaten, bereit. Ausgehend von der Position des Aktionspunktes und des Nutzers auf der Ellipsoidenoberfläche muss eine Umrechnung auf den ellipsoidischen Abstand dieser Punkte erfolgen. Dazu werden getrennt die Abstände auf dem Längenkreis und dem Breitenkreis bestimmt und dann daraus der Abstand zwischen den beiden Punkten ermittelt. Wie bereits in Kapitel 2.1 beschrieben wurde, gibt der Latitudenwert den Winkel zwischen Äquator, dem Referenzpunkt und dem Breitengrad innerhalb eines Längenkreises an. Für die Berechnung des Abstandes zwischen Nutzer und Aktionspunkt auf dem Längenkreis muss die Bogensegmentlänge bestimmt werden. Da alle Längenkreise den gleichen Umfang besitzen, reicht die Umrechnung mittels eines konstanten Faktors aus. Hierbei entspricht eine Bogenminute einer Bogensegmentlänge von 1.852.276 Metern (≈ eine nautische Meile) bei einem Meridianumfang von 40.009.153 Metern. Abbildung 5.10 zeigt den Abstand auf dem Meridian lat∆ von P1 und P2 , die durch lat1 und lat2 beschrieben werden. Etwas schwieriger ist die Berechnung des Abstandes auf dem Breitenkreis, da die Breitenkreise keinen konstanten Umfang besitzen. Je weiter weg sich der Breitenkreis vom Äquator befindet, desto geringer wird sein Umfang. Der Umfang des Breitenkreises kann jedoch mit einer gewissen Toleranz relativ einfach berechnet werden und entspricht dem Produkt aus dem Kosinus des Latitudenwertes mit dem Äquatorradius (= 40.076.592 Meter). Mit Hilfe des Umfangs kann nun der Abstand zwischen Nutzer und Aktionspunkt auf dem Breitenkreis berechnet werden. Diese Abstandsberechnung unterliegt einigen Vereinfachungen. Eine exakte Berechnung des Abstandes (soweit dies überhaupt möglich ist) steht aber in keinem Verhältnis zur Verbesserung des Gesamtergebnisses, da die hier berechneten Werte sich bereits sehr nahe an der Realität bewegen und eine Verbesserung nur unter sehr hohem Rechenaufwand erzielt würde. Insgesamt ergibt sich somit folgender logischer Ausdruck (Latituden- und Longitudenwerte in Dezimalgradangaben): ((ulat − alat ) · 1.852.276)2 + ((ulon − alon ) · cos(alat · 40.076.592)2 ≤ (4 · v + 10)2 Als Aktion wurde die InitiatePiggyBackingDataAction, die die aktuelle Bewegungsrichtung an die Dienstinitiierung anhängt, gewählt. Für jeden Aktionspunkt muss nun eine ECA-Regel mit den hier beschriebenen Ereignissen, Bedingungen und Aktionen erzeugt und der Initiierungsmiddleware übergeben werden. 3 Zur Vereinfachung wird in dieser Arbeit die Erde als Ellipsoid betrachtet 82 KAPITEL 5. IMPLEMENTIERUNG P2 Meridian lat2 lat1 latδ lat∆ P1 Äquator Abbildung 5.10: Abstand der Punkte P1 und P2 auf dem Längenkreis Routenführung Wird durch die Dienstinitiierungsschicht die Dienstausführung angestoßen, wird anhand der Route und beliebiger anderer Informationen die Navigationsinformation in den oben beschriebenen Darstellungsformen generiert. Mindestens ist dazu der aktuelle Aktionspunkt mit der einzuschlagenden Richtung nötig. Die Identifikation dieses Aktionspunktes erfolgt anhand der durch die Dienstinitiierung gelieferten ID des gefeuerten Triggers. Die ID entspricht genau einem Aktionspunkt der Route. Die allozentrische Austrittsrichtung ist in diesem Aktionspunkt spezifiziert. Die Austrittsrichtung kann bereits zur Generierung der allozentrischen Navigationsinformation genutzt werden. Wurde der Initiierung die Bewegungsrichtung des Nutzers angehängt, kann darauf eine Umorientierung der Navigationsinformation erfolgen. Wurden alle Navigationsinformationen erstellt, werden sie an die Präsentationsmiddleware übergeben. 5.5.6 Präsentationsmiddleware Die Präsentationsmiddleware hat eine ähnliche Aufgabe wie die Initiierungsmiddleware. Sie verwaltet den Zugriff der Dienstausführungsschicht auf die Dienstpräsentationsschicht. Dadurch benötigt die Dienstausführungsschicht keinerlei Kenntnis über die Fähigkeiten und Eigenschaften der einzelnen Präsentatoren. Außerdem muss sie sich nicht um Kommunikationsdetails zu den Präsentatoren kümmern. Diese Aufgaben übernimmt die Präsentationsmiddleware. Jeder Präsentator meldet sich zu Beginn bei der Präsentationsmiddleware an. Die Anmeldung muss dabei Informationen zu unterstützten Medienformaten und Charakteristika dieser Medien beinhalten. Unterstützt der Präsentator zum Beispiel die Darstellung von Grafiken im PNG-Format, so sollte in den Charakteristika zumindest die Displaygröße enthalten sein. Dadurch kann die Präsentationsmiddleware die von der Dienstausführungsschicht übergebenen grafischen Navigationsinformationen auf die Displaygröße anpassen. Analoges gilt für andere Darstellungsformen. Die Präsentationsmiddleware legt alle Informationen zu unterstützten Medienformaten und Charakteristika, sowie Informationen über den Zugriff auf den Präsentator in einer geeigneten Datenstruktur ab. Wird der Präsentationsmiddleware eine Navigationsinformation übergeben, überprüft sie, ob ein registrierter Präsentator existiert, der die Navigationsinformation darstellen kann. Gegebenenfalls kann hier eine Transformation der Navigationsinformation zwischen verschiedenen Medienformaten erfolgen. Handelt es sich um eine grafische Darstellung, erfolgt in jedem Fall eine Anpassung an die Displaygröße des Präsen- 83 5.5. UMSETZUNG DER LBPS-SCHICHTEN Äquator Parallele long2 long1 longδ P2 long∆ Nullmeridian P1 Abbildung 5.11: Abstand der Punkte P1 und P2 auf dem Breitenkreis tators. Gegebenenfalls folgen weitere Anpassungen an Farbtiefe, Farbwahl, etc. Abschließend übergibt die Präsentationsmiddleware die Navigationsinformation an den entsprechenden Präsentator. Da die Objektserialisierung keine Serialisierung von derartigen Medien zulässt und so keine Übergabe der Navigationsinformation an den Präsentator bei Verteiltheit möglich ist, muss an dieser Stelle eine andere Technik eingesetzt werden. MIDP verfügt über die Möglichkeit Medien über Datenströme zu laden. Dadurch können grafische Medien wie folgt geladen werden: Image image = Image.createImage(Connector.openInputStream(mediaAddress)) Für MIDP 2.0 lädt folgender Codebaustein verbale Medien: Player player = Manager.createPlayer(mediaAddress) Auf diese Weise ist es möglich, Medien zur Laufzeit auf das mobile Endgerät zu laden. Dieser Vorgang muss aber vom mobilen Endgerät angestoßen werden. Deshalb wird von der Präsentationsmiddleware das Medium zum Beispiel auf einem Webserver öffentlich zugänglich hinterlegt und dem Präsentator die URL, unter der das Medium zugänglich ist, übergeben. Der Präsentator kann daraufhin das Medium laden und darstellen. 5.5.7 Dienstpräsentation Die Dienstpräsentation stellt Medien dar, welche ihr von der Dienstausführungsschicht überlassen wurden. Für den MoBiLe-Service wurden zwei Präsentatoren implementiert. Der RasterPresenter ist zuständig für die Darstellung von Rastergrafiken im PNG-Format. PNG wurde als Format gewählt, da dies derzeit das einzige für MIDP vorgeschriebene Grafikformat ist und so auf jedem Mobiltelefon mit MIDP unterstützt wird. Der zweite Präsentator, der SoundPresenter, kann verschiedenste verbale Medien abspielen. Die unterstützten Medienformate können von Endgerät zu Endgerät unterschiedlich sein. Für die Dienstpräsentation kommen keine Anwendungen, die standardmäßig auf dem mobilen Endgerät verfügbar sind, in Frage, da diese kein Pushing unterstützen. Standardanwendungen, wie ein InternetBrowser, der bereits auf den meisten mobilen Endgeräten vorhanden ist, arbeiten meist im RequestResponse-Modus und sind deshalb höchstens unterstützend einsetzbar. 84 KAPITEL 5. IMPLEMENTIERUNG 5.6 Konfigurationskomponente Abbildung 5.12: Beispiele der Konfigurationsoberfläche Die Location-based Push-Architektur ist durch die oben beschriebene Implementierung bereits voll funktionsfähig. Zur Steuerung, Kontrolle und Konfiguration, d.h. zur Auswahl von Routen, zur Auswahl von Darstellungsformen, zum Starten und Beenden der Navigation, etc. muss allerdings noch eine weitere Komponente hinzugefügt werden. Diese ermöglicht die Steuerung der Dienstinitiierungs-, der Dienstausführungsund der Dienstpräsentationsschicht (vgl. Abb. 5.13). Da eine Steuerung von Dienstinitiierungs- und Dienstpräsentationsschicht nur lokal auf dem mobilen Endgerät möglich sein soll, kann hierfür auf eine lokale Steuerschnittstelle des Initiators und der Präsentatoren zugegriffen werden. Der Zugriff auf die Schnittstelle der Dienstausführung erfolgt über das DCF. Dadurch kann eine Steuerung über native Methodenaufrufe oder über eine Socketverbindung erfolgen. Durch die Implementierung weiterer Stubs, die zum Beispiel eine Unterstützung des HTTP-Protokolls ermöglichen, ist hier auch eine Konfiguration durch einen Internet-Browser möglich. So kann die Route zum Beispiel von zuhause über den Internet-Browser eines stationären Rechners mit großem Display betrachtet und ausgewählt werden und später durch einfaches Starten des Dienstes auf dem mobilen Endgerät die Navigation zu dieser Route erfolgen. Presentation Configuration Presentation MW Application Initiation MW Initiation Abbildung 5.13: Konfigurationskomponente Präsentatoren des MoBiLe-Service enthalten zwei Steuermethoden, die das Starten und Stoppen des Präsentators ermöglichen. Der Initiator besitzt ebenfalls diese Steuermethoden, sowie eine Kontrollmethode, die Aufschluss über den aktuellen Zustand des Initiators liefert. Der MoBiLe-Service besitzt auch die genannten Steuermethoden und zusätzlich eine Menge an Konfigurationsmethoden: • setPreferences zur Konfiguration von gewünschten Darstellungsformen, etc. • getRoutes zur Anzeige von Routen mit bestimmten Annotationen (Name, Länge, etc.) 5.6. KONFIGURATIONSKOMPONENTE 85 • getRouteInfo zur Anzeige von detaillierten Routeninformationen zu einer Route • selectRoute zur Auswahl einer Route • getSelectedRoute zur Anzeige der gewählten Route Zur Nutzung der Steuer-, Kontroll- und Konfigurationsschnittstelle wurde im Rahmen dieser Arbeit eine grafische Oberfläche für MIDP entworfen, die dem Nutzer den Zugriff auf diese Schnittstelle ermöglicht (vgl. Abb. 5.12). Ein Zustandsdiagramm, das den Ablauf der Steuerung, Kontrolle und Konfiguration zeigt, ist in Abbildung 5.14 dargestellt. Abbildung 5.14: Zustandsdiagramm der Konfigurationsoberfläche Die Abbildung zeigt zusätzlich einige Zustände, die für die Konfiguration des DCF und der BluetoothVerbindung mit dem GPS-Empfänger nötig sind. Zur Konfiguration der Bluetooth-Verbindung wurde eine angepasste Version des von [blu ] bereitgestellten Werkzeugs zum Bluetooth-Device-Discovery und Bluetooth-Service-Discovery eingesetzt. Kapitel 6 Evaluierung Im Rahmen dieser Arbeit wurde der MoBiLe-Service, dessen Implementierung im letzten Kapitel dargestellt wurde, realisiert und getestet. Dabei sind sowohl einige Schwächen in der Implementierung identifiziert worden, als auch Probleme in der zugrunde liegenden Technologie. Aufgedeckte Schwächen wurden, falls möglich, in einer überarbeiteten Version des MoBiLe-Service behoben. Einige Probleme in genutzten Technologien wurden in der Implementierung gelöst, bzw. umgangen. Im Rahmen dieser Arbeit konnten allerdings auch einige dieser Probleme nicht oder nur marginal gelöst werden. Dieses Kapitel befasst sich mit den aufgedeckten Schwächen der Implementierung und Problemen in zugrunde liegenden Technologien und gibt, soweit möglich, Lösungsvorschläge. Ein realer Einsatz des MoBiLe-Service innerhalb einer Mountain-Bike-Tour wird am Ende dieses Kapitels evaluiert. 6.1 Evaluierung der Implementierung und Technologie 6.1.1 Probleme von GPS Wie bereits in Kapitel 5.1 beschrieben, wurde zur Ortung des Nutzers der Fortuna Clip-On Bluetooth GPS Receiver eingesetzt. Dieser GPS-Empfänger verfügt über zwei Modi, dem Standardmodus (ST) und dem erweiterten Modus (XT). Für den MoBiLe-Service bietet der XT-Modus den entscheidenden Vorteil, dass dieser einen Empfang auch in empfangsschwachen Gebieten, wie zum Beispiel im Wald, ermöglicht. Außerdem liefert der GPS-Empfänger im XT-Modus bei Stillstand nur eine einzige Position zurück. Im ST-Modus hingegen schwankt die Position in einem Umkreis von ca. 10 Metern um die reale Position. Um dies zu verwirklichen, wird im XT-Modus der Stillstand erkannt und so die Position auf diesen Wert fixiert. Leider wird eine Bewegung aus dieser Stillstandsphase erst sehr spät erkannt, so dass ein Übergang vom Fixwert auf die reale Position erst stark verzögert erfolgt. Diese Tatsache kann die Funktionsfähigkeit des MoBiLe-Service enorm einschränken. Desweiteren reagiert der GPS-Empfänger im XT-Modus bei höheren Geschwindigkeiten verzögert auf Positionsveränderungen. Schon bei 10-20 km/h kann diese Verzögerung bemerkt werden und zu Verfälschungen der gemessenen Position führen. Obwohl bei niedrigen oder keinen Geschwindigkeiten der XT-Modus genauere Positionen mit einer kürzeren Startzeit sogar in empfangsschwachen Gebieten liefert, ist ein Einsatz für den MoBiLe-Service, der auch höhere Geschwindigkeiten unterstützen muss, nicht möglich. Die Nutzung des GPS-Empfängers im ST-Modus liefert ungenauere Positionsinformationen mit längeren Startzeiten nur in empfangsstarken Regionen. Allerdings können akzeptable Werte auch bei höheren Geschwindigkeiten erzielt werden. Aus der Nutzung des ST-Modus resultieren aber leider folgende Probleme. Die Positionsbestimmung im Wald ist teilweise stark eingeschränkt oder gar nicht möglich. Desweiteren kann kein Stillstand erkannt werden, da der GPS-Empfänger durch die Ungenauigkeit der Positionsbestimmung von einer ständigen Bewegung ausgeht. Aufgrund der schwankenden Positionsinformationen 86 6.1. EVALUIERUNG DER IMPLEMENTIERUNG UND TECHNOLOGIE 87 im Stillstand liefert er deshalb immer eine geringe Geschwindigkeit und eine interpolierte Richtung. Diese Richtungsinformation stimmt nicht mit der realen Richtung des GPS-Empfängers überein. Der XT-Modus liefert bei erkanntem Stillstand hingegen keine Richtungsinformation. Somit kann vom MoBiLe-Service erkannt werden, dass keine Bewegung durchgeführt wird und deshalb keine interpolierte Richtung bestimmbar ist. Daraufhin wird dem Nutzer eine allozentrische Navigationsinformation präsentiert. Im STModus kann dies nicht auf triviale Art und Weise erkannt werden. Zur Lösung des Problems werden in der Implementierung Richtungsinformationen bei niedrigen Geschwindigkeiten automatisch vernichtet. So werden keine falschen Richtungsinformationen geliefert und der MoBiLe-Service stellt keine falschen egozentrischen Navigationsinformationen zur Verfügung. 6.1.2 Inhärente Probleme von J2ME Bereits im vorigen Kapitel wurde auf einige inhärente Probleme der J2ME-Plattform eingegangen. Diese sollen hier nochmals kurz zusammengefasst werden. Ein Problem war die Integration von dynamisch generierten ECA-Regeln. Da der J2ME-Classloader nur das Laden von Standardklassen und Klassen der MIDlet-Suite zulässt, können zur Laufzeit keine beliebigen ECA-Regeln geladen werden. Die Klasse der ECA-Regel muss deshalb zum Installationszeitpunkt bereits in die MIDlet-Suite integriert werden. Lösung des Problems war die generische ECA-Regel. Diese besitzt eine einzige Zugriffsmethode und alle Informationen des Triggers sind in Instanzvariablen enthalten. Um die ECA-Regel über Netzwerkverbindungen zu übertragen, muss sie serialisiert werden. Leider unterstützt J2ME standardmäßig keine Objektserialisierung. Lösung war eine selbst entwickelte Objektserialisierung. Hierbei können primitive Datentypen, sowie Objekte, die aus primitiven Datentypen bestehen, serialisiert werden. Dazu müssen alle Informationen durch primitive Datentypen darstellbar sein. Komplexe Bedingungen werden deshalb mittels Strings serialisiert. Hierdurch ist es nun möglich, ECA-Regeln dynamisch zu konfigurieren und über Netzverbindungen zu übertragen, um sie für die Dienstinitiierung einsetzen zu können. Ein weiteres Problem, welches zwar nicht direkt durch J2ME entsteht, aber innerhalb der Programmierumgebung auftritt, ist das Öffnen lokaler Netzwerkverbindungen. Das Öffnen einer Netzwerkverbindung für paketvermittelte Datendienste wie GPRS ist nur in Verbindung mit Infrastrukturkomponenten (SGSN/GGSN) möglich. Jedes Paket über diese lokale Netzwerkverbindung wird deshalb nicht lokal auf dem Endgerät übertragen, sondern über den Umweg der Infrastruktur. Dadurch muss jedes Paket die Luftschnittstelle mit den bereits genannten Nachteilen überqueren. Eine lokale Kommunikation zwischen den Schichten der Location-based Push-Architektur ist deshalb nicht über Netzwerkverbindungen möglich. Lösung stellt das Dynamic Connection Framework (vgl. Kapitel 5.4) dar. Je nachdem, ob eine lokale oder entfernte Kommunikation stattfinden soll, wählt das DCF entweder einen nativen Methodenaufruf oder einen Methodenaufruf über eine Socketverbindung. Innerhalb der Schichten bleibt die Wahl der Verbindungsart durch Stubs verborgen. Zur Unterstützung weiterer Protokolle kann das DCF einfach erweitert werden. 6.1.3 Probleme mobiler Endgeräte Neben den bereits genannten Problemen sind bei der Implementierung auch einige Schwierigkeiten bei der Nutzung der mobilen Endgeräte aufgetreten. Diese sind auf Spezifikationsabweichungen zurückzuführen. Für einige Vorabtests kam das Sony Ericsson P900 zum Einsatz. Wie bereits in [Klin 04] festgestellt wurde, sind in einigen Softwareversionen des P900 Statusmeldungen bei der Gerätesuche mittels JABWT vertauscht. Dadurch wird bei erfolgreicher Gerätesuche grundsätzlich ein INQUIRY ERROR geliefert. Eine ordnungsgemäße Implementierung der Gerätesuche ist deshalb nicht möglich. Eine Lösung des Problems ist die Nichtbeachtung der Statusmeldungen. Probleme, die im Zusammenhang mit der Implementierung auf dem Siemens S65 entstanden, waren Fehler bei der Bluetooth-Dienstsuche. Bei Hinzunahme bestimmter Attribute bei der Dienstsuche, liefert das optionale Paket JABWT des S65 fehlerhafte ServiceRecords. Außerdem werden durch die J2MEPlattform auf dem S65 offene Ein-/Ausgabeströme über Bluetooth beim Beenden des MIDlets nicht auto- 88 KAPITEL 6. EVALUIERUNG matisch geschlossen. Die Bluetooth-Schnittstelle steht danach, auch für Nicht-J2ME-Anwendungen, nicht mehr zur Verfügung. Einzige Lösung ist hier der Neustart des Gerätes. Neben den hier erwähnten Problemen mit Bluetooth in J2ME zeigte das S65 auch allgemeine Fehler in der Bluetooth-Implementierung. So führte ein Bluetooth-Zugriff mittels OBEX-Browse zwangsläufig zum Absturz des Systems. Außerdem wurden nur sehr geringe Datenraten über die Bluetooth-Schnittstelle erreicht, die selten 5 Kilobyte/s überschritten. Auch der Wechsel zum Siemens SK65 bot hier keine Lösung. Erst durch den Einsatz des Nokia 6630 war eine ordnungsgemäße Nutzung der Bluetooth-Schnittstelle möglich. Alle Zugriffe erfolgten so, wie sie in der Spezifikation festgehalten sind. Außerdem können mit dem Nokia 6630 Datenraten bis zu 40 Kilobyte/s erreicht werden, was die Arbeit mit dem mobilen Endgerät sehr verbesserte. 6.1.4 Probleme beim Routeneinstieg Erste Tests des MoBiLe-Service zeigten zwar die generelle Funktionsfähigkeit des Dienstes, lieferten aber noch einige Kritikpunkte. So war es schwer, einen Routeneinstieg zu finden. Um an den Startpunkt der Route zu gelangen, musste man die Umgebung nach dem ersten Aktionskreis absuchen, solange bis die erste Navigationsinformation präsentiert wird. Diese Problematik wurde durch das Einfügen eines weiteren Triggers gelöst. Dieser bietet beim Start des Dienstes automatisch Hilfestellung zum Erreichen des Startpunktes der Route. Die Bedingung dieser ECARegel ist stets true. Dadurch wird die Aktion bei der ersten Auswertung ausgeführt. Als Aktion wurde die InitiatePiggyBackingDataAction gewählt, an die die Position des Nutzers angehängt wird. Dadurch erlangt die Navigationsapplikation die aktuelle Position des Nutzers und kann die Richtung bestimmen, in der der erste Aktionspunkt der Route zu finden ist. Die Berechnung der Richtung erfolgt durch arctan( xy ), wobei x bzw. y die Differenz der aktuellen Position und des ersten Aktionspunktes bezüglich der x-Achse bzw. y-Achse ist. Leider kann dieser Ausdruck unter J2ME nicht einfach ausgewertet werden, da J2ME keine Arcusfunktionen unterstützt. Lösung des Problems war eine Berechnung des Arcus-Tangens durch eine Taylorreihenapproximation. Folgende Taylorreihe liefert im Intervall x ∈ [0; 1] eine Annäherung an den Arcus-Tangens: arctan(x) = ∞ X i=0 (−1)i x2i+1 2i + 1 1 ) angenähert werden. Da der ArcusFür das Intervall ]1; ∞[ kann der Arcus-Tangens durch π2 − arctan( |x| Tangens punktsymmetrisch zum Ursprung ist, ergeben sich Werte für das Intervall ] − ∞; 0[ durch Punktspiegelung. In der Implementierung des MoBiLe-Service wird für die Bestimmung des Arcus-Tangens folgende Methode benutzt: 2 4 6 8 10 12 public double arctan(double d) { if (d<0) return (-1)*arctan(d*(-1)); else if (d>1) return Math.PI/2 - arctan(1/Math.abs(d)); else { double result = 0; for (int i=0; i<loops; i++) result += pow(-1,i)*pow(d,2*i+1)/(2*i+1); return result; } } Die Variable loops gibt an, wie viele Reihenglieder für die Approximation genutzt werden. Ein ausreichendes Ergebnis wird bereits mit fünf Reihengliedern erzielt. Da J2ME auch keine Potenzfunktion (ab ) standardmäßig zur Verfügung stellt, wurde eine triviale Potenzfunktion pow(a, b) selbst implementiert. 6.1. EVALUIERUNG DER IMPLEMENTIERUNG UND TECHNOLOGIE 89 Durch das Einfügen dieses Triggers kann der Nutzer den Routenstartpunkt wesentlich einfacher finden. Desweiteren hilft eine Vergrößerung des Aktionskreisradius für den Startpunkt bei der Suche. 6.1.5 Probleme mit Connectivity Ein weiteres Problem, das bereits in vorigen Kapiteln vermehrt angesprochen wurde, ist die Connectivity zwischen mobilem Endgerät und der Infrastruktur. Kann aus einem beliebigen Grund die Verbindung zur Infrastruktur bei Verteiltheit nicht mehr genutzt werden, kann keine Dienstinitiierung und folglich keine Präsentation von Navigationsinformationen mehr erfolgen. Zur Lösung des Problems kann dem Präsentator eine Default-Navigationsinformation vorab übergeben werden, die bei nicht ausreichender Connectivity automatisch dargestellt wird. Für einen Präsentator für grafische Darstellungsformen kann dies zum Beispiel eine Karte sein, die die komplette Route enthält. Dadurch kann der Nutzer selbst eine Navigation durchführen. Dies ist zwar für ihn wesentlich aufwändiger, aber immerhin noch möglich. Ohne diese Lösung könnte gar keine Navigationshilfe mehr bereitgestellt werden. 6.1.6 Probleme beim Verlassen der Route Die Routen des MoBiLe-Service beziehen sich einzig und allein auf Aktionspunkte. Informationen zu Pfaden, die zwischen diesen Aktionspunkten verlaufen, wurden bisher völlig außer Acht gelassen. Für eine funktionsfähige Navigation sind diese auch nicht notwendig. Dazu muss sich der Nutzer aber stets auf den Pfaden zwischen den Aktionspunkten bewegen. Verlässt er aus irgendeinem Grund die Route, wird keine Dienstinitiierung mehr durchgeführt und deshalb auch keine Navigationsinformation bereitgestellt. Zur Lösung dieser Problematik existieren folgende Ansätze: • Merkt der Nutzer selbst, dass er sich von der Route entfernt hat, so kann er mittels Pull-Verfahren selbst Navigationsinformationen anfordern, die ihn auf seinem Weg zurück zur Route unterstützen. • Innerhalb der Route können neben Informationen zu Aktionspunkten auch Informationen zu den Pfaden zwischen den Aktionspunkten vermerkt werden. Diese können zum Beispiel in Form einzelner Streckenabschnitte (bei geraden Pfaden) oder in Form von Bezier-Kurven (bei gebogenen Pfaden) aus vorhanden Pfadinformationen generiert werden. Durch zusätzliche Trigger können diese Pfadbeschreibungen in die Dienstinitiierungsschicht integriert werden. Entfernt sich der Nutzer daraufhin um eine bestimmte Distanz von diesen Pfadbeschreibungen, wird der Dienst initiiert und eine Navigationsinformation bereitgestellt, die ihm den Weg zurück zur Route beschreibt. Dazu muss an die Dienstinitiierung die Position des Nutzers angehängt werden. Schwierigkeiten in der Umsetzung dieses Ansatzes entstehen, falls keine ausreichenden Pfadinformationen zur Verfügung stehen. • Ein anderer Lösungsansatz ist daher die manuelle Korridorgenerierung bei der Routenerzeugung. Möglich wäre hier zum Beispiel, dass der Nutzer bei der Erzeugung der Route Korridore definieren kann, die nicht verlassen werden dürfen. Daraufhin ergibt sich ein ähnlicher Verlauf wie bereits bei vorigem Punkt beschrieben wurde. • Ein weiteres Konzept, das nicht auf die zweidimensionalen Pfade zurückgreift, ist die Definition von Kontrollpunkten. Hierzu muss zum Beispiel bei der Routengenerierung alle 100 Meter ein Kontrollpunkt gesetzt werden. Überschreitet die Entfernung zu diesen Kontrollpunkten einen bestimmten Schwellwert, wird eine Dienstinitiierung ausgelöst und der Nutzer auf die Route zurücknavigiert. Die Definition der Kontrollpunkte kann bei der Routenerstellung erfolgen. Bei der grafischen Routenerstellung kann diese dadurch umgesetzt werden, dass der Nutzer zum Beispiel alle 100 Meter einen Punkt (Aktionspunkt oder Kontrollpunkt) setzen muss. Zur Lösung des Problems existieren eine Vielzahl an Ansätzen, die je nach Art des Dienstes und verfügbaren Informationen eingesetzt werden können. 90 KAPITEL 6. EVALUIERUNG 6.2 Versuchsergebnisse Um den MoBiLe-Service auf Funktionsfähigkeit zu testen, wurde der Dienst einem realen Anwendungsszenario ausgesetzt. Dazu wurde eine Route mittels des im Anhang A dargestellten Routendienstes erstellt und daraufhin die Navigation an dieser realen Route getestet. Die erstellte Route verläuft zwischen Fendtund Taubenberg im Süden Münchens (vgl. Abb. 6.1). Die Länge der Route beträgt 20,5 Kilometer und verläuft über ca. 500 Höhenmeter. Bei einer Durchschnittsgeschwindigkeit von 15 km/h kann die Route innerhalb von knapp 1,5 Stunden zurückgelegt werden. Abbildung 6.1: Mountain-Bike-Tour am Taubenberg Zu Beginn wurde die Route mit dem im Anhang beschriebenen Routendienst definiert. Insgesamt wurden für die Routenbeschreibung 17 Aktionspunkte herangezogen. Die Definition erfolgte durch Anklicken auf dem Kartenhintergrund und anschließendes Bestimmen der Austrittsrichtung. Durch die Veröffentlichung stand sie für den MoBiLe-Service zur Verfügung. Als Startpunkt diente die Kirche von Mitterdarching. Aufgrund des bereits zuvor durchgeführten Bluetooth-Discovery, konnte dieser Konfigurationsschritt des LBPSs übersprungen werden. Für den Test wurde sowohl die lokale als auch die verteilte Variante des Dienstes in zwei unterschiedlichen Durchgängen eingesetzt. Der erste Durchgang erfolgte mit lokaler Dienstausführung, d.h. ohne Outsourcing der Dienstausführungsschicht. Nachdem dies in der allgemeinen LBPS-Konfiguration eingestellt wurde, konnte der MoBiLe- 6.2. VERSUCHSERGEBNISSE 91 Service gestartet werden. Anschließend wurde die zuvor definierte Route ausgewählt. Das Starten der Navigation führte nach einer Wartezeit von wenigen Sekunden zur ersten Navigationsinformation. Sie enthielt einen Pfeil, der in die Richtung des Startpunktes zeigte. Der Einstieg in die Route durch oben beschriebenen Ansatz stellte sich als sehr nützlich und zielführend heraus. Angekommen am Startpunkt der Route, erfolgte die Präsentation einer weiteren Navigationsinformation, die aus einem Pfeil und einer verbalen Richtungsinformation bestand. Diese zeigte, wie erwartet, in die Richtung der weiterführenden Route. Der darauf folgende Streckenabschnitt verlief teilweise im dichten Wald. Obwohl hier Einschränkungen in der Ortung erwartet wurden, lieferte der GPS-Empfänger kontinuierlich relativ genaue Ortsinformationen. Demzufolge kam die Initiierung des Dienstes und die Präsentation der Navigationsinformation stets rechtzeitig zustande und zeigte die gewünschten Resultate. Die Pfeildarstellung konnte gut wahrgenommen werden und zeigte meist in die richtige Richtung. An einigen wenigen Aktionspunkten stimmte der Pfeil nicht genau mit der einzuschlagenden Richtung überein, ließ die weiterführende Route aber trotzdem intuitiv erahnen. Auch die Geschwindigkeitsabhängigkeit für die frühzeitige Dienstinitiierung zum Beispiel bei Bergabfahrten meisterte der MoBiLe-Service mit großem Erfolg. So erschien eine Navigationsinformation bereits ca. 100 Meter vor dem Abbiegevorgang bei einer Geschwindigkeit von ca. 40 km/h. Dadurch konnte frühzeitig der Bremsvorgang eingeleitet werden. Die verbale Darstellung der Navigationsinformation unterstützte die Pfeildarstellung sehr zum Vorteil des Nutzers. Dadurch war eine Navigation auch ohne ständiges Betrachten des Displays möglich. Leider ist die Lautstärke des integrierten Lautsprechers des Nokia 6630 für diese Anwendung etwas leise, so dass Anweisungen meist nur partiell verstanden wurden. Durch den Blick auf die Pfeildarstellung konnten diese Probleme aber behoben werden. Nach einer 1,5 stündigen Fahrt wurde schließlich wieder der Startpunkt erreicht. Ein weiterer Durchgang erfolgte mit der verteilten Alternative des MoBiLe-Service. Nachdem in der Konfiguration der Location-based Push-Architektur die IP-Adresse des Application Servers eingetragen wurde, konnte der eigentliche MoBiLe-Service gestartet werden. Die Verbindung mit dem Application Server wurde daraufhin aufgebaut und eine Routenwahl konnte erfolgen. Die einzelnen Schritte der Routenwahl zeigten zwar merkliche Verzögerungen, die durch den Datenaustausch über die Luftschnittstelle resultierten, konnten aber wie bei der lokalen Variante durchgeführt werden. Nachdem die Navigation gestartet wurde, zeigte die Pfeildarstellung relativ zeitnah die Position des Startpunktes an. Die Navigation durch die Route erfolgte ähnlich zur lokalen Variante. Teilweise konnte der Datenaustausch über die Luftschnittstelle durch eine verzögerte Bereitstellung der Navigationsinformationen bemerkt werden. Eine rechtzeitige Benachrichtigung über Richtungsänderungen wurde aber trotzdem erzielt. Auch komplexe Aktionspunkte, die zum Beispiel unter hohen Geschwindigkeiten erreicht werden, führten zu einer rechtzeitigen Benachrichtigung. Leider war der Empfang zu örtlichen Basisstationen des Mobilfunknetzes an einer Stelle der Route so gering, dass ein Verbindungsabbruch erfolgte. Dadurch war keine ausreichende Connectivity mehr gegeben. Eine Dienstinitiierung und folglich auch eine Bereitstellung von Navigationsinformationen war deshalb nicht mehr möglich. Leider konnte dieser Verbindungsabbruch innerhalb des MIDlets nicht festgestellt und deshalb keine geeignete Fehlerbehandlung eingeleitet werden. Eine Benachrichtigung des Nutzers konnte so nicht erfolgen und eine Navigation schlug fehl. Einzigster Hinweis auf den Verbindungsabbruch war ein Symbol am Displayrand, das Symbian OS dafür vorsieht. Durch eine manuelle“ Wegfindung wurde kurze Zeit später wieder ein Gebiet erreicht, das den Empfang ” möglich machte. Die Verbindung zum Application Server wurde daraufhin durch das Betriebssystem automatisch wieder aufgebaut und die Navigation konnte fortgeführt werden. Die Navigation über die restliche Route verlief wie gewünscht. Als Resultat dieses Versuchs ergibt sich also folgende Aussage. Die lokale Ausführung zeigte das gewünschte Verhalten wie es in den Anforderungen spezifiziert wurde. Die Navigation war klar und intuitiv verständlich. Bis auf wenige leichte Abweichungen zeigte die Pfeildarstellung eine korrekte Richtung an und wurde durch die verbale Darstellung sinnvoll unterstützt. Navigationsinformationen wurden stets rechtzeitig präsentiert. Insgesamt war eine äußerst zufrieden stellende Navigation möglich, die dem Nutzer dadurch einen hohen Mehrwert bot. Für die verteilte Variante wurde leider festgestellt, dass die Connectivity für eine ordnungsgemäße Nutzung nicht überall vorherrscht und deshalb nicht wie gefordert eingesetzt werden kann. Die lokale Variante ist deshalb für derartige Navigationsdienste derzeit noch vorzuziehen. Wird in Zukunft jedoch der Empfang des Mobilfunknetzes weiter ausgebaut, so stellt die verteilte Variante eine interessante Alternative dar. Die 92 KAPITEL 6. EVALUIERUNG Versuchsergebnisse haben gezeigt, dass die Verzögerung, die durch die Übertragung über die Luftschnittstelle entsteht, für Navigationsdienste beinahe vernachlässigt werden kann. Auch die monetären Kosten, die durch die Übertragung entstanden, hielten sich durch die geringe Menge an ausgetauschten Daten während der Navigation sehr niedrig. Zukünftige Versuche werden daher zeigen, ob auch die verteilte Variante für die Mountain-Bike-Navigation eingesetzt werden kann. Kapitel 7 Schlussfolgerung und Ausblick Zusammenfassend kann gesagt werden, dass der MoBiLe-Service die in Kapitel 2.3 erarbeiteten Anforderungen weitgehend erfüllt, und dass eine Architektur entworfen wurde, die derartige Dienste in komfortabler und effizienter Weise umsetzt. Natürlich können einige Aspekte identifiziert werden, die in diesem Zusammenhang äußerst wichtig sind, aber aufgrund des zeitlichen Hintergrundes nicht behandelt werden konnten. Dazu gehören vor allem sicherheitskritische Betrachtungen, da durch das eingesetzte TriggerKonzept Ortsinformationen des Nutzers freigegeben werden. Derartige Daten müssen jedoch mit äußerster Vorsicht behandelt werden, damit kein Missbrauch erfolgen kann. Sie sollten deshalb besonders geschützt werden. Lösungen sind an dieser Stelle zum Beispiel, dass nur autorisierten Applikationen die Integration der Trigger ermöglicht wird und der Nutzer über vorhandene Trigger genauestens informiert wird. Desweiteren muss natürlich auch die Übertragung der Ortsinformationen gegen Abhören und Verfälschen gesichert werden. Dazu stehen verschlüsselte Übertragungen (z.B. HTTPS), Verfahren zur Wahrung der Integrität (z.B. Prüfsummen) und Anonymisierung zur Verfügung. Ein weiterer Aspekt, auf den hier nicht genauer eingegangen wurde, ist der Einsatz der Mobilfunktechnologie. Die Konzeption der Architektur und vor allem die Verteilung der LBPS-Schichten auf Entitäten wurde bisher nur reduziert auf zwei Entitäten betrachtet. Diese sind das mobile Endgerät und die Infrastruktur. Jedoch besteht die Mobilkommunikationsinfrastruktur nicht aus einem einzigen Gerät, sondern aus einer Vielzahl an Entitäten. Je nach Mobilfunkgeneration (z.B. GSM oder UMTS) und der Version (z.B. UMTS Release 99) stehen verschiedene Entitäten zur Verfügung, die für die einzelnen LBPS-Schichten von Interesse sind. Beispiel hierfür ist das Gateway Mobile Location Center (GMLC) [3gp a], welches dafür vorgesehen ist, Ortsinformationen für LBSs bereitzustellen. Mittels des GMLC soll eine Abstraktion über verschiedenste Ortungsverfahren erfolgen und so eine einfache Verwirklichung von LBSs ermöglicht werden. Eine weitere interessante Technologie ist das IP Multimedia Subsystem (IMS) [3gp b], das in Release 5 im UMTS-Infrastrukturnetz eingesetzt werden soll. IMS soll die Unterstützung von Sprachtelefonie sowie Multimediadiensten in UMTS verbessern. Dazu positioniert sich IMS im paketvermittelten UMTS-Netz, bildet darin aber ein klar abgegrenztes Subnetz. Zentrales Element des IMS ist das Call Session Control Function (CSCF) (vgl. Abb. 7.1). Es kontrolliert und steuert IMS Sessions und steht deshalb in Interaktion mit vielen anderen Komponenten des UMTS-Netzes. Beispiel hierfür sind Application Server, auf denen eigene Dienste oder Dienste von Drittanbietern zur Verfügung gestellt werden. Für den Austausch von Nutzdaten zum und vom Public Switched Telephone Network (PSTN) hat es Einfluss auf den Media Gateway (MGW). Zur Kommunikation mit dem mobilen Endgerät stehen Gateway GPRS Support Node (GGSN) und Serving GPRS Support Node (SGSN) bereit. Innerhalb des UMTS-Netzes erfolgt eine strikte Trennung zwischen Signalisierungsverkehr und Nutzdatenverkehr. Als Signalisierungsprotokoll wird SIP (vgl. Kapitel 3.3) eingesetzt. Dabei fungiert das CSCF als SIP-Proxy. Soll die Location-based Push-Architektur auf das UMTS-Netzes angewendet werden, so können bei der Verteilung der einzelnen LBPS-Schichten die oben beschriebenen Entitäten des UMTS-Netz in Betracht gezogen werden. Auch der Signalisierungsverkehr mittels SIP stellt eine interessante Alternative zu der 93 94 KAPITEL 7. SCHLUSSFOLGERUNG UND AUSBLICK Application Server CSCF SGSN MGW GGSN externe Netze (Internet, PSTN,...) Nutzdaten Signalisierungsdaten Abbildung 7.1: Stark vereinfachter Aufbau des UMTS-Netzes (Release 5) proprietären Kommunikation in der derzeitigen Location-based Push-Architektur dar und könnte in Zukunft deshalb darauf angepasst werden (vgl. hierzu auch [PSM 01, Tosi 03]). All diese Betrachtungen bezüglich der derzeitigen bzw. zukünftigen Mobilfunktechnologie wurden in dieser Arbeit außer Acht gelassen, da sie vor allem in der heutigen Zeit einem stetigen Wandel unterliegen. So ändern sich die Zusammensetzung und die Art der Kommunikation der Entitäten der Infrastruktur sehr häufig und extrem schnell. Die grundsätzliche Funktionalität der einzelnen LBPS-Schichten und die Zweiteilung von mobilem Endgerät und Infrastruktur sind jedoch auch auf längere Zeit gültig. Dadurch zeigen die Ergebnisse dieser Arbeit nicht nur einen kurzfristigen Charakter, sondern sind auch langfristig anwendbar. Ein weiterer Punkt, der in dieser Arbeit nicht in Betracht gezogen wurde, sind 3D-Aspekte. Dies betrifft einerseits die Positionierung und andererseits die Darstellung. Die Positionsbestimmung fand nur auf der zweidimensionalen Erdoberfläche statt. Vor allem in der Zukunft werden 3D-Positionen jedoch sicherlich eine entscheidende Rolle spielen. Ob dreidimensionale Betrachtungen der Nutzerposition beim MoBiLeService einen hohen Mehrwert bieten, muss noch im Einzelnen betrachtet werden und wird in dieser Arbeit nicht weiter behandelt. Obwohl 3D-Darstellungen in Navigationsdiensten vermehrt zum Einsatz kommen, wurde diesem Aspekt hier nur wenig Beachtung geschenkt. 3D-Darstellungen bieten eine Vielzahl neuer Möglichkeiten, wie 3D-Walkthroughs [KLEC 03] entlang der Route, und neuartige Hilfestellungen für den Nutzer. Für den MoBiLe-Service zeigten sich diese aber eher als störend, da die visuelle Aufnahmezeit der komplexen dreidimensionalen Objekte teilweise stark ansteigt und diese deshalb für das Mountain-Biken weniger gut geeignet sind. Die Versuchsergebnisse aus Kapitel 6.2 haben gezeigt, dass die Anforderungen an den MoBiLe-Service mit dem derzeitigen Prototyp weitgehend erfüllt wurden. Dabei ist zu bemerken, dass ein großer Teil des Dienstes bereits durch die Location-based Push-Architektur abgedeckt wurde. Die Erweiterungen, um letztendlich den MoBiLe-Service anzubieten, waren relativ gering und konnten in kurzer Zeit erfolgen. Durch die Verallgemeinerung vieler eingesetzter Konzepte, wie den dynamisch konfigurierbaren Triggern in Form von ECA-Regeln, können die Anforderungen einer Vielzahl von LBPSs abgedeckt werden. Der Aufwand für die Implementierung verhält sich dadurch äußerst gering. Um zum Beispiel den ortsabhängigen Email-Push-Service anzubieten, der bereits vielfach erwähnt wurde, muss im Grunde genommen nur eine Komponente zum Erzeugen der ECA-Regeln und eine Komponente für das Anfordern und Übergeben der Emails implementiert werden. Zusätzlich muss die Konfigurationskomponente angepasst werden, wobei diese bereits auf eine einfache Erweiterung ausgelegt wurde und so Standardfunktionen wie das Bluetooth-Discovery und die Wahl des Dienstes unangetastet bleiben können. Dadurch ist es möglich, in kürzester Zeit verschiedene LBPSs anbieten zu können. Stehen weitere Sensorinformationen zur Verfügung, kann die Location-based Push-Architektur außerdem leicht um Dienstinitiierungen basierend auf diesen Sensorinformationen erweitert werden. Dazu muss ein weiterer Initiator implementiert werden, der diese Sensorinformationen generiert, anfordert, verwal- 95 tet, Trigger aktualisiert und Aktionen ausführt. Stehen zum Beispiel Wetterinformationen zur Verfügung, kann der MoBiLe-Service um wetterbasierte Trigger erweitert werden. Ein entsprechender Initiator kann so den MoBiLe-Service anstoßen, falls die Regenwahrscheinlichkeit innerhalb des Routengebietes einen Schwellwert übersteigt. Daraufhin kann der MoBiLe-Service dem Nutzer beispielsweise eine kürzere Alternativroute anbieten. Andere Beispiele für Trigger, die im Zusammenhang mit dem MoBiLe-Service interessante Einflüsse haben, sind Trigger, die bei zeitnahem Sonnenuntergang den Dienst anstoßen, oder bei steigender Ozonbelastung den Nutzer frühzeitig warnen. All diese Trigger können ohne komplizierte Veränderungen der Architektur eingesetzt werden und interessante neue oder erweiterte Dienste anbieten. In Zusammenhang mit dem wachsenden Angebot an mobilen Diensten werden derartige LBPSs in Zukunft möglicherweise interessante Geschäftsprozesse abbilden. Vielleicht tragen sie zum Erreichen der lang ersehnten Killer Applikation“ der heutigen Zeit bei, die voraussichtlich nicht aus einer einzigen Anwendung ” bestehen wird, sondern aus einer Vielzahl an Diensten, die den Nutzer bei seinen alltäglichen Aufgaben hilfreich unterstützen. 96 KAPITEL 7. SCHLUSSFOLGERUNG UND AUSBLICK Anhang A Routendienst Die wesentliche Grundlage der Wegfindung sind Routen. Definitionen zu Routen finden sich in Kapitel 2.2. Zur Erzeugung, Verwaltung und Bereitstellung von Routen dienen Routendienste. In Kapitel 2.2 wurden zwei wesentliche Arten von Routendiensten identifiziert. Diese liefern entweder statisch oder dynamisch generierte Routen. Während dynamische Routen bei jeder Anfrage neu erzeugt werden, stehen statische Routen meist für längere Zeit zur Verfügung und entsprechen den Bedürfnissen einer breiten Nutzergruppe. Der hier beschriebene Routendienst soll Routen für den MoBiLe-Service liefern. Diese sollen sowohl für den lokalen als auch für den verteilten MoBiLe-Service nutzbar sein. Dabei wird in dieser Arbeit nur ein Routendienst, der auf einer Entität der Infrastruktur bereit steht, eingesetzt. Dies entspricht einer OffboardLösung. Dadurch kann der Routendienst auf einfache Art und Weise von verschiedenen Navigationsdiensten eingesetzt werden und große Mengen an Daten zur Routenerstellung hinzuziehen. In der Regel sind Routen für das Mountain-Biken nicht wie bei der Fahrzeugnavigation dazu gedacht, über eine beliebige Pfadfolge von Ort A nach Ort B zu gelangen. Die Routen zeichnen sich meist durch speziell gewählte Pfadfolgen aus. Diese werden in der Regel von wenigen oder keinen motorisierten Fahrzeugen benutzt, sind aber mit dem Mountain-Bike befahrbar. In manchen Fällen können aber auch nicht-befahrbare Tragestrecken vorkommen. Außerdem haben sie meist eine mehr oder weniger starke Steigung (bis max. ∼ 30 Prozent). Eine weitere Besonderheit ist, dass bis auf seltene Ausnahmen der Zielpunkt dem Startpunkt entspricht. Die Route definiert also eine geschlossene Pfadfolge. Die hier behandelten Routen werden deshalb nicht dynamisch bei jeder Anfrage generiert, sondern einmal erzeugt und stehen dann für längere Zeit zur Verfügung. Eine Route kann damit vielfach genutzt werden. Neben der Bereitstellung und Verwaltung der Routen soll der hier beschriebene Routendienst eine Erstellung von statischen Routen auf Basis einer grafischen Benutzerschnittstelle ermöglichen. Dazu muss der Routendienst über digitale geografische Datenbestände verfügen. Das folgende Kapitel gibt einen Überblick über diese Kartenbestände verschiedener Hersteller. Im Anschluss wird die Architektur des Routendienstes beschrieben und eine kurze Einführung in die Implementierung gegeben. Abschließend folgt eine Evaluierung der Resultate aus dem realen Einsatz des Routendienstes in Zusammenarbeit mit dem MoBiLe-Service. A.1 Digitale geografische Datenbestände NAVTEQ NAVTEQ [nav ] ist neben Tele Atlas einer der führenden Anbieter digitaler Pfadinformationen für Deutschland. Seit 1993 bemüht sich das Unternehmen, alle Pfade innerhalb Deutschlands einerseits durch Luftbildaufnahmen und andererseits durch reales Abfahren der Pfade zu erfassen (vgl. [GKW 04]). Seit dem Jahr 2000 sind alle deutschen Straßen vollständig in den Daten enthalten. Derzeit wird der Bestand durch die Erfassung von Wegen erweitert. Zum Zeitpunkt dieser Arbeit beinhalten die NAVTEQ Daten Pfade mit einer Gesamtlänge von etwas mehr als einer Million Kilometern. 97 98 ANHANG A. ROUTENDIENST Neben den Positionen zum WGS84-Datum enthalten einzelne Pfadsegmente bis zu 160 Attribute (z.B. Namen, Hausnummern, Vorfahrtsregelungen, Abbiegeeinschränkungen, Geschwindigkeitsbeschränkungen). Außerdem gibt mehr als 200.000 PoIs aus 44 Kategorien (z.B. Restaurants, Krankenhäuser, Tankstellen). Die Summe aller Informationen ergibt so mehrere Gigabyte Daten, die von NAVTEQ kommerziell vertrieben werden. Aktualisierungen des Datenbestandes erfolgen in der Regel halbjährlich. Die Daten sind für 17 Länder in sieben Formaten erhältlich. Neben Westeuropa werden Pfadinformationen auch zu Nordamerika und Regionen des Mittleren Ostens angeboten. Unterstützte Formate sind Shape, MapInfo Tab-File, Oracle Spatial, SIF+, GDF 3.0, SDAL und RTM. Tele Atlas Das Unternehmen Tele Atlas [tel ] bietet digitale Pfadinformationen für insgesamt 22 Länder an. Darunter sind viele westeuropäische Länder, die USA sowie Kanada. Die Daten sind in den Formaten GDF 3.0, Shape, Oracle Spatial, RMF, MapInfo Tab-File, ArcSDE SDX-File und ArcIMS Route Server SDC-File erhältlich. Hauptsächlich wurden die Tele Atlas Daten durch reales Abfahren der Pfade erzeugt. Aber auch Luftbildaufnahmen, Satellitenbilder und andere geografische Primär- und Sekundärdaten werden zur Datenerfassung eingesetzt. Durch die sehr fassettenreiche Datenerhebung garantiert Tele Atlas eine Genauigkeit der Daten von 5-12 Metern. Eine Aktualisierung der Daten erfolgt halbjährlich. Wie bei NAVTEQ können Pfadsegmente durch 150 Attribute (z.B. Namen, Hausnummern, Vorfahrtsregelungen) erweitert werden. Neben Pfadinformationen enthalten die Daten PoIs und Informationen zu Flüssen und Seen, politischen Grenzen, Postleitzahlenbereiche, etc. Neben diesen Pfadinformationen liefert Tele Atlas dynamische Daten wie Verkehrsinformationen, Unfälle oder Baustellen. PTV Ein weiterer wichtiger Lieferant von Pfadinformationen ist PTV [ptv ]. PTV zeichnet sich nicht durch große Mengen eigener Pfadinformationen aus, sondern stellt verschiedenste Produkte, die sich in irgend einer Art und Weise mit Mobilität beschäftigen, zur Verfügung. In diesem Sinne werden von PTV Lösungen für modulare Technologieplattformen, Routing- und Mapping-Dienste und auch konkrete Dienste wie zum Beispiel ein Offboard-Navigationsdienst und eine Online-Mitfahrzentrale bereitgestellt. Dabei liefert PTV nicht nur die Produkte, sondern auch Beratung, Hosting und Support dieser Produkte. Gleichzeitig vertreibt PTV aber auch digitale Inhalte. Diese beinhalten Verkehrsinformationen, Wetterinformationen, PoIs und digitale Pfadinformationen. Die digitalen Pfadinformationen bestehen aus Daten von NAVTEQ, Tele Atlas und AND [and ], sowie eigenen Datenbeständen. Der Gesamtdatenbestand umfasst alle Länder Europas mit über 500.000 Orten und Pfadsegmente mit einer Gesamtlänge von ca. sechs Millionen Kilometern. ATKIS Neben den oben genannten Lieferanten digitaler Pfadinformationen werden digitale geografische Daten auch von Vermessungsämtern angeboten. Das Projekt ATKIS (Amtliches TopographischKartographisches Informationssystem) [atk ] der Arbeitsgemeinschaft der Vermessungsverwaltungen (AdV) beschäftigt sich mit der Erfassung dieser Daten. Ziel von ATKIS ist die Erstellung einer digitalen Informationsbasis für topografische Geodaten der Bundesrepublik Deutschland. Die Umsetzung wurde von der AdV an die Vermessungsämter der Länder übergeben, die per Gesetz dazu verpflichtet sind, das Landesgebiet digital zu erfassen. Jedes Land erstellt deshalb ein zweidimensionales, vektorbasiertes, objektstrukturiertes und vom Nutzer erweiterbares Digitales Landschaftsmodell (DLM). Die im Basis-DLM ” enthaltenen Objekte werden bestimmten Objektarten zugeordnet und durch ihre räumliche Lage, ihren geometrischen Typ (Punkt, Linie, Fläche), beschreibende Attribute (z. B. Straßenname, Fahrbahnbreite) und Beziehungen zu anderen Objekten (Relationen) definiert“ [blv ]. Die Genauigkeit des Basis-DLM soll 510 Meter betragen. Aktualisierungen erfolgen mindestens alle drei Jahre. ATKIS sieht Anwendungsgebiete der digitalen Karten unter anderem in den Bereichen Energie-, Forst- und Landwirtschaft, Landnutzungs-, Regional- und Streckenplanung, Verkehrsnavigation, Transport sowie in der allgemeinen Freizeitgestaltung. Das Bayrische Landesvermessungsamt liefert derzeit den ATKIS-Datenbestand in drei verschiedenen Formaten. Diese sind EDBS, DXF und Shape. A.2. ARCHITEKTUR A.2 99 Architektur Bei dem in dieser Arbeit erstellten Routendienst steht die Erstellung von Routen mittels einer grafischen Benutzeroberfläche im Vordergrund. Diese soll es möglich machen, auf einfache Art und Weise statische Routen zu erzeugen. Die dazu einsetzbaren geografischen Datenbestände wurden bereits angesprochen. Um diese in eine grafische Form für die Benutzeroberfläche zu überführen und darauf basierend die Erstellung der Route zu ermöglichen, soll dieses Kapitel eine Architektur entwerfen, mit deren Hilfe dies umgesetzt werden kann. Der Großteil der Architektur wird dabei von dem Projekt OpenMap [ope b] bereitgestellt. OpenMap ist aus einem Forschungsprojekt in Zusammenarbeit mit der Defense Advanced Research Projects Agency (DARPA) des DoD entstanden. OpenMap wird heute von vielen staatlichen sowie nicht-staatlichen Institutionen genutzt. Für diese Arbeit hat sich die Version 4.6.2 von OpenMap als äußerst brauchbare Lösung für die Routenerstellung herausgestellt. A.2.1 OpenMap OpenMap ist in J2SE implementiert und Open-Source. Es besteht zum größten Teil aus Java Beans. Die wesentlichen Java Beans sind der MapHandler, die MapBean und das Layer. Der MapHandler ist die zentrale Komponente des Systems. Er ist das Verbindungsglied zu allen anderen Beans und ermöglicht so die Interaktion zwischen allen Komponenten. Eine der entscheidenden Interaktionen findet zwischen der MapBean und den Layers statt. Die MapBean ist für die grafische Anzeige der Karten verantwortlich. Sie besitzt einige Operationen, um die Darstellung zu verändern. Zu diesen Operationen gehören Vergrößerung, Verkleinerung, Verschiebung, Aus-/Einblenden von Informationen, etc. Durch die MapBean können Layers dargestellt werden. Sollen mehrere Layers dargestellt werden, veranlasst die MapBean die Zeichnung der Layers in der spezifizierten Reihenfolge. So erhält man einen geschichteten Aufbau, in dem einzelne Layers (=Schicht) individuelle Informationen einbringen. Diese Art der Darstellung zeigte sich während der Arbeit als sehr flexibel und äußerst pragmatisch. Jede der eingesetzten Schichten ist selbst verantwortlich für die Datenakquisition, Konstruktion und die grafische Aufbereitung der Daten. Durch die Anzeige in der MapBean erhält jede Schicht die aktuelle Projektion 1 . Dadurch kann die Schicht die darzustellenden Informationen für diese Projektion aufbereiten. Darüber hinaus kann eine Schicht ihr eigenes Kontextmenü kreieren und auf Maus- und Tastatureingaben reagieren. OpenMap stellt bereits einige Schichten standardmäßig zur Verfügung. Dazu gehört beispielsweise das CSVTiledImagePlugIn, zur Darstellung von einfachen Rastergrafiken. Diese müssen manuell georeferenziert werden. Dazu müssen die Koordinaten der Rastergrafik bekannt sein. Ein weiteres Layer ist das ShapeLayer zur Darstellung von Karten im ESRI Shape Format. ESRI Shape ESRI Shape ist ein standardisiertes Format zur Formalisierung von vektorbasierten, topografischen, digitalen Karten (vgl. [esr 98]). Es enthält einzelne Geoobjekte, die geografische Erscheinungen (wie z.B. Pfade, Gewässer, Bebauungsflächen) repräsentieren. Geoobjekte enthalten nicht-topologische Geometrie- und Attributinformationen und werden in drei Dateien abgelegt. Diese sind die Hauptdatei (.shp), die Indexdatei (.shx) und die Attributtabelle (.dbf). Die Hauptdatei besteht aus einem Header mit fester Länge und einer variablen Anzahl von Geoobjektbeschreibungen mit variabler Länge. Der Header der Hauptdatei enthält unter anderem Informationen über die Dateilänge, die Version und den dargestellten Bereich. Jede Geoobjektbeschreibung hat wiederum einen eigenen Header und eine variable Anzahl an Datensätzen. Im Header wird dem Geoobjekt eine fortlaufende Nummer und die Länge der Datensätze zuordnet. Datensätze des Geoobjekts können unterschiedliche Shape-Typen“ besitzen. Beispiele für Shape-Typen sind Points (Punkte bestehend aus X- und Y” Koordinate), MultiPoints (Liste von Punkten), PolyLines (Liste von Liniensegmenten, die wiederum aus 1 OpenMap bezeichnet als Projektion nicht nur die Kartenprojektion, sondern zusätzlich den aktuellen Kartenmittelpunkt (in Latitude/Longitude), die Skalierung und die Höhe und Breite der Anzeige 100 ANHANG A. ROUTENDIENST einer Liste von Punkten besteht) und Polygone (Liste von Ringen, die wiederum aus einer Liste von Punkten besteht). Die Indexinformationen zu den Geoobjekten in der Indexdatei müssen die gleiche Reihenfolge haben wie in der Hauptdatei. Zur schnelleren Suche von Geobjektbeschreibungen beinhaltet jede Indexinformation den Offset des Geoobjekts in der Hauptdatei. Um die Indexinformation schnell auffinden zu können, haben Indexinformationen eine konstante Länge. Die Attributtabelle besteht aus Geoobjektattributen, wie zum Beispiel Namen, Straßenarten oder Geschwindigkeitsbeschränkungen, und Verweisen auf andere Attributtabellen. Die Anzahl und Art der Attribute hängt in der Regel von der Art des Geoobjektes ab. Um Attribute eindeutig Geoobjekten zuordnen zu können, müssen die Attribute in der gleichen Reihenfolge wie die entsprechenden Geoobjekte in der Hauptdatei angeordnet sein. Das Format der Attributtabelle ist das standardmäßige dBase-Format. Meist werden Karten im ESRI Shape Format in Form einzelner Schichten mit bestimmten Informationen angeboten. Informationen einer Schicht sind zum Beispiel Pfade, Gewässer, Siedlungsflächen, etc. Durch geschickte Wahl dieser Schichten können wichtige Informationen eingeblendet und unwichtige Informationen ausgeblendet werden, um so keine Überflutung an Informationen in der Karte zu erzeugen. OpenMap Viewer OpenMap liefert bereits eine vorkonfigurierte Anwendung mit dem Namen OpenMap Viewer, der aus einer Zusammenstellung der oben genannten Java Beans besteht. Die Konfiguration erfolgt innerhalb einer Textdatei, so dass ein Hinzufügen einzelner Schichten, Menükomponenten, Statuszeilen, etc. ohne Neukompilierung des Systems durchgeführt werden kann. Die Konfiguration kann aber nicht zur Laufzeit erfolgen. Neben den Java Beans sind im OpenMap Viewer viele weitere wichtige Klassen, Skripte, Makefiles, etc. enthalten, die die Arbeit sehr erleichtern. Beispielsweise kann durch das Makefile direkt der OpenMap Viewer in Form einer MacOSX-Applikation generiert werden oder mit Hilfe von Skripten die Projektion von Karten im ESRI Shape Format betrachtet werden. A.2.2 Routenerstellung Mittels OpenMap ist es nun möglich, Karten in verschiedensten Formaten darzustellen. Ein Hauptziel dieses Routendienstes ist aber, die Erstellung von Routen zu ermöglichen. Dazu kann auf einer weiteren Schicht, die über der Karte dargestellt wird, die Erstellung der Routen erfolgen. Während die darunter liegende Schicht als Daten Geoinformationen akquiriert, konstruiert und grafisch aufbereitet, sind die Informationen dieser Schicht Routen. Den Anforderungen entsprechend soll es mehrere Eingabemöglichkeiten bei der Erstellung der Routen geben. Einerseits sollen Aktionspunkte grafisch definiert werden können und andererseits auch in textueller Form veränderbar sein. Desweiteren gibt es eine dritte Eingabemöglichkeit für die Spezifikation der Routenannotationen. Die Darstellung der Aktionspunkte erfolgt dementsprechend in grafischer Form und in Form einer textbasierten Liste. Routenannotationen werden ebenfalls in Listenform dargestellt, wobei diese speziell auf die Art der Annotation angepasst ist. Um durch die verschiedenen Ein- und Ausgabemöglichkeiten keine Inkonsistenzen bei der Routenerstellung zu erzeugen, ist es sinnvoll, nur eine zentrale Verwaltung der Route einzusetzen. All diese Anforderungen werden durch das Konzept des Model-View-Controller (MVC) Designmusters (vgl. [BMR+ 96]) abgebildet. Das MVC Designmuster trat erstmals in den 70er Jahren in der Programmiersprache Smalltalk80 in Erscheinung. Die MVC-Architektur basiert auf einer strikten Trennung der drei Komponenten Model, View und Controller (vgl. Abb. A.1). Das Model verwaltet die Daten (hier z.B. Routen) und hält dafür eine interne Repräsentanz dieser Daten. Views sind verantwortlich für die Darstellung der Daten. Dabei kann es verschiedenste Darstellungsformen der Daten geben. Für die Routendarstellung soll hier eine grafische sowie eine textuelle Präsentation erfolgen. Controller kümmern sich um Ereignisse, die eine Veränderung des Models nach sich ziehen. Diese Ereignisse werden meist durch den Nutzer ausgelöst. Innerhalb des Routendienstes ist ein Ereignis zum Beispiel das Klicken mit der Maus auf die Karte, um einen Aktionspunkt zu setzen. Um sowohl Views als auch Controller zu einem bestehenden Model hinzufügen zu können, sind das Model und die Views/Controller nur einer geringen Kopplung ausgesetzt. Für die Views wird dies zum Beispiel 101 A.3. IMPLEMENTIERUNG Controller View Model Abbildung A.1: Model-View-Controller (MVC) durch das Publish/Subscribe-Muster erlangt. Dazu meldet sich ein View bei dem korrespondierenden Model an (Subscribe), um daraufhin bei jeder Änderung des Datenbestandes über die Aktualisierung informiert zu werden (Publish). Das Model merkt sich dabei nicht speziell, welcher View sich registriert hat, sondern hält bloß eine Liste aller angemeldeten Views, die bei einer Veränderung informiert werden müssen. Jeder View besitzt dazu eine Zugriffsmethode für die Aktualisierung. A.2.3 Routenbereitstellung Um die Routen für den Navigationsdienst zu erlangen, müssen sie an einer Schnittstelle des Routendienstes zur Verfügung gestellt werden. Hierfür wurde eine Socketschnittstelle gewählt, so dass der Zugriff sowohl durch Navigationsapplikationen auf dem mobilen Endgerät als auch durch ausgelagerte Navigationsapplikationen in der Infrastruktur erfolgen kann. Für die Kommunikation zwischen Navigationsdienst und Routendienst wurde ein einfaches proprietäres Protokoll gewählt, das analog zum bereits beschriebenen Protokoll innerhalb des MoBiLe-Service aufgebaut ist. Für die lokale Variante des MoBiLe-Service kann hierdurch unnötiger Datenverkehr über die Luftschnittstelle, der durch die große Menge an Signalisierungsverkehr zum Beispiel bei HTTP oder SMTP entsteht, verhindert werden. Der Routendienst beherrscht derzeit drei Zugriffsmethoden, die eingesetzt werden können, um gesamte Routen, Aktionspunkte von Routen oder deren Annotationen abzufragen. Diese Methoden sind getRoute, getActionPoints und getAnnotations. Wird kein Parameter zu diesen Methoden angegeben, werden alle verfügbaren Informationen zurückgeliefert. Parameter können die angeforderte Route genauer spezifizieren. Als Parameter kann die bereits in Kapitel 5.5 vorgestellte RouteProperty eingesetzt werden. A.3 Implementierung Wie genau die oben beschriebene Architektur in der Implementierung umgesetzt wurde, wird im Folgenden behandelt. Hierbei wurden einige wichtige Details, wie zum Beispiel die Umsetzung der MVC-Architektur, ausgewählt. Für eine vollständige Beschreibung wird auf den Quellcode des Routendienstes verwiesen. A.3.1 Model Das Model (RouteModel) der grafischen Routenerstellung ist verantwortlich für den Zugriff auf die Route. Zur Beschreibung der Route wurde die bereits in Kapitel 5.5 dargestellte Form benutzt, die im Wesentlichen aus einer geordneten Liste von Aktionspunkten mit einer bestimmten Position und einer 102 ANHANG A. ROUTENDIENST einzuschlagenden Richtung besteht. Zusätzlich können zu jeder Route noch eine Menge an Annotationen hinzugefügt werden. In der Implementierung wurden als Annotationen nur der Name der Route, der Schwierigkeitsgrad, die Länge der Route und die zu überwindenden Höhenmeter eingesetzt. Alle Zugriffe auf die Route, unabhängig davon, ob es sich um lesende Zugriffe der Views oder schreibende Zugriffe der Controller handelt, werden durch das Model durchgeführt. Dazu implementiert das RouteModel das Interface Model, welches alle möglichen schreibenden Zugriffe spezifiziert. Über dieses Interface können die verschiedenen Controller auf das RouteModel zugreifen. Die für den Zugriff implementierten Methoden sind: • setRoute zum Setzen einer neuen Route • addActionPoint zum Hinzufügen eines Aktionspunktes zur aktuellen Route • removeActionPoint um Aktionspunkte aus der aktuellen Route zu entfernen • setAnnotations um Annotationen an die aktuelle Route anzuhängen • saveRoute um Routen persistent im Dateisystem abzuspeichern Außerdem stellt das RouteModel die Methode addView bereit, um Views zu diesem Model hinzuzufügen. Bei jeder Veränderung der Route durch obige Zugriffsmethoden werden alle Views über die Änderung informiert. A.3.2 View Zur Darstellung der aktuellen Route stehen dem Nutzer diverse Views für das RouteModel zur Verfügung, die automatisch oder manuell eingeblendet werden (vgl. Abb. A.2). RouteLayer SaveRoute MenuItem ActionPoint InfoPanel Route InfoPanel RouteModel LoadRoute MenuItem Abbildung A.2: MVC-Architektur des Routendienstes A.3.2.1 Grafische Darstellung der Aktionspunkte Der wichtigste View ist sicherlich die grafische Darstellung auf dem Kartenhintergrund. Die Karte wird dabei durch eine darunter liegende Schicht angezeigt. Als digitaler Datenbestand wurden topografische Karten im ESRI Shape Format gewählt, da diese über eine hohe Genauigkeit verfügen, einen gewissen Grad an Semantik der enthaltenen Geoobjekte besitzen und mit einem sehr hohen Detailgrad in Deutschland angeboten werden. Die eingesetzten Karten stammen vom Bayrischen Landesvermessungsamt und bestehen aus einer Menge einzelner Schichten. Als wichtige Schichten für die Erstellung von MountainBike-Touren stellten sich Schichten mit folgenden Informationen heraus (in aufsteigender Ordnung): • Besiedlung: Darstellung von Siedlungsflächen A.3. IMPLEMENTIERUNG 103 • Bepflanzung: Darstellung von Wäldern oder Baumgruppen • Gewässer: Darstellung von Flüssen, Bächen und Seen • Pfadinformationen: Darstellung von Straßen, Wegen, Plätzen, etc. Die Geoobjekte der einzelnen Schichten können durch verschiedenfarbige Einfärbung visuell voneinander getrennt werden. Für die Farbwahl wurden die in Deutschland gängigen Farben gewählt (Siedlung: orangebraun, Pflanzen: grün, Gewässer: blau, Pfadinformationen: schwarz). Dadurch kann der Nutzer ohne große Vorkenntnis oder Betrachtung der Legende intuitiv den dargestellten Inhalt verstehen. Überhalb dieser Schichten liegt das RouteLayer, das die Aktionspunkte als rote Kreise darstellt. Je nach Stärke der Vergrößerung besitzt der Kreis unterschiedliche Radien bezüglich des zugrunde liegenden Kartenmaterials, so dass er eine einheitliche Größe in der Darstellung besitzt. In unmittelbarem Umfeld des Kreises ist außerdem die ID des Aktionspunktes zu finden, um eindeutig vom Nutzer identifiziert werden zu können. Ein Screenshot mit allen implementierten Views ist in Abbildung A.3 dargestellt. Abbildung A.3: Screenshot der grafischen Oberfläche des Routendienstes A.3.2.2 Textuelle Darstellung der Aktionspunkte Neben der grafischen Darstellung der Aktionspunkte zeigt eine Listendarstellung die Aktionspunkte der aktuellen Route in aufsteigender Reihenfolge. Die Darstellung in textueller Form erfolgt erst nach manueller Wahl eines entsprechenden Symbols in der Werkzeugleiste. Wird aus der Liste (javax.swing.JList) ein Aktionspunkt ausgewählt, erscheint dessen ID sowie dessen Austrittsrichtung innerhalb des Fensters. 104 A.3.2.3 ANHANG A. ROUTENDIENST Textuelle Darstellung der Route Eine dritte Darstellung der Route präsentiert alle Annotationen der aktuellen Route und einige weitere Informationen. Darstellbare Annotationen sind der Name der Route, der Schwierigkeitsgrad, die Länge und die Anzahl der Höhenmeter. Je nach Art der Annotation erfolgt eine unterschiedliche Darstellung. Name, Länge und Höhenmeter erscheinen in Textfeldern, wobei die Textfelder der Länge und Höhenmeter ausschließlich Dezimalzahlen darstellen können. Der Schwierigkeitsgrad wird durch eine javax.swing.JComboBox präsentiert, die Werte zwischen 1 und 5 enthalten kann. Desweiteren wird für jede Route die interne ID angezeigt. A.3.3 Controller Eingabemöglichkeiten für die Route werden durch einige Controller des Routendienstes repräsentiert. Meist sind diese an die Views gekoppelt. Es existieren aber auch einige Controller die keinem View zugeordnet werden können (vgl. Abb. A.2. A.3.3.1 Grafische Aktionspunktmanipulation Innerhalb der grafischen Darstellung der Aktionspunkte kann durch einfaches Klicken mit der Maus ein Aktionspunkt gesetzt werden. Bevor dieser in die Route übernommen wird, muss der Nutzer noch manuell die Austrittsrichtung bestimmen (vgl. Abb. A.4). Dazu werden ihm acht mögliche Sektoren bereitgestellt, die den Himmelsrichtungen N ord, N ordost, Ost, S üdost, S üd, S üdwest, W est, N ordwest entsprechen. Durch Anklicken kann der Nutzer die Austrittsrichtung spezifizieren. Wird an einer anderen Stelle als der vorgeschlagenen Richtungen geklickt, wird der Vorgang abgebrochen. Daraufhin kann ein anderer Aktionspunkt gesetzt werden. Zur Wahrung der Flexibilität wurde bei der Routenbestimmung durch den Nutzer nicht auf Geoobjekte, im Speziellen auf Pfadinformationen, eingegangen, obwohl dies prinzipiell möglich und sinnvoll ist. Pfadinformationen sind auf einfache Art und Weise aber nur in Vektorgrafiken zugänglich (vgl. [Beck 02]). Um mit gleicher Technik auch Rastergrafiken einsetzen zu können, wurde die oben dargestellte Art der Aktionspunkt- und Austrittsrichtungsbestimmung gewählt. Hierbei muss eine manuelle Wahl der Austrittsrichtung erfolgen. Abbildung A.4: Spezifikation der Austrittsrichtung aus Aktionspunkt A.4. EVALUIERUNG UND AUSBLICK A.3.3.2 105 Textuelle Aktionspunktmanipulation Die oben beschriebene textuelle Darstellung der Aktionspunkte ist gleichzeitig ein weiterer Controller. Durch Auswahl eines Aktionspunktes aus der Liste wird dessen ID und Austrittsrichtung in einem Textfeld bzw. einer ComboBox angezeigt. Innerhalb des Textfeldes und der ComboBox können diese Werte nachträglich verändert werden. Außerdem können einzelne Aktionspunkte an dieser Stelle entfernt werden. A.3.3.3 Textuelle Annotationsmanipulation Ähnlich wie bei der Darstellung der Aktionspunkte kann in der textuellen Darstellung der Routenannotationen das entsprechende RouteProperty geändert werden. Änderungen sind möglich für den Routennamen, den Schwierigkeitsgrad, die Länge und die Anzahl der Höhenmeter. Die interne ID der Route sowie die Anzahl der Aktionspunkte können an dieser Stelle nicht verändert werden. A.3.3.4 Routenspeicherung Wurde die Route erfolgreich erstellt, kann sie im Dateisystem persistent abgelegt werden. Hierfür existiert ein weiterer Controller, der durch das Menü gestartet werden kann. Wird er aufgerufen, so muss im Folgenden der Ort der Speicherung und der Dateiname festgelegt werden. Durch Bestätigung wird die Route über das RouteModel unter dem Dateinamen abgelegt und kann so später wieder geladen werden. Außerdem kann die Route ab der Speicherung für den Navigationsdienst zugänglich gemacht werden. A.3.3.5 Routenwiederherstellung Bereits abgespeicherte Routen können durch einen weiteren Menüpunkt wieder geladen werden. Dazu muss der Nutzer die Datei, innerhalb der die Route abgelegt wurde, spezifizieren. Nach dem Ladevorgang wird die geladene Route an das RouteModel übergeben. Das RouteModel führt daraufhin (wie bei allen Änderungen) eine Aktualisierung der Views durch. Die Routenwiederherstellung und Routenspeicherung stellen nur Contoller dar und besitzen keine Views, da sie nur Operationen auf die Route, aber keine Darstellung der Route durchführen. A.3.4 RouteServer Der RouteServer stellt die veröffentlichten Routen an einer Socketschnittstelle bereit. Auf diese Socketschnittstelle kann der Navigationsdienst zugreifen. Dabei ist unwichtig, ob der Navigationsdienst lokal oder verteilt ist. Für den Zugriff stehen die bereits beschriebenen Methoden zur Verfügung. Gestartet und gestoppt wird der Routendienst durch einen Menüpunkt des OpenMap Viewers. Dabei kann angegeben werden, welche Routen durch die Socketschnittstelle veröffentlicht werden sollen. A.4 Evaluierung und Ausblick Die Implementierung des Routendienstes hat gezeigt, dass eine Umsetzung auf der Basis von OpenMap sehr komfortabel und zielführend ist. Die oben angeführten Aspekte ließen sich wie gewünscht umsetzen und nutzen. So entstand ein Routendienst, der den gewünschten Anforderungen an die Routenerstellung, -verwaltung und -bereitstellung weitgehend entgegenkommt. Routen lassen sich auf eine nutzerfreundliche Art definieren und verändern, persistent speichern und später wiederherstellen. Das zugrunde liegende Kartenmaterial präsentierte sich als äußerst detailreich und exakt 106 ANHANG A. ROUTENDIENST in der Georeferenzierung. Für einige ausgewählte Testpunkte ergab sich nur ein geringer Messfehler zwischen Koordinaten der Karte und Koordinaten aus dem Fortuna Clip-On Bluetooth GPS Receiver. Leider benötigt das vektorbasierte Kartenmaterial für die Darstellung relativ viel Rechenleistung, was bei Vergrößerungen, Verschiebungen oder Bearbeitungen teilweise zu längeren Wartezeiten führte. Diese beliefen sich meist auf wenige Sekunden, die die Arbeit nur unwesentlich beeinträchtigten. Möglicherweise können hier noch Effizienzsteigerungen zum Beispiel durch Caching erzielt werden. Wie bereits angesprochen, kann in Erweiterungen des Routendienstes auch auf die Geoobjekte des ESRI Shape eingegangen werden. Mögliche Vorteile ergeben sich zum Beispiel durch die automatische Bestimmung der Austrittsrichtung und die Einfärbung relevanter Pfadsegmente. Dadurch wäre beispielsweise auch eine automatische Bestimmung der Routenlänge und der Anzahl der Höhenmeter möglich. Desweiteren könnten mehrere Routen gleichzeitig eingeblendet und bearbeitet werden bzw. Alternativrouten zu einer Route definierbar sein. Zusammenfassend kann gesagt werden, dass an die Weiterentwicklung des Routendienstes keine Grenzen gesetzt sind. Vorstellbar sind diverse Erweiterungen für verschiedenste Funktionen und Eigenschaften. Die derzeitige Version des Routendienstes ist aber vollkommen ausreichend für die Erstellung, Verwaltung und Bereitstellung der Mountain-Bike-Routen und hat sich in der Praxis bereits als sehr nützlich herausgestellt. Literaturverzeichnis [3gp a] Gateway Mobile Location Center. Technischer Bericht 03.71, 3rd Generation Partnership Project (3GPP). [3gp b] IP Multimedia Subsystem. Technischer Bericht 23.228, 3rd Generation Partnership Project (3GPP). [3gp c] Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface. Technischer Bericht 24.011, 3rd Generation Partnership Project (3GPP). [3gp d] Push Service. Technischer Bericht 22.174, 3rd Generation Partnership Project (3GPP), März. [3gp e] Support of Push service. Technischer Bericht 23.974, 3rd Generation Partnership Project (3GPP). [3gp 04] Functional stage 2 desctiption of Location Services (LCS). Technischer Bericht 23.271, 3rd Generation Partnership Project (3GPP), 2004. [AAH+ 97] A BOWD , G REGORY D., C HRISTOPHER G. ATKESON, JASON H ONG, S UE L ONG, ROB KO OPER und M IKE P INKERTON : Cyberguide: A Mobile Context-Aware Tour Guide. In: ACM Wireless Networks, Seiten 421–433, 1997, citeseer.ist.psu.edu/abowd97cyberguide.html . [act ] Falk Active Pilot, http://www.activepilot.de . [and ] Automotive Navigation Data, http://www.and.com . [Ande 03a] A NDERSSON , O LA: Mobile SVG Profiles: SVG Tiny and SVG Basic. Technischer Bericht, W3C, 2003, http://www.w3.org/TR/SVGMobile/ . [Ande 03b] A NDERSSON , O LA: Scalable Vector Graphics (SVG) 1.1. Technischer Bericht, W3C, 2003, http://www.w3.org/TR/SVG11/ . [Andr 91] A NDREWS , G REGORY R.: Paradigms for Process Interaction in Distributed Programs. 1991. [atk ] Amtliches Topographisch-Kartographisches Informationssystem, http://www.atkis.de . [b2m ] B2Motion - NavMe, http://www.navme.de . [BBKL ] B UTZ , A NDREAS, J ÖRG BAUS, A NTONIO K R ÜGER und M ARCO L OHSE: A Hybrid Indoor Navigation System. . [BCK 04] BAUS , J ÖRG, K EITH C HEVERST und C HRISTIAN K RAY: A Survey of Map-based Mobile Guides. 2004. [Beck 02] B ECKERT, C HRISTIANE: Möglichkeiten der Beschaffung und Bereitstellung digitaler Karten im Sondersammelgebiet. Technischer Bericht, DFG, 2002. [BKK 01] BAUS , J ÖRG, C HRISTIAN K RAY und A NTONIO K R ÜGER: Visualisation of route descriptions in resource-adaptive navigation aid. 2001. 107 108 LITERATURVERZEICHNIS [BKKW ] BAUS , J ÖRG, C HRISTIAN K RAY, A NTONIO K R ÜGER und W OLFGANG WAHLSTER: A Resource-Adaptive Mobile Navigation System. . [bla ] Blackberry, http://www.blackberry.com . [blu ] Bluelet - Bluetooth GUI Component, http://www.benhui.net . [blv ] Bayrisches Landesvermessungsamt, http://www.blva.de . [BMR+ 96] B USCHMANN , F RANK, R EGINE M EUNIER, H ANS ROHNERT, P ETER S OMMERLAD und M ICHEAL S TAL: Pattern-oriented software architecture. John Wiley & Sons, 1996. [BoCa 46] B ORGES , J ORGE L UIS und A DOLFO B IOY C ASARES: Of Exactitude in Science. 1946, www.kyb.tuebingen.mpg.de/bu/people/bs/borges.html . [Brow ] B ROWN , P. J.: Triggering information http://www.cs.kent.ac.uk/pubs/1998/591/content.html . [BuTu ] B URMAKIN , E UGENE M. und J UHA O. T UOMINEN: Development of mobile distributed applications. . [CCR 03] C HEN , X IAOYAN, Y ING C HEN und FANGYAN R AO: An Efficient Spatial Publish/Subscribe System for Intelligent Location-Based Services. 2003. by context. , [CDM+ 00] C HEVERST, K EITH, N IGEL DAVIES, K EITH M ITCHELL, A DRIAN F RIDAY und C HRISTOS E FSTRATIOU: Developing a Context-aware Electronic Tourist Guide: Some Issues and Experiences. In: Proceedings of CHI 2000, Netherlands, 2000. , http://www.guide.lancs.ac.uk/CHIpaper.pdf . [CDMF 00] C HEVERST, K EITH, N IGEL DAVIES, K EITH M ITCHELL und A DRIAN F RIDAY: The Role of Connectivity in Supporting Context-Sensitive Applications. 2000. [ChKo 00] C HEN , G UANLING und DAVID KOTZ: A Survey of Context-Aware Mobile Computing Research. 2000. [Chun 03] C HUNG , N G P ING: Positioning of Mobile Devices. August 2003, http://www.giscentrum.lu.se/www summeruniverstity/projects2003/PingChung.pdf . [cld a] Connected Limited Device Configuration 1.0. Technischer Bericht JSR-30, Java Community Process (JCP). [cld b] Connected Limited Device Configuration 1.1. Technischer Bericht JSR-139, Java Community Process (JCP). [CST 04] C AETANO , A RTUR, A NTONIO R ITO S ILVA und J OSE T RIBOLET: Using Roles To Specify Business Object Collaborations. Technischer Bericht, 2004. [Czom 00] C ZOMMER , R ENATE: Leistungsfähigkeit fahrzeugautonomer Ortungsverfahren auf der Basis von Map-Matching Techniken. Doktorarbeit, Universität Stuttgart, Dezember 2000. [DeAb 99] D EY, A NIND K. und G REGORY D. A BOWD: Towards a Better Understanding of Context and Context-Awareness. 1999. [DFGS 05] D ÜRR , M ICHAEL, KORBINIAN F RANK, A NDREAS G IESEMANN und D OMINIK S CHMIDT: Location Based Services. 2005. [Dijk 76] D IJKSTRA , E. W.: A Discipline of programming. Prentice Hall, New York, 1976. [elb ] European Location Based Advertising. http://www.yellowmap.com/mobile/elba.asp. [esr 98] ESRI Shapefile Technical Description. Technischer Bericht, ESRI, 1998. [Fiel 99] F IELDING: HTTP/1.1. Technischer Bericht, Internet Engineering Task Force (IETF), Juni 1999. LITERATURVERZEICHNIS 109 [for ] Fortuna, http://www.fortuna.com.tw . [for 04] Nokia 6630, Juni 2004, http://www.forum.nokia.com/main/0,6566,016-2219,00.html . [FrZd 96] F RANKLIN , M ICHAEL und S TAN Z DONIK: Dissemination-Based Information Systems. IEEE Data Engineering Bulletin, 19(3), September 1996. [Fuch 02] F UCHS , F LORIAN: Realizing Location-Based Push-Services on Mobile Devices, 2002. [Funk ] F UNK , NATHAN: Java Expression Parser, http://jep.sourceforge.net . [gal ] Galileo Joint Undertaking, http://www.galileoju.com . [gar ] Garmin, http://www.garmin.de . [GaSh 93] G ARLAN , DAVID und M ARY S HAW: An Introduction to Software Architecture. In: A MBRIO V. und G. T ORTORA (Herausgeber): Advances in Software Engineering and Knowledge Engineering, New Jersey, 1993. World Scientific Publishing Company. LA , [gdf 96] Geographic Data Files (GDF). Technischer Bericht 14825:1996(E), International Standards Organisation (ISO), 1996. [geo 84] Geodesy for the layman. Technischer Bericht DMA TR 80-003, Defense Mapping Agency, Washington D C, 1984. [geo 04] Geopriv Requirements. Technischer Bericht RFC 3693, Internet Engineering Task Force (IETF), 2004. [GKW 04] G RANDE , A NTJE, B IRGIT K RAUS und D OROTHEE W IEGAND: Standortbestimmung. CT Magazin, (10), 2004. [glo a] Global Locate A-GPS, http://www.glocallocate.com/A-GPS/A-GPS-Frameset.htm . [glo b] Global’naya Navigatsionannaya Sputnikovaya Sistema, http://www.glonass-center.ru . [gsm ] GSM Coverage, http://www.gsmworld.com/roaming/gsminfo/cou de.shtml . [gsm 03] Location Based Services. Technischer Bericht SE.23, GSM Association, 2003, http://www.gsmworld.com/technology/applications/location.shtml . [Hell 04] H ELLMANN , W IEBKE: Völlig losgelöst ans Ziel. Chip, November http://www.chip.de/artikel/c1 artikel 12835281.html?tid1=20827&tid2=0 . [HiBo 01] H IGHTOWER , J EFFREY und G AETANO B ORIELLO: Location Sensing Techniques. 2001. [HLP ] H UANG , A NDREW C., B ENJAMIN C. L ING und S HANKAR P ONNEKANTI: Pervasive Computing: What Is It Good For? . [hof 93] GPS - Theory and Practice. Springer-Verlag Wien, 2 Auflage, 1993. [iet 99] Session Initiation Protocol. Technischer Bericht RFC 2543, Internet Engineering Task Force (IETF), 1999. [jab ] Java APIs for Bluetooth Wireless Technology. Technischer Bericht JSR-82, Java Community Process (JCP). [jam ] Jamba, http://www.jamba.de . [jav ] Java 2, http://java.sun.com . [Klat 04] K LATZKY, ROBERTA L.: Allocentric and Egocentric Spatial Representations: Definitions, Distinctions, and Interconnections. 2004. 2004, [KLEC 03] K RAY, C HRISTIAN, K ATRI L AAKSO, C HRISTIAN E LTING und VOLKER C OORS: Presenting Route Instructions on Mobile Devices. 2003. 110 LITERATURVERZEICHNIS [Klin 04] K LINGSHEIM , A NDRE N.: J2ME Bluetooth Programming. Diplomarbeit, Universtität Bergen, 2004. [Klip 03] K LIPPEL , A LEXANDER: Wayfinding Choremes - Conceptualizing Wayfinding and Route Direction Elements. Doktorarbeit, Universität Bremen, 2003. [Kola ] KOLAROFF , S TEPHEN: JEPLite - JEP enlited, http://jeplite.sourceforge.net . [kow ] GPS, http://www.kowoma.de/gps . [Kray 03] K RAY, C HRISTIAN: Situated Interaction on Spatial Topics. Doktorarbeit, Universität des Saarlandes, 2003. [KrBa 03] K RAY, C HRISTIAN und J ÖRG BAUS: A survey of mobile guides. 2003. [Kuip 00] K UIPERS , B. J.: The spatial semantic hierarchy. In: Artificial Intelligence, Seiten 191–233, 2000. [Küpp 05] K ÜPPER , A XEL: LBS - Fundamentals and Operation. John Wiley & Sons, 2005. [KüTr 05] K ÜPPER , A XEL und G EORG T REU: From Location to Position Management: User Tracking for Loction-based Services. 2005. [lap 03] Location API for J2ME. Technischer Bericht 179, Java Community Process (JCP), 2003. [LeRo 00] L EONHARDI , A LEXANDER und K URT ROTHERMEL: A Comparison of Protocols for Updating Location Information. 2000. [LKAA 96] L ONG , S UE, ROB KOOPER, G REGORY D. A BOWD und C HRISTOPHER G. ATKESON: Rapid Prototyping of Mobile Context-Aware Applications: The Cyberguide Case Study. In: Mobile Computing and Networking, Seiten 97–107, 1996, citeseer.ist.psu.edu/long96rapid.html . [Logs 92] L OGSDON , T OM: The NAVSTAR Global Positioning System. Van Nostrand Reinhold, 1992. [LPKü 04] L INNHOFF -P OPIEN , C LAUDIA und A XEL K ÜPPER: Vorlesung: Location Based Services, 2004. [m3g ] Mobile 3D Graphics API for J2ME. Technischer Bericht JSR-184, Java Community Process (JCP). [Maea 04] M ABROUK , M ARWA und ET AL .: OpenGIS Location Services (OpenLS): Core Services. Technischer Bericht 03-006r3, Open GIS Consortium Inc., Januar 2004. [mag ] Magellan, http://www.magellangps.com . [Mala 99] M ALAKA , R AINER: Deep Map: The Multilingual Tourist Guide. 1999. [mas ] Mascot Capsule, http://www.mascotcapsule.com/ . [MaZi 00] M ALAKA , R AINER und A LEXANDER Z IPF: DEEP MAP - Challenging IT research in the framework of a tourist information system. 2000. [me4 ] ME4SE, http://kobjects.sourceforge.net/me4se . [mid a] Mobile Information Device Profile 1.0. Technischer Bericht JSR-37, Java Community Process (JCP). [mid b] Mobile Information Device Profile 2.0. Technischer Bericht JSR-118, Java Community Process (JCP). [mlp ] Mobile Location Protocol. Technischer Bericht, Open Mobile Alliance (OMA). [mma ] Mobile Media API 1.1. Technischer Bericht JSR-135, Java Community Process (JCP). [mob ] Mobile Navigator. http://www.wayfinder.com. [mog ] MOGI, http://www.mogimogi.com . LITERATURVERZEICHNIS [Mont ] 111 M ONTELLO: Navigation. . [MTSM 03] M C G OVERN , JAMES, S AMEER T YAGI, M ICHAEL S TEVENS und S UNIL M ATHEW: Java Web Services Architecture. Morgan Kaufmann Publishers, 2003. [nav ] NAVTEQ, http://www.navteq.com . [Nico 03] N ICOLAI , ROEL: Spatial referencing by coordinates. Technischer Bericht, Open GIS Consortium Inc., Oktober 2003. [Nieb 04] N IEBISCH , F RANK L.: Smartphones weisen den Weg. Handelsblatt, Dezember 2004, http://www.handelsblatt.com/pshb?fn=tt&sfn=go&id=87913 . [nme ] National Marine Electronics Association (NMEA), http://www.nmea.org . [nok ] Nokia 6630, http://www.nokia.com/nokia/0,,58708,00.html . [o2 ] O2, http://www.o2online.de . [off a] Navstar Global Positioning System, http://tycho.usno.navy.mil/gps.html . [off b] NAVSTAR GPS, ftp://tyscho.usno.navy.mil/pub/gps/gpsb2.txt . [ope a] OpenGL ES. Technischer Bericht. [ope b] OpenMap - Open Systems Mapping Technology, http://openmap.bbn.com . [PARA 02] PARAMOUNT: Client/Server Trade-Off. Technical Note Deliverable D7, 2002. [Pars 04] PARSONS , D.: The mobile future. In: Res. Lett. Inf. Math. Sci., Seiten 47–58, 2004. [Pass 92] PASSINI , R.: Wayfinding in architecture. Van Nostrand Reinhold Company, New York, 1992. [PCW 84] PARNAS , D. L., P. C. C LEMENTS und D. M. W EISS: The Modular Structure of Complex Systems. 1984. [PKK ] P OSPISCHIL , G ÜNTHER, H ARALD K UNCZIER und A LEXANDER K UCHAR: LoL@: a UMTS location based service. . [PSM 01] P OSPISCHIL , G ÜNTHER, J OHANNES S TADLER und I GOR M ILADINOVIC: A Locationbased Push Architecture using SIP. Denmark, September 2001. . [ptv ] PTV AG, http://www.ptv.de . [PUM 02] P OSPISCHIL , G ÜNTHER, M ARTINA U MLAUFT und E LKE M ICHLMAYR: Designing LoL@, a Mobile Tourist Guide for UMTS. 2002. [Röck 03] R ÖCKL , M ATTHIAS: Highlevel Service Handover in einem kontextuellen Framework, 2003. [RöLa 02] R ÖFER , T. und A. L ANKENAU: Route-Based Robot Navigation. In: F REKSA , C. (Herausgeber): Künstliche Intelligenz - Themenheft Spatial Cognition, Seiten 29–31. Fachbereich 1 der Gesellschaft für Informatik e.V., 2002. [Roth 03] ROTH , J ÖRG: Flexible Positioning For Location-based Services. 2003. [rou ] Route 66. http://www.66.com. [RuKr 03] RUPNIK , ROK und M ARJAN K RISPER: The role of mobile applications in information systems. 2003. [SAW 94] S CHILIT, B ILL N., N ORMAN A DAMS und ROY WANT: Context-Aware Computing Applications. 1994. [Schi 95] S CHILIT, W ILLIAM N OAH: A System Architecture for Context-Aware Mobile Computing. Doktorarbeit, Columbia University, 1995. 112 LITERATURVERZEICHNIS [Schm 04] S CHMATZ , K LAUS -D IETER: Java 2 Micro Edition - Entwicklung mobiler Anwendungen mit CLDC und MIDP. Nummer 3-89864-271-2. dpunkt.verlag, April 2004. [Simo 05] S IMON , M URIEL: Galileo - The European Programme for Global Navigation Services. ESA Publications Division, Niederlande, 2 Auflage, Januar 2005. [sir ] SIRF, http://www.sirf.com . [SLPR 03] S TRANG , T HOMAS, C LAUDIA L INNHOFF -P OPIEN und M ATTHIAS R ÖCKL: Highlevel Service Handover through a Contextual Framework. 2003. [SMLP ] S AMULOWITZ , M ICHAEL, F LORIAN M ICHAHELLES und C LAUDIA L INNHOFF -P OPIEN: CAPEUS: An Architecture for Context-Aware Selection and Execution of Services. . [sql 99] Structured Query Language. Technischer Bericht SQL3, International Standards Organisation (ISO), 1999. [StLP 03] S TRANG , T HOMAS und C LAUDIA L INNHOFF -P OPIEN: Service-Interoperabilität auf Kontextebene. 2003. [Stra 05] S TRANG , T HOMAS: Vorlesung: Ubiquitous Services, Wintersemester 04/05. [Stra 03] S TRANG , T HOMAS: Service-Interoperabilität in Ubiquitous Computing Umgebungen. Doktorarbeit, Ludwig-Maximillians-Universität München, 2003. [svg ] Scalable 2D Vector Graphics API for J2ME. Technischer Bericht JSR-226, Java Community Process (JCP). [sym ] Symbian OS, http://www.symbian.com . [TavS 03] TANENBAUM , A NDREW S. und M AARTEN VAN S TEEN: Distributed Systems. Prentice Hall, März 2003. [tel ] Teleatlas, http://www.teleatlas.com . [tin ] TinyLine - Mobile SVG Software for J2ME, http://www.tinyline.com . [tol ] Toll Collect, http://www.toll-collect.de . [Tolm 48] T OLMAN , E DWARD C.: Cognitive maps in rats and men. Psychological Review, (55):189– 208, 1948. [tom ] Tom Tom Mobile 5, http://www.tomtom.com . [Tosi 03] T OSI , DAVIDE: An Advanced Architecture for Push Services. Technischer Bericht, Universita degli Studi di Milano - Bicocca, 2003. [Umar 97] U MAR , A MJAD: Object-Oriented Client/Server Interent Environments. Prentice Hall, 1997. [uml 03] Unified Modeling Language Specification. Technischer Bericht, Object Management Group (OMG), 2003. [UPNM ] U MLAUFT, M., G. P OSPISCHIL, G. N IKLFELD und E. M ICHLMAYR: LoL@, a Mobile Tourist Guide for UMTS. . [VAL+ 01] V ÄRE , JANNE, N. A SOKAN, S HREEKANTH L AKSHMESHWAR, S YLVIE B RUNESSAUX und C EDRIC C ARON: Report on the Review and Selection of Authentication and Security Techniques, Applicable Internet Technologies, Hardware Platforms, Mobile Phones and Internet Terminals. Technischer Bericht, Nokia - VTT Information Technology - MATRA Systemes & Information, 2001. [VHT ] VALLECILLO , A NTONIO, J UAN H ERNANDES und J OSE M. T ROYA: Component Interoperability. . 113 LITERATURVERZEICHNIS [Wald 03] WALDEN , M ARTIN: Towards the integration of vector map graphics in mobile environments. Diplomarbeit, Lund Institute of Technology, 2003. [wap a] Wireless Application Protocol, http://wapforum.org . [wap b] Wireless Application Protocol Push Architecture, http://www1.wapforum.org/tech/terms.asp?doc=WAP250-PushArchOverview-20010703-a.pdf . [Warr 99] WARREN , I AN: The Renaissance of Legacy Systems. Springer, Januar 1999. [web ] Webraska, http://www.webraska.com . [Weis 91] W EISER , M ARK: The Computer for the Twenty-First Century. Scientific American, Seiten 94–100, 1991. [wgs ] World Geodetic System 1984, http://www.wgs84.com . [wik ] Wikipedia, http://www.wikipedia.de . [WKBH 00] W ERNER , S., B. K RIEG -B R ÜCKNER und T. H ERRMANN: Modeling navigational knowledge by route graphs. In: Spatial cognition II. Integrating abstract theories, empirical studies, formal methods, and practical applications, 2000. [ZiAr 02] Z IPF, A LEXANDER und H IDIR A RAS: Proactive Exploitation of the Spatial Context in LBS through Interoperable Integration of GIS-Services with an Multi Agent System. 2002. [Zieg 04] Z IEGLER , P ETER -M ICHAEL: Routenplaner im Handy. http://www.heise.de/mobil/artikel/50891 . [Zogg 02] Z OGG , J EAN -M ARIE: GPS Basics. lab/usbgps/doc/gps basic.pdf . Heise Online, Juli 2004, u-blox, März 2002, http://www.ee.ucr.edu/ cr-