auf dem Fingerprintverfahren
Abschlussarbeit
zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.)
an der
Hochschule für Technik und Wirtschaft Berlin Fachbereich Wirtschaftswissenschaften II
Studiengang Angewandte Informatik
1. Prüfer: Prof. Dr.-Ing. Thomas Schwotzer 2. Prüfer: Dr. Alexander Huhn
Eingereicht von: Johann Winter Datum der Abgabe: 06.10.2017
Diese Arbeit beschäftigt sich mit der Neustrukturierung und der Weiterentwicklung ei- ner Android-Applikation zur Ortung in Gebäuden mittels WLAN-Fingerprintverfahren.
Ausgangspunkt ist eine Prototyp-Anwendung, mit der ein simples WLAN-Fingerprinting möglich ist. Mithilfe dieser Fingerprints wird ein Graph bestehend aus Knoten und Kanten im Sinne der Graphentheorie aufgebaut, wobei die Knoten des Graphen unterschiedlichen Orten entsprechen und die Kanten den jeweiligen Wegen zwischen diesen Orten. An- schließend kann die kürzeste Route zwischen Orten ermittelt werden, was die Basis für eine Navigation darstellt. Dies alles geschieht ohne Internetverbindung oder Zuhilfenahme anderer Ortungsverfahren.
Die Anwendung teilt sich in Funktionen für die Kalibrierungsphase, in welchen der Aufbau des Graphen, also die Aufnahme von Orten und Wegen geschieht, und Funktionen, die die Ortung und Routensuche für den Endnutzer übernehmen. Zur Suche der kürzesten Rou- te wird der Dijkstra-Algorithmus implementiert. Eine Datenbanklösung zur Speicherung der in der Anwendung erzeugten Daten wurde mit SQLite realisiert. Bei der Neustruk- turierung wurde nach Prinzipien der komponentenbasierten Entwicklung gearbeitet, um Übersichtlichkeit und Modularität zu gewährleisten.
This bachelor thesis deals with the restructuring and the further development of an Android application for indoor-localization based on Wifi fingerprinting. Initial point is a prototype application, with which a simple fingerprinting is possible. These fingerprints are used to build a graph containing nodes and edges in terms of the graph theory, where nodes represent points of interest and edges represent the ways between them. After that, the shortest route between two points of interest can be found, which is the basis for navigation. All these functionalities are realized without internet connection and without using other positioning systems.
The application consists of two parts. In the first part, the calibration phase, the graph is built, which means that points of interest and ways are recorded. In the second part, localization and the routing search is provided for the user. For searching the shortest route, the Dijkstra-algorithm has been implemented. The database functionality for saving the data generated by the application is realized by a SQLite database. The restructuring of the application was done according to the principles of component-based software development, to get better overview and higher modularity for later reuse of the code.
1 Einleitung 1
1.1 Vorwort . . . 1
1.2 Aufgabe/Fragestellung . . . 2
1.3 Abgrenzung . . . 2
2 Grundlagen 4 2.1 Indoor-Ortungsverfahren . . . 4
2.2 WLAN . . . 4
2.3 Fingerprintverfahren . . . 6
2.4 Graphenmodell . . . 7
3 Komponenten der Anwendung 11 3.1 Entwurfsmuster . . . 11
3.2 Komponenten . . . 13
3.2.1 Node . . . 13
3.2.2 Edge . . . 13
3.2.3 Fingerprint . . . 13
3.2.4 WifiScanner . . . 14
3.2.5 LocationCalculator . . . 14
3.2.6 Dijkstra-Algorithmus . . . 14
3.2.7 Persistenz . . . 16
4 Wichtige Packages, Klassen und Interfaces 18 4.1 Packages . . . 18
4.2 Klassen / Interfaces . . . 19
4.2.1 FingerprintTask . . . 19
4.2.2 DatabaseHandlerFactory . . . 20
4.2.3 JSONConverter . . . 20
4.2.4 JSONWriter . . . 21
4.2.5 Tabelle der Interfaces . . . 22
4.3 Zusammenspiel der Klassen und Interfaces . . . 24
4.3.1 Aufbau eines Fingerprints . . . 24
4.3.2 Bestimmung des Standortes . . . 25
4.3.3 Berechnung einer Route . . . 26
5 Bedienungsanleitung der App 28 6 Test 40 6.1 Allgemeines . . . 40
6.2 Vergleich WLAN-Signalstärken . . . 40
6.3 Mögliches Testszenario . . . 42
6.4 Trägheit beim passiven Scannen . . . 42
7 Zusammenfassung und Ausblick 44 7.1 Zusammenfassung . . . 44
7.2 Ausblick . . . 45
8 Anhang 46
Abbildungsverzeichnis A
Tabellenverzeichnis B
Glossar C
Abkürzungsverzeichnis D
Literaturverzeichnis E
Eigenständigkeitserklärung F
Einleitung
1.1 Vorwort
Wer kennt das nicht, man ist in einem großen Gebäudekomplex oder in einem Bahnhof in einer fremden Stadt und man sucht einen bestimmten Raum oder ein bestimmtes Gleis.
In solch einem Moment wäre oft schon eine Standortbestimmung, oder noch besser, eine Route zum gewünschten Ziel eine große Hilfe, doch von Wegweisern und Gebäudeplänen oder einem Info-Point ist häuftig nichts zu sehen. Man könnte nun meinen, dass dies in der heutigen Zeit kein Problem mehr sein sollte, schließlich hat ja beinahe jeder ein Smartphone in der Tasche, welches ja auch im Straßenverkehr oft als Hilfe für das Finden einer Route genutzt wird. Das Problem ist, dass die herkömmliche satellitengestützte Standortbestimmung via Global Positioning System (GPS), wie sie in Ortungs- und Navigationsanwendungen wie beispielsweise „Google Maps“ verwendet wird, in Gebäuden, insbesondere U-Bahnhöfen sehr schlecht bis gar nicht möglich ist, da die dicken Wände und Decken die Signale der Satelliten abschirmen. Deshalb müssen andere Signale für die Ortung verwendet werden. Hierfür gibt es verschiedenste Ansätze, wie zum Beispiel die Verwendung von Bluetooth-Beacons. Bluetooth-Beacons sind kleine Funksender, die meist in regelmäßigen Abständen eine eindeutige Kennung versenden, die dann von dem Endgerät, zum Beispiel einem Smartphone empfangen wird. So wird das Signal des am stärksten empfangenen Beacons als das des räumlich am nächsten liegenden Beacons angenommen und somit der Anbringungsort dieses Beacons als Standort angenommen.
Neben der Möglichkeit der Standortbestimmung mit Beacons gibt es in vielen modernen
Gebäuden, und insbesondere auch auf den U-Bahnhöfen der Berliner Verkehrsbetriebe (BVG) ein übergreifendes WLAN-Netzwerk oder sogar kostenlosen Internetzugang über WLAN-Hotspots wie im Fall der BVG. Diese WLAN-Accesspoints können auf ähnliche Art und Weise wie die Bluetooth-Beacons zur Standortbestimmung und damit auch zur Routenfindung genutzt werden. Die Ortung über WLAN-Signale hat den gravierenden Vorteil, dass die erforderliche Hardware, also WLAN-Accesspoints, schon vorhanden ist und somit der Aufwand der Inbetriebnahme für solch ein Ortungsverfahren deutlich geringer ist als bei der Beacon-Variante.
1.2 Aufgabe/Fragestellung
Ziel dieser Arbeit ist es, eine einfach zu bedienende Android-Anwendung zu erstellen, wel- che die Erfassung und Verwaltung von Orten (inklusive Bilder der Orte) und Wegen sowie die Standortbestimmung für den Endnutzer ermöglicht. Hierzu sollen neue Datentypen für das Model entworfen werden und es muss eine Persistenzlösung gefunden werden, um die aufgenommenen Daten zu sichern und einen Datenimport und Datenexport in die Anwendung zu ermöglichen. Des Weiteren soll eine Lösung zur Berechnung einer Route zwischen zwei Orten bzw. dem Standort und einem anderen Ort implementiert werden.
Für die Anwendung soll eine möglichst komponentenbasierte Struktur verwendet werden, um eine spätere Weiterentwicklung zu ermöglichen.
1.3 Abgrenzung
Grundlage für diese Arbeit sind die Erkenntnisse der Masterthesis „Optimierung der Indoor-Ortung mittels Fingerprintverfahren basierend auf WLAN“ von Carola Walter aus dem Jahr 2017 [Wal17] und die daraus entstandene Prototypanwendung. Die daraus ent- nommenen Filteralgorithmen zur Fehlerkorrektur bzw. Verarbeitung der aufgenommenen WLAN-Daten („Gleitender Mittelwertfilter“ und „Kalman Filter“) sowie der Algorithmen zur Berechnung der „Euklidischen Distanz“ und „K-Next-Neighbor-Algorithmus“ sind
nicht Gegenstand dieser Arbeit. Ebenfalls nicht Teil dieser Arbeit ist der Berechnungs- Algorithmus für die Standortbestimmung (Pattern Matching von Fingerprints). Die Me- nüpunkte „Wegvermessung“, „Kalibrierung“ und „Aufnehmen“ der Android-Anwendung gehören zur Bachelorthesis „Indoor Vermessung - Bestimmung von relativen Koordina- ten relevanter Punkte in geschlossenen Räumen mittels Sensoren“ von Benjamin Kneer [Kne17].
Grundlagen
2.1 Indoor-Ortungsverfahren
Es gibt bereits unterschiedlichste Verfahren zur Ortung in Gebäuden, auf die aber hier nicht weiter eingegangen werden soll. Eine gute Erarbeitung dazu findet sich in der Mas- terthesis von Carola Walter [Wal17]. Das in dieser Arbeit genutzte Verfahren ist das Fingerprintverfahren auf der Basis von WLAN.
2.2 WLAN
Allgemeines
Die Drahtlosnetzwerktechnologie Wireless Local Area Network, kurz WLAN, genauer der „802.11“-Funkstandard, ermöglicht das drahtlose Verbinden eines Endgerätes mit einem Accesspoint bzw. Router. Ein Router bzw. Accesspoint besitzt in den meisten Fällen neben seiner weltweit eindeutigen Hardwareadresse, auch MAC-Adresse genannt, auch einen Netzwerknamen, die SSID, unter welchem die Endgeräte das Netzwerk finden können, um sich mit ihm zu verbinden. Die Kopplung der Endgeräte mit dem jeweiligen Accesspoint findet meist über die Eingabe der Service Set Identifier (SSID) beim Endgerät statt. In größeren Gebäuden ist es üblich, ein oder mehrere Netzwerke im gesamten Gebäude zu auszustrahlen, wozu ein einziger Accesspoint aufgrund seiner relativ geringen
Reichweite nicht ausreichend ist. Aus diesem Grund werden mehrere Accesspoints mit der gleichen SSID im Gebäude eingerichtet, so dass das Endgerät den Accesspoint vom Nutzer unbemerkt wechselt, wenn der Nutzer sich im Gebäude bewegt, und die Signalstärke des aktuell verbundenen Accesspoints zu schwach wird. Diese Gegebenheiten in Gebäuden (und auch U-Bahnhöfen der BVG) macht sich das hier verwendete Ortungsverfahren zu
Nutze.
Die flächendeckende WLAN-Abdeckung führt dazu, dass an den meisten Orten im Ge- bäude mehrere WLAN-Accesspoints mit der gleichen SSID, aber unterschiedlichen MAC- Adressen (Basic Service Set Identification (BSSID)) und Signalstärken (RSSI) empfangbar sind. Aus diesen unterschiedlichen Signalstärken an einem Ort ergibt sich in Kombination ein eindeutiger Fingerabdruck des Ortes, hier im Weiteren „Fingerprint“ genannt. Eine Positionsbestimmung mit mehr als fünf Accesspoints führt allerdings zu keiner höheren Genauigkeit. [Vgl. God14, S. 29]
Diese Möglichkeit der Ortung in Gebäuden birgt allerdings Fehlerquellen. Im Gegensatz zum Freifeld, in welchem die Dämpfung der Funkwellen in Abhängigkeit von der Ent- fernung vom Sender genau berechnet werden kann, ist dies in Gebäuden, insbesondere auf Bahnhöfen, wo sich viele Personen bewegen, kaum genau möglich. Es gibt neben den baulich bedingten Hindernissen wie glatten Flächen, rauen Flächen welche eine Reflek- tion der Funkwellen verursachen können und Kanten, welche eine Beugung der Wellen zur Folge haben können auch sich ständig verändernde Hindernisse wie sich bewegende Personen, in U-Bahnhöfen auch einfahrende U-Bahn-Züge etc. Um diesen Gegebenheiten beim Ausmessen eines Ortes entgegenzuwirken, werden mehrere Messungen gemacht und diese am Ende mithilfe von Filtern so bearbeitet, dass einzelne minimale und maximale Abweichungen der empfangenen Signalstärken geglättet werden.
Aktives und passives Scannen
Um die umliegenden WLAN-Netzwerke zu ermitteln, muss ein Scan ausgeführt werden.
Gundsätzlich lässt sich das Scannen nach Netzwerken in passives und aktives Scannen unterscheiden. Beim aktiven Scan sendet der Client einen sogenannten „probe request“
als Broadcast an alle Accesspoints, welche darauf mit einem „probe response“ antworten [Tip12, S. 2]. Dieser enthält die wichtigen Informationen wie SSID und die MAC-Adresse
der Accesspoints. So kann relativ schnell jeder WLAN-Kanal nach Accesspoints abgefragt werden. Der passive Scan, wie auch vom Android WifiManager genutzt, wartet auf jedem WLAN-Kanal einzeln eine gewisse Zeit auf ein sogenanntes „Beacon frame“. Dies ist ein Datenpaket, welches Accesspoints in regelmäßigen Zeitintervallen von sich aus senden, also ohne vorherige Abfrage. Dies kann zu Messfehlern insbesondere bei kurzen Messungen führen wie in Kapitel 6.4 beschrieben. Abbildung 2.1 zeigt die beiden Scanprinzipien.
Abbildung 2.1: Aktives und passives Scannen nach „WLAN Configuration Guide - Tech- nical Support - H3C“
(a) Aktives Scannen
(b) Passives Scannen
2.3 Fingerprintverfahren
Das Fingerprintverfahren zur Feststellung eines Ortes ist neben der Triangulation (dem Messen der Winkel) und Trilateration (dem Messen der Entfernungen bzw. Zeiten, wie beispielsweise bei GPS verwendet) ein wichtiges Ortungsprinzip und ist distanzunabhän- gig. Es basiert im Gegensatz zu distanzabhängigen Verfahren nicht auf der Messung der Abstände zu Sendern, sondern auf der Wiedererkennung von Signalmustern bzw.
Signalstärken oder eines anderen Merkmals [vgl. Lin14, S. 3f]. Grundsätzlich kann das WLAN-Fingerprintverfahren sowohl innerhalb von Gebäuden verwendet werden, als auch in dichter besiedeltem Gebiet wie beispielsweise in Städten auch auf der Straße, da die Verbreitung von WLAN auch in Privathaushalten sehr verbreitet ist.
Der Ortungsvorgang setzt sich zusammen aus zwei Phasen. Die erste Phase ist die Da- tenerfassung bzw. Vermessung und damit die Vorbereitung für die eigentliche Ortung (siehe „recording mode“ in Abbildung 2.3). Es wird ein Fingerprint, also eine Kombination aus gemessenen Signalstärken verschiedener Accesspoints für jeden später relevanten Ort gespeichert, so dass später in Phase zwei mit diesen Fingerprints verglichen werden kann.
Phase zwei ist die eigentliche Ortungsphase, in der das Endgerät, welches die Daten aus Phase eins enthält, eine Messung der Signale oder des Merkmals vornimmt). Dieses Signal- muster wird dann mit der Datenbasis, also den Fingerprints aus der Vorbereitungsphase, verglichen. Der Ort, der dem gemessenen Signalmuster am nächsten kommt, also nach verschiedenen, vorher festgelegten Kriterien mit ihm übereinstimmt, wird als der aktuelle Standort angenommen (siehe „location mode“ in Abbildung 2.3).
Die vorliegende Applikation nutzt das „signal strength-“ (RSS-) basierte Fingerprintver- fahren. Je nach Hardware des Endgerätes werden hierbei aus dem 2,4-GHz-Band und dem 5-GHz-Band WLAN-Accesspoints mit ihrer eindeutigen Hardwareadresse (MAC-Adresse) in Kombination mit den jeweils an den verschiendenen relevanten Orten gemessenen Si- gnalstärken (RSSI) als Merkmale für den jeweiligen Fingerprint benutzt. So wird ein für einen Ort eindeutiger Fingerabdruck für jeden relevanten Ort erzeugt. Relevante Orte kön- nen in diesem Zusammenhang beispielsweise Orte wie ein bestimmtes Gleis, ein Geschäft oder ein Fahrstuhl sein. Durch so festgelegte Orte z.B. die eines Bahnhofes soll ein Graph entstehen, der das jeweilige Gebäude oder den Bahnhof repräsentiert.
2.4 Graphenmodell
Ein Graph im Sinne der Graphentheorie ist eine abstrakte Struktur, die eine Menge von Objekten in Zusammenhang mit den Verbindungen dieser Objekte repräsentiert. Die Objekte dieser Struktur werden meist „Knoten“ genannt (englisch: „node“ oder „vertex“), die Verbindungen zwischen den Knoten werden meist als „Kanten“ (englisch: „edge“) bezeichnet. Eine Kante verbindet jeweils zwei Knoten miteinander. Es wird zwischen gerichteten und ungericheten Graphen unterschieden. Der Unterschied hierbei ist, dass die Kanten gerichteter Graphen einen Start- und Endknoten besitzen [vgl. TW15, S.19f] und
1In Anlehnung an http://www.progressingeography.com/fileup/1007- 6301/FIGURE/2015-34-4/Images/1007-6301-34-4-457/img_1.png
Abbildung 2.3: Ortungsprinzip des Fingerprinting1
die Kante so eine Richtung bekommt, graphisch als Pfeil dargestellt. Zusätzlich können die Kanten eines Graphen auch gewichtet sein, man spricht in diesem Zusammenhang auch vom „Kantengewicht“ oder den „Kosten einer Kante“. Dieses Kantengewicht ist eine Reelle Zahl, welche einer Kante zugeordnet wird. Diese Eigenschaft der Kanten kann später für die Suche der kürzesten Route zwischen zwei Knoten genutzt werden.
Nachfolgend wird nur auf den ungerichteten Graphen weiter eingegangen, da nur dieser im Falle der Routenfindung in der Applikation gebraucht wird, schließlich können zu Fuß abgeschrittene Wege in beide Richtungen begangen werden.
Ein ungerichteter Graph G = (V, E) besteht aus einer Knotenmenge V 2 und einer Kantenmenge E 3, wobei jeder Kante e ∈E vonG zwei Knoten aus V zugeordnet sind [Tit03]. Eine Kante wird mit e = {u, v} beschrieben, wobei u und v die Knoten an den Enden der Kante sind.
In Abbildung 2.4 ist ein ungerichteter Graph am Beispiel eines Bahnhofes beschrieben.
Die gelben Kreise repräsentieren hierbei die Knoten bzw. relevanten Orte, die Linien
2Vertices
3Edges
dazwischen die Kanten bzw. die Wege, die diese Orte verbinden. Der Graph kann also mit
G= ({1,2,3,4,5,6},{a, b, c, d, e, f, g}) beschrieben werden, der die Kanten
a={1,2}, b={2,3}, c ={1,4}, d={2,4}, e={2,5}, f ={4,6}, g ={5,6}
enthält.
Abbildung 2.4: Beispielgraph eines Bahnhofes
Die Kanten des Graphen können gewichtet sein, das bedeutet, es wird jeder Kante eine Zahl zugeordnet, auch „Kosten“ der Kante genannt. Dieses Kantengewicht ist im Sinne der Wegesuche die Distanz zwischen zwei Orten. Die Knoten des Graphen repräsentieren relevante Orte und die Kanten die Wege, welche diese Orte verbinden.
Mithilfe eines Suchalgorithmus wie dem „Dijkstra-Algorithmus“, auf welchen später näher eingegangen wird, kann dieser Graph nun durchlaufen werden, und es lässt sich feststellen, ob zwei Knoten miteinander verbunden sind (direkt oder indirekt), also ob es einen Weg zwischen zwei Orten gibt und welche minimale Distanz dazwischen liegt. Es ergeben sich dadurch die Zwischenstationen, die auf der Route zum Ziel passiert werden müssen.
Die in Abbildung 2.5 rot markierte Route würde dann wie folgt beschrieben werden:
R= (1, c,4, f,6) .
Stationen der Route sind die Knoten 1, 4 und 6 und es werden die Wegecundf beschritten, um von Ausgang 1 zu Bahnsteig 2 zu gelangen.
Abbildung 2.5: Route im Bahnhof
Komponenten der Anwendung
Eine Komponente im Sinne der komponentenbasierten Softwareentwicklung ist ein Stück Software, das „eine kohärente Funktionalität bietet und durch strikte Kapselung der Implementierung eine gewisse Eigenständigkeit besitzt, die eine lose Kopplung zwischen der Komponente und ihrer Umgebung ermöglicht“ [Hoh02]. Bei der Implementierung der Android-Anwendung wurde versucht, die Software nach diesem Prinzip zu konstruieren.
Die Komponenten wurden möglichst modular und damit wiederverwendbar gestaltet, auf der anderen Seite aber auch nicht zu kleingranular, so dass die Funktionalitäten getrennt sind, aber die Zusammenhänge übersichtlich und erkennbar bleiben.
Durch die Strukturierung in diese Komponenten kann die Anwendung später leicht erwei- tert werden.
„A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.“ 1
3.1 Entwurfsmuster
Um dieses Prinzip umzusetzen, bot sich der Einsatz von Entwurfsmustern, sogenannten
„Design-Pattern“ an. Sie helfen dem Entwickler bei der Strukturierung von Codes, den
1Definition einer Softwarekomponente von Clemens Szyperski [Szy99]
Überblick zu behalten und ermöglichen durch vereinheitlichte Schemata ein schnelleres Verständnis von fremdem Quelltext. Das wichtigste Entwurfsmuster war das Prinzip
„Program to an interface“. Dieses Entwurfsmuster ist besonders gut für die Umsetzung des oben erwähnten Modularitätsprinzips geeignet, da das Interface die Implementierung einer Klasse verbirgt. Das bedeutet, dass eine fremde Person, die die Funktionalitäten der Klasse nutzen möchte, sich nicht mit der genauen Implementierung auseinanderzusetzen braucht, sondern die Methoden in einem übersichtlichen und selbsterklärenden bzw. gut dokumentierten Interface bereitgestellt bekommt. Vorteil dieses Entwurfsmusters ist, dass die Implementierung, also die Umsetzung der Funktionalitäten beliebig verändert werden kann, solange sie noch das Interface erfüllt, also seine Methoden enthält. Damit ist die Funktionalität wie in einer Blackbox abgekapselt, siehe Abbildung 3.1.
Des Weiteren wurde das Entwurfsmuster „Factory“ genutzt. Mithilfe einer Factory lässt sich die Implementierung einer Klasse davor schützen, direkt angesprochen und verändert zu werden. Dies geschieht zunächst, indem der Zugriffsmodifikator der Klasse auf „package- private“ gesetzt wird. Damit ist die Klasse nur innerhalb ihres Packages sichtbar. Die Factory-Klasse dient nun dazu, mit ihrer Methode „createInstance()“ bzw. „getInstance()“
bei Bedarf die Instanzen der Klasse zu erzeugen. Wird eine Instanz gebraucht, wird also keine direkte Instanz der Implementierungsklasse erzeugt, sondern über die Factory, welche den Zugriffsmodifikator „public“ besitzt, und somit von überall nutzbar ist.
Abbildung 3.1: Generierung eines Node mittels Factory
3.2 Komponenten
3.2.1 Node
Ein „Node“ im Sinne der Anwendung ist das Datenmodel für einen Knoten im Graphen- modell, in der App auch „Ort“ genannt. Er repräsentiert einen Ort wie beispielsweise den Ausgang eines U-Bahnhofes, ein bestimmtes Geschäft oder ein anderer „Point of Interest“, der für den Nutzer der App später relevant sein könnte. Er enthält seinen Namen, der ihn eindeutig von anderen Nodes unterscheidet, eine optionale Beschreibung, Koordinaten [Kne17], sowie den Dateipfad zu einem Foto des Ortes und einen WLAN-Fingerprint.
Zusätzlich enthält er einen Platzhalter in Form einer Zeichenkette, „additionalInfo“, der für spätere Zwecke genutzt werden kann.
3.2.2 Edge
Ein „Edge“ im Sinne der Anwendung ist das Datenmodel für eine Kante im Graphen- modell, in der App auch „Weg“ genannt. Es verbindet jeweils zwei Nodes miteinander, und signalisiert damit, dass diese wechselseitig von einander erreichbar sind. Eindeutig- keit erlangt ein Edge dabei durch die Kombination der beiden zugehörigen Nodes. Als weitere Information enthält ein Edge einen Wahrheitswert, ob dieser Weg barrierefrei ist, und eine Zahl, die die Länge des Weges angibt. Von der in der App unter Menüpunkt
„Wegevermessung“ befindlichen Vermessungsfunktion erzeugte Daten werden als Liste der Schrittkoordinaten ebenfalls in dem Edge-Objekt hinterlegt. Wie auch die Nodes, haben Edges ebenfalls eine Platzhalter-Zeichenkette, „additionalInfo“, die für spätere Zwecke genutzt werden kann.
3.2.3 Fingerprint
Die Messdaten der Anwendung (MAC-Adressen und Signalstärken) werden als Ableitung des Interfaces „Fingerprint“ in einem Objekt gespeichert, welches dann dem jeweiligen Node zugeordnet wird. Die Anwendung besitzt ein Package namens „fingerprint“, welches
die zum Erzeugen von Fingerprints erforderlichen Klassen und Interfaces enthält (siehe Kapitel 4 „Packages, Klassen und Interfaces“ und Kapitel 2.3 „Fingerprintverfahren“).
3.2.4 WifiScanner
Das Modul „WifiScanner“ ermöglicht es, alle zum aktuellen Zeitpunkt in Empfangsreich- weite des Endgerätes befindlichen WLAN-Netzwerke zu ermitteln und als Liste der Netz- werknamen (SSID) der betreffenden Netzwerke zurückzugeben. Es besteht die Möglichkeit, beim Scan nur Netzwerke mit zwei oder mehr Accesspoints zu berücksichtigen, da zwei Accesspoints das Minimum für das Fingerprintverfahren sind. Der WifiScanner wird benö- tigt, um die Auswahl des SSID-Filters festzulegen, der beim Fingerprinting zum Einsatz kommt.
3.2.5 LocationCalculator
Das Modul „LocationCalculator“ bietet die Funktionalität zum berechnen eines Standortes aus einem gegebenen Fingerprint. Es vergleicht den aufgenommenen Fingerprint mit den Referenzdatensätzen in der Datenbank, und errechnet so den wahrscheinlichsten Standort.
Dies übernimmt die Methode namens „calculateNodeId“, der ein Fingerprint übergeben wird. Wird kein Standort gefunden, wird „null“ zurückgegeben.
3.2.6 Dijkstra-Algorithmus
Der Dijkstra-Algorithmus (nach seinem Erfinder Edsger W. Dijkstra benannt) ist ein Algorithmus zur Ermittlung der kürzesten Pfade in einem kantengewichteten Graphen.
In dieser Anwendung findet er den kürzesten Weg zwischen zwei Orten, beispielsweise zwischen zwei Geschäften eines Einkaufszentrums oder zwischen zwei Bahnsteigen eines Bahnhofes. Zusätzlich ist es dem Nutzer möglich, ein weiteres Suchkriterium für die Wegesuche mit einzubeziehen, nämlich die Barrierefreiheit der Route. So soll der Dijkstra- Algorithmus in diesem Fall nur Routen ermitteln, die zuvor als barrierefrei gekennzeichnet wurden, beispielsweise für Rollstuhlfahrer.
Der für die Anwendung implementierte Dijkstra-Algorithmus erzeugt vor seinen Berechnun- gen aus den Nodes aus der Datenbank „DijkstraNodes“ und aus den Edges „DijkstraEdges“.
Die Dijkstra-Datentypen enthalten jeweils nur die für den Algorithmus relevanten Daten der Nodes und Edges, also bei Nodes die ID und bei Edges die beiden verbundenen Knoten und das Kantengewicht. Ziel dieses Verfahrens ist, die vom Algorithmus genutzten Daten so schlank wie möglich zu halten, um bei größeren Datensätzen Berechnungszeit zu sparen.
Es werden Methoden bereitgestellt für die Vorberechnungen (Aufbau des Graphen), die Ermittlung der kürzesten Distanzen zwischen Knoten und die Routensuche.
Und nun zur allgemeinen Funktionsweise des Algorithmus. Zunächst wird ein beliebiger Knoten des Graphen als Startpunkt gewählt. In der Applikation ist das der als Startpunkt ausgewählte Ort. In einer Liste wird festgehalten, ob ein Knoten bereits vom Algorith- mus „besucht“ wurde, und für jeden Knoten ein Distanzwert, mit welchen Kosten er vom Startpunkt aus erreichbar ist. Dieser Distanzwert ist anfangs für alle Knoten außer dem Startknoten unendlich, der Startknoten hat die Distanz null. Für jeden vom Startknoten direkt erreichbaren Knoten wird nun der Distanzwert in einer Tabelle gespeichert, an- schließend wird der nächste Knoten ausgewählt, üblicherweise der, der mit den geringsten Kosten erreichbar ist (vom Startpunkt aus). Dieser Knoten wird nun als „besucht“ markiert bzw. gespeichert. Von diesem Knoten aus wird nun wieder ermittelt, welche Knoten direkt erreichbar sind und die Kosten für jeden dieser Knoten vom Startpunkt aus addiert. Ist der so ermittelte Distanzwert zu einem Knoten geringer, als der bisher gespeicherte, wird dieser in der Liste aktualisiert. Nun wird wieder der Knoten mit den geringsten Kosten vom Startpunkt aus gewählt, und die direkt mit ihm verbundenen Knoten ermittelt und deren Distanz aktualisiert. Dies geschieht so lange, bis alle Knoten des Graphen „besucht“
sind, und so vom Startpunkt aus die kürzesten Distanzen zu jedem anderen erreichbaren Knoten bekannt sind. [Dij59]
Abbildung 3.2: Pseudocode des Dijkstra-Algorithmus2
3.2.7 Persistenz
Datenbank
Damit die Applikation nach dem Beenden beim erneuten Start noch alle aufgenomme- nen Daten enthält, benötigt sie eine Persistenz-Lösung. Die Prototyp-Anwendung, die als Grundlage für diese Arbeit dient, speicherte ihre Daten in Form einer JavaScript Object No- tation (JSON)-Datei im internen Speicher des Gerätes (meist das „SDcard“-Verzeichnis).
Diese Lösung ist nur für kleinere Datenmengen geeignet, da bei jedem Speichern die JSON-Objekte neu gebildet und zu einer Datei neu zusammengesetzt werden müssen, was unnötigen Rechenaufwand bedeutet. Um dies zu vermeiden, wurde für die Applikation eine SQLite-Datenbanklösung erstellt, in der die aufgenommenen Knoten (Orte) und Kan- ten (Wege) gespeichert werden. SQLite ist leichtgewichtig, und nativ im Android-System enthalten, benötigt also keine zusätzlichen Bibliotheken, da die Klasse „SQLiteOpenHel- per“3 die zum Management der Datenbank erforderlichen Methoden zur Verfügung stellt.
Die Datenbank liegt im Applikationsverzeichnis der Anwendung, und wird im Falle einer Deinstallation mit gelöscht, weshalb eine Import-/Exportfunktion implementiert wurde.
Mit dieser kann die gesamte Datenbank in den externen Speicher des Gerätes kopiert und aus diesem auch wieder hergestellt werden.
2Quelle: http://math.mit.edu/ rothvoss/18.304.3PM/Presentations/1-Melissa.pdf
3https://developer.android.com/reference/android/database/sqlite/SQLiteOpenHelper.html
Speichern der Einstellungen
Für das Persistieren der Einstellungen der App wurden das in Android enthaltene Interface
„SharedPreferences“ 4 genutzt. Sie erlaubt das einfache Speichern von Key-Value-Paaren, bzw. Zeichenketten und Wahrheitswerten. Alle unter dem Menüpunkt „Einstellungen“ zu findenden Einstellungen wie der SSID-Filter oder der Voreinstellungen der Filteralgorith- men werden auf diese Weise persistiert. Bei Deinstallation der Anwendung werden die Einstellungen ebenfalls gelöscht.
JSONWriter
Der JSONWriter bietet zusätzlich zur SQLite-Datenbank eine weitere Speichermöglichkeit.
Bei Aufnahme eines neuen Ortes werden die Fingerprint-Daten automatisch auch in eine JSON-Datei im externen Speicher des Gerätes geschrieben. Weitere Informationen sind im Kapitel 4 „Wichtige Packages, Klassen und Interfaces“ zu finden.
4https://developer.android.com/reference/android/content/SharedPreferences.html
Wichtige Packages, Klassen und Interfaces
4.1 Packages
Diese Arbeit umfasst folgende Packages. Jedes Package enthält die jeweilig zugehörigen Klassen und Interfaces.
Tabelle 4.1: Tabelle der Packages Package-Name Funktionen
node Nodes erstellen, verwalten, anzeigen edge Edges erstellen, verwalten, anzeigen fingerprint Fingerprints erstellen
nodelist Liste aller Nodes location Standortbestimmung dijkstra Dijkstra-Algorithmus
persistence Persistenz: Datenbank, JSON-Verarbeitung, und Import/Export settings Einstellungen
wifi_scanner Scannen nach Netzwerken in Reichweite
4.2 Klassen / Interfaces
4.2.1 FingerprintTask
Das Aufnehmen eines Fingerprints, ob zum Erstellen eines Ortes oder zum Lokalisieren des Standortes, wird von der Klasse „FingerprintTask“ übernommen. Da ein Laufen im Main-Thread der Anwendung diese für die Dauer der Aufnahme einfrieren würde, weil das User-Interface auf diesem Thread läuft, muss die Abarbeitung dieser Aufgabe im Hintergrund geschehen. Hierzu bietet Android mehrere Möglichkeiten. Zum einen gibt es die Java-Klasse „Thread“, mit der neue Threads erstellt und gesteuert werden können, zum Anderen gibt es die in Android native Klasse „AsyncTask“, die eine „Helper“-Klasse um die Klassen „Thread“ und „Handler“ bildet, so dass diese einfach zu nutzen sind. Sie ermöglicht also ebenfalls eine Abarbeitung einer Aufgabe im Hintergrund. Die Klasse „Thread“ wurde für rechenintensivere und länger dauernde Aufgaben konzipiert, während „AsyncTask“ für leichtgewichtigere und kürzere Aufgaben konzipiert wurde 1. Damit ist sie die für die Messung von Signalstärken und MAC-Adressen im Hintergrund geeignetere Variante. Ihre Methode „onProgressUpdate“ ermöglicht zusätzlich das leichte Verändern von Elementen der Nutzeroberfläche, wie beispielsweise dem Countdown oder dem Fortschrittsbalken beim Erstellen eines Ortes.
Zusätzlich ist die „FingerprintTask“-Klasse noch mit der Activity-Klasse, die die Nutzer- Oberfläche steuert, über das Interface „AsyncResponse“ verbunden. Ist die Messung der WLAN-Signale abgeschlossen, oder wurde zwischendurch abgebrochen, wird die Methode
„onProcessFinish()“ aufgerufen, welche das Ergebnis der Messung (das Fingerprint-Objekt) an die Activity zurück liefert, ohne dass diese (Main-Thread) auf den AsyncTask warten muss. Auf diese Weise sind Nutzeroberfläche und Messung voneinander unabhängig.
Die Klasse besitzt zwei Konstruktoren, einen für den normalen Aufnahmemodus, und einen für den „Verbose“-Modus. Der Konstruktor für den Verbose-Betrieb bekommt zusätzlich ein TextView übergeben, in welchem die Messdaten während der Aufnahme angezeigt werden (siehe auch Kapitel „3.7 Einstellungen“). Während des Aufnahmeprozesses, dessen Dauer über den Parameter „seconds“ beim Erstellen der Instanz geregelt ist, wird jede Sekunde nach Accesspoints gescannt. Hierbei wird die per Parameter übergebene SSID
1https://developer.android.com/reference/android/os/AsyncTask.html
zum Filtern der Messdaten benutzt. Ist diser Filter „null“, werden alle empfangbaren Netzwerke gemessen. Die gefundenen Accesspoints werden als Kombination ihrer MAC- Adressen und Signalstärken in eine Liste gespeichert. Diese Liste wird gemeinsam mit dem aktuellen Zeitstempel in eine weitere Liste gespeichert, welche später das Kernstück des Fingerprints darstellt. Über den boolean-Parameter „calculateAverage“ der Klasse kann bei Erstellen der Klasse angegeben werden, ob die Ergebnisse mit dem arithmetischen Mittel verrechnet werden sollen. Dies wird von der Klasse „AverageSignalCalculator“
übernommen, und muss für Messungen mit mehreren Datensätzen (also Messungen, die länger als eine Sekunde dauern) ausgeführt werden, um den Durchschnitt der Messzyklen im Fingerprint-Objekt zu speichern.
4.2.2 DatabaseHandlerFactory
Für die Nutzung der SQLite-Datenbank durch die Anwendung ist wichtig, dass zu einem Zeitpunkt jeweils immer nur eine Instanz der Datenbank-Klasse existiert, da es sonst zu Fehlern kommen kann. Beispielsweise wenn mehrere Instanzen gleichzeitig versuchen, die gleiche Ressource zu verändern. Um sicherzustellen, dass immer nur eine Instanz der Datenbank-Klasse existiert, wurden die Design-Pattern „Factory“ und „Singleton“
verwendet. Die Factory prüft bei jedem Aufruf ihrer Methode „getInstance()“, ob bereits ein Objekt der Datenbank-Klasse „DatabaseHandlerImpl“ erstellt wurde. Besteht bereits ein Objekt dieser Klasse, wird dieses von der Factory zurückgegeben, besteht noch keines, wird ein neues erzeugt.
4.2.3 JSONConverter
Die Persistierung von mehreren ineinander verschachtelten Klassen, wie es bei den von der App aufgenommenen Fingerprints der Fall ist, gestaltet sich schwierig mit einer SQLite- Datenbank, da dafür kein passender Datentyp bereitsteht. Um dennoch die Datenstruktur der Klasse „Fingerprint“ speichern zu können, wurde die Klasse JSONConverter erstellt.
Sie enthält die Methode „convertSignalSampleListToJSON“, welche in der Lage ist, die in Fingerprint-Objekten enthaltene Liste von „SignalSample“-Objekten in eine Zeichenkette umzuwandeln, welche dann in der SQLite-Datenbank als einfacher String gespeichert
werden kann. Die Methode „convertJsonToSignalSampleList“ wandelt den JSON-String wieder zurück in ein passendes Objekt, wenn er aus der Datenbank ausgelesen wurde.
4.2.4 JSONWriter
Neben der Persistierung der Fingerprint-Daten in der SQLite-Datenbank wird zusätzlich eine JSON-Textdatei im Verzeichnis
1 /storage/emulated/0/IndoorPositioning/JSON/
erstellt, welche die Messdaten des Fingerprints (in Rohform) ebenfalls enthält. Diese können anschließend für administrative Zwecke beispielsweise mit einem „JSON-Reader“
direkt am Endgerät ausgelesen werden.
4.2.5 Tabelle der Interfaces
Die Quelltexte der Interfaces mit ihrer vollständigen Beschreibung befinden sich im Anhang.
Diese Übersicht soll nur der Orientierung dienen.
Interface Methode Beschreibung
Node getId() ID (Name) des Knoten holen
setId() ID (Name) des Knoten setzen
getDescription() Beschreibung des Knoten holen getFingerprint() Fingerprint des Knoten holen getCoordinates() Koordinaten des Knoten holen setCoordinates() Koordinaten des Knoten setzen
getPicturePath() Pfad des zum Knoten gehörigen Fotos holen getAdditionalInfo() Zusätzliche Informationen holen (Platzhalter) setAdditionalInfo() Zusätzliche Informationen setzen (Platzhalter)
Edge getNodeA() Anfangs-Knoten der Kante holen
getNodeB() End-Knoten der Kante holen
getAccessibility() Barrierefreiheit der Kante ermitteln setAccessibility() Barrierefreiheit der Kante setzen
getWeight() Kantengewicht (Strecke) der Kante ermitteln setWeight() Kantengewicht (Strecke) der Kante setzen getStepCoordsList() Liste der Koordinaten holen, aus denen die Kan-
te besteht
getAdditionalInfo() Zusätzliche Informationen holen (Platzhalter) setAdditionalInfo() Zusätzliche Informationen setzen (Platzhalter) WifiScanner getAvailableNetworks() SSIDs in Empfangsreichweite ermitteln Accesspoint-
Information
getMacAddress() MAC-Adresse des Accesspoint holen
getRssi() Signalstärke des Accesspoint holen (in dBm)
Fingerprint getSsid() SSID (Netzwerkname) holen, sofern SSID-Filter
verwendet wurde
getSignalSampleList() Liste von SignalSamples des Fingerprint holen LocationCalculator calculateNode() Standort aus Fingerprint errechnen
getAccesspointInformations() AccesspointInformations aus SignalSample ex- trahieren
calculateNewNodeDateset() -Nicht Teil dieser Arbeit- [Wal17]
getMultiMap() -Nicht Teil dieser Arbeit- [Wal17]
Fortsetzung auf nachfolgender Seite
Fortsetzung - Tabelle der Interfaces
Interface Methode Beschreibung
getMacAddresses() MAC-Adressen eines Knoten aus dem Finger- print extrahieren
DijkstraAlgorithm mapNodes() DijkstraNodes aus Nodes erstellen
mapEdges() DijkstraEdges aus Edges erstellen
execute() (Vor-)Berechnungen von einem gegebenen Start- Knoten aus beginnen
findMinimalDistances() Kürzeste Distanzen zu allen Knoten ab einem gegebenen Start-Knoten
getDistance() Distanz zwischen zwei gegebenen Knoten ermit- teln
getNeighbors() Nachbarknoten zu gegebenem Knoten ermitteln isSettled() Ermitteln, ob gegebener Knoten bereits durch-
laufen wurde
getShortestDistance() Kürzeste Distanz zwischen dem beim Ausführen von execute() übergebenen Startknoten und ei- nem anderen Knoten ermitteln
getPath() Pfad zwischen dem beim Ausführen von execu-
te() übergebenen Startknoten und einem ande- ren Knoten
DatabaseHandler insertNode() Einen Knoten in die Datenbank einfügen updateNode() Einen Knoten in der Datenbank updaten getAllNodes() Eine Liste aller Knoten holen
getNode() Einen einzelnen Knoten holen
checkIfNodeExists() Prüfen, ob ein Knoten bereits existiert (Der Na- me wird geprüft)
deleteNode() Einen einzelnen Knoten löschen
insertEdge() Eine Kante in die Datenbank einfügen getEdge() Eine einzelne Kante aus der Datenbank holen getAllEdges() Eine Liste aller Kanten holen
updateEdge(-A-) Die Informationen einer Kante aktualisieren (bis auf die Felder nodeA und nodeB
updateEdge(-B-) Die Felder nodeA und nodeB einer Kante ak- tualisieren (Seiteneffekt beim umbenennen von Knoten)
checkIfEdgeExists() Prüfen, ob eine Kante bereits existiert
deleteEdge() Eine einzelne Kante löschen
Fortsetzung auf nachfolgender Seite
Fortsetzung - Tabelle der Interfaces
Interface Methode Beschreibung
getWritableDatabase() SQLite-Datenbankobjekt holen um es zu bear- beiten
importDatabase() Datenbankdatei aus externem Speicher impor- tieren
exportDatabase() Datenbankdatei in externen Speicher exportie- ren
AsyncResponse processFinish() Wird von der Klasse FingerprintTask aufgeru- fen, wenn dieser fertig ist
Tabelle 4.2: Tabelle der Interfaces
4.3 Zusammenspiel der Klassen und Interfaces
Die Funktionen rund um das Fingerprinting und zur Routenberechnung sind die wichtigs- ten Komponenten der Anwendung. Sie werden nachfolgend beschrieben.
4.3.1 Aufbau eines Fingerprints
Das in jedem Node enthaltene „Fingerprint“-Objekt enthält eine Liste von „SignalSample“- Objekten, welche jeweils die Messdaten einer Sekunde der Messung beinhalten. „SignalS- ample“-Objekte wiederum enthalten eine Liste von „AccessPointInformation“-Objekten, von denen jedes die MAC-Adresse und Signalstärke eines Accesspoints enthält. Abbildung 4.1 zeigt den Aufbau des Fingerprints.
Abbildung 4.1: Klassendiagramm Fingerprint
4.3.2 Bestimmung des Standortes
Zur Bestimmung des aktuellen Standortes tippt der Nutzer in der LocationActivity auf einen der Ortungsbuttons. Der Event-Listener erstellt ein Objekt der Klasse Fingerprint- Task, welches die für die Messung nötigen Parameter und Graphical User Interface (GUI)- Elemente per Konstruktor übergeben bekommt. Die FingerprintTask-Instanz zeichnet nun jede Sekunde die entsprechenden Informationen der umliegenden Router auf; jede Sekunde der Messung wird pro empfangenem Accesspoint ein Objekt der Klasse „AccessPointIn- formation“ erzeugt, welche in einem SignalSample-Objekt zusammengefasst werden. So entsteht nach und nach der Fingerprint. Wurde die 10-Sekunden-Messung durchgeführt, wird über die Klasse „AverageSignalCalculator“ anschließend ein Mittel dieser Daten be- rechnet, und diese an die Activity zurückgegeben. Die Activity erzeugt nun ein Objekt der Klasse „LocationCalculator“ und übergibt den zuvor berechneten Fingerprint. Diese Klasse ermittelt nun mithilfe der über den „DatabaseHandler“ geladenen Fingerprints aller gespeicherten Nodes unter Zuhilfenahme der Klassen „MovingAverage“, „KalmanFil- ter“, „EuclideanDistance“ und „KNearestNeighbor“ die beste Übereinstimmung mit dem übergebenen Fingerprint. Diese wird an die LocationActivity zurückgegeben und dem Nutzer angezeigt.
Abbildung 4.2: Sequenzdiagramm der Lokalisierung
4.3.3 Berechnung einer Route
Um eine Route zwischen zwei Orten zu berechnen, wählt der Nutzer in der RouteFin- derActivity aus den beiden Dropdown-Menüs den Start- und den Zielort aus und drückt anschließend auf den Button zur Routenberechnung. Das erzeugt ein Objekt der Klasse
„DijkstraAlgorithm“, dessen Methode „execute()“ den Startknoten übergeben bekommt.
Sie ruft auf dem vorhandenen DatabaseHandler-Objekt die Methoden „getAllNodes“ und
„getAllEdges“ auf, welche Listen aller gespeicherten Orte und Wege zurückliefern, von denen nun Objekte der Klassen „DijkstraNode“ und „DijkstraEdge“ erstellt werden. Nun wird von der Activity die Methode „getPath()“ aufgerufen, welcher der Zielknoten über- geben wird. Der Dijkstra-Algorithmus berechnet die Route, welche dann an die Activity zurückgegeben und dem Nutzer angezeigt wird (Siehe Abbildung 4.3).
Abbildung 4.3: Sequenzdiagramm der Routensuche
Bedienungsanleitung der App
Die Applikation besteht grundlegend aus zwei Teilen, dem administrativen Teil und dem Nutzerteil. Der administrative Teil sorgt für die Aufnahme und Verwaltung neuer Orte und Wege und beinhaltet die Menüpunkte „Ort aufnehmen“, „Orte verwalten“, „Wege verwalten“ sowie „Import / Export“ und die Einstellungen. Der Nutzerteil zielt auf den Endanwender ab und beinhaltet die Menüpunkte „Standort finden“ und „Route finden“.
Nachfolgend sind die einzelnen Menüpunkte und Funktionen im Detail erklärt.
Damit die App funktioniert, müssen folgende Berechtigungen beim ersten Start der App erteilt werden:
• Kamera, für das Aufnehmen der Bilder zu den Orten,
• Standort, für das Scannen der WLAN-Netzwerke in Reichweite benötigt und
• Speicherzugriff, zum Speichern der Daten und Bilder
Des Weiteren muss beim Betrieb der App die WLAN-Funktionalität und ein Ortungs- dienst (GPS und/oder der Google-Standortdienst) des Gerätes eingeschaltet sein, da diese für das Scannen nach Netzwerken und damit für die Aufnahme von Orten und die Standortermittlung (über WLAN) benötigt werden.
Ort aufnehmen
Der Menüpunkt „Ort aufnehmen“ ist für das Erfassen von neuen Orten zuständig. Ein Ort kann eine Beschreibung, ein Foto, einen WLAN-Fingerprint und Koordinaten enthalten.
Die hier aufgenommenen Orte können später über die Funktion „Standort ermitteln“
gefunden werden und in der Funktion „Route finden“ als Wegpunkte auf der Route zum gewünschten Ziel auftauchen.
Zuerst trägt der Nutzer den Namen des Ortes ein, an dem er sich aktuell befindet und welchen er in die Datenbank aufnehmen möchte (siehe Markierung 1 in Abbildung 5.2a).
Der Name des Ortes dient dabei als eindeutiges Merkmal des Ortes, er muss also unique (einmalig) sein; ist der Name schon vorhanden, sieht der Nutzer eine Fehlermeldung in Form eines Toast und kann den Namen ändern. Nun kann der Nutzer noch eine optionale Beschreibung eingeben wie z.B. zusätzliche Informationen, die den Ort genauer charakterisieren (siehe Markierung 2), und mit einem Tap auf das Kamerasymbol ein Foto von einem prägnanten Merkmal des Ortes, zum Beispiel eines Geschäftes, machen (siehe Markierung 3).
Nach der Installation der App wird der Fingerprint standardmäßig ohne SSID-Filter aufgenommen. Weitere Informationen zu den Filtermöglichkeiten sind in der Rubrik 5
„Einstellungen“ zu finden.
Aus der Auswahlliste „Messzeit“ wird die Dauer der Fingerprint-Messung in Minuten ausgewählt (siehe Markierung 4). Diese kann ab einem Minimum von einer Minute bis zu einer Dauer von 60 Minuten gewählt werden. Generell lässt sich dabei feststellen, dass eine Messung von drei Minuten vollkommen ausreicht, und eine längere Messdauer nicht zwangsläufig zu einer genaueren Messung führt [Wal17, Kap. 3.2.2 Messdauer].
Mit einem Tap auf das Fingerprint-Symbol (siehe Markierung 5) startet die Messung. Hier- zu sollte der Nutzer sich möglichst wenig bewegen, damit die Messung nicht verfälscht wird.
Für Bahnhöfe und andere öffentliche Gebäude empfiehlt sich eine Messung bei möglichst geringem Personenaufkommen, beispielsweise nachts. Anhand des Countdowns (siehe Mar- kierung 6) und des Fortschrittsbalkens (siehe Markierung 7) ist der aktuelle Fortschritt der Messung ersichtlich. Anschließend kann der Ort mit einem Tap auf das Disketten-Symbol gespeichert werden (siehe Markierung 8). Der Speichern-Button kann auch ohne vorherige
Eingabe der Beschreibung, eines Bildes oder Messung eines Fingerprints betätigt werden.
Für das Speichern eines Ortes ist nur ein Name erforderlich, die restlichen Daten können auch im Nachhinein noch hinzugefügt werden.
Abbildung 5.1: Ort aufnehmen (Screenshot)
(a) Ort aufnehmen 1 (Screenshot) (b) Ort aufnehmen 2 (Screenshot)
Orte verwalten
Der Menüpunkt „Orte verwalten“ ist in erster Linie eine Liste zur Übersicht der gespei- cherten Orte (siehe Abbildung 5.4a). Durch einen einfachen Tap auf einen Eintrag gelangt der Nutzer in die Änderungsansicht des gewählten Ortes (siehe Abbildung 5.4b). Hier gibt
es die Möglichkeit, den Namen des Ortes, die Beschreibung, das Bild und die Koordinaten (sofern vorhanden: diese werden von der Funktion „Wegvermessung“ aus dem Seitenmenü generiert) zu editieren, oder den Fingerprint neu aufzunehmen. Das Hinweisfeld „WLAN- Filter“ zeigt den Namen des WLAN an, welches zur Aufnahme des Fingerprints genutzt wurde (siehe Markierung 1). Wurde kein Filter genutzt, entfällt dieses. Ein grünes Häkchen auf dem Fingerprint-Symbol signalisiert, dass schon ein Fingerprint zu dem Ort vorhan- den ist (siehe Markierung 2). Ein Tap auf das Bild wechselt zur Vollbildansicht (siehe Markierung 3). Mit einem Tap auf das Mülltonnen-Symbol (siehe Markierung 4) kann der Ort aus der Datenbank gelöscht werden (inklusive des Fotos).
Des Weiteren besteht die Möglichkeit, den Fingerprint eines Ortes im Detail anzuzeigen, falls vorhanden. Hierzu auf das Info-Symbol unten rechts am Bildschirm tippen (siehe Markierung 5). Es wird eine Liste mit den Sekunden der Messung und den jeweils empfan- genen Accesspoints mit MAC-Adresse und Signalstärke angezeigt. Mit einem langen Tap auf einen Listeneintrag der Ortsliste mit nachfolgender Bestätigung kann ein Ort direkt gelöscht werden.
Abbildung 5.3: Orte verwalten (Screenshot)
(a) Orte verwalten (Screenshot) (b) Ort editieren (Screenshot)
Wege verwalten
Der Menüpunkt „Wege verwalten“ ist eine Übersicht über alle erzeugten Wege. Ein Weg verbindet hierbei immer zwei Orte und kann barrierefrei sein, was später bei der Wegesuche eine Rolle spielt. Die Vermessung bzw. Erstellung von Wegen befindet sich unter dem Menüpunkt „Wegvermessung“. Zusätzlich hat der Nutzer die Möglichkeit, für Testzwecke Wege zu erstellen (ohne eine Vermessung).
Abbildung 5.5: Wege verwalten (Screenshot)
Hierzu den Startpunkt des Weges aus dem ersten Dropdown-Menü auswählen (siehe Abbildung 5.5, Markierung 1), und den Endpunkt aus dem zweiten Dropdown (sie- he Markierung 2). Mit der Checkbox mit dem Titel „barrierefrei“ kann angegeben werden, ob der Weg barrierefrei ist (siehe Markierung 3). Anschließend tippt der Nut- zer auf den Button (siehe Markierung 4), und da sich eine Kante über ihren Start- und Endpunkt eindeutig identifiziert, wird zunächst geprüft ob die Kante bereits exis- tiert. Falls dies nicht der Fall ist wird eine neue Kante des Graphen erstell und es er- scheint ein neuer Eintrag in der Wege-Liste (siehe Markierung 5).
Die Einträge der Wege-Liste können durch Tippen und Halten mit nachfolgender Be- stätigung gelöscht werden.
Standort ermitteln
Der Menüpunkt „Standort ermitteln“ ist die Ortungsfunktion der Anwendung. Um die aktuelle Position zu ermitteln, muss der Nutzer auf einen der beiden Ortungs-Buttons (siehe Abbildung 5.6, Markierung 1) tippen. Der Unterschied zwischen den beiden Or-
tungsmöglichkeiten besteht in der Dauer der Messung.
Abbildung 5.6: Standort ermitteln (Screen- shot)
Im Normalfall sollte die einsekündige Mes- sung ausreichen. Wählt der Nutzer die 10- sekündige Messung, kann er den Fortschritt am Fortschrittsbalken unterhalb der Mess- buttons erkennen. Für die Messung wird, sofern eingestellt, ein SSID-Filter genutzt.
Dieser kann in den Einstellungen verändert bzw. abgeschaltet werden. Ist kein SSID- Filter eingestellt, werden alle verfügbaren WLAN-Netzwerke zur Standortermittlung genutzt.
Nach abgeschlossener Messung wird im un- teren Bereich des Bildschirms der gefun- dene Ort mit Namen, Beschreibung und Bild angezeigt. Andernfalls wird „Kein Ort gefunden“ ausgegeben (siehe Markierung 2).
Route finden
Die Funktion „Route finden“ bietet dem Nutzer die Möglichkeit, den kürzesten, oder den kürzesten barrierefreien Weg von einem Ort zum anderen zu ermitteln.
Abbildung 5.7: Route finden (Screenshot)
Aus den beiden Dropdown-Menüs wählt der Nutzer Start- und Zielpunkt (siehe Ab- bildung 5.7, Markierung 1), und mit der Checkbox „Barrierefrei“, ob er einen barrie- refreien Weg sucht (siehe Markierung 2). Es besteht außerdem die Möglichkeit, den ak- tuellen Standort als Startpunkt zu verwen- den, dies geschieht durch Tippen auf das Standort-Symbol rechts neben dem Drop- down des Startpunktes (siehe Markierung 3). Für die Standortbestimmung wird je nach Einstellung ein SSID-Filter genutzt.
Der Tap auf „Route“ startet die Suche per Dijkstra-Algorithmus (siehe Markierung 4).
Im unteren Bereich des Bildschirms wird nun die kürzeste Route in Form einer Liste angezeigt. Ganz oben steht der Startpunkt, dann folgen nach unten hin die Stationen der Route (Orte, die passiert werden sol- len), und als letztes erscheint der Endpunkt.
Zwischen den Orten der Liste wird die Dis- tanz dieser in Metern angezeigt (siehe Mar- kierung 5). Unter dem Button „Route an- zeigen“ erscheint die aufsummierte Gesamt- strecke (siehe Markierung 6).
Durch einen Tipp auf eine Zwischenstation der Route werden erweiterte Informationen wie die Beschreibung, das WLAN-Netzwerk (SSID) des gemessenen Ortes, die Koordinaten und das Bild des Ortes angezeigt.
Import / Export
Mithilfe dieses Menüpunktes lässt sich die der Anwendung zugrunde liegende SQLite- Datenbank in den Nutzerspeicher des Endgerätes („SDCARD“-Verzeichnis) exportieren bzw. importieren.
Der Import und Export findet jeweils aus bzw. in folgende Datei statt:
Codeauszug 5.1: Pfad zum Exportverzeichnis
1 /storage/emulated/0/IndoorPositioning/Exported/indoor_data.db
Importieren
Um die Daten (Orte, Wege und Messergebnisse) aus einer bestehenden Datenbankdatei dem Dateinamenindoor_data.dbin die Anwendung zu importieren, tippt der Nutzer auf den Import-Button. Es erscheint ein Dialog mit der Frage, ob die Datei wirklich importiert werden soll; es werden alle bisherigen Daten aus der Datenbank der Anwendung gelöscht!
Tippt der Nutzer auf „OK“, findet er die importierten Daten an gewohnter Stelle (Orte verwalten, Wege verwalten und Standort ermitteln -> Details).
Hinweis: die Bilder werden nicht mit der Datenbank exportiert! Sie können durch einfaches Copy-Paste aus dem Verzeichnis der Anwendung im Speicherbereich des Nutzerspeicher kopiert und dort wieder eingefügt werden. Der Pfad zu diesem Verzeichnis ist folgender:
Codeauszug 5.2: Pfad zum Bilderverzeichnis
1 /storage/emulated/0/IndoorPositioning/Pictures/
Exportieren
Um die SQLite-Datenbank der Anwendung zu exportieren (einen „DB-Dump“ in den Nut- zerspeicher des Endgerätes speichern), tippt der Nutzer auf die Schaltfläche „Exportieren“.
Die erzeugte „.db“-Datei befindet sich nun unter dem oben genanntem Pfad.
Abbildung 5.8: Import / Export der Datenbank (Screenshot)
Einstellungen
Unter dem Menüpunkt „Einstellungen“ befinden sich die Einstellungen für Aufnahme, Ortung und Wegemessung (siehe Abbildung 5.9). Die Filter können zu- bzw. abgewählt und in ihrem Wert verändert werden.
Verbose-Modus
Ist das Häkchen bei „Verbose-Modus“ gesetzt, werden bei allen Fingerprint-Operationen zusätzlich Messergebnisse ausgegeben. Diese erscheinen in Form von MAC-Adressen in
Kombination mit der jeweiligen Signalstärke in den Activities „Ort aufnehmen“, „Standort ermitteln“ und „Route finden“ jeweils in der Infobox am unteren Bildschirmrand.
Aufnahme
Filter für Fingerprints
Für die Aufnahme des Fingerprints gibt es zwei Möglichkeiten. Entweder es wird nur ein bestimmtes WLAN-Netzwerk berücksichtigt, es wird also nach einer SSID (Netzwerkname) gefiltert, oder es wird ohne WLAN-Filter aufgenommen, wobei alle Netzwerke in Emp- fangsreichweite berücksichtigt werden. Die Aufnahme mit einem Filter ist beispielsweise in U-Bahnhöfen sinnvoll, da Passanten manchmal ihr Endgerät als mobilen WLAN-Hotspot nutzen und diese Netzwerke den Fingerprint verfälschen würden. Die Variante ohne Filter ist beispielsweise für Wohnhäuser in dicht besiedeltem Gebiet geeignet, da dort meist viele verschiedene Netzwerke empfangbar sind. Soll ein SSID-Filter verwendet werden, kann dies durch Setzen des entsprechenden Häkchens „SSID-Filter benutzen“ aktiviert werden.
Tippt der Nutzer nun auf „Filtern nach SSID“, wird eine Liste der aktuell in Empfangs- reichweite befindlichen Netze angezeigt, so dass das entsprechende Netz ausgewählt werden kann. Dieses Netz wird bis zur Auswahl eines anderen Filters oder bis zum Abschalten desselben sowohl für die Aufnahme von Fingerprints als auch für die Standortbestimmung genutzt. In der Liste sind nur Netzwerke aufgeführt, die mindestens zwei Access-Points (unterschiedliche MAC-Adressen) in Empfangsreichweite haben, da dies als Minimum für
das Fingerprintverfahren notwendig ist.
Hinweis: Wenn ein SSID-Filter aktiviert wurde, dieses Netzwerk aber bei der Aufnahme oder Standortbestimmung nicht in Empfangsreichweite ist, wird ein leerer Fingerprint aufgenommen! Um dies zu erkennen, kann der Verbose-Modus genutzt werden, mit dem die empfangenen Accesspoints sichtbar gemacht werden.
Abbildung 5.9: Einstellungen (Screenshot)
Die Filteralgorithmen zur Verarbeitung der Fingerprint-Daten sind nicht Teil dieser Arbeit, sondern der Masterthesis von Carola Walter entnommen [Wal17], und werden deshalb hier nicht weiter beschrieben.
Messung
Dieser Teil der Einstellungen ist Teil der Arbeit von Benjamin Kneer [Kne17]
Test
6.1 Allgemeines
Eine Anwendung zu testen, deren Funktionalität von äußeren Einflüssen wie zum Beispiel Passantenandrang und baulichen Eigenschaften (siehe Kapitel 2.2) beeinflusst wird, gestal- tet sich relativ schwierig. Es können kaum zwei vergleichbare Testsituationen geschaffen werden, beispielsweise auf einem U-Bahnhof, da sich die Umgebung permanent ändert; es fahren Bahnen ein oder Passanten bewegen sich. Diese äußeren und schwer kontrollierba- ren Gegebenheiten verändern die Ausbreitung der Funkwellen der WLAN-Accesspoints.
So ist es kaum möglich, an einem Ort zwei Messungen (zur Standortbestimmung) unter vergleichbaren Bedingungen zu tätigen.
6.2 Vergleich WLAN-Signalstärken
An einem Punkt im Gebäude wurde dreimal nacheinander eine dreiminütige Messung getätigt. Accesspoint1 und Accesspoint2 befinden sich etwas weiter entfernt, während Accesspoint3 im selben Raum wie das messende Endgerät platziert ist. Die Ergebnisse finden sich in den nachfolgenden Tabellen 6.1, 6.2 und 6.3, die Messwerte sind in dBm (Dezibel Milliwatt) angegeben. Doppelte Messwerte wurden nicht entfernt.
Auch wenn sich die Ergebnisse der einzelnen Messungen der Accesspoints jeweils relativ ähnlich sind, gibt es doch größere Unterschiede, wie beispielsweise die Standardabweichung.
Tabelle 6.1: Ergebnisse der 1. Messung mit dem Xiaomi Mi4
Accesspoint1 Accesspoint2 Accesspoint3
Max. -74 -78 -25
Min. -82 -81 -27
Mittelwert -76.86 -79 -25.02
Median -76 -79 -25
Standardabweichung 2.29 0.89 0.21
Tabelle 6.2: Ergebnisse der 2. Messung mit dem Xiaomi Mi4
Accesspoint1 Accesspoint2 Accesspoint3
Max. -69 -76 -25
Min. -75 -82 -44
Mittelwert -73.17 -80.26 -25.55
Median -73 -80 -25
Standardabweichung 1.53 1.21 2.69
Tabelle 6.3: Ergebnisse der 3. Messung mit dem Xiaomi Mi4
Accesspoint1 Accesspoint2 Accesspoint3
Max. -72 -77 -25
Min. -79 -79 -38
Mittelwert -75.87 -78.13 -25.56
Median -76 -78 -25
Standardabweichung 1.75 0.43 1.76
Dies ist insbesondere bei Accesspoint3 interessant, da sich dieser im selben Raum wie das Endgerät befand und somit ursprünglich keine größeren Schwankungen zu erwarten waren.
6.3 Mögliches Testszenario
Ein mögliches Testszenario im Bereich der öffentlichen Verkehrsmittel wäre, die Aufnahme- phase und die Ortungsphase im menschenleeren Bahnhof zu testen, beispielsweise nachts unter der Woche. Hierbei wäre dann auf Bahnsteigen auch darauf zu achten, dass die Mes- sungen in der Phase zwischen dem Einfahren der Züge stattfinden, so dass diese keinen Einfluss auf die Funksignale haben. Tests dieser Art könnten mögliche Themen zukünftiger Ausarbeitungen werden.
Eingehende Tests der Android-Applikation finden sich in der Bachelorthesis von Benjamin Kneer aus dem Jahr 2017 [Kne17], welche auch insbesondere auf das Verhalten der Sensoren des Endgerätes eingeht.
6.4 Trägheit beim passiven Scannen
Beim Testen der Anwendung fiel auf, dass sich die Messergebnisse beim Fingerprinting häufig über mehrere Sekunden nicht verändern. Diese Beobachtung wurde ebenfalls von Carola Walter gemacht [Wal17, Kapitel 3.3.1]. Dies betrifft sowohl die Aufnahmephase als auch die Lokalisierung. Grund hierfür ist die Android-Klasse „WifiManager“, welche nur passiv scannen kann (siehe auch Kapitel 2.2).
So kann es sein, dass ein WLAN-Kanal mehrfach durchlaufen werden muss, bis alle auf diesem Kanal empfangbaren Accesspoints mit ihren aktuellen Signalstärken in die Ergeb- nisliste aufgenommen wurden. Für jeden empfangenen Accesspoint wird die zuletzt emp- fangene Signalstärke (RSSI) vorgehalten, bis eine aktuellere Messung dieses Accesspoints verfügbar ist. Dies führt dazu, dass sich unter Umständen alte Messwerte im Ergebnis der Messung befinden, was eine fehlerhafte Standortbestimmung zur Folge haben kann, insbesondere bei schnell aufeinander folgenden Messungen.
Hinzu kommt, dass je nach Endgerät der Scanvorgang zum Durchlaufen aller Kanäle ins- gesamt unterschiedlich lang dauert. Bei den getesteten Endgeräten1 dauert dieser Vorgang ca. fünf Sekunden. Aus diesem Grund kann insbesondere die 1-sekündige Standortbestim- mung, wie sie in der LocationActivity und der RouteFinderActivity genutzt wird, falsche Ergebnisse liefern. Ein möglicher Workaround wäre eine minimale Messzeit über fünf Sekunden, oder das Leeren des Cache des WifiManager, so dass alte Messdaten entfernt werden, falls dies möglich ist. Eine Recherche zu dem Thema hat leider kein Ergebnis geliefert.
Ein weiterer möglicher Workaround ist das Speichern von Zeitstempeln (ein Feld in den vom WifiManager gelieferten ScanResults) für jede empfangene MAC-Adresse, wenn sie das erste Mal auftaucht, und eine Überprüfung beim nächsten Messdurchlauf, ob sich der Zeitstempel geändert hat. Hat sich dieser nicht geändert, wird die RSSI für diesen Accesspoint verworfen, ansonsten wird dieser aktualisiert. Sind mehr als ein per Grenzwert definierter Anteil der Messungen verworfen worden, bzw. veraltet, wird die Messung als ungültig erklärt und die Meldung „Bitte erneut versuchen“ angezeigt. Ein entsprechender Versuch, diese Vorgehensweise bei einsekündigen Lokalisierungen umzusetzen, findet sich in der Klasse „FingerprintTask“. Leider entstanden trotz dieser Maßnahme beim Testen fehlerhafte Lokalisierungen.
Die beschriebenen Messfehler könnten insbesondere bei einer auf dieser Technologie beru- henden Echtzeit-Navigation problematisch sein.
1Xiaomi Mi4, Android 6.0.1 und Xiaomi Mi5 Pro, Android 7.0
Zusammenfassung und Ausblick
7.1 Zusammenfassung
Die in Kapitel 1.2 beschriebenen Anforderungen konnten weitestgehend erfüllt werden. So wurde die zugrundeliegende Prototyp-Anwendung hinsichtlich ihrer Nutzerfreundlichkeit umgebaut. Die Anwendung wurde rund um die Aufnahme von „Nodes“ verbessert, so dass es nun möglich ist, Knoten mit zusätzlichen Informationen wie einer Beschreibung und einem Foto zu versehen und diese im Nachhinein zu editieren, sowie den zugehörigen Fingerprint anzuzeigen und neu aufzunehmen. Darüber hinaus kann ein SSID-Filter zu- und abgeschaltet werden, der es ermöglicht, Orte aufzunehmen, an denen es nur wenig Accesspoints mit dem gleichen Netzwerknamen gibt, wie es häufig in Wohnhäusern der Fall ist. Die Messdaten können per „Verbose“-Modus in Echtzeit bei der Messung einge- blendet werden. Des Weiteren wurde eine Möglichkeit der Kantenerstellung und deren Verwaltung eingerichtet, die das Verbinden von Orten durch Wege ermöglicht, so dass letztlich ein Graph aus Knoten und Kanten aufgebaut werden kann. Dieser Graph, welcher nach Aufnahme aller relevanten Daten eine Lokalität repräsentiert, kann nun von der Rou- tensuche durchlaufen werden. Mithilfe des implementierten Dijkstra-Algorithmus kann der Nutzer nun eine Route von einem zum anderen Ort finden, wobei die Gesamtstrecke in Metern, sowie die Zwischenstationen (Orte auf dem Weg zum Zielpunkt) und die dazwi- schen liegenden Teilstrecken angezeigt werden. Zusätzlich dazu besteht die Möglichkeit, nur Routen anzeigen zu lassen, deren Wege vorher als barrierefrei gekennzeichnet wurden, was beispielsweise für Rollstuhlfahrer von Nutzen sein kann.
Auf programmatischer Ebene wurde die Applikation durch Refactoring neu strukturiert.
Dies betrifft insbesondere die Umsetzung des Prinzips „Program to an interface“, wel- ches die Implementierungen hinter den Interface verbirgt, und so die Einarbeitungszeit verringert und damit die Wiederverwendbarkeit des Code erhöht. Die unnötigen Ver- schachtelungen von Klassen wurden aufgelöst, und die Klassen und Interfaces nach Zweck in Packages sortiert. Die Daten der Anwendung werden in einer SQLite-Datenbank ge- speichert, deren Zugriff über eine Singleton-Factory geregelt ist, um fälschlicherweise entstandene gleichzeitige Mehrfachzugriffe zu verhindern. Diese Datenbank kann über eine Import- und Exportfunktion als Datei in den externen Gerätespeicher bzw. aus diesem wieder geladen werden.
7.2 Ausblick
Diese Arbeit könnte in Zukunft als Grundlage für eine Echtzeit-Navigation dienen, wie man sie von anderen Navigations-Anwendungen kennt. Hierzu könnte beispielsweise im Falle der Möglichkeit des aktiven WLAN-Scans eine sekündliche Positionsbestimmung per WLAN erfolgen, deren Ergebnisse dann mit den über die Sensoren aufgenommenen Lage-, Beschleunigungs- und Höhendaten verrechnet werden und so eine Navigation in Echtzeit inklusive Richtungspfeil ermöglichen.
Eine Möglichkeit zum Zusammenführen von mehreren, von verschiedenen Endgeräten exportierten Datenbankdateien zu einer einzigen Datenbank, wäre wahrscheinlich für zukünftige Einsatzszenarien ebenfalls von Nutzen.
Anhang
Quelltext der Interfaces
Node
1 public interfaceNode {
2 /∗∗
3 ∗ Getter for the ID (name) of a node 4 ∗ @return the ID (name)
5 ∗/
6 String getId();
7
8 /∗∗
9 ∗ Setter for the ID (name) of a node 10 ∗ @param id the ID (name)
11 ∗/
12 voidsetId(String id);
13
14 /∗∗
15 ∗ Getter for the description of a node 16 ∗ @return the description string
17 ∗/
18 String getDescription();
19
20 /∗∗
21 ∗ Getter for the fingerprint of a node
