MOBILE ERFASSUNG VON RELATIVEN POSITIONSDATEN DURCH CROWDSOURCING

Transkript

1 Fakultät für Informatik, Institut für Systemarchitektur, Lehrstuhl für Rechnernetze Diplomarbeit MOBILE ERFASSUNG VON RELATIVEN POSITIONSDATEN DURCH CROWDSOURCING Tobias Reinsch Mat.-Nr.: Betreut durch: Dr.-Ing. Thomas Springer und: Dr.-Ing. Michael Ameling Eingereicht am

2 2

3 ERKLÄRUNG Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen wörtlich oder sinngemäß übernommenen Gedanken sind als solche kenntlich gemacht. Ich erkläre ferner, dass ich die vorliegende Arbeit an keiner anderen Stelle als Prüfungsarbeit eingereicht habe oder einreichen werde. Dresden,

4 4

5 INHALTSVERZEICHNIS 1 Einleitung Motivation Zielstellung Aufbau der Arbeit Grundlagen Crowdsourcing Definition und Zielstellung Herausforderungen Position- und Orientierungsbestimmung Einleitung und Begriffsklärung Methoden zur Positionsbestimmung Positionsbestimmung in Gebäuden Zusammenfassung Anforderungen Client Funktionale Anforderungen Nichtfunktionale Anforderungen

6 3.1.3 Optionale Anforderungen Server Funktionale Anforderungen Nichtfunktionale Anforderungen Optionale Anforderungen Abgrenzung Verwandte Arbeiten Indoor-Positionierung und -Navigation Simultaneous Localization and Mapping Crowdsourcing Mapbiquitous Zusammenfassung Konzept Begriffsklärung Überblick Crowdsourcing Was können die Nutzer beitragen? Evaluation der Beiträge Nutzermotivation und Gamification Systemarchitektur Crowdsourcing-Server Mobiler Client Gamification-Server Server Datenbank Schnittstellen RESTful API JSON Datenaustausch Inhaltsverzeichnis

7 5.6 Datenmodell Client Programmablauf Zusammenfassung Implementierung Technologiegrundlagen SAP HANA Cloud Platform Java API for RESTful Web Services (JAX-RS) Java Persistence API (JPA) Java Architecture for XML Binding (JAXB) SAP Gamification Platform Architektur Crowdsourcing Server ios Client Gamification Server Zusammenfassung Evaluation Testumgebung Testfälle Teilnehmer Durchführung Auswertung Befragung Gamification Herausforderungen bei der Aufzeichnung Verbesserungsvorschläge der Studienteilnehmer Entstandenes Wegenetz Fazit Inhaltsverzeichnis 7

8 7.6 Optimierung der Aggregation Auswertungen der Anforderungen Client-Anforderungen Server-Anforderungen Richtlinien für die Routenberechnung und Navigation Zusammenfassung Zusammenfassung und Ausblick 75 8 Inhaltsverzeichnis

9 1 EINLEITUNG 1.1 MOTIVATION Vorstellbar ist folgende Situation aus dem Leben an der Universität: Ein Student im ersten Semester ist auf dem Weg zum ersten Seminar, in der Hand ein Zettel mit dem Veranstaltungsort. Glücklich, dass er das Seminargebäude mit Hilfe des Smartphones endlich gefunden hat, steht er vor der nächsten Herausforderung, bei dem das Smartphone nicht mehr hilfreich ist. Er muss den richtigen Raum finden, jedoch scheint das Gebäude wie ein Labyrinth gebaut zu sein. Da er schon spät dran ist, fragt er einen vorbei gehenden Studenten nach dem Weg. Dieser antwortet: Einfach den Flur gerade aus, dann rechts die Treppe in den zweiten Stock und dann die dritte Tür links. Er bedankt sich und findet mit den erhaltenen Informationen rechtzeitig den richtigen Seminarraum. Dieser Ausschnitt aus dem Leben eines Studenten ist nur ein Beispiel um zu illustrieren, wie oft Menschen im Alltag auf Unterstützung bei der Wegfindung im Gebäude angewiesen sind. Digitale Navigationsassistenzsysteme spielen seit Jahrzehnten eine wichtige Rolle für Regierung und Wirtschaft. Mit der Abschaltung der selective availability für das Global Positioning System (GPS) im Jahr 2000 und der damit gestiegenen Genauigkeit bei der Positionsbestimmung [1] erlebten Navigationsassistenzsysteme ihren Aufschwung auch im Bereich der Verbraucherelektronik. Seitdem wurden eine Vielzahl von Navigationsdiensten entwickelt die vor allem in Verbindung mit mobilen Endgeräten kaum noch aus unserem alltäglichen Leben wegzudenken sind. Dabei liefern die zu Grunde liegenden Technologien zur Positionsermittlung (GPS, WLAN, Mobilfunknetze) eine nur sehr eingeschränkte Genauigkeit. Besonders in Gebäuden lässt sich oft keine zuverlässige Position mit den genannten Technologien ermitteln [14]. Zwar gibt es Bestrebungen bestehende Infrastrukturen für die Positionsermittlung in Gebäuden zu optimieren [22,36] oder neue Infrastrukturen für die Positions- und Orientierungsermittlung aufzubauen [4]. Diese sind jedoch entweder nicht flächendeckend verfügbar, nicht mit den bislang verbreiteten mobilen Endgeräten kompatibel, setzen eine proprietäre Infrastruktur voraus oder sind noch Forschungsgegenstand. Diese Erkenntnisse bilden die Motivation dieser Arbeit zur Entwicklung eines Navigationsassistenten, welcher ein Minimum an absoluten Positions- und Orientierungsdaten benötigt. Das einleitende Beispiel illustriert dabei, dass absolute Positionsinformationen (ausschließlich Start und Ziel) nicht zwingend notwendig sind. Darüber hinaus wird deutlich wie intuitiv wir mit relativen Positionsabgaben umgehen. 9

10 1.2 ZIELSTELLUNG Das Ziel dieser Arbeit ist die Entwicklung einer Crowdsourcing-Plattform zur Erstellung eines Wegenetzplans als Grundlage zur Fußgängernavigation in Gebäuden. Der Wegenetzplan soll aus den Beiträgen vieler Nutzer aggregiert werden. Dazu soll eine Anwendung für ein mobiles Endgerät entwickelt werden, mit der sich Wegstrecken im Gebäude aufzeichnen lassen. Die Zielgruppe dieser Anwendung hat dabei Kenntnisse von den Wegen in einem Gebäude und ist bereit dieses Wissen zu teilen. Der Nutzer definiert bei der Erstellung eines Pfades jeweils einen Wegpunkt als Start und Ziel. Bei einem Wegpunkt kann es sich beispielsweise um Räume, Hallen oder Ähnliches handeln. Während der Nutzer sich vom Start zum Ziel bewegt, informiert er die Anwendung mit je einer Richtungsinformation für jede Kreuzung, die er passiert. Während der Aufzeichnung der Wegstrecken soll weitestgehend auf die absolute Positionsbestimmung des Nutzers verzichtet werden. Die auf diese Art aufgezeichneten Wegstrecken werden an einen Server übertragen. Der Server aggregiert diese Daten und fügt sie zu einem Wegenetzplan zusammen. Dieser Wegenetzplan dient als Basis für die Routenberechnung in Gebäuden. Die Umsetzung eines Navigationsassistenten erfolgt in einer parallel laufenden Masterarbeit [37]. Wie bei der Aufzeichnung von Wegstrecken spielt die räumliche Positionsbestimmung des Nutzers bei der Navigation eine untergeordnete Rolle. Stattdessen erfolgt die Zielführung über relative Richtungsangaben. Abschließend soll evaluiert werden, in wie weit die relative Positionierung und Orientierung eine absolute Positionsbestimmung des Nutzers bei der Navigation im Gebäude ersetzen kann. 1.3 AUFBAU DER ARBEIT Der Aufbau dieser Arbeit gliedert sich in acht Kapitel und folgt dabei dem Ablauf der begleitenden Forschung. Nachdem dieses Kapitel bereits die Motivation und die daraus folgende Zielstellung vorstellte, werden im anschließenden Kapitel einige spezifische Grundlagen erläutert. Die Erkenntnisse aus diesem Kapitel festigen die Aussagen der Motivation. Die Anforderungen im Kapitel 3 vertiefen die Zielstellung. Weiterhin stellen sie den Maßstab dar, an dem die Qualität des Konzepts gemessen wird. Kapitel 4 stellt verwandte Arbeiten vor. Es wird geprüft, welche Herausforderungen und Zielstellungen adressiert werden, um die Relevanz für die vorliegende Arbeit zu bestimmen. Basierend auf diesen Vorbetrachtungen wird in Kapitel 5 ein Gesamtkonzept für eine Plattform entwickelt, welches die gegebenen Anforderungen erfüllt. Eine prototypische Implementierung wird im darauf folgenden Kapitel dokumentiert. Dies soll die Umsetzbarkeit des Konzeptes aufzeigen. In Kapitel 7 (Evaluation) wird das Konzept auf Basis des Prototyps im Rahmen einer Nutzerstudie evaluiert, einschließlich einer Überprüfung auf Erfüllung der Anforderungen. Die abschließende Zusammenfassung bündelt die Erkenntnisse dieser Arbeit. Weiterhin wird ein Ausblick gegeben, wie anschließende Forschungen das Konzept optimieren und erweitern können. 10 Kapitel 1 Einleitung

11 2 GRUNDLAGEN In diesem Kapitel werden Grundlagen behandelt, die für das Verständnis der vorliegenden Arbeit hilfreich sind. Die Erkenntnisse aus diesen Grundlagen festigen so auch die Motivation der Arbeit. Im Detail soll der Begriff Crowdsourcing behandelt werden, der das Konzept dieser Arbeit entscheidend prägt. Weiterhin werden verschiedene existierende Technologien zur räumlichen Positionsbestimmung vorgestellt und es wird abgewägt, inwieweit diese als Grundlage für die Indoor-Navigation geeignet sind. 2.1 CROWDSOURCING Definition und Zielstellung Bei dem Umgang mit dem Begriff Crowdsourcing soll dessen Definition geklärt werden. Durch die Vielfältigkeit von Crowdsourcing-Projekten und -Produkten wird der Begriff von verschiedenen Personen unterschiedlich definiert und interpretiert. Crowdsourcing ist ein Neologismus des Wired Autors Jeff Howe. An dieser Stelle soll auf die ursprüngliche White Paper Definition des Begründers [18] zurück gegriffen werden: Crowdsourcing ist der Akt der Auslagerung einer Aufgabe, die traditionell von einem bestimmten Beauftragten (üblicherweise ein Angestellter) ausgeführt wurde, an eine undefinierte und generell große Gruppe von Menschen, in Form eines offenen Aufrufs. Gassmann [9] untersucht dazu verschiedene Crowdsourcing-Plattformen und unterteilt diese in fünf Kategorien: Intermediäre Plattformen Intermediäre Plattformen bringen verschiedene Parteien zusammen und agieren als Vermittler. Die Betreiber solcher Plattformen ziehen im Allgemeinen keinen direkten Nutzen oder gar Gewinn aus dem erstellten Wissen. Stattdessen bieten sie einen Marktplatz an. Auf diesen Marktplätzen ist es auf der einen Seite möglich Problem- und Aufgabenstellungen einzustellen und auf 11

12 der anderen Seite Hilfe zur Lösung einer Aufgabe anzubieten. Für die Lösung der Probleme werden Honorare oder Preise ausgehandelt. Die Lösenden sind in der Regel individuell agierende Experten. Gemeinsam eine freie Lösung Bei dieser Art von Crowdsourcing-Plattform arbeitet ein Kollektiv von Individualpersonen an der Lösung eines Problems oder an einer Aufgabenstellung. Jedem Nutzer steht es frei auf das entstandene Wissen zuzugreifen oder sich selber an der Wissensgenerierung oder Problemlösung zu beteiligen. Die bekannteste Plattform dieser Art ist Wikipedia, bei der an einer freien Enzyklopädie gearbeitet wird. Auch Open-Source-Plattformen wie GitHub und SourceForge gehören zu dieser Kategorie. Unternehmenseigene Plattform Bei unternehmenseigenen Plattformen gibt es eine zentrale Instanz in Form eines Unternehmens, welches die Leitung übernimmt. Teilnehmer dieser Plattformen sind (potentielle) Kunden eines Unternehmens. In den bestehenden Projekten dieser Art steuern die Teilnehmer Produktideen bei, geben Hinweise für die Produktverbesserung oder präsentieren eigene Gestaltungsvorschläge. Diese Plattformen sollen den Unternehmen bei der Verbesserung der eigenen Produkte helfen und für eine bessere Kundenbindung sorgen. Dazu schaffen die Unternehmen auch Anreize in Form von Gutscheinen, Preisen und Ähnlichem. Marktplätze für eigene Ideen Bei dieser Kategorie stehen keine Probleme und Aufgaben im Vordergrund, die es zu lösen gilt. Stattdessen können Nutzer ihre eigenen Ideen und Entwürfe präsentieren. Das Unternehmen, welches den Marktplatz betreibt, produziert basierend auf den Ideen die finalen Produkte. Dabei stimmen die Nutzer auch ab, welche Ideen letztendlich umgesetzt werden. Die entstandenen Produkte können direkt auf der Plattform erstanden werden. Öffentliche Intiativen Diese Kategorie von Crowdsourcing Plattformen ähnelt dem Aufbau der Kategorie Gemeinsam eine freie Lösung. So wird auch an einer freien Lösung gearbeitet. Die Leitung dieses Prozesses übernimmt hier hingegen eine öffentliche Einrichtung wie Universitäten oder gar die Regierung eines Staats. Sobzak und Groß [32] nehmen eine abweichende Unterteilung angelehnt an Howe vor: Wissensintensive Diensleistung (Crowdwisdom, vgl. intermediäre Plattform) Crowdwisdom soll die individuellen Fähigkeiten und Talente von Personen vereinen und so für Innovationen und Problemlösungen sorgen. Spezielle Plattformen dienen dazu als Anlaufstelle, um Problemstellungen zu veröffentlichen und an der Lösung zu arbeiten. Häufig handelt es sich dabei um kreative Aufgaben in Form einer Ausschreibung. Die Ergebnisse dieser Arbeit sind im Allgemeinen nicht frei. Erstellung von Inhalten (Crowdcreation, vgl. Gemeinsan eine freie Lösung, unternehmenseigene Plattformen, Markplatz für eigene Ideen) Bei Crowdcreation haben die Nutzer einen weiterführenden Einfluss. Auf zumeist offenen Plattformen wird so das Wissen von Nutzern gesammelt und steht wiederum den Nutzern frei zur 12 Kapitel 2 Grundlagen

13 Verfügung. Bekannte Beispiele dafür sind Wikipedia, Open Street Map und Youtube. Unternehmen geben ihren Kunden auf diese Weise Einfluss auf die Produktgestaltungen oder ermöglichen den Nutzern gar ihre eigenen Produkte zu entwerfen. Filter und Bewertungen im Netz (Crowdvoting) Bei Crowdvoting ermöglicht eine besonders große Anzahl von Nutzern das Filtern, Sortieren, Organisieren und Bewerten von großen Datenmengen. Finanzierung (Crowdfunding) Crowdfunding unterscheidet sich sehr von den restlichen Crowdsourcing Arten. Es bezeichnet die Geldbeschaffung durch (kleine) Teilzahlungen von vielen Interessenten. Auf Crowdfunding- Plattformen können eigene Ideen und Produkte präsentiert werden. Interessenten können sich so einfach an der Finanzierung beteiligen Herausforderungen Aus dem großen Potential von Crowdsourcing ergeben sich auch Herausforderungen. Dies liegt vor allem an der hohen Anzahl von (potentiellen) Nutzern und Beitragenden begründet. Doan et al. [7] zeigen dazu vier Hauptherausforderungen auf: Anwerben und Bewahren von Nutzern Die Frage nach der Anwerbestrategie ist kritisch für den erfolgreichen Produktivstart einer Crowdsourcing-Plattform. Eine Crowdsourcing-Plattform erhält erst mit den Nutzern seinen Wert. Etablierte Plattformen zeigen einige Lösungswege auf: Nutzer fordern. Die richtige Autorität voraus gesetzt, kann es von Personen verlangt werden sich an der Plattform zu beteiligen und Inhalt zu generieren. Dies kann vor allem im Unternehmensumfeld umgesetzt werden. Nutzer bezahlen. Sehr weit verbreitet und akzeptiert ist der Ansatz Personen für ihre Beteiligung zu bezahlen. Nach Freiwilligen fragen. Eine sehr einfache Variante ist es Nutzer um eine freiwillige Teilnahme zu bitten und diese dafür zu motivieren. YouTube und Wikipedia als zwei der größten Crowdsourcing-Plattformen im Internet nutzen diese Strategie. Nutzerbeteiligung als Bezahlung. Bei diesem Modell bekommen Personen Zugang zu einem Dienst A indem sie sich an einem Crowdsourcing-Dienst B beteiligen. Sie bezahlen somit mit dem Wissen oder der Arbeit, welche sie der Crowdsourcing-Plattform zukommen lassen ein moderner Tauschhandel. Nutzer beobachten. Bei diesem Modell beteiligen sich Personen nur implizit am Crowdsourcing-Prozess. So wird das Verhalten von Nutzen in anderen Bereichen ausgewertet und die Ergebnissen fließen in die Plattform ein. Unter Umständen wird diese indirekte Teilnahme sogar vor dem Nutzer verborgen. Um die gewonnen Nutzer über längere Zeit aktiv an das System zu binden, gibt es verschiedene Methoden zur Motivation. Dazu zählen: 2.1 Crowdsourcing 13

14 sofortige Belohnung Aufzeigen der Bedeutsamkeit, des Rangs oder Rufs eines Nutzers Wettbewerbe Schaffung von unterhaltsamen Inhalten wie spielerische Elemente Besonders wichtig sind diese Motivationselemente bei freiwilligen Nutzern. Was können die Nutzer beitragen? Nach dem geklärt wurde, wie Personen zur Teilnahme bewegt werden können, gilt es zu definieren, in welchem Maße die Nutzer sich beteiligen können. Dazu müssen die Aufgaben beschrieben werden und auf welcher Weise diese erfüllt werden können. Die Aufgabenliste kann dabei nach dem kognitiven Schwierigkeitsgrad unterteilt werden. Danach können die Rollen der Nutzer definiert werden. Kognitiv anspruchsvolle Aufgaben sollten primär an hochrangige Mitglieder verteilt werden. Dieses Vorgehen erhöht die Qualität des Crowdsourcing-Systems. Weiterhin sollte bedacht werden, welche Aufgaben besser von Menschen und welche besser von Maschinen erledigt werden können, bzw. wie Menschen Computern bei der Lösung von Aufgaben unterstützen können. Zusammenführen der Beiträge Eine weitere wichtige Frage ist, wie mit den Beiträgen verfahren wird und wie diese kombiniert werden können. Die bestehenden Crowdsourcing-Plattformen unterscheiden sich inwieweit sie die Beiträge unterschiedlicher Nutzer zusammenführen. Die Schwierigkeit dabei besteht in der Konfliktlösung: Wie werden differierende Lösungen bezüglich eines Problems behandelt? Zur Lösung dieses Problems wurden einige Ansätze entwickelt. Eine Möglichkeit ist eine gewichtete Kombination auf Basis der Nutzer- und Beitragsbewertung. So kann es anderen Nutzern erlaubt sein, die Qualität eines Beitrags zu bewerten. Es ist auch eine komplett manuelle Konfliktlösung denkbar, wie sie bei Wikipedia und Open Source Software eingesetzt wird. Bei solch komplexen Aufgaben sind automatische Konfliktlösung selten zielführend. Die Konfliktlösung wird umso komplexer, wenn Maschinen und Menschen gegensätzliche Inhalte beitragen. Bewertung der Nutzer und ihrer Beiträge Wie bereits im vorhergehenden Abschnitt angesprochen wurde, ist eine Bewertung von nutzergenerierten Inhalten hilfreich, um die allgemeine Qualität der Crowdsourcing-Plattform zu erhöhen. Besonders wichtig ist dabei das Filtern von fehlerhaften oder gar schädlichen Daten und Nutzern. Deren Einfluss sollte so gering wie möglich gehalten werden. Ein Rollenmodell ist dabei hilfreich. Mit steigender Anzahl qualitativer Beiträge bekommen Nutzer mehr Einfluss auf das System. Schädliche Nutzer können über manuelle und automatische Mechanismen ausfindig gemacht werden. Bei einer manuellen Überprüfung suchen zuverlässige Nutzer nach fehlerhaften Einträgen. Bei automatischen Tests müssen Nutzer Aufgaben lösen deren Antworten dem Crowdsourcing-System bekannt sind. Mit der korrekten Lösung der Aufgabe steigt die Zuverlässigkeit des Nutzers. 14 Kapitel 2 Grundlagen

15 Wurden schädliche Nutzer ausfindig gemacht, können ihnen Strafen auferlegt werden, beispielsweise eine Sperre oder die Veröffentlichung ihrer Vergehen. Die Inhalte des Nutzers können darüber hinaus aus dem Crowdsourcing-System entfernt werden, insofern diese Operation generell möglich ist. 2.2 POSITION- UND ORIENTIERUNGSBESTIMMUNG Einleitung und Begriffsklärung Bei der Entwicklung und Bedienung eines Navigationsassistenten spielt der Begriff Position (bzw. Ort) eine große Rolle. So muss jeweils eine (initiale) Nutzerposition sowie Zielposition bestimmt werden um eine Zielführung umzusetzen. Dabei gibt es jedoch unterschiedliche Interpretationen für den Begriff Position. Es ist notwendig diesen für den vorliegenden Kontext zu definieren. Küpper [21] folgend lassen sich Positionen einteilen in: Deskriptive Positionen sind bezogen auf reale Orte und Objekte. Dies können natürliche geografische Orte sein wie Berge oder Seen, jedoch auch künstliche Objekte wie Gebäude und Städte. Im Kontext der Navigation in Gebäuden sind besonders Räume, Gänge, Treppen sowie Aus- und Eingänge von Relevanz. Adressiert und identifiziert werden diese Ort über ihren Namen oder eine Beschreibung. Dies ist die natürliche Weise im alltäglichen Leben mit Positionen umzugehen. Für deskriptive Positionen wird meist der Begriff Ort als Synonym verwendet. Räumliche Positionen hingegen bezeichnen einen Punkt im euklidischen Raum. Im technischen Kontext entspricht dies häufig der Definition für den Begriff der Position. Räumliche Positionen werden meist durch zwei- oder dreidimensionale Koordinaten ausgedrückt. Dabei besitzt eine räumliche Position folgende Bestandteile: Ein Koordinatensystem zur Einordnung der Koordinaten. Dabei können lokale oder globale Koordinatensysteme genutzt werden. Weit verbreitet ist die Verwendung von ETRS89, wie es bei GPS zum Einsatz kommt. Ein Datum zum Bestimmen der Lage im Koordinatensystem. Eine Projektion für die Abbildung auf einer Karte. Für die Beschreibung des Nutzers im Kontext eines Navigationssystems werden häufig weitere räumliche Daten benötigt. Von großer Bedeutung ist die Blickrichtung bzw. Ausrichtung einer Person. Diese wird als Orientierung bezeichnet. Für die Navigation auf einer Ebene genügt eine Definition der Orientierung über einen Winkel, genannt Gierung. Im dreidimensionalen Raum werden zusätzlich Roll- und Nickwinkel benötigt [30]. Bei vielen Methoden zur Bestimmung von räumlichen Positionen lässt sich die Orientierung nicht direkt ermitteln. Oftmals kann diese relativ aus mehreren zeitlich versetzten räumlichen Positionen berechnet werden und beschreibt in dem Fall die Bewegungsrichtung eines Objektes. Orientierungsangaben können auch im Zusammenhang mit deskriptiven Positionen verwendet werden. Statt mit Hilfe von Winkeln kann die Orientierung in Bezug auf eine weitere deskriptive Position angegeben werden, sprich die Blickrichtung zu einem Ort. Die Kombination aus (deskriptiver oder räumlicher) Position und Orientierung wird als Pose bezeichnet. Der Einfachheit halber, bezieht sich der Begriff Position im weiteren Verlauf dieses Kapitels auf eine räumliche Position. 2.2 Position- und Orientierungsbestimmung 15

16 2.2.2 Methoden zur Positionsbestimmung Positionsbestimmung beschreibt den Prozess der Ermittlung einer räumlichen Position eines Objektes oder Person. Dafür wurden eine Reihe von Methoden mit jeweils unterschiedlichen Ansätzen entwickelt. Küppler [21] unterteilt diese Methoden in folgende: Näherungsmessung Diese weit verbreitete Methode beruht auf einem einfachen Prinzip: Ein Sender mit bekannter Position kommuniziert mit einem Empfänger, dessen Position ermittelt werden soll. Sobald sich der Empfänger in Reichweite zum Sender befindet, kann für den Empfänger eine Position nahe des Senders angenommen werden. Die Genauigkeit der Positionsbestimmung ist direkt abhängig von der Reichweite des eingesetzten Kommunikationskanals. Anwendung findet diese Methode in den globalen Mobilfunknetzen (GSM, UMTS, LTE) zur Bestimmung der Position eines Teilnehmers. Weitverbreitet ist diese Methode auch für die Positionsbestimmung in Gebäuden. Genutzt werden WLAN- und NFC- (RFID) Sender mit den passenden Empfängern. Dem geht jedoch eine Bestimmung der räumlichen Positionen der einzelnen Sender und gegebenenfalls die Installation einer Senderinfrastruktur voraus. Lateration Im Gegensatz zur Näherungsmessung muss bei der Lateration ein Empfänger mit mindestens drei Sendern gleichzeitig kommunizieren, um seine zweidimensionale Position zu ermitteln. Ausgehend von der Näherungsmessung zu den Sendern in Reichweite kann über ein lineares Gleichungssystem eine genauere Position ermittelt werden. Dabei kann zwischen zwei Methoden unterschieden werden: Bei der Kreislateration wird von einem kreisförmigen Sendebereich ausgegangen. Als Position des Empfängers wird der Schnittpunkt der Sendebereiche berechnet. Dabei muss der Radius des Sendebereichs für jeden Sender bekannt sein. Die Positionsbestimmung bei der Hyperbellateration oder Hyperbelnavigation basiert auf Reichweitenunterschieden. Bei zwei überlappenden Sendebereichen markiert eine Hyperbel alle Punkte bei der die Differenz der Abstände zu den Sendern konstant ist. Mit drei überlappenden Sendebereichen lässt sich der Schnittpunkt zweier Hyperbeln berechnen, welcher als Position des Empfängers angenommen wird. Bei beiden Methoden ist weiterhin der Radius des Sendebereichs entscheidend für die Genauigkeit. Der Fehler bei der Positionsbestimmung ist jedoch weitaus niedriger als bei reiner Näherungsmessung. Angewandt wird die Lateration beim Global Positioning System (GPS). Mit Hilfe eines erdumspannenden Netzes von geostationären Satelliten kann ein GPS-Empfänger global seinen Standort ermitteln. Angulation Bei der Angulation erfolgt die Positionsermittlung auf Basis von Winkeln. Der Empfänger misst den Winkel, mit dem das Signal des Senders eingeht. Dabei müssen Signale von mindestens zwei Basisstationen empfangen und ausgewertet werden, um eine 2D-Position zu ermitteln. Für die Umsetzung dieser Methode in der Praxis wird häufig eine Funktechnik mit Richtantennen eingesetzt. Die Streuung bei der Signalausbreitung sowie Reflexion und Beugung sind dabei große Fehlerquellen. Triangulation bezeichnet die Ermittlung einer 3D-Position mit mindesten drei Basisstationen. 16 Kapitel 2 Grundlagen

17 Dead Reckoning Dead Reckoning, auch als Koppelnavigation oder Trägheitsnavigation bezeichnet, hatte eine lange Tradition in der Schifffahrt. Ausgehend von einem Ort mit bekannter absoluter Position wird die aktuelle Position eines Objektes extrapoliert. Dabei helfen Informationen über die Bewegungsrichtung, die Geschwindigkeit, die zurück gelegte Strecke, das Ziel und weitere Bewegungsdaten. Die initiale Position wird über andere Methoden bestimmt. Die Genauigkeit ist abhängig von dem Wissen über die Bewegung. Generell besitzt diese Methode einen Drift. Fehler bei der Modellierung der Bewegung addieren sich über die Zeit. Somit kann bei der Koppelnavigation zwar eine hohe lokale und temporäre Genauigkeit erzielt werden, jedoch kann diese nicht über einen langen Zeitraum aufrecht erhalten werden. Weitere absolute Positionsdaten, von einer alternativen Positionsbestimmung, können den Drift zurücksetzen. Trotz der langen Geschichte dieser Methode ist diese sehr aktuell und wird im Luftverkehr und bei der Navigation im Gebäude eingesetzt. Pattern Matching Ein weitere Methode ist die Positionsbestimmung über Pattern Matching. Dabei wird die Umgebung oder Szene untersucht, in der Positionsbestimmung erfolgen soll. Dafür existieren zwei Verfahren: Optische Analyse untersucht die Szene mit bildgebenden Sensoren. Mit Bildverarbeitungsverfahren können Veränderungen der Umgebung über die Zeit erkannt werden. So kann beispielsweise die Position eines Objekts verfolgt werden, dass sich in und durch die untersuchte Umgebung bewegt. Zur globalen Einordnung dieser relativen räumlichen Position wird ein Bezugssystem benötigt, welches über andere Positionsbestimmungsmethoden bestimmt werden kann. Nicht-Optische Analyse benutzt keine bildgebenden Verfahren. Stattdessen werden andere physikalische Eigenschaften untersucht. So lassen sich beispielsweise Signalstärken und die Ausbreitung von Funksignalen aufzeichnen. Über die bekannte Position der Sender dieser Signale lassen sich Positionen bestimmen. Diese Technik wird Fingerprinting genannt und findet große Anwendung bei der Positionsbestimmung in Gebäuden über Auswertung von WLAN Funksignalen. Grundsätzlich lassen sich die vorgestellten Methoden kombinieren. Dead Reckoning und Pattern Matching sind sogar abhängig von initialen Positionsdaten aus anderen Quellen. Die Kombination verschiedener Methoden kann die Genauigkeit der Positionsbestimmung stark erhöhen Positionsbestimmung in Gebäuden Wie in der Motivation zu dieser Arbeit angeklungen ist und auch Küpper [21] aufzeigt, gibt es Bedarf an Anwendungen, die mit einer Nutzerposition in Gebäuden arbeiten. Eine große Herausforderung in diesen Szenarien ist das Fehlen einer allgemeinen Infrastruktur für die Positionsbestimmung in Gebäuden. Außerhalb von Gebäuden existieren dagegen solche Infrastrukturen; allen voran GPS. Dies ermöglicht erst eine Vielzahl von Navigationsanwendungen im Außenbereich. In diesem Kontext gilt die Entwicklung einer Positionsbestimmungslösung in Gebäuden ohne dedizierte Infrastruktur als wichtiges Forschungsziel. Auch dazu zeigt Küpper [21] einige Ansätze auf: 2.2 Position- und Orientierungsbestimmung 17

18 WLAN Positionsbestimmung Im Prinzip kann WLAN als Mobilfunk aufgefasst werden, bei dem die einzelnen WLAN- Basisstationen die Mobilfunkzellen darstellen. Dies trifft besonders im Fall von IEEE im Infrastrukturmodus zu, bei dem alle Teilnehmer sich direkt mit den Basisstationen verbinden. Weitere Eigenschaften von WLAN-Netzen werden bei der Positionsbestimmung genutzt. Über die empfangene Signalstärke (RSS) und den Signal-Rauschabstand (SNR) können Rückschlüsse auf die Distanz zur Basisstation gezogen werden. Die Informationen über RSS und SNR werden über sogenannte Beacons ermittelt, welche die Basisstation in kurzen Intervallen an alle Empfänger sendet. Auf Basis dieser Gegebenheiten existieren drei Methoden zur Positionsbestimmung: Näherungsmessung. Wie bei anderen Mobilfunknetzen kann auch bei WLAN eine Näherungsmessung durchgeführt werden. Mit den RSS und SNR Werten kann die Basisstation mit höchster Signalqualität in Reichweite gewählt werden. Unter der Annahme, dass die Basisstation mit der höchsten Signalqualität am nächsten zum Empfänger gelegen ist und mit bekannter räumlicher Position der Basisstationen lässt sich die räumliche Position des Empfängers ermitteln. Lateration. Ausgehend von der Näherungsmessung kann auch bei WLAN eine Lateration durchgeführt werden. Dabei müssen mindestens drei Basisstationen in Reichweite sein. Der Abstand zu den Basisstationen wird über RSS und SNR Messung geschätzt. Eine Signal- Laufzeitmessung ist aufgrund der kurzen Distanzen bei WLAN nicht praktikabel. Fingerprinting. Fingerprinting zählt zu den Pattern-Matching-Methoden. Bei WLAN- Fingerprinting werden RSS-Muster an Referenzpunkten aufgezeichnet. Die Position der Referenzpunkte ist dabei bekannt und wurde über eine alternative Methode ermittelt. Die aufgezeichneten Muster werden zentral in einer Datenbank gespeichert. Bei der Positionsbestimmung wird wiederum ein RSS-Muster aufgenommen. Dieses wird über Pattern- Matching-Algorithmen mit den bestehenden Mustern in der Datenbank verglichen. Bei Korrelation kann die Position des dazugehörigen Referenzpunktes angenommen werden. Satelliten Positionsbestimmung Aktuelle Forschungen bemühen sich um die satellitengestützte Positionsermittlung in Gebäuden, im besonderen GPS. Das für Außenbereiche entwickelte GPS sendet relativ schwache Signale. In Gebäuden nimmt die Signalstärke durch Wände, Fenster und Türen weiterhin stark ab. Dadurch ist der Signal-Rausch-Abstand in Gebäuden sehr niedrig. Mit handelsüblichen GPS-Empfängern ist das Ermitteln einer Position damit unmöglich. Werden diese Empfänger modifiziert, sodass sie länger nach GPS-Signalen suchen, kann oftmals eine Position ermittelt werden. Die Zeit bis zum Ermitteln einer Position ist dabei jedoch unpraktikabel lang und eignet sich nur für statische Objekte. Durch die Kombination von vielen Empfängern, die auf unterschiedlichen Frequenzen hören, lässt sich diese Zeit verringern. In mobilen Endgeräten ist diese Technik noch nicht verfügbar. Das Alternativsysteme Glonass besitzt sehr ähnliche Eigenschaften, wodurch sich die gleichen Schlussfolgerungen für die Nutzung in Gebäuden ergeben. 18 Kapitel 2 Grundlagen

19 Indoor-Dead-Reckoning Für die Positionsbestimmung im Gebäude kommen häufig Dead-Reckoning Systeme zu Einsatz. Ihr Vorteil ist, dass sie komplett unabhängig von einer (Funk-) Infrastruktur im Gebäude sein können. Ausgehend von einer absoluten Position beim Betreten des Gebäudes, wird die Position im Gebäude relativ über die Modellierung der Bewegung der Person oder des Objekts errechnet. Dabei kommen unter anderem Beschleunigungssensoren und Gyroskope als Inertialsysteme zum Einsatz. Besonders in der Robotik ist dieser Ansatz verbreitet, da sich die Bewegungsmodelle von Robotern sehr exakt erstellen lassen. Dieser Ansatz wird in aktuellen Forschungen auf die Fußgängernavigation im Gebäude übertragen und mit WLAN-Lateration und -Fingerprinting kombiniert. Abseits der infrastrukturlosen Ansätze existieren auch Methoden zur Bestimmung der Position auf Basis einer dedizierten Infrastruktur: Positionsbestimmung mit NFC NFC ist ein Übertragungsstandard für die kabellose Kommunikation über kurze Distanzen. Radio Frequency Identification (RFID) ist eine dazugehörige Funktechnik. Sie wurde für die Identifikation von Objekten entwickelt und vor allem in der Warenverwaltung und Logistik eingesetzt. Die kurze Reichweite von meist nicht mehr als einigen Zentimetern ermöglicht passive und sehr kostengünstige Empfänger, genannt Tags. Mit diesen Tags lassen sich auch kostengünstige Infrastrukturen in Gebäuden realisieren, indem diese Tags an wichtigen Orten im Gebäude angebracht werden. RFID-Lesegeräte können über Näherungsmessung ihre (deskriptive) Position bestimmen. Wird bei der Positionsbestimmung eine räumliche Position benötigt, müssen die Referenzpunkte manuell eingemessen werden. Ultraschall und Infrarot Positionsbestimmung Ähnlich zu der Positionsbestimmung mit NFC-Tags lässt sich eine Positionsbestimmung mit Ultraschall- oder Infrarotsendern und -Empfängern durchführen. Durch die größeren Reichweiten ist eine Lateration oder das Fingerprinting von Vorteil, bedarf jedoch einer flächendeckenden Infrastruktur. Im Vergleich zu NFC ist eine genauere und kontinuierliche Positionsbestimmung möglich bei wesentlich höheren Installations- und Betriebskosten. 2.3 ZUSAMMENFASSUNG Die in diesem Kapitel vorgestellten Grundlagen ermöglichen einen Einblick in die Themen Crowdsourcing und (Indoor-) Positionsbestimmung. Besonders im Hinblick auf das Crowdsourcing lassen sich grundlegende Ansätze übernehmen. So wird im Verlauf der Arbeit ein Crowdsourcing- Konzept nach den Kategorien Crowdwisdom und gemeinsam eine freie Lösung erstellt werden, welches auch die hier vorgestellten Herausforderungen adressieren muss. Hinsichtlich der Positionsbestimmung wurden verschiedene Technologien für den Außen- und Innenbereich vorgestellt. Diese bilden die Grundlage für viele bestehende Navigationsanwendungen. In Kapitel 4 werden verwandte Arbeiten vorgestellt, welche diese Techniken anwenden. Dabei soll auch geklärt werden inwieweit diese Techniken als Grundlage für die vorliegende Arbeit dienen können. 2.3 Zusammenfassung 19

20 20 Kapitel 2 Grundlagen

21 3 ANFORDERUNGEN Ziel der Arbeit ist die Entwicklung einer Plattform zur Sammlung relativer Positionsdaten durch Crowdsourcing für die Erstellung eines Wegenetzgraphen. Die Wegenetzinformationen bilden die Grundlage für einen Navigationsassistenten, der die Zielführung über relative Positionen und Orientierungen realisiert. Der Einsatzbereich des Navigationsassistenten fokussiert sich speziell auf Gebäude, in denen eine absolute räumliche Positionierung schwierig ist. Die Aufgabenstellung setzt dabei folgende Kernpunkte: Anwendung von Crowdsourcing-Techniken Konzeption eines Clients für aktuelle Smartphones Entwicklung eines Prototyps für die ios Plattform Evaluation der Ergebnisse mit geeigneten Methoden Im Folgenden sollen diese Anforderungen genauer betrachtet und detaillierter spezifiziert werden. Dabei werden die Anforderung für Client und Server separat betrachtet. Die Anforderungen werden dazu jeweils in funktionale, nichtfunktionale und optionale Anforderungen unterteilt. 3.1 CLIENT Funktionale Anforderungen Der Client der Crowdsourcing-Plattform soll den Nutzern erlauben Pfade aufzuzeichnen, die diese zu Fuß in Gebäuden zurücklegen. Dabei informiert der Nutzer die Anwendung explizit über jeden Richtungs- und Stockwerkwechsel. Das bedeutet, dass der Client im Gehen bedient werden muss. Folglich sollte dieser eine hohe Mobilität aufweisen, um dem Nutzer den Umgang zu erleichtern. Das bedeutet eine intuitive Bedienbarkeit die geringe Aufmerksamkeit des Nutzers fordert. Aktuelle Smartphones sind generell klein und leicht genug für eine einhändige Bedienung, besitzen eine umfangreiche Sensorik und sind ausreichend leistungsstark für die Verarbeitung dieser Sensordaten. Zusammen mit den umfangreichen Entwicklungswerkzeugen ermöglichen sie die Entwicklung einer solchen mobilen Anwendung und sind somit eine geeignete Plattform. 21

22 Die Aufzeichnung von Wegstrecken soll jeweils durch die Eingabe eines Wegpunktes begonnen und beendet werden. Weg- oder auch Referenzpunkte bezeichnen Orte mit bekannter deskriptiver Position. Innerhalb von Gebäuden sind dies hauptsächlich Türschilder, Raumnummern oder QR- und Barcodes. Eine größere Anzahl von Referenzpunkten ermöglicht eine genauere Verschränkung der einzelnen Wegstrecken. Die mit der mobilen Anwendung aufgezeichneten Daten müssen an einen Server übertragen werden, welcher die Daten sammelt und aggregiert. Die funktionalen Anforderungen an den Client lassen sich wie folgend zusammenfassen. AC1 Entwicklung einer Anwendung für ein mobiles Endgerät mit aktueller Technik (Smartphone) AC2 Aufzeichnung von im Gebäude gegangenen Wegen durch Richtungseingaben des Nutzers AC3 Wegpunkt-Eingabe oder -Scan bei Aufzeichnungsbeginn und -Ende AC4 Stockwerkswechsel während der Aufzeichnung möglich AC5 Deskriptive Positions- und Orientierungsbestimmung der Referenzpunkte AC6 Upload der Wegstreckendaten nach der Aufzeichnung Nichtfunktionale Anforderungen Eine Reihe von nichtfunktionalen Anforderungen sind bei der Entwicklung und dem Betrieb der mobilen Anwendung von Bedeutung. Sie haben einen ähnlich hohen Stellenwert wie die funktionalen Anforderungen. So werden hohe Ansprüche an die Mobilität der Anwendung gesetzt. Die kognitive Belastung soll möglichst niedrig sein, damit die Anwendung auch während des Zurücklegens der alltäglichen Wege benutzt werden kann. Prinzipiell muss der Nutzer keine Wege speziell für diese Anwendung ablaufen. Um dies zu gewährleisten ist die Benutzerführung besonders ergonomisch zu gestalten. Eine hohe Usability fördert zudem die Zufriedenheit der Anwender, was im Besonderen bei dem vorliegenden Crowdsourcing-Konzept entscheidend ist. Neben der Usability sind weitere Anforderungen von hoher Relevanz. Die Anwendung sollte robust gegen Störungen gestaltet werden, im Speziellen bei Ausfällen der Netzwerkverbindung. Idealerweise werden diese Fehler vor dem Nutzer verborgen und beeinflussen nicht die Bedienung der Anwendung (geringe Fehlerrate). Für die Aufzeichnung der Wegstrecken soll keine zusätzliche Infrastruktur an Referenzpunkten, Sensoren und Sendern aufgebaut werden, da dies einen großen Aufwand und hohe Kosten [17] bedeuten würde und den Einsatz der Plattform erheblich einschränkt. Die Anwendung soll weitestgehend unabhängig von Rahmenbedingung sein und soll flächendeckend eingesetzt werden können. Das bedeutet auch die Unabhängigkeit von Flur- oder Gebäudeplänen. Durch den Crowdsourcing-Ansatz kommt die Nutzermotivation als Anforderung zum Tragen [7]. Der Anwender kann keinen direkten Nutzen aus der Anwendung ziehen. In erster Linie stellt er freiwillig Daten und Zeit zur Erstellung dieser Daten zur Verfügung. Die Nutzer sollen dabei nicht über Expertenwissen verfügen müssen. Es müssen Anreize geschaffen werden, um Personen zur Teilnahme zu motivieren. Dies ist ein komplexer Prozess und kann auf unterschiedlichen Wegen realisiert werden. Wichtig ist dabei die Ausarbeitung eines schlüssigen Konzeptes. Usability ist wiederum ein wichtiger Teil dieses Konzepts [7]. Die nichtfunktionalen Anforderungen an den Client lassen sich wie folgt zusammenfassen. ACN1 Hohe Usability ACN2 Robustheit gegen Netzwerkausfall ACN3 Geringe Fehlerrate ACN4 Motivation der Nutzer zum Aufzeichnen von Wegstrecken ACN5 Kein Expertenwissen bei der Bedienung nötig ACN6 Unabhängigkeit von spezieller Infrastruktur ACN7 Unabhängigkeit von Gebäude- und Flurplänen 22 Kapitel 3 Anforderungen

23 Abbildung 3.1: Client-Anforderungen Optionale Anforderungen Die Sammlung von Sensordaten während der Aufzeichnung von Wegstrecken kann hilfreich für die Aggregation und Navigation sein. Relevanz haben die Daten des Beschleunigungssensors für die Schritterkennung und -zählung [14]. Auch die räumliche Positionsbestimmung der Wegpunkte kann in manchen Umgebungen aussagekräftig sein (beispielsweise Wegpunkte nahe von Fenstern). Der Client könnte somit diese räumliche Positionsbestimmung in die Aufzeichnung integrieren. Die optionalen Client-Anforderungen lassen sich damit wie folgt zusammenfassen: ACO1 Sammlung und Auswertung von Sensordaten für die Schritterkennung- und -zählung ACO2 Absolute räumliche Positionsbestimmung der Wegpunkte als Teil der Aufzeichnung Tabelle 3.1 zeigt noch einmal alle Client-Anforderungen im Überblick. 3.2 SERVER Funktionale Anforderungen Der Server hat zwei Kernaufgaben. Zum einen muss er die vom Client übermittelten Daten in einem geeigneten Modell speichern. Zum anderen muss er die einzelnen Beiträge wertschöpfend verarbeiten. 3.2 Server 23

24 Damit der Client mit dem Server kommunizieren kann, muss eine passende Schnittstelle serverseitig angeboten werden, die es dem Client erlaubt aufgezeichnete Wegdaten an den Server zu übermitteln. Die empfangenen Daten müssen aufbereitet und persistent gespeichert werden. Bei der Verarbeitung der Crowdsourcing-Daten sind zwei Herausforderungen von Bedeutung [7]: Wie können die Informationen kombiniert werden, um die Zielstellung zu erfüllen? Wie können die Nutzer und ihre Beiträge evaluiert werden? Daraus ergeben sich Anforderungen an den Server: Es müssen die einzelnen Wegdaten der Nutzer zu einem Wegnetz aggregiert werden, welches als Basis für eine Navigation dienen kann. Bei der Aggregation der Daten muss der Server die Qualität der Daten bewerten. Die Wegdaten werden durch den Crowdsourcing-Ansatz von Laien erstellt und übermittelt. Dadurch ist die Qualität der Daten nicht gesichert. Es können unvollständige oder gar falsche Informationen übermittelt werden. Die als fehlerhaft erkannten Datensätze muss der Aggregationsmechanismus filtern, damit Nutzerbeiträge von minderer Qualität nicht die Qualität des gesamten Wegenetzes senken. Die funktionalen Anforderung an den Server lassen sich wie folgt zusammenfassen. AS1 Anbieten einer Schnittstelle zum Übermitteln von Wegdaten AS2 Persistentes Speichern der empfangenen Daten AS3 Bewertung der Aufzeichnungen AS4 Filtern von Beiträgen minderer Qualität AS5 Erstellung eines Wegenetzes aus einzelnen Teilstrecken (Aggregation) Nichtfunktionale Anforderungen Weiterhin gelten für den Server nichtfunktionale Anforderungen. Aufgrund der hohen Mobilität des Clients muss von einer Kommunikation über Mobilfunk ausgegangen werden. Dieser Kommunikationskanal ist von der Kapazität und dem Datendurchsatz eingeschränkt [28]. Zudem sind Funkverbindungen wesentlich störanfälliger als kabelgebundene Verbindungen. Dadurch entstehende Verluste bei der Datenübertragung verlangsamen die Verbindung zusätzlich [20]. In Gebäuden kann die Empfangsqualität besonders gering sein. Nach diesen Gesichtspunkten sollte ein kompaktes Datenformat und effizientes Kommunikationsschema eingesetzt werden. Um die Daten von vielen Nutzer und Gebäuden verwalten zu können muss der Server skalierbar gestaltet werden. Dies ist notwendig, da eine Instanz des Servers für eine Vielzahl von Gebäuden, d.h. global, genutzt wird. Folgend eine Zusammenfassung der nichtfunktionalen Anforderungen an den Server. ASN1 Effizienz bei der Kommunikation durch Einsatz von kompakten Protokollen und Datenformaten ASN2 Skalierbarkeit bei der Kommunikation zur Verwaltung von vielen Clients ASN3 Skalierbarkeit beim Persistieren und Aggregieren großer Datenmengen 24 Kapitel 3 Anforderungen

25 Abbildung 3.2: Server-Anforderungen Optionale Anforderungen Auf der Serverseite existieren zusätzlich zu den funktionalen und nichtfunktionalen Anforderungen ein paar optionale Anforderungen. So ist eine Gamification-Integration wünschenswert. Bei der Aggregation könnte somit auf die Rangliste zugegriffen werden, um die Bewertung der Nutzer zu verbessern. Auch kann so eine bessere Auswertung der übermittelten Aufzeichnungen vorgenommen werden, beispielsweise die Erkennung und Benachrichtigung über bestätigte Aufzeichnungen. Weiterhin ist eine Visualisierung der Aufzeichnungen und Pfade wünschenswert, zur Veranschaulichung der Wissensbasis für die Navigation Die optionalen Server-Anforderungen lassen sich damit wie folgt zusammenfassen: ASO1 Integration der Gamification-Komponenten ASO2 Visualisierung von Aufzeichnungen und Pfaden Tabelle 3.2 zeigt noch einmal alle Server-Anforderungen im Überblick. 3.3 ABGRENZUNG Im Rahmen der Entwicklung eines Prototyps haben einige Softwareaspekte einen geringeren Stellenwert. Diese Punkte sollen nicht als Anforderungen aufgenommen werden, haben jedoch Relevanz für eine Produktiv-Implementierung des Konzepts. Sicherheit ist von genereller Relevanz. Durch den Einsatz von drahtloser Kommunikation und deren Abhörbarkeit [28] wird die Bedeutung von Sicherheit weiter gesteigert. Die Rohdaten von Nutzern sollten für andere Nutzer nicht modifizierbar sein. Persönliche Details von Nutzern sollten nicht für andere einsehbar sein. Auch sollte kein Nutzer in der Lage sein unerlaubt Daten im Namen von anderen Nutzern zu übermitteln. Insgesamt wahrt dieses Vorgehen auch die Integrität der Daten. Bei der Sammlung von umfangreichen Nutzer- und Bewegungsdaten spielt die Anonymisierung dieser Daten eine Rolle. Besonders im produktiven Einsatz sollte diese Anonymisierung durchgeführt werden, um eine Nutzerüberwachung auszuschließen. Im Rahmen der Entwicklung eines Prototyps spielt dies wiederum eine untergeordnete Rolle. Der Umfang der gesammelten Daten 3.3 Abgrenzung 25

26 ist wesentlich geringer und diese Daten werden nicht über einen längeren Zeitraum gespeichert. Durch die geringere Nutzeranzahl kann zudem besser über den Umgang mit den Daten aufgeklärt werden. Bei einem produktiven Einsatz des Servers sollte die Serverinfrastruktur eine hohe Erreichbarkeit und Stabilität besitzen, damit sich Systemausfälle nicht negativ auf die Nutzererfahrung auswirken und die Nutzerbeteiligung senken. Die Performanz der Servers ist nicht generell von hoher Bedeutung. Ein Großteil der Kommunikation kann asynchron oder gar verzögert stattfinden, sodass der Nutzer Latenzen und längere Übertragungszeiten nicht wahrnimmt. Prozesse, bei der Anwender blockiert werden, sollten jedoch innerhalb einer Sekunde verarbeitet werden [23]. Für einen reibungslosen Betrieb und die Fehlerbehandlung muss vor allem der Server Wartbarkeit aufweisen, beispielsweise durch Monitoring und Backup-Mechanismen. Im produktiven Einsatz kommt der Korrektheit bei Erstellung des Wegenetzes eine größere Bedeutung zu. Filtermechnismen sollten sich an die Anzahl der Nutzer anpassen. Durch eine größere Nutzerzahl ist mit einer höheren Redundanz an Wegstreckendaten zu rechnen. Erst diese Redundanz ermöglicht die automatische Erkennung von fehlerhaften Daten. Beiträge sollten generell von unterschiedlichen Nutzern explizit oder implizit durch das Einsenden übereinstimmender Wegstrecken bestätigt werden. 26 Kapitel 3 Anforderungen

27 4 VERWANDTE ARBEITEN In diesem Kapitel werden verwandte Arbeiten vorgestellt, welche eine ähnliche Zielstellung besitzen wie die vorliegende Arbeit oder Teilprobleme des Konzeptes adressieren. Im Vergleich wird dabei das Gesamtkonzept aus Crowdsourcing und Navigation betrachtet [37]. Dabei werden die Arbeiten thematisch abgrenzt und innerhalb einer Kategorie verglichen. Abschließend wird geklärt, inwieweit Konzepte für die vorliegende Arbeit (CINA) übernommen werden können. 4.1 INDOOR-POSITIONIERUNG UND -NAVIGATION In diesem Abschnitt werden Arbeiten vorgestellt, welche das Thema Indoor-Positionierung und Indoor-Navigation auf unterschiedliche Weise adressieren. A Hybrid Indoor Navigation System Butz et al. [4] befassten sich mit verschiedenen Techniken zur Nutzerführung während der Fußgängernavigation im Gebäude. Dabei werden die technischen Möglichkeiten des Endgeräts, die vorliegende Datenbasis sowie die örtlichen Gegebenheiten im Gebäude für eine adaptive Navigation betrachtet. In der Arbeit wird das Navigationssystem und der Nutzer als Einheit beschrieben, die sich gegenseitig ergänzen. Wenn das Navigationssystem Kenntnisse über den Standort und die Orientierung des Nutzer hat, kann dieses den Nutzer bei Neuorientierung unterstützen. Solltem dem Navigationssystem jedoch nur vage oder keine Informationen vorliegen, so müssen dem Nutzer entsprechende Informationen mitgeteilt werden, nach denen er sich selber orientieren kann. So zeigt die Arbeit, dass eine Navigation auch ohne kontinuierliche Positionsermittlung erfolgen kann, wenn bei der Nutzerführung die richtige Präsentation verwendet wird. Besonders von Bedeutung sind die in der Arbeit getroffenen Aussagen für die Nutzerführung bei der Navigation in CINA [37]. 27

28 Indoor Infrastructure-less Solution based on Sensor Augmented Smartphone for Pedestrian Localisation Die Arbeit von Trehard et al. [36] befasst sich mit der Herausforderung der räumlichen Positionsbestimmung für Fußgänger im Gebäude. Dabei wurde ein Dead-Reckoning-System für Smartphones entwickelt, welches eine relative Position berechnet, basierend auf der Bewegung, ausgehend von einem Ort mit bekannter räumlicher Position. Zur Steigerung der Genauigkeit wurde zu den eingebauten Sensoren ein externes Anemometer genutzt, welches an das Smartphone angebracht wurde. Damit wurde unter optimalen Bedingungen eine gute Genauigkeit von zwei bis vier Metern erreicht. Durch die Charakteristik von Dead-Reckoning-Systemen sinkt die Genauigkeit stark bei längeren Wegen. Die Autoren gaben in diesem Fall eine Genauigkeit von 7 bis 49 Metern an, was grenzwertig für eine verlässliche Navigation ist. Diese Arbeit zeigt, mit welcher Technik und Genauigkeit eine infrastrukturlose Positionsbestimmung im Gebäude mit einem weitverbreiteten mobilem Endgerät möglich ist. Dies kann den Grundstein für die räumliche Aufzeichnung von Wegstrecken in Gebäuden bilden, was eine Kernanforderung des Konzepts der vorliegenden Arbeit darstellt. Eingeschränkt wird dies jedoch durch die Zuhilfenahme von speziellen Sensoren und die geringere Genauigkeit auf langen Wegen. Development of an Indoor Navigation System Using NFC Technology Ozdenizci et al. [26] beschreiben ein Indoor-Navigationsystem mit einer NFC-Infrastruktur. In dieser verwandten Arbeit erfolgt die Nutzerführung während der Navigation mit Hilfe von Referenz- NFC-Tags. Der Nutzer ermittelt seine Position durch das Berühren dieser Tags mit einem NFCfähigen Endgerät, wie Smartphones (vgl. RFID-Positionsbestimmung in Kapitel 2). Dabei werden räumliche Positionen verwendet. Nach expliziter Eingabe des Ziel, erfolgt eine Routenberechnung. Diese Route wird auf dem Endgerät auf Basis einer Karte präsentiert. Die Kartendaten werden dazu von einem Kartenserver auf das Endgerät geladen. Während der Navigation kann sich der Nutzer an anderen Tags neu orientieren, welche an vielen Orten im Gebäude installiert sind. Eine kontinuierliche Positionsbestimmung erfolgt nicht. Insgesamt stellen Ozdenizci et al. [26] eine vergleichsweise günstige Plattform vor, welche dabei jedoch nicht gänzlich infrastrukturlos arbeitet. Kartendaten müssen von Experten erstellt und bereit gestellt werden. NFC-Tags müssen installiert und eingemessen werden. Positiv hervorzuheben ist die Unabhängigkeit von Sensordaten mit schwankender Genauigkeit, wodurch die Robustheit stark verbessert wird. I 2 Navi An Indoor Interactive NFC Navigation System for Android Smartphones Das I 2 Navi [5] verfolgt einen sehr ähnlichen Ansatz wie Ozdenizci et al. [26]. So wurde ein kostengünstiges Indoor-Navigationssystem mit einer NFC-Tag-Infrastruktur implementiert. Sowohl die Architektur als auch der Programmablauf sind nahezu identisch. So ergeben sich die gleichen Vor- und Nachteile. Wie bei Ozdenizci et al. [26] wurden auch in dieser Arbeit verschiedene Techniken zur Positionsbestimmung im Gebäude evaluiert, wobei vergleichbare Schlussfolgerungen wie in Kapitel 2 gezogen wurden. 28 Kapitel 4 Verwandte Arbeiten

29 SiRFstarV CSR entwickelt mit SiRFstarV [6] einen hybriden Sensor für die Outdoor- und Indoor- Positionsbestimmung in mobilen Endgeräten. Neben der direkten Positionsbestimmung über GPS und Glonass wird ein virtueller Sensor implementiert. Dieser virtuelle Sensor fusioniert mehrere physikalische Sensoren (GPS, GLONASS, WLAN, MEMS) und Positionierungstechniken (Triangulation, Dead-Reckoning, Fingerprinting). Daraus wird eine globale Schnittstelle für die Anwendungsentwicklung bereit gestellt. Die Genauigkeit und Verlässlichkeit dieses neuen Sensors muss jedoch noch gezeigt werden, wenn die ersten Endgeräte mit diesem ausgestattet werden. Bei ausreichender Genauigkeit könnten traditionelle Navigationsansätze basierend auf räumlichen Positionen für die Indoor-Navigation genutzt werden, ohne eine teure Infrastruktur für die Positionierung im Gebäude aufbauen zu müssen. Bislang kann jedoch nicht darauf zurück gegriffen werden, sodass das Konzept von CINA keine kontinuierliche räumliche Positionsbestimmung der Nutzer vorsieht. Google Indoor Maps Google arbeitet mit Google Indoor Maps an einer eigenen Lösung für die Indoor-Navigation [13]. Die Indoor-Navigation wird dabei in die bestehende Karten- und Navigtionsanwendung Google Maps integriert. So werden die Konzepte zur Nutzerführung weitestgehend von der bestehenden Plattform übernommen. Auch bei Google Indoor Maps wird das Kartenmaterial von Experten erstellt und für die Navigation aufbereitet. Die Positionierung erfolgt mit Hilfe von GPS/Glonass und Wifi. Dadurch ist die Genauigkeit sehr stark von den lokalen Begebenheiten abhängig und oftmals nicht ausreichend genau. 4.2 SIMULTANEOUS LOCALIZATION AND MAPPING Simultaneous Localization and Mapping (kurz SLAM) ist eine Methode zur Positionsbestimmung von Objekten und gleichzeitiger Kartographie. Dieser Ansatz hat seinen Ursprung in der Robotik bei der autonomen Steuerung von Robotern und Fahrzeugen. Aktuelle Forschungen versuchen den Ansatz auf die Fußgängernavigation im Gebäude zu projizieren. Eine große Herausforderung ist dabei die Bewegungsmodellierung des Nutzers. Wo Roboter aufgrund ihrer Fortbewegungsweise (beispielsweise Räder oder Ketten) sehr genau ihre Pose bestimmen können, ist die Bewegung von Menschen wesentlich komplexer und weniger einheitlich. Folgend werden dazu zwei Forschungen vorgestellt: WiSlam & GraphSLAM Bruno [3] und Robertson [27] forschten an einer SLAM-Technik für Fußgänger im Gebäude. Das Konzept sieht vor, dass der Nutzer einen Intertial-Sensor am Fuß befestigt. Dieser liefert wesentlich rauschfreiere Daten als ein (in der Hand gehaltenes) Smartphone derzeit kann. Kombiniert mit Wifi-RSS-Messungen kann der Drift bei der Bewegungsmodellierung minimiert werden, was zu einer für die Indoor-Navigation guten Genauigkeit in der Testumgebung führt. Die Kartenerstellung wird über ein Bayessches Netz abgeschätzt. Durch den Einsatz von spezieller Sensorik, ist WiSLAM jedoch nur bedingt für das Crowdsourcing geeignet. 4.2 Simultaneous Localization and Mapping 29

30 GraphSLAM [19] implementiert einen vergleichbaren Ansatz und erreicht eine Genauigkeit zwischen 1,75 m und 2,18 m unter optimalen Bedingungen. Dabei kommt jedoch kein weit verbreitetes mobiles Endgerät (Smartphone) zum Einsatz und ist dadurch ebenfalls für das Crowdsourcing nur bedingt geeignet. Die vorgestellten Forschungen zu Indoor-SLAM zeigen unter welchen Rahmenbedingungen eine räumliche Positionsbestimmung bei gleichzeitiger Kartographie möglich ist. Es lässt sich manifestieren, dass diese Techniken nicht flächendeckend eingesetzt werden können, ohne den Einsatz spezieller Endgeräte / Sensoren oder eine optimale Funknetz-Infrastruktur. 4.3 CROWDSOURCING Während sich die bisher vorgestellten Arbeiten vorwiegend mit der Positionsbestimmung und Navigation im Gebäude befassen, werden nachfolgend verwandte Arbeiten mit Crowdsourcing- Ansätzen vorgestellt. Diese stellen einen engeren Bezug zu der eigenen Arbeit her. Open Street Map Open Street Map (OSM) [15] ist eine der größten Crowdsourcing-Plattformen im WWW. Das Ziel ist eine globale Kartographie. Dabei wird das Konzept der freien gemeinsamen Lösung verfolgt. Das erzeugte Kartenmaterial ist somit frei zugänglich. Damit werden kartenbasierte Anwendungen für kleine Unternehmen und non-profit Organisationen möglich, die sich den Einkauf von professionell erstellten Karten nicht leisten können. Durch die große Menge an Nutzern und auf Grund des dynamischen Charakters der Plattform sind die Kartendaten oftmals aktueller als professionelle Karten. Auf der anderen Seite existieren weiße Flecken, die nicht kartographiert wurden sowie Falschinformationen. Die Qualität der Daten ist prinzipiell schwankend und oft unbekannt. Neben der manuellen Kartographie mit einen Karteneditor, ist eine (teil-) automatische Erstellung von Karten, ausgehend von Luftbildern möglich. Zusätzliche Metadaten werden als Schlüssel-Wert-Paare annotiert. Alle geographischen Entitäten werden als Knoten betrachten, besitzen eine räumliche Position. Flächen oder Pfade werden als Liste von Knoten gespeichert und werden Wege genannt. Crowdsourcing wird ebenfalls für das Offline-Rendering von Kartendaten angewandt (Tiles@Home). So wird die Rechenlast auf viele Nutzer verteilt. Öffentliche Treffen und Veranstaltungen tragen zur Nutzerbeteiligung bei. Open Street Map zeigt, dass es möglich ist, globale Kartendaten mit Crowdsourcing zu erzeugen. Auch wird der Charakter von Crowdsourcing-Daten deutlich. Bislang ist OSM für Außenbereiche konzipiert und es existieren nur wenige Daten zu Gebäuden. Durch den strengen Fokus auf räumliche Positionsdaten in Kombination mit einer schwachen räumlichen Positionsbestimmung im Gebäude ist es für die Indoor- Navigation nur sehr begrenzt geeignet. An einer Erweiterung von OSM für Bereiche innerhalb von Gebäuden wird bereits geforscht. [10]. Weiterhin existieren Outdoor-Navigationslösungen basierend auf OSM [25]. Waze Waze [31] verfolgt einen anderen Crowdsourcing-Ansatz als OSM. Ziel der Plattform ist, es dem Autofahrer eine intelligente Auto-Navigation anzubieten, die aktuelle Verkehrs- und Straßenbedingungen berücksichtigt. Waze stellt dazu eine Anwendung für Smartphones bereit. Während der Fahrt sammelt die Anwendung Daten zur Erstellung eines Bewegungsprofils. Durch den Abgleich der Bewegungsdaten vieler Nutzer lassen sich Korrelationen und damit Verkehrsstörungen 30 Kapitel 4 Verwandte Arbeiten

31 in Echtzeit erkennen, die folglich von anderen Waze-Nutzern umgangen werden können. Neben dieser impliziten Form des Crowdsourcing, haben die Nutzer auch die Möglichkeit während der Fahrt explizit Staus, Baustellen, usw. zu markieren. Außerdem können die Nutzer das Kartenmaterial in einem Web-Editor bearbeiten. Im Unterschied zu OSM unterliegt das Kartenmaterial jedoch keiner freien Lizenz und basiert auf professionell erstellten Karten. Zur Steigerung der Nutzermotivation wurde ein Gamification-System mit Rängen integriert. Insgesamt wurde dieses Navigationssystem speziell für die Navigation auf der Straße konzipiert und optimiert. Es zeigt jedoch auch, dass und wie eine Navigationslösung auf Crowdsourcing-Basis funktionieren kann. Google Map Maker Mit Google Map Maker [12] öffnet Google seinen Kartendienst für Ergänzungen von Privatpersonen. Damit erreicht Google Maps Crowdsourcing-Charakter. Die Schnittstelle dazu ist ein online Karteneditor, vergleichbar mit Waze und OSM. Wie bei Waze wird das Kartenmaterial jedoch nicht frei zur Verfügung gestellt. Die Änderungen von Privatnutzern sind dabei nur Vorschläge die nach einem Review-Prozess in das Kartenmaterial übernommen werden. Bislang lassen sich mit Google Map Maker nur Außenbereiche editieren. 4.4 MAPBIQUITOUS Die Plattform Mapbiquitous [33] verfolgt ähnliche Ziele wie CINA. Es ist ein integriertes System für Location-Based-Services im Außen- und Innenbereich. So implementiert es auch eine Indoor- Navigation. Gebäudedaten (Grundrisse, Daten für die Navigation) werden nicht durch Crowdsourcing erzeugt, sondern werden nach offenen Standards von Gebäudedatenservern geladen. Dabei werden existierende Kartendaten für Außenbereiche mit dem Grundriss überlagert. Die Positionierung erfolgt über GPS in Kombination mit Wifi-Fingerprinting und einem Dead-Reckoning- Algorithmus. Implizites Crowdsourcing wird bei der Plattform zur Verbesserung der Gebäudedaten und GSM-Fingerprinting benutzt [16]. Explizites Crowdsourcing kommt für eine manuelle Korrektur der Positionsbestimmung zum Einsatz [2]. Zusammengefasst stellt Mapbiquitous eine umfangreiche Lösung für Location-Based-Services im Innen- und Außenbereich für Smartphones zur Verfügung. Grenzen gibt es jedoch hinsichtlich der Genauigkeit der Positionsbestimmung in Gebäuden und durch die Abhängigkeit von Gebäudedatenservern. 4.5 ZUSAMMENFASSUNG Nachdem in diesem Kapitel einige verwandte Arbeiten vorgestellt wurden, soll abschließend geklärt werden, inwiefern deren Konzepte in der vorliegenden Arbeit verwendet werden können. Dazu werden die Arbeiten in Tabelle 4.1 gegenübergestellt. Die Arbeiten zur Indoor-Positionsbestimmung und -Navigation betonen nach den Grundlagen noch einmal die Herausforderungen bei der räumlichen Positionsbestimmung in Gebäuden. Dabei schafft es keine dieser Arbeiten ein Indoor-Positionsermittlung zu entwickeln, die sich als Grundlage für das Konzept von CINA eignet. Es existieren Einschränkungen durch die Wahl der Hardware, teure Infrastrukturen oder mangelnde Genauigkeit. Daher wird CINA keine räumliche Positionsbestimmung als Grundlage haben. 4.4 Mapbiquitous 31

32 Dem entgegen steht das Crowdsourcing. In diesem Kontext sind die Ansätze etablierter Plattformen hilfreich für die Erstellung eines eigenen Crowdsourcing-Konzepts. OSM zeigt vor allem, dass globale Crowdsourcing-Projekte auf Basis von Freiwilligen und Laien funktionieren können. Insoweit wird dieses Konzept von CINA übernommen. Durch die verschiedenen Arbeiten wird jedoch auch die Aggregation als Herausforderung betont, der somit in CINA eine wichtige Rolle zukommt. Bei MapBiquitous kommen explizite und implizite Crowdsourcing-Verfahren zum Einsatz. Diese beiden Ansätze sollen auch im CINA-Konzept betrachtet werden. Letztendlich ist der Ansatz von CINA eigenständig und grenzt sich stark von den bestehenden Plattformen ab, welche entscheidende Einschränkungen besitzen. Daher wird CINA als neue Plattform von Grund auf entwickelt und kann so speziell auf die Anforderungen zugeschnitten werden. 32 Kapitel 4 Verwandte Arbeiten

33 Abbildung 4.1: Auswertung der verwandten Arbeiten 4.5 Zusammenfassung 33

34 34 Kapitel 4 Verwandte Arbeiten

35 5 KONZEPT Dieses Kapitel stellt das Gesamtkonzept der Crowdsourcing-Plattform vor. Im Besonderen wird darauf eingegangen, wie die im vorausgegangenen Kapitel 3 gestellten Anforderungen erfüllt werden können. Nach einer Begriffsklärung wird zu Beginn des Kapitels die Crowdsourcing- Charakteristik und ihre Besonderheiten dargelegt. Nachfolgend wird das Konzept anhand der drei Komponenten: Client, Server und Gamification detailliert erläutert. 5.1 BEGRIFFSKLÄRUNG Nachdem zu Beginn dieser Arbeit bereits spezifische Begriffe des Konzepts verwendet wurden, sollen diese nun klar definiert werden. Wegpunkt: Ein Wegpunkt ist ein Ort mit bekannter deskriptiver Position, beschrieben durch einen im Gebäude eindeutigen Namen. Damit sind Wegpunkte gleichzeitig Referenzpunkte für die Navigation im Gebäude. Ein Wegpunkt ist genau einem oder keinem Gebäude zugeordnet. Kreuzungspunkt: Ein Kreuzungspunkt ist ein Ort auf der Wegstecke, an dem sich mehrere Wege treffen. Eine Anweisung gibt für einen Kreuzungspunkt an, für welchen Weg sich an dem Kreuzungspunkt bei der Aufzeichnung entschieden wurde. Die Position von Kreuzungspunkten ist nicht bekannt, dadurch unterscheiden sich Kreuzungspunkte von Wegpunkten. Anweisung: Eine Anweisung beschreibt eine Richtungs- oder Bewegungsangabe: geradeaus, links, rechts, Treppe hoch, Treppe runter. Eine Anweisung bezieht sich jeweils auf einen Kreuzungspunkt oder einen Wegpunkt. Wegstrecke: Eine Wegstrecke beschreibt den physikalischen Weg von einem Startwegpunkt zu einem Zielwegpunkt durch eine geordnete Liste von Anweisungen. Durch Folgen der Anweisungen gelangt man vom Startwegpunkt zum Zielwegpunkt. Wegstrecken werden als unidirektional aufgefasst, solange die Bidirektionalität nicht explizit durch einen Nutzer bestätigt wurde. 35

36 Aufzeichnung: Eine Aufzeichnung beschreibt die Erstellung der geordneten Liste von Anweisungen für eine Wegstrecke. Der Begriff Aufzeichnung bezeichnet ebenso das Resultat dieses Prozesses. übereinstimmende Aufzeichnungen: Besitzt eine Aufzeichnung denselben Start- sowie Endwegpunkt und die identische Abfolge von Anweisungen, so stimmt die Aufzeichnung mit einer anderen Aufzeichnung überein. bestätigte Aufzeichnung: Existiert für eine Aufzeichnung mindestens eine übereinstimmende Aufzeichnung, so wird die Aufzeichnung als bestätigt bezeichnet. Pfad: Ein Pfad ergibt sich aus der Aggregation von Aufzeichnungen und bildet die Grundlage für die Routenberechnung bei der Navigation. Wie eine Aufzeichnung wird ein Pfad durch Start- und Zielwegpunkt sowie eine geordnete Liste von Anweisungen beschrieben. Route: Eine Route wird durch einen Startwegpunkt und einen Endwegpunkt sowie eine geordnete Liste von Pfaden definiert. Sie beschreibt so einen (längeren) Weg im Gebäude, auf dem mehrere Wegpunkte passiert werden können. Eine Route bildet die Grundlage für die Wegführung bei der Navigation. CINA: CINA ist ein Akronym für Crowdsourced Indoor Navigation Assistant und bezeichnet die in dieser Arbeit beschriebene Crowdsourcing-Plattform. CINA schließt auch die parallel laufende Masterarbeit von Wang [37] ein. 5.2 ÜBERBLICK Bevor die Einzelheiten des Konzepts geklärt werden, wird an dieser Stelle ein Gesamtüberblick präsentiert. Dadurch soll der Zusammenhang der einzelnen Bausteine veranschaulicht werden. Dreh- und Angelpunkt des Konzepts ist das Crowdsourcing. Durch die Wahl dieses Ansatzes wird der Charakter der Plattform maßgeblich geprägt. Ziel des Crowdsourcing-Prozesses ist die Erstellung einer Wissensbasis für die Fußgänger-Navigation im Gebäude. Der nötige Aufwand für die Konzeption dieses Prozesses lässt sich in drei Arbeitsschritte einteilen. Schritt eins: Das Crowdsourcing-Konzept. Zu Beginn des Konzepts muss der Umfang und die Regeln des Crowdsourcings definiert werden. Dabei helfen die vier Fragen aus dem Grundlagen- Kapitel (2): Wie werden Nutzer angeworben und gehalten? Was können die Nutzer beitragen? Wie können die Nutzer und ihre Beiträge bewertet werden? Wie können die Beiträge kombiniert werden, um das Crowdsourcing-Ziel zu erreichen? Diese Fragen sollen im Laufe des nächsten Abschnitts geklärt werden. Schritt zwei: Die Systemarchitektur. Um das Crowdsourcing möglich zu machen, muss eine Plattform konzipiert werden. Bei dieser Plattform findet das Crowdsourcing an denselben Orten wie die dadurch ermöglichte Navigation statt. Damit geht die Notwendigkeit eines mobilen Endgeräts einher, auf welchem die Beiträge der Nutzer erstellt werden. Die Crowdsourcing-Nutzer bewegen sich mit je einem Endgerät durch ein ihnen bekanntes Gebäude. Dabei zeichnen sie die gegangenen Wegstrecken auf. Dies geschieht durch das Angeben von Start- und Zielwegpunkt und einer sukzessiven Kennzeichnung der Kreuzungen durch das Eingeben von Richtungsanweisungen. Damit ergibt sich eine Client-Server-Architektur. Der Client ermöglicht das Aufzeichnen der Wegstrecken und übermittelt diese an den Server. Der Server speichert die eingehenden Nachrichten und verarbeitet diese. Erweitert wird diese Architektur von einem Gamification-Server, der optional die Nutzer als Spieler verwaltet und damit für eine höhere Motivation sorgen soll. Diese Architektur wird im weiteren Verlauf des Kapitels genauer vorgestellt. 36 Kapitel 5 Konzept

37 Schritt drei: Der Arbeitsfluss. Der bereits in Schritt zwei zur Sprache gekommene Arbeitsfluss wird im letzten Arbeitsschritt genauer definiert. Dabei wird der Programmablauf auf Client- und Server-Seite festgelegt. Es werden auch die Schnittstellen zwischen den Komponenten geschaffen und dafür geeignete Protokolle ausgewählt. Aus diesen drei Schritten vervollständigt sich das Konzept, welches in den folgenden Abschnitten konkretisiert wird. 5.3 CROWDSOURCING Durch den Crowdsourcing-Ansatz bei der Erstellung der Wissensbasis für die Navigation ergeben sich besondere Anforderungen und Herausforderungen. Das Crowdsourcing-Konzept wird anhand der Schlüsselherausforderungen für Crowdsourcing-Plattformen erarbeitet, welche in Kapitel 2 vorgestellt wurden Was können die Nutzer beitragen? Die erste Anforderung bedingt die Definition der Entitäten für den Crowdsourcing-Workflow. Anders ausgedrückt: Welche Daten können die Nutzer beitragen? Die Beantwortung dieser Frage wird getrennt nach expliziten und impliziten Beiträgen betrachtet. Explizit Explizite Beiträge beziehen sich auf die aktive Bereitstellung von Informationen. Der Nutzer ist sich dabei bewusst, dass neues Wissen erzeugt wird. Das Konzept umfasst folgende Arten von aktiven Beiträgen: Scan von Wegpunkten Eingabe von Richtungsanweisungen an Wegpunkten und Kreuzungen im Rahmen einer Aufzeichnung Metadaten zu Wegpunkten (Typ und Gebäude) Implizit Implizite Beiträge sind vor dem Nutzer verborgen und geschehen im Hintergrund als Reaktion auf Aktionen vom Nutzer. Im Konzept sind folgende implizite Beiträge vorgesehen: Speicherung/Auswertung von Daten der Inertialsensoren während der Aufzeichnung für die Schritterkennung/ -zählung und Bewegungsmodellierung Optionale Aufzeichnung räumlicher Positionsdaten der Wegpunkte, sofern diese mit den Sensoren des mobilen Geräts ermittelbar sind Bestätigung von Aufzeichnungen durch Prüfen auf übereinstimmende Aufzeichnungen anderer Nutzer Die insgesamt sechs Arten von Beiträgen gehen allesamt mit der Aufzeichnung von Wegstrecken einher. Der mobile Client wird somit als Single-Purpose-Anwendung konzipiert. 5.3 Crowdsourcing 37

38 5.3.2 Evaluation der Beiträge Durch den Einsatz von Laien als Produzenten, ist die Qualität der Aufzeichnungen nicht garantiert und kann stark schwanken. Daher ist es nötig die Beiträge der Nutzer zu evaluieren, bevor sie weiter verwendet werden. Die Bewertung erfolgt nach einer Aufzeichnung und nach mehreren Kriterien. Grundsätzlich ist die Bewertung einer Aufzeichnung abhängig von der Bewertung des Nutzers, welcher sie erstellt hat, wobei sich die Bewertung eines Nutzers wiederum aus den Bewertungen seiner vorangegangen Aufzeichnungen ergibt. Bei der Evaluation einer Aufzeichnung wird auf übereinstimmende Aufzeichnungen anderer Nutzer geprüft. Existieren übereinstimmende Aufzeichnungen, so verbessert sich die Bewertung der Aufzeichnung. Dient eine Aufzeichnung als Grundlage für eine Navigation, so sieht das Konzept eine Aufwertung der Aufzeichnung bei erfolgreicher Navigation vor. Eine Abwertung von Nutzern und deren Beiträgen über die Zeit findet nicht statt. Das Wegenetz wird im Konzept als statisch aufgefasst. Damit benötigen Aufzeichnungen keine Halbwertszeit hinsichtlich ihrer Bewertung. Bei identischer Bewertung zweier Aufzeichnungen mit den selben Start- Zielwegpunkten kann jedoch die aktuellere Aufzeichnung bevorzugt werden. Zusammenfassend ergibt sich daraus folgende Formel für die Bewertung einer Aufzeichnung: R(u) = A + 2 A c R(a) = R n + A i c R(u) = Bewertung des Nutzers R(a) = Bewertung der Aufzeichnung A = Menge der eingesendeten Aufzeichnungen A c = Menge der bestätigten Aufzeichnungen des Nutzers A i c = Menge der übereinstimmenden Aufzeichnungen R n = Navigationsbewertung der Aufzeichnung Die Bewertung der Nutzer besteht aus zwei Teilen. Den quantitativen Anteil stellt die Anzahl der Aufzeichnungen des Nutzers dar. Der Nutzer soll für die Bemühungen bei den Aufzeichnungen belohnt werden, sodass jede einzelne Aufzeichnung die Bewertung steigert. Der qualitative Anteil ist die Anzahl der bestätigten Aufzeichnungen des Nutzers. Für diese Aufzeichnungen kann man Aussagen über die Qualität machen. Aus diesem Grund gehen diese doppelt in die Bewertung ein. Die Bewertung aus der Aufzeichnung besteht ebenso aus zwei Teilen. R n ist die Summe aus den Bewertungen der Navigationen bei denen diese Aufzeichnung verwendet wurde. Dies kann somit einen positiven oder negativen Wert haben. Der zweite Teil ist die Anzahl der übereinstimmenden Aufzeichnungen. Die Summanden haben qualitativen Charakter und bekommen damit keine zusätzliche Gewichtung. Nach diesen Formeln existiert kein oberer Grenzwert für die Bewertungen der Nutzer und Aufzeichnungen. Bei Bedarf können die Bewertungen jedoch jederzeit normiert werden. Die Gewichtung der Summanden in den Formeln stellt jeweils nur einen Ausgangspunkt dar. Die optimale Berechnung und Gewichtung ist nicht trivial und lässt sich nur durch eine extensive Evaluation ermitteln, was aus Gründen der Forschungseffizienz nicht Teil dieser Arbeit ist. 38 Kapitel 5 Konzept

39 Abbildung 5.1: Ablauf der Aggregation 5.3 Crowdsourcing 39

40 Aggregation der Beiträge Die größte Herausforderung im Crowdsourcing-Prozess ist das Zusammenführen der einzelnen Beiträge und die damit einhergehende Konfliktlösung. Diese Zusammenführung wird als Aggregation bezeichnet. Das Ziel der Aggregation ist das Erstellen einer Wissensbasis für die Navigation. Die einzelnen Wegstrecken in Form von Aufzeichnungen werden dabei in einen Graphen überführt. Der Graph beinhaltet dabei eine Menge von Pfaden. Diese Pfade sind zusammengefasste Aufzeichnungen mit dem entsprechenden Start- und Zielwegpunkt. Die Aggregation beinhaltet mehrere Teilprozesse. Aufzeichnungen minderer Qualität werden gefiltert und nicht in die Wissensbasis aufgenommen. Übereinstimmende Aufzeichnungen werden zusammengefasst und die Wissensbasis übernommen. Zudem findet eine Konfliktlösung bei konträren Aufzeichnungen statt. Für die Aggregation von Aufzeichnungen gelten folgende Regeln. (I). Die Mengen von Aufzeichnungen mit der Kardinalität A = 1 für einen gegebenen Start- und Zielwegpunkt werden als Pfad in den Graph übernommen. (II). Für Mengen von übereinstimmenden Aufzeichnungen mit der Kardinalität A > 1 für einen gegebenen Start- und Zielwegpunkt werden alle bestätigten Aufzeichnungen in den Graph übernommen. (III). Bestätigte Aufzeichnungen werden gruppiert und in einen Pfad vereinigt. (IV). Bei der Vereinigung in Regel (III) werden die Laufzeiten für jede Anweisung als arithmetisches Mittel berechnet. Die Bewertung eines Pfades berechnet sich aus folgender Formel. R(p) = U u=0 R(u) + A a=0 R(a) u = Nutzer U = Menge der Nutzer die eine Aufzeichnung für den Pfad beitragen a = Aufzeichnung A = Menge der Aufzeichnungen die zu einem Pfad vereinigt werden R(a) = Bewertung der Aufzeichnung R(u) = Bewertung des Nutzers R(p) = Bewertung des Pfades Die Bewertung ergibt sich somit aus der Summe der Bewertungen der Nutzer die an dem Pfad beteiligt sind summiert mit der Summe aus den Bewertungen der Aufzeichnungen aus denen sich der Pfad ergibt. Darin sind quantitative und qualitative Werte kodiert. Beide Summanden gehen gleichwertig ein. Auch diese Formel ist ein initialer Ansatz für die Berechnung der Bewertung. Für eine Optimierung ist eine extensive Evaluation nötig. Ohne diese kann keine bestätigte Aussage zur richtigen Gewichtung getroffen werden. Für die Aggregation von Wegpunkten gelten folgende Regeln: (I). Neue Wegpunkte werden inklusive den Metadaten in den Graph übernommen (II). Für existierende Wegpunkte werden neue Metadaten übernommen 40 Kapitel 5 Konzept

41 Das Ergebnis der Aggregation ist ein Graph mit spezifischen Eigenschaften. Die Knoten des Graphs repräsentieren Wegpunkte. Die Kanten des Graphs repräsentieren Pfade. Die Kanten des Graphs sind gerichtet, entsprechend der Angabe von Start- und Zielwegpunkt. Die Kanten des Graphs sind gewichtet, entsprechend der Bewertung des Pfads. Der Graph ist ein Multigraph. Es können mehrere Pfade zwischen zwei Wegpunkten existieren, wenn diese bestätigt wurden. Der Graph ist nicht-transitiv. Für die Routenberechnung bei der Navigation kann der Graph jedoch in einen transitiven Graph überführt werden. Abbildung 5.1 illustriert den Ablauf der Aggregation auf dem Crowdsourcing-Server als Flussdiagramm Nutzermotivation und Gamification Ein wichtiger Bestandteil des Konzeptes ist die Vorgehensweise zur Nutzermotivation und - bindung. Im Vergleich zu vielen anderen Anwendungen ist die Wertschöpfungskette umgekehrt. Ein Nutzer der Crowdsourcing-Anwendung hat keinen direkten Nutzen bei der Verwendung, stattdessen steckt er Arbeit in diese. Die Benutzung erfolgt auf freiwilliger Basis. CINA orientiert sich somit am Ansatz weit verbreiteter Crowdsourcing-Plattformen wie Wikipedia und Open-Street- Map, welche ebenfalls auf die Beiträge von Freiwilligen vertrauen. Wie in diesen Plattformen ziehen die Anwender bei CINA einen Nutzen aus den Beiträgen anderer Nutzer. Wie in den Grundlagen aufgezeigt wurde, sind Crowdsourcing-Plattformen jedoch keine Selbstläufer. Es sollten zusätzliche Anreize für die Zuarbeit der Nutzer geschaffen werden. CINA nimmt sich dazu Gamification-Methoden zu Hilfe, um die Motivation zu steigern und die Nutzer an die Plattform zu binden. Das Schlüsselattribut des Gamification-Konzeptes ist die Punktzahl des Nutzers. Alle Gamification-Komponenten motivieren den Nutzer auf spezifische Weise und steigern die Punktzahl und damit die Bewertung des Nutzers. Die Punktzahl kann dadurch auch als Messwert für die Vertrauenswürdigkeit und die Aktivität des Nutzers genutzt werden. Das Gamification-Konzept umfasst Abzeichen, Missionen, Ränge und eine Bestenliste. Nutzer können Abzeichen durch das Auslösen bestimmter Aktionen verdienen. Diese sind besonders hilfreich, um dem Nutzer die Errungenschaften zu präsentieren die er erreicht hat und die ansonsten nicht ersichtlich sind. Dazu gehört das Bestätigen von Aufzeichnungen anderer Nutzer durch das Einsenden einer übereinstimmenden Aufzeichnung. Somit beziehen sich Abzeichen auf implizite Crowdsourcing-Beiträge. Missionen beziehen sich dagegen auf die expliziten Crowdsourcing-Beiträge. Es sind vorgegebene Aufgaben, zu deren Erfüllung der Nutzer aufgefordert wird, etwa die Aufzeichnung einer Wegstrecke mit vorgegebenen Start- und Zielwegpunkten. Das Verdienen von Abzeichen und das Erfüllen von Missionen erhöht jeweils die Punktzahl des Nutzers. Erreicht der Nutzer eine bestimmt Punktzahl, steigt er einen Rang auf. So soll der Nutzer weiter animiert werden, indem sein positiver Einfluss sowie das in ihn gesetzte Vertrauen aufgezeigt wird. Die Nutzer mit den höchsten Punktzahlen werden zusätzlich in einer Rangliste festgehalten. 5.3 Crowdsourcing 41

42 Abbildung 5.2: System Architektur 5.4 SYSTEMARCHITEKTUR In diesem Abschnitt wird das Architekturkonzept der Crowdsourcing-Plattform vorgestellt. CINA basiert auf einer Client-Server-Architektur mit den drei Komponenten: Crowdsourcing- Server, mobiler Client und Gamification-Server. Abbildung 5.2 illustriert diesen Aufbau. Die Client- Server-Architektur ermöglicht eine zentrale Verwaltung der von den Clients erzeugten Daten. Die Client-Seite der Plattform kann durch eine variable Anzahl von Clients repräsentiert werden. Dabei existiert für jede Client-Instanz ein separates Endgerät. Durch den mobilen Charakter dieser Endgeräte ist der Standort beliebig und kann während der Benutzung der Client-Anwendung geändert werden. Jedes Endgerät verfügt dazu über eine Mobilfunkeinheit für das öffentliche Mobilfunknetz, was die Kommunikation mit dem Server für nahezu beliebige Standorte ermöglicht [34]. Der Crowdsourcing-Server wird dynamisch instanziiert, entsprechend der Anfragen der Clients. Alle Server-Instanzen kommunizieren dabei mit einer zentralen Datenbank. Die Crowdsourcing und Gamification sind aufgrund der unterschiedlichen Aufgabenbereich auch logisch getrennt. Die beiden Server-Anwendungen können so separat skalieren. Durch die Installation in derselben Cloud-Umgebung ist die räumliche Distanz gering. 42 Kapitel 5 Konzept

43 5.4.1 Crowdsourcing-Server Der Aufbau und die Funktionsweise des Crowdsourcing Servers orientiert sich an dem Programmierparadigma Representational State Transfer, kurz REST [8]. So agiert der Server zustandslos und nach dem Request-Response-Prinzip. Die empfangenen und gesendeten Daten sind selbst beschreibend und benötigen keine weiteren Informationen über ihren Zustand. Der Server ist ressourcenorientiert. Ressourcen sind abstrakte Schnittstellen, welche Zugriff auf die Funktionen des Servers erlauben. Der Interceptor empfängt die Anfragen des Clients. Die in der Anfrage enthaltene Nachricht wird vom Parser in das Klassenmodel überführt. Ein Router leitet die Anfrage des Clients an die richtige Ressource weiter, abhängig von der geforderten URI. Der Umgang mit den Ressourcen geschieht mit den GET, PUT, POST und DELETE Methoden. Das Verhalten dieser Methoden wird in der Ressource implementiert. Für den Crowdsourcing-Prozess besitzt der Server drei Ressourcen: User: Die User-Ressource verwaltet das Anlegen eines neues Nutzers (POST) sowie das Abrufen von Metadaten der Nutzer (GET). Die Ressource kommuniziert für das Schreiben und Lesen persistenter Daten mit der Datenbank. Recording: Die Recording-Ressource ermöglicht das Übermitteln von Aufzeichnungen (POST). Die neue Aufzeichnung wird ausgewertet und in die Datenbank eingepflegt. Dabei kommuniziert die Ressource mit der Gamification-Plattform. Je nach Inhalt der Aufzeichnung können Gamification-Ereignisse ausgelöst werden. Nach dem Speichern der Aufzeichnung wird die Aggregation gestartet, indem die Path-Ressource angefragt wird (GET). Weiterhin können über diese Ressource existierende Aufzeichnungen abgefragt werden (GET). Path: Die Path-Ressource ist für die Aggregation der Aufzeichnungen zuständig (GET). Dazu implementiert sie die im Abschnitt vorgestellten Regeln. Auch diese Ressource kommuniziert mit der Datenbank für den Zugriff auf die gespeicherten Aufzeichnungen und das Speichern der erzeugten Pfade. Das entstandene Wegenetz kann mit einer GET-Anfrage abgerufen werden. Die Routenberechnung für die Navigation ist als weitere Ressource konzipiert und wird in der anknüpfenden Arbeit [37] genauer beschrieben. Für die Kommunikation der Ressourcen mit der Datenbank existiert ein Persistence Abstraction Layer, der die Schnittstelle des Datenbanktreibers abstrahiert und als Programmierschnittstelle zur Verfügung stellt. Datenbank und Datenbanktreiber können dadurch ausgetauscht werden, ohne dass der Programmcode modifiziert werden muss Mobiler Client Der Aufbau des Clients folgt dem Model-View-Controller-Muster. Die Datenhaltung ist von der Nutzerschnittstelle getrennt. Controller übernehmen dabei die Vermittlung zwischen den beiden Schichten. Die Wiederverwendbarkeit der einzelnen Komponente wird dadurch erhöht und es wird für eine klare Abgrenzung der Zuständigkeiten der Komponenten gesorgt. Die entsprechenden Schichten lassen sich im Architekturdiagramm 5.2 wiedererkennen. Die View-Schicht wird durch das User Interface repräsentiert. Die Controller-Schicht besteht aus Recording Controller, Gamification Controller, User Interface Controller und RESTful Client. Zu der Model-Schicht gehört das Klassenmodell, der persistente Speicher und der Persistence Abstraction Layer. User Interface: Die Bedienoberfläche des Clients ist für mobile Geräte mit kleinen Displays konzipiert. Entsprechend ist die Oberfläche in mehrere Bildschirme unterteilt. Das Konzept sieht die 5.4 Systemarchitektur 43

44 Carrier 18:02 80 % Carrier 18:02 80 % (a) Erster Entwurf (b) Zweiter Entwurf Abbildung 5.3: Entwurf der Bedienoberfläche für die Aufzeichnung Bedienung der Oberfläche mit Touchscreen vor. Abbildung 5.3 zeigt dazu zwei Entwürfe für den Bildschirm der Aufzeichnung, welcher den Hauptbildschirm der Anwendung darstellt. Bereits im ersten Entwurf wurden die Schlüsselattribute des Designs festgelegt. Diese gehen Hand in Hand mit den Anforderungen eines solchen mobilen Endgeräts. Es dominieren große Elemente auf dem Bildschirm. Diese erlauben eine komfortable Eingabe der Richtungsanweisungen. Die Anzahl der Bedienelemente sind auf ein Minimum reduziert. Dies sorgt für einen hohen Wiedererkennungswert der einzelnen Bedienelemente und die Bedienung kann leicht verinnerlicht werden. Durch die geringe Anzahl an Bedienelementen können diese entsprechend groß gestaltet werden, was Fehleingaben vorbeugt. Die vier Hauptrichtungsanweisungen (geradeaus, links, rechts, zurück) sind entsprechend ihrer logischen Richtung platziert. Der zweite Entwurf optimiert das Konzept der Bedienoberflächen an einigen Punkten. Für eine verbesserte Einhandbedienung wurden die wichtigeren Bedienelemente am unteren Ende des Bildschirms ausgerichtet. Dadurch lässt sich die Anweisung geradeaus einfacher mit dem Daumen erreichen. Im Gegenzug wurden die Bedienelemente, die tendenziell weniger genutzt werden, von den Wichtigeren abgegrenzt. Dies beugt Fehleingaben vor. Weiterhin wurde der zentrale Button verkleinert. Mit diesem wird eine Aufzeichnung gestartet und beendet. Dafür konnten die umgebenden Buttons vergrößert werden, für eine komfortable Bedienung mit großen Fingern. Der zweite Entwurf sieht zudem eine Gestenbedienung vor. Die vier Richtungen können somit durch Wischgesten in die entsprechende Richtung eingegeben werden. Diese Gesten werden mit einer haptischen Rückmeldung bestätigt. Damit ist sogar ein blinde Bedienung für die wichtigsten Aktionen möglich. Der Abstand zu den seitlichen Rändern des Displays wurde vergrößert und erlaubt so eine flexiblere Handhabung des Endgeräts ohne Fehleingaben zu riskieren. Alle Bedienelemente geben eine visuelle Rückmeldung als Bestätigung der Eingabe. Entwurf zwei stellt den Ausgangspunkt für die Implementierung der Benutzeroberfläche dar. 44 Kapitel 5 Konzept

45 User Interface Controller: User Interface Controller sind eine Reihe von Klassen, welche die Darstellung und Interaktion auf der Bedienoberfläche regeln. Für jeden Bildschirm ist ein spezieller User Interface Controller vorgesehen. Recording Controller: Der Recording Controller ist für die Ablaufsteuerung einer Aufzeichnung zuständig. Dazu besitzt der Controller vier Unterkomponenten für die unterschiedlichen Aufgaben während der Aufzeichnung. Der Instruction Recorder speichert die vom Nutzer eingegebenen Richtungsanweisungen und die Zeit zwischen den Anweisungen. Der Waypoint Scanner ermöglicht die Eingabe von Wegpunkten am Start und am Ende der Aufzeichnung. Dazu kann auch das Scannen von QR- und Barcodes oder das Lesen von NFC-Tags gehören. Die Spatial Positioning-Komponente ermittelt eine räumliche Position des Clients an den Wegpunkten. Wie in den vorangegangenen Kapiteln dargelegt wurde, ist diese Positionsermittlung in Gebäuden oftmals nur mit einer geringen Genauigkeit oder gar nicht möglich. Aus diesem Grund werden die ermittelten räumlichen Positionsdaten mit der dazu gehörenden Genauigkeit gespeichert. Die Daten können folglich als zusätzliche Parameter für die Routenberechnung und Navigation dienen, sind jedoch keine Grundlage für die Aggregation. Zusätzliche Metadaten liefert neben dem Spatial Positioning das Pedometer. Dieses zeichnet die während der Aufzeichnung gegangen Schritte auf, mit Hilfe der Sensoren des Endgeräts. Die dabei zu erwartende Genauigkeit ist besonders auf längeren Wegstrecken gering, wie in Kapitel 2 gezeigt wurde. So werden die Daten des Pedometers, wie die räumlichen Positionsdaten auch, nur als zusätzliche Parameter verwendet. Gamification Controller: Der Gamification Controller verwaltet die Gamification Elemente des Clients. Der Gamification Controller ist als eigenständige Komponente konzipiert. Damit verwaltet der Controller die Kommunikation zum Gamification Server, das Überwachen und Reagieren auf Gamification-Ereignisse sowie das Steuern der Gamification-User-Interface-Elemente. Die Kommunikation mit dem Crowdsourcing-Server wird über den RESTful Client abgewickelt. Dieser abstrahiert die Schnittstelle zum Server und stellt sie als einfache Programmierschnitte für die Controller bereit. Weiterhin überführt der RESTful Client den Inhalt der Servernachrichten in das Klassenmodell und vice versa mit Hilfe des JSON Parser. Die Controller speichern ihre Daten, wie Aufzeichnungen und Metadaten zu Gebäuden und Wegpunktypen, auf einem persistenten Speicher (Persistent Storage). Wie auf dem Server gibt existiert dazu eine Abstraktionsschicht, welche die Verwaltung des Speichers als Programmierschnittstelle zur Verfügung stellt (Persistence Abstraction Layer) Gamification-Server Wie auf dem Client, erfolgt auch auf Serverseite eine Trennung zwischen den Gamification- Komponenten und der eigentlichen Crowdsourcing-Funktionalität. Diese Trennung ermöglicht flexible und getrennte Anpassungen und Erweiterungen der beiden Bereiche. Die Crowdsourcing- Anwendungen auf Client und Serverseite ist damit weitestgehend unabhängig von dem Gamification-Server. Die Crowdsourcing-Funktionalitäten können einfach durch das Ausschalten des Gamification-Servers deaktiviert werden. Die Gamification-Komponenten auf der Serverseite werden somit von einer eigenständigen Serveranwendung verwaltet. Diese Serveranwendung speichert und verwaltet die Abzeichen, Missionen, Ränke, Regeln und Nutzer in einer eigenen Datenbank. Die Regeln kapseln die Logik des Gamification-Konzepts, beispielsweise wann ein Abzeichen erlangt wird, oder unter welchen Bedingungen eine Mission erfüllt ist. Die Rule Engine wertet die eingehenden Nachrichten von Client und Crowdsourcing-Server aus und löst Ereignisse entsprechend der registrierten Regeln aus. 5.4 Systemarchitektur 45

46 5.4.4 Server Datenbank Eine besondere Bedeutung kommt der Datenbank für die Gamification-Server-Anwendung zu. Durch den Crowdsourcing-Ansatz und das Fehlen von Beschränkungen auf bestimmte Gebäude können große Datenmengen generiert werden. Diese müssen von der Datenbank gespeichert und performant durchsucht werden können. Aufgrund dieser Anforderung kommt eine hybride In-Memory-Datenbank zum Einsatz. Die Verlagerung der Datenhaltung in den Hauptspeicher ermöglicht eine performante Auswertung großer Datenmengen. Darüber hinaus werden die Daten auf einem langsameren persistenten Medium gespeichert, um Datenverlust vorzubeugen. Weiterhin sieht das Konzept eine spaltenorientierte Arbeitsweise in der Datenbank vor, welche die Effizienz der Datenhaltung und -speicherung weiter steigert was besonders bei der gegebenen Datenstruktur von Aufzeichnungen mit vielen Attributen, einer starken Verschachtelung und geringer Content-Länge gilt. Damit ist die gesamte Serverseite sehr flexibel gegenüber der Anzahl von Nutzern und Aufzeichnungen. 5.5 SCHNITTSTELLEN Neben den bereits beschriebenen internen Programmierschnittstellen existieren Schnittstellen zwischen den drei Hauptkomponenten. Diese haben als Webschnittstelle besondere Anforderungen und Eigenschaften. Um den Bewegungsraum des Clients nicht einzuschränken, kommunizieren Client und Server über das Internet im öffentlichen Mobilfunknetz RESTful API Wie im vorangegangenen Abschnitt vorgestellt wurde, ist die Crowdsourcing-Serveranwendung als RESTful-Service konzipiert. Somit stellt der Crowdsourcing-Server auch eine Schnittstelle nach dem REST-Prinzip für den Client bereit. Als Protokoll kommt HTTP zum Einsatz. Der Client kann die jeweilige Ressource über eine bestimme URL erreichen. Der Router bildet die URL auf die entsprechende URI ab. Neben der URL gehört eine Methode zu einer Anfrage. Verfügbar sind die HTTP-Methoden: GET, PUT, POST, DELETE. GET Methoden werden für das Abrufen von Daten und für das Auslösen von Funktionen verwendet. Für das Übermitteln von Daten, insbesondere Aufzeichnungen, wird die POST-Methode genutzt. Ein Löschen von Daten mit der DELETE-Funktion und das Modifizieren von Daten mit der PUT-Funktion ist im Konzept nicht vorgesehen JSON Datenaustausch Bei der Kommunikation zwischen Client und Server kommt das Datenformat JSON zum Einsatz. Dieses Format zeichnet sich durch eine kompakte Repräsentation der darin enthaltenen Informationen aus und besitzt somit einen geringen Overhead. Damit ist es besonders geeignet für den Datenaustausch auf begrenzten Kommunikationskanälen wie Mobilfunknetze. Dem REST-Konzept folgend sind die übertragenen JSON-Objekte selbst beschreibend. Aufgrund des Aufbaus von JSON ist es für die Abbildung von Klassenstrukturen objektorientierter Software geeignet. Darüber hinaus ermöglicht JSON eine höhere Verarbeitungsgeschwindigkeit im Vergleich zu ähnlichen Datenformaten [24]. 46 Kapitel 5 Konzept

47 5.6 DATENMODELL Abbildung 5.4: Datenmodell des Crowdsourcing-Server An dieser Stelle wird das Konzept zum Datenmodell vorgestellt, welches als Grundlage für das persistente Speichern von Aufzeichnungen und Pfaden auf der Server-Seite verwendet wird. Abbildung 5.4 zeigt dazu ein Entity-Relationship-Diagramm. Die beiden wichtigsten Entitäten in dem Datenmodel sind die Aufnahme und der Pfad, wobei deren Struktur weitestgehend übereinstimmt. Aufzeichnung und Pfad besitzen je eine id zur eindeutigen Referenzierung, einen Verweis zu einem Gebäude, eine Referenz zu je einem Start- und Zielwegpunkt, eine Referenz zu einer Menge von Anweisungen, eine numerische Bewertung und einen Wahrheitswert über die Umkehrbarkeit. Aufzeichnungen besitzen darüber hinaus eine Referenz zu dem Nutzer, der sie erstellt hat. Pfade beinhalten zusätzlich die arithmetisch gemittelte Anzahl der Schritte und die arithmetisch gemittelte Laufzeit. Diese beiden Werte können so auf einfachem Wege für die Routenberechnung heran gezogen werden. Nutzer werden als Entität mit einem eindeutigem Namen, einer numerischen Bewertung und einer Referenz zu den Aufzeichnungen des Nutzers modelliert. Die Entität Anweisung dient zur Abbildung der geordneten Liste von Anweisungen in Aufzeichnungen und Pfaden. Dazu besitzt die Anweisung eine Nummer, welche die Position in der Liste 5.6 Datenmodell 47

48 repräsentiert. Der Typ verweist auf die logische Richtungsanweisung. Zusätzlich werden die Anzahl der Schritte und die Laufzeit gespeichert, welche sich auf die Wegstrecke zwischen der aktuellen Anweisung und der nachfolgenden Anweisung beziehen. Die Modellierung der Richtungsanweisungen als zusätzliche Entität Anweisungstyp anstelle eines textuellen Eintrages hat mehrere Vorteile. Zum einen fügt dies weitere Semantik zu der Anweisung hinzu. Über die id können Anweisungen explizit identifiziert werden, anstelle eines impliziten Vergleichs von Zeichenketten. Zum anderen wird die Richtungsanweisung erweiterbar beispielsweise um eine dazugehörige Grafik oder eine Sprachanweisung. Die Anweisungstypen werden bei der Installation automatisch im Datenmodell verankert und bieten damit ein Anweisungsverzeichnis zur Nutzung in der Client- und Server-Anwendung. Die gleiche Vorgehensweise wurde für Gebäude angewandt. Diese beinhalten jeweils noch eine Referenz zu den dazugehörigen Aufzeichnungen und Pfaden. Wegpunkte werden ebenfalls als eigene Entität modelliert. Neben einer generierten id wird der Name des Wegpunktes gespeichert. Der Name ist beispielsweise die Raumnummer und kann in mehreren Gebäuden vorkommen und kann daher nicht als alleinige id verwendet werden. Weiterhin sind im Wegpunkt Referenzen zu Gebäude, Wegpunkt-Typen und räumlicher Position gespeichert. Wie die Anweisungstypen sind die Wegpunkttypen vordefiniert und wurden aus denselben Gründen als eigenständige Entität modelliert. Die räumliche Position (GeoLocation) speichert neben den drei Welt-Koordinaten (latitude, longitude, altitude) die Genauigkeit in Metern, mit der die Koordinaten bestimmt wurde. Dies ist insofern von Relevanz, da die zu erwartenden Genauigkeiten stark schwanken werden, je nach den Gegebenheiten im Gebäude. 5.7 CLIENT PROGRAMMABLAUF In diesem Abschnitt soll der Ablauf des Crowdsourcing-Prozesses auf Client und Server-Seite gezeigt werden. Zur besseren Veranschaulichung wird der Ablauf an dieser Stelle in Phasen unterteilt. Eine solche strikte Trennung ist in der Anwendungslogik nicht vorgesehen. Phase 1: Setup. Bei dem ersten Start der Client-Anwendung auf einem Mobilgerät wird der Nutzer aufgefordert einen Account anzulegen, bestehend aus einem eindeutigem Nutzernamen. Nach erfolgreicher Registrierung des Accounts bei den beiden Server-Anwendungen, wird dem Nutzer ein Tutorial präsentiert. In diesem Tutorial wird der Nutzer über den Zweck der Anwendung und den Arbeitsablauf bei der Aufzeichnung informiert. Mit dieser Maßnahme soll die Selbsterklärungsfähigkeit der Client-Anwendung gefördert werden. Hat der Nutzer das Tutorial abgeschlossen, wird die Oberfläche für die Aufzeichnung präsentiert. Phase 2: Synchronisation mit dem Server. Bei jedem Start der Anwendung erfolgt eine Synchronisation mit dem Server. Dabei werden die auf dem Server gespeicherten Informationen zu Gebäuden und Wegpunkten geladen, die für die Aufzeichnung notwendig sind. Diese Daten werden im persistenten Speicher des Endgeräts abgelegt und sind so bei einem Offline-Start der Anwendung verfügbar, bei der keine Synchronisation erfolgen kann. Die Synchronisation erfolgt asynchron im Hintergrund, sodass der Nutzer durch diesen Ablauf nicht abgelenkt oder gar blockiert wird. Phase 3: Aufzeichnung. Der Nutzer beginnt die Aufzeichnung mit der Eingabe eines Wegpunkts, beispielsweise durch Scannen eines QR-Codes mit der Kamera des mobilen Endgeräts. Nach der Eingabe wird der Nutzer aufgefordert die Richtung einzugeben in die er sich begeben wird. Im Hintergrund starten die bereits vorgestellten Dienste: Pedometer, Instruction Recorder und Spatial Positioning. Der Nutzer beginnt sich in Richtung seines Ziels zu bewegen. Zu jeder Zeit kann der Nutzer eine Richtungsanweisung eingeben und der Anwendung damit das Passieren einer 48 Kapitel 5 Konzept

49 Kreuzung, bzw. das Erreichen des Ziels signalisieren. Die Dienste, insbesondere der Instruction Recorder werden darauf hin aktualisiert. Erreicht der Nutzer seinen Zielwegpunkt, gibt er diesen in der Anwendung an. Dies kann wiederum durch das Scannen eines QR-Codes erfolgen. Damit wird die Aufzeichnung abgeschlossen und die Hintergrunddienste werden gestoppt. Abschließend kann der Nutzer Metadaten angeben, zu Gebäude, Wegpunkttyp und ob die aufgezeichnete Wegstrecke entgegen der Aufzeichnungsrichtung begangen werden kann was in der Regel der Fall ist, jedoch anderenfalls die Navigation unmöglich macht. Phase 4: Upload. Nachdem die Aufzeichnung beendet wurde, wird diese im persistenten Speicher abgelegt. Anschließend übermittelt der Client die Aufzeichnung zum Server. Sollte der Upload scheitern, hat der Nutzer die Möglichkeit den Upload zu einem geeignetem Zeitpunkt zu wiederholen. Dazu hat der Nutzer Zugriff auf eine Liste seiner bereits getätigten Aufzeichnungen. Die eingehenden Aufzeichnungen wertet der Server aus uns speichert sie in der Datenbank. Phase 5: Aggregation. Nach jedem Speichern der Aufzeichnung auf Serverseite, wird die Aggregation der Aufzeichnungen gestartet. Bei einer großen Anzahl an Aufzeichnungen (>1000) ist eine längere Bearbeitungszeit zu erwarten (>30 Sekunden). Aus diesem Grund läuft die Aggregation asynchron ab. Der Client muss bei dem Übermitteln von Aufzeichnungen folglich nicht auf die Aggregation warten. Bei der Aggregation gelten die Regeln, die im Abschnitt Aggregation der Beiträge (5.3.2) aufgestellt wurden. Das Resultat der Aggregation ist ein (aktualisiertes) Wegenetz in Form eines Graphen. Ab diesem Zeitpunkt kann die Routenberechnung für die Navigation auf die neuen Informationen zugreifen. Phase 6: Gamification. Basierend auf der Auswertung der Aufzeichnung in Phase 4, werden parallel zur Phase 5 die Gamification-Aktionen auf dem Gamification-Server ausgelöst. Je nach Charakteristik der Aufzeichnung kann dies Auswirkungen auf die Abzeichen, Missionen, Ränge und Punkte des Nutzers haben. Der Nutzer wird durch den Client über diese Ereignisse informiert. 5.8 ZUSAMMENFASSUNG In diesem Kapitel wurde im Detail das Konzept der Crowdsourcing-Plattform CINA vorgestellt. Dabei wurde geklärt was der Crowdsourcing-Charakter für die Plattform bedeutet und wie die damit einhergehenden Herausforderungen adressiert werden. Darauf aufbauend wurde ein Architektur- Konzept entwickelt und vorgestellt. Abschließend wurde gezeigt, wie der Crowdsourcing-Prozess auf Basis des Architektur-Konzeptes abläuft. Dieses Kapitel bildet die Grundlage für die Implementierung, die im folgenden Kapitel vorgestellt wird. 5.8 Zusammenfassung 49

50 50 Kapitel 5 Konzept

51 6 IMPLEMENTIERUNG In diesem Kapitel wird die Umsetzbarkeit des Konzepts anhand einer prototypischen Implementierung gezeigt. Zu Beginn werden einige Technologien vorgestellt, die bei der Implementierung zum Einsatz kommen. Daran anschließend wird der Prototyp analog zu den drei Konzept- Komponenten: Crowdsourcing-Server, Gamification Server und Client vorgestellt. 6.1 TECHNOLOGIEGRUNDLAGEN Wie bereits angedeutet wurde, kommen einige Basistechnologien zum Einsatz auf deren Basis der entwickelt Prototyp wird. Am wichtigsten sind dabei die Plattformen für Crowdsourcing-Server, Gamification Server und Client. Für deren Umsetzung kommen die SAP HANA Cloud Platform, die SAP Gamification Platform sowie ios zum Einsatz SAP HANA Cloud Platform SAP HANA Cloud Platform ist eine Entwicklungsplattform für Java EE Cloud Anwendungen. Sie zählt zu den Platform as a Service (PaaS) -Angeboten. PaaS bezeichnet Dienste bei denen eine (Entwicklungs-) Plattform für Webanwendungen inklusive den darunter liegenden Schichten von Hardware, Netzwerk und Software angeboten werden. PaaS unterstützen meist den gesamten Produktzyklus von Implementierung über Testen bis zum Produktiveinsatz. Kunden dieser Dienste können damit auf die Anschaffung von eigener Hardware und Netzwerktechnik sowie auf die Einrichtung von Software für die Netzwerkinfrastruktur verzichten. HANA Cloud setzt sich aus vier Komponenten zusammen [29]: Entwicklungsumgebung: Aufbauend auf Eclipse, erweitert um das HANA Cloud SDK für Java Webanwendungen. Laufzeitumgebung: Basierend auf der SAP eigenen Implementierung der Java VM ermöglicht sie die Ausführung von HANA Cloud Anwendungen. Plattformdienste: Eine Reihe von APIs zum Umgang mit Dokumenten und Protokollen, Konnektivität, Persistenz und Authentifizierung. 51

52 HTML5 UI Werkzeuge: Eine Sammlung von Bedienelementen zur Entwicklung eines HTML5 Frontends für HANA Cloud Anwendungen. Im Folgenden sollen die Komponenten genauer vorgestellt werden. Entwicklungsumgebung Die Entwicklungsumgebung für HANA Cloud Anwendungen ist eine Erweiterung der Eclipse IDE für Java EE. Der Anwendungsentwicklungsprozess ist dabei nahezu identisch. Die HANA SDK Plugins unterstützen dabei hauptsächlich bei der Kommunikation mit der Laufzeitumgebung. Dadurch wird auch eine einfache Verteilung der Webanwendung an den Server ermöglicht. Weiterhin ist es mit dem Werkzeug möglich eine lokale Instanz des Servers einzurichten. Die mitgelieferten Kommandozeilen-Werkzeuge helfen bei dem Build-Prozess. Durch den offenen Charakter von Eclipse stehen bei der Entwicklung auch eine Vielzahl von SDKs und Plugins von Drittherstellern zur Verfügung. HANA Cloud Runtime Die Cloud Runtime besitzt drei Ebenen (Abbildung 6.1). Auf unterster Ebene sitzt eine Java Virtual Machine. Dabei wird eine SAP-eigene Implementierung eingesetzt (SAP JVM). Diese ist jedoch vollkommen mit Java 6 und 7 kompatibel. Darüber sitzt der Laufzeit Container (Application Runtime Container) für Java EE Anwendungen. Dieser ist modular und leichtgewichtig aufgebaut und für Java EE 6 Webanwendungen zertifiziert. Somit entspricht der Entwicklungsprozess von HANA Cloud Anwendungen weitestgehend dem von Java EE 6 Anwendungen. Zusätzlich zu der Java EE6 APIs stehen einige spezielle HANA Cloud APIs zur Verfügung. Durch die Kompatibilität zu Java EE 6 lassen sich ohne Weiteres auch Software-Bibliotheken von Drittherstellern ausführen. Die Anwendungen aus dem Laufzeit Container werden in speziellen Recheneinheiten ausgeführt. Die Recheneinheiten sind dabei virtualisiert. Das erlaubt eine flexible Zuteilung von Hardwareressourcen für die einzelne Webanwendung. Der Laufzeitumgebung steht eine Datenbank zur Seite. Es kann zwischen der traditionellen relationalen Datenbank MaxDB und der hybriden In-Memory-Datenbank SAP HANA gewählt werden. HANA Cloud Services Das HANA Cloud SDK enthält eine Reihe von Diensten mitsamt APIs, die bei der Anwendungsentwicklung unterstützen. Connectivity Service: Dieser Dienst bietet eine zuverlässige und abgesicherte Kommunikation zu den Geschäftsdaten aus der Cloud. Zusätzlich können über diesen Dienst auch Daten von entfernten (Unternehmens-) Infrastrukturen konsumiert werden. Persistence Service: Der auf JPA basierende Persistenz-Dienst verwaltet die Datenbanken in HANA Cloud. Jedoch können mit dem Dienst auch JDBC-Datenbanken angesprochen werden. Document Service: Während der Persistenz-Dienst den Umgang mit strukturierten Daten verwaltet, lassen sich mit dem Dokument-Dienst unstrukturierte Daten verarbeiten und persistent speichern. Dabei wird das OASIS Protokoll angewandt. 52 Kapitel 6 Implementierung

53 Abbildung 6.1: HANA Cloud Runtime Identity Service: Der Identitäts-Dienst ist verantwortlich für die Authentifizierung und ermöglicht Single-Sign-On (SSO) zwischen den Anwendungen in HANA Cloud. Dieser Dienst verwendet die Security Assertion Markup Language (SAML) zum Beschreiben der Authentifizierung. HTML5 UI Werkzeuge Die HTML5 Werkzeuge dienen der Erstellung von Web-Clients für die HANA Cloud Webanwendungen. Diese Werkzeuge enthalten ein Sammlung von Bedienelementen, die häufig bei der Entwicklung von HTML-Frontends benötigt werden. Dabei sind diese Elemente von dem Entwickler konfigurier- und modifizierbar. Innerhalb der Eclipse-Entwicklungsumgebung lassen sich diese Bedienelement zu einer Anwendung komponieren, inklusive Layout-Vorschau. Das Programmiermodell entspricht dem Modell View Controller (MVC) Prinzip. Die Javascript Bibliothek verwendet dabei CSS3 und die quelloffene jquery Bibliothek Java API for RESTful Web Services (JAX-RS) JAX-RS ist eine Programmierschnittstelle für Java EE Anwendungen für die Erstellung von RESTful Webservices. Die Ressourcen werden dabei mit Hilfe von Annotationen ausgeschrieben. Je nach Implementierung müssen die Ressourcen zusätzlich in einem Manifest verankert werden oder werden automatisch erkannt. Es folgt ein kurzer Überblick über die wichtigsten kennzeichnet die URI einer Ressource. Der interne Router von JAX-RS leitet die Client- Anfragen entsprechend ihrer URL an die richtige markieren, mit welcher Methode die Ressource aufgerufen definieren den MIME-Type der Anfrage und Antwort. 6.1 Technologiegrundlagen 53

54 Die Ressourcen werden als öffentliche Java Methoden implementiert und können frei in Klassen arrangiert werden Java Persistence API (JPA) JPA ist eine weitere Java Programmierschnittstelle. Diese unterstützt bei der Kommunikation mit persistenten Datenquellen, insbesondere relationale Datenbanken. Die Entitäten werden dabei als POJO (Plain Old Java Object) modelliert. Annotationen sorgen für eine lose Kopplung zwischen Datenquelle und Java Objekt. Die wichtigsten Annotationen kennzeichnet ein POJO als Entität der Datenquelle. Das ist die Voraussetzung, wenn ein Objekt mit JPA persistiert werden gibt in dem Zusammenhang den Tabellennamen der Entität an, unter dem das Objekt abgelegt werden markiert ein kennzeichnet ein Attribut, dessen Wert generiert wird und definiert die @ManyToOne werden Beziehungen zwischen den Entitäten definiert. JPA definiert mit JPQL eine Sprache zur Abfrage von Entitäten aus der Datenquelle. Die Syntax ähnelt dabei der SQL. Bei SQL-Datenquellen werden JPQL Anfragen zur Laufzeit in SQL übersetzt Java Architecture for XML Binding (JAXB) JAXB ist die dritte große Java Programmierschnittstelle, die im Prototyp zur Anwendung kommt. Sie unterstützt die XML-Datenbindung. In Verbindung mit JAX-RS können XML kodierte Nachrichten in Java-Objekte überführt werden und vice versa. So wird bei der Implementierung der Ressourcen das Datenformat der REST-Nachrichten vollständig verborgen. Um diese Übersetzung zu ermöglichen, werden wiederum POJOs mit Annotationen markiert eine Klasse als kennzeichnet die Felder als XML- definiert Felder als Attribute des XML-Wurzelelements. Einige Implementierungen von JAXB unterstützen auch JSON als Datenformat, wie es im Prototyp eingesetzt wird. Mit den identischen Annotationen erfolgt eine entsprechende Zuordnung zu JSON- Objekten, -Arrays und -Feldern SAP Gamification Platform Die SAP Gamification Platform unterstützt die Einführung von Gamification-Konzepten in bestehende Anwendungen. Es wird nicht nur eine Programmierschnittstelle bereit gestellt, sondern eine gesamte Plattform. Zu den unterstützten Spielmechaniken gehören unter anderem: Punkte, Abzeichen, Missionen, Unter-Missionen und virtuelle Gegenstände. Auf technischer Seite umfasst die Plattform: eine Programmierschnittstelle zur einfachen Integration der Dienste, einen Dienst zur Verwaltung der Spielregeln, eine Analytik-Komponente, Skalierbarkeit durch die Cloud- Infrastruktur sowie SDKs für mobile und HTML5-Frontends. Die Spielmechaniken können über eine Wegoberfläche konfiguriert werden. Die Spielregeln werden dabei in der Drools Rule Language definiert und stellen Wenn-Dann -Konstrukte dar. Die Regeln werden in der Rule Engine registriert. Diese überwacht die Regeln und löst sie entsprechend ihrer Bedingungen aus. 54 Kapitel 6 Implementierung

55 6.2 ARCHITEKTUR Abbildung 6.2: System Architektur des Prototyps Die Architektur des Prototyps entspricht weitestgehend dem Konzept. Es kommt eine dreigeteilte Client-Server-Architektur zum Einsatz. Die Crowdsourcing-Server-Anwendung ist eine Neuentwicklung, basierend auf der SAP HANA Cloud Plattform. Dabei werden die eingangs vorgestellten Java Programmierschnittstellen angewandt. Der Gamification-Server ist eine Instanz der SAP Gamification Platform. Die Gamification-Logik wurde entsprechend der Regelbeschreibungssprache implementiert. Der Client wurde auf Basis von ios für das iphone entwickelt. Die Umsetzung der einzelnen Komponenten wird in den folgenden Abschnitten ausführlicher vorgestellt. 6.3 CROWDSOURCING SERVER Der Crowdsourcing-Server wurde als Java EE Anwendung mit dem SAP Hana Cloud Platform SDK entwickelt. Die innere Architektur entspricht weitestgehend dem Konzept. Für die Implementierung der einzelnen Komponenten wurden die eingangs vorgestellten Programmierschnittstellen angewandt. Dies hat mehrere Vorteile. Zum einen wird der Entwicklungsaufwand deutlich reduziert. Zum anderen besitzen diese APIs als Quasi-Standards eine gesicherte Qualität und deren Einsatz hat sich in vielen anderen Anwendungen bewährt. JAX-RS in Kombination mit JAXB bildet die Grundlage für die Implementierung der RESTful Server-Anwendung mit JSON als Datenformat. Die einzelnen Ressourcen wurden als POJO- Klassen umgesetzt und entsprechend annotiert. Eingehende Aufzeichnungen und die daraus 6.2 Architektur 55

56 entstehenden Pfade werden mit Hilfe von JPA in einer SAP HANA Datenbank gespeichert. Diese eignet sich als hybride In-Memory-Datenbank optimal für große Mengen von Aufzeichnungen. Zum Austausch von Gamification-Nachrichten mit dem Gamification-Server besitzt der Crowdsourcing-Server einen JSON-RPC Client (Connector). Diese Komponente nutzt die Java- API der SAP Gamification Platform. 6.4 IOS CLIENT Wie bereits erwähnt, wurde der Prototyp für das iphone (ab iphone 3GS) als Endgerät entwickelt. Mit ios liegt diesen Geräten ein modernes Betriebssystem zugrunde, auf dessen Basis sich alle Funktionen des geplanten Konzepts implementieren lassen. Das iphone als Endgerät entspricht den Anforderungen des Clients. Es ist leicht, mobil (Anforderung AC1) und lässt sich sehr gut einhändig bedienen, was die Mobilität weiter steigert. Es sind eine Reihe von Sensoren (Beschleunigungssensor, digitaler Kompass, 3-Achsen Gyroskop ab iphone 4) integriert mit denen eine Schritterkennung durchgeführt werden kann (Anforderung ACO1). Das Gerät besitzt auch einen GPS- und WLAN-Empfänger für die räumliche Positionierung (Anforderung ACO2). Das integrierte Funkmodul ermöglicht die Kommunikation mit dem Server (Anforderung AC6). Die eingebaute Kamera mit Autofokus und Hilfslicht (ab iphone 4) ermöglichen das Scannen von QRund Barcodes. Die Softwarearchitektur des Clients entspricht weitestgehend dem Konzept. Das User Interface wurde mit einem xcode Storyboard und dem Interface Builder realisiert. Die User Interface Controller zur Verwaltung des User Interface wurden als View Controller implementiert. Eine große Komponente stellt weiterhin der Recording Controller dar, welcher den Ablauf der Aufzeichnung verwaltet. Wie im Konzept registriert der Instruction Recorder die eingegebenen Richtungsanweisungen. Für eine schnelle und komfortable Aufzeichnung von Wegpunkten implementiert der Prototyp eine Komponente zum Scannen von QR- und Barcodes unter Einsatz des ZBar SDK. Das Pedometer wurde auf Basis der UIAccelerometer-API implementiert. Die Schritterkennung erfolgt durch eine Schwellwertanalyse der Differenz der Beschleunigungswerte für die drei Achsen X,Y und Z bei dem Vergleich zwei aufeinanderfolgender Sensorwerte. Die Abtastfrequenz wurde mit 60Hz angesetzt, für eine Erkennung schnellerer Schritte. Ein Low-Pass-Filter filtert kleine Bewegungen mit hoher Frequenz (Vibrationen, Schütteln, etc.). Bei der Aufzeichnung der Wegpunkte findet im Location Manager eine räumliche Positionsbestimmung statt. Diese Funktion basiert auf der CoreLocation Programmierschnittstelle. Wenn eine räumliche Position ermittelt werden kann, wird diese als Parameter für den Wegpunkt zusammen mit der dazugehörigen Genauigkeit gespeichert. Die Gamfication-Elemente des Prototyps wurden auf Grundlage des SAP Gamification SDK für ios entwickelt. Der Gamification Controller konfiguriert und komponiert die darin enthaltenen UI-Elemente und übergibt sie an das User Interface. Das SAP Gamification SDK kapselt die Kommunikation zur SAP Gamification Platform, welche auf JSON RPC über HTTP basiert. Die Kommunikation zwischen dem mobilen Client und dem Crowdsourcing Server wird von der AFNetworking API unterstützt. Diese verwendet intern die native JSON API für das Umwandeln ein- und ausgehender JSON-Nachrichten. Für das persistente Speichern von Daten besitzt die Client-Anwendung eine SQLite Datenbank. Dadurch lässt sich auch eine große Anzahl an Aufzeichnungen effektiv speichern. Zur Laufzeit der Anwendung können Daten aus der Datenbank in das Managed Object Model überführt 56 Kapitel 6 Implementierung

57 Abbildung 6.3: Benutzeroberfläche für die Aufzeichnung im Prototyp werden. Diese Transaktionen werden von nativen CoreData API verwaltet. Diese API agiert als Abstraktionsschicht für die Speicherebene und vereinfacht damit das persistente Speichern von objektorientierten Datensätzen. Bei der Gestaltung der Bedienoberfläche setzt der Prototyp am Entwurf aus dem Konzept an. Das Look & Feel orientiert sich an den Gestaltungsrichtlinien der zum Zeitpunkt der Implementierung aktuellen ios-version 6. Im Hauptbildschirm der Anwendung (Abbildung 6.3) dominieren so Texturen, kräftige Typographien und die Bedienelemente haben eine plastische Gestalt. Die Registrierung und das Tutorial (Abbildung 6.4) zum Eingang der Anwendung schlägt hinsichtlich der Gestaltung die Brücke zur flachen Designsprache von ios 7. Dies ergab sich aus der verstärkten Nutzung von Bildern als Hintergrund, welche wiederum die didaktische Grundlage für das Tutorial bilden. Die Gamification-Komponenten des User Interfaces (Abbildung 6.5) basieren auf dem ios SDK der SAP Gamification Platform. Diese Bedienelemente wurden in einem eigenständigen View Controller arrangiert. Der Nutzer wird beim Bedienen der Anwendung mit Hilfe von anwendungsinternen Benachrichtigungen am oberen Rand des Bildschirms über Gamification-Ereignisse informiert. Die Rangliste stellt eine Erweiterung außerhalb des SDKs dar. 6.5 GAMIFICATION SERVER In diesem Abschnitt wird die Implementierung des Gamification-Servers auf Basis der SAP Gamification Platform genauer vorgestellt. Diese Plattform stellt nahezu alle Funktionalitäten und Schnittstellen bereit, die für die Umsetzung des Gamfication-Konzepts notwendig sind. Die SAP Gamification Platform wurde wie der Crowdsourcing-Server auf Basis der SAP HANA Cloud Platform entwickelt. Dadurch lässt sich eine Instanz der Gamification-Plattform in derselben Cloud- Umgebung aufsetzen. Nach der Installation der Gamification-Server-Anwendung muss diese konfiguriert werden. Alle Gamification-Komponenten: Punkte, Level, Abzeichen und Missionen sowie die Regeln lassen sich über eine Administrationsoberfläche im Browser konfigurieren. Abbildung 3 zeigt eine Übersicht zu den im Prototyp verfügbaren Abzeichen. Die Spielregeln werden in der Drools Rule Language definiert. Abbildung 6.7 zeigt dazu ein Beispiel. Diese Regel prüft das 6.5 Gamification Server 57

58 (a) Startbild (b) Registrierung (c) Tutorial Abbildung 6.4: Registrierung und Tutorial im Prototyp (a) Nutzerprofil (b) Missionen Abbildung 6.5: Gamification-Komponenten im Prototyp 58 Kapitel 6 Implementierung (c) Rangliste

59 IceBreaker - Übermitteln der ersten Aufzeichnung Approver - Übermitteln einer übereinstimmenden Aufzeichnung Student - Abschließen des Tutorials TopContributor - Erreichen der Top3 der Bestenliste Navigator - Erfolgreiche Navigation aufgrund einer eigenen Aufzeichnung Columbus - Aufzeichnen einer unbekannten Wegstrecke Sherlock - Scannen eines unbekannten Wegpunktes Abbildung 6.6: Übersicht aller Abzeichen when $p : Player($playerid : uid) eval(queryapi.hasplayermission($playerid, 'Record Paths') == true) eval(queryapi.getpointsforplayer($playerid, 'SubmittedRecordings').getAmount() >= 3)" then updateapi.completemission($playerid, 'Record Paths'); updateapi.addmissiontoplayer($playerid, 'Record more Paths'); updateapi.givepoints($playerid, 'Contribution', 1, 'Finished mission'); update($p); end. Abbildung 6.7: Beispielregel Erfüllen der Mission Zeichne drei Wegstrecken auf für einen Nutzer. Als Bedingungen werden geprüft, ob die Regel dem Nutzer zugewiesen ist und ob dieser Nutzer drei oder mehr Aufzeichnungen übermittelt hat. Trifft dies zu, wird die Konsequenz (then) ausgelöst. In der Beispielregel wird die Mission als absolviert markiert, der Nutzer bekommt eine anschließende Mission zugewiesen und erhält einen Punkt für das Erfüllen der Mission. 6.6 ZUSAMMENFASSUNG In diesem Kapitel wurde die Umsetzbarkeit des Konzepts gezeigt. Es wurde eine prototypische Plattform entwickelt, basierend auf den Basistechnologien: ios, Java EE, SAP HANA Cloud Platform und SAP Gamfication Platform. Die Systemarchitektur und die Abläufe konnten nahezu vollständig aus dem Konzept übernommen werden. Das folgende Kapitel untersucht die Gebrauchstauglichkeit des Konzepts anhand des Prototypen und prüft inwieweit dieser die gestellten Anforderungen erfüllt. 6.6 Zusammenfassung 59

60 60 Kapitel 6 Implementierung

61 7 EVALUATION Dieses Kapitel überprüft die Gebrauchstauglichkeit des Konzepts dieser Arbeit unter Betrachtung der Anforderungen aus Kapitel 3. Als Grundlage dient dabei der im vorangegangenem Kapitel beschriebene Prototyp, der bereits die generelle Umsetzbarkeit des Konzepts beweist. Im folgenden wird im Detail untersucht in welchem Ausmaß der Prototyp die Anforderungen erfüllt. Zur Betrachtung der nichtfunktionalen Anforderungen wurde eine Nutzerstudie geplant und durchgeführt. Im Besonderen wurden dabei die Aspekte Usability, Tutorial, Aufzeichnungsverlauf und Gamification studiert. Die Auswertung der Nutzerstudie zeigt die Herausforderungen des Konzeptes auf. Die Ergebnisse der Evaluation fließen in den Aggregationsprozess ein, um die darin existierenden Algorithmen hinsichtlich einer stabilen Datengrundlage für die Navigation zu optimieren. 7.1 TESTUMGEBUNG Die Nutzerstudie wurde in einer Büroumgebung durchgeführt. Charakteristisch dafür sind lange Flure mit mehreren kleineren Büroräumen zu beiden Seiten. Alle Räume dieser Umgebung waren mit einem eindimensionalen Barcode ausgestattet, was für die Eingabe von Start- und Zielwegpunkt genutzt wurde. Einzelne Räume waren darüber hinaus mit QR-Codes versehen. Die Position der Barcodes variierte, in den meisten Fällen waren diese jedoch im Türrahmen auf der linken oder rechten Seite auf Kopfhöhe angebracht. Die QR-Codes befanden sich im Gegensatz dazu neben oder direkt auf der Tür eines Raumes, sodass ein Nutzer beim Scannen des QR-Codes immer in Richtung Tür blickte. Die Büros befanden sich in der zweiten Etage eines größeren Gebäudes und sind über eine Treppe vom Foyer erreichbar. 7.2 TESTFÄLLE Im Rahmen der Testumgebung wurden die Tester angehalten zwei vorgegebene Wege aufzuzeichnen. Der erste Weg lag auf einer Etage und hatte eine Länge von circa 110 Metern, was eine ungefähre Laufzeit von etwas mehr als einer Minute bedeutet. Dieser Weg lässt sich mit 61

62 sechs Anweisungen beschreiben. In der Mitte des Weges mussten sich die Nutzer zwischen zwei parallelen Teilstrecken entscheiden, welche einen geringen Distanzunterschied hatten. Mit diesem Testfall sollte eine einfache Form von Aufzeichnungen getestet werden. Gleichzeitig sollten die Teilnehmer anhand dieses einfachen Testfalls mit der Anwendung vertraut werden. Der zweite Weg umfasste einen Stockwerkwechsel von der zweiten Etage zum Haupteingang im Erdgeschoss. Die Distanz und Zeit des zweiten Wegs waren vergleichbar mit dem ersten Weg. Eine weitere Besonderheit des zweiten Wegs war das Foyer, welches die Tester abschließend mittig durch eine Treppe betraten. Dieses Foyer bot mehr Bewegungsfreiraum als die Gänge zwischen den Büros. Mit diesem Weg sollte evaluiert werden, inwieweit komplexere Wegstecken eine größere Herausforderung bei der Aufzeichnung darstellen und ob das Konzept für Stockwerkwechsel geeignet ist. Das Ziel des ersten Weges war identisch mit dem Start des zweiten Weges. Somit lassen sich beide Wege bei der Navigation verbinden. Darüber hinaus teilen sich beide Wege eine Teilwegstrecke. Weiterhin wurden die Tester gebeten drei weitere Wege mit wählbarem Start und Ziel aufzuzeichnen. Dabei konnten die Teilnehmer frei entscheiden, welche Wegpunkte sie aufzeichnen. Auch Stockwerkwechsel wurden erlaubt. Damit sollte untersucht werden inwieweit die Nutzer motiviert wurden weitere Aufzeichnungen zu tätigen und ob sich Überlappungen im Pfadnetz ergeben. Alle Testfälle wurden als Gamification-Missionen abgebildet und somit direkt aus der Anwendung abrufbar. Die Testfälle können wie folgt zusammen gefasst werden: Testfall 1: Die Nutzer wurden gebeten eine vorgegebene Wegstrecke aufzuzeichnen: einfache Wegstrecke: ca. 110 Meter, sechs Anweisungen, kein Etagenwechsel alternative Teilstrecke in der Mitte des Wegs Testfall 2: Die Nutzer wurden gebeten eine weitere vorgegebene Wegstrecke aufzuzeichnen: komplexere Wegstrecke: Etagenwechsel, Durchquerung eines Foyers keine alternative Teilstrecke Testfall 3: Die Nutzer werden gebeten weitere Wegstrecken aufzuzeichnen: drei zusätzliche Aufzeichnungen mit selbst gewähltem Start und Ziel keine Begrenzung in der Wegpunktwahl Stockwerkwechsel möglich 7.3 TEILNEHMER Die Nutzerstudie wurde mit insgesamt 17 Teilnehmern durchgeführt. Die Teilnehmer der Nutzerstudie waren allesamt mit der Umgebung vertraut. Als Akademiker mit technischem Hintergrund und Mitarbeiter eines Softwarekonzerns lassen sich die Teilnehmer allgemein als technikaffin bezeichnen. Jedoch war nur ein kleiner Teil der Tester mit dem Umgang von iphone-anwendungen vertraut. Weiterhin hat auch nur ein kleiner Teil der Nutzer bis dato explizit zu Crowdsourcing Plattformen beigetragen. Die dazugehörenden Personen nannten dabei auch die verwandte Plattform Open Street Map. 88 Prozent der Teilnehmer gaben an, ein Interesse an einer Anwendung für die Navigation in Gebäuden zu haben. 62 Kapitel 7 Evaluation

63 7.4 DURCHFÜHRUNG Vor dem ersten Gebrauch der Anwendung wurden die Teilnehmer der Nutzerstudie über den Einsatzzweck der Anwendung und die grundlegenden Ansätze dieser Crowdsourcing-Plattform informiert. Den Umgang mit der Anwendung lernten die Nutzer direkt während der Benutzung, im Rahmen eines Tutorials. Dabei wurden die Nutzer Schritt für Schritt über den Programmablauf instruiert. Damit wurde das Ziel einer selbsterklärenden Anwendung verfolgt. Die Anweisungen zu den Testfällen erhielten die Nutzer direkt als Gamification-Mission und wurden für das Erfüllen in Form von Punkten belohnt. Ihren Rank im Vergleich zu den Kollegen konnten die Nutzer über eine Rangliste in der Anwendung erfahren. Über den gesamten Zeitraum des Tests wurden die Nutzer begleitet, um im Rahmen des Think- Aloud-Protokolls die Herausforderungen sowie Erfolgserlebnisse notieren zu können. Im Anschluss an die Tests wurden die Teilnehmer gebeten einen Fragebogen zu beantworten. Ein wichtiger Bestandteil war dabei die Bewertung der Usability der Anwendung, welche durch mehrere Fragen und Aussagen aufgeschlüsselt wurde. Die Teilnehmer bewerteten diese Fragen und Aussagen jeweils auf einer fünfstufigen Likert-Skala. Der vollständige Fragebogen befindet sich im Anhang der Arbeit. 7.5 AUSWERTUNG Die Durchführung der Nutzerstudie verlief erfolgreich. Alle drei Hauptkomponenten: die iphone Anwendung, der Crowdsourcing-Server und der Gamification-Server liefen über den gesamten Zeitraum der Nutzerstudie stabil. Wie in den folgenden Abschnitten detailliert erläutert wird, ermöglichte die Nutzerstudie viele wichtige Erkenntnisse. Besonders hinsichtlich der Aggregation von Aufzeichnungen tragen die Ergebnisse der Nutzerstudie zur Optimierung des Prozesses bei. Auch durch die Antworten in der Befragung ließen sich besondere Herausforderungen bei der Aufzeichnung von Wegstrecken erkennen Befragung Wie im vorangegangenen Abschnitt erläutert wurde, war der Hauptzweck der Befragung die Einschätzung der Usability der Client-Anwendung. Dazu wurde die Bewertung in mehrere Fragen untergliedert. Dies erhöht die Transparenz bei der Auswertung und ist für die Teilnehmer der Nutzerstudie leichter zu erfassen. Allgemein schrieben die Teilnehmer der iphone-anwendung eine gute bis sehr gute Usability zu. Dazu bewerteten die Teilnehmer die Teilbereiche Look & Feel, Reaktionsverhalten, Selbsterklärungsvermögen sowie QR- und Barcode Erkennung (Abbildung 7.1). Bei allen Teilbereichen vergaben mindestens 75 Prozent der Nutzer die Noten gut oder sehr gut (vier oder fünf Punkte auf der Likert-Skala). Negative Bewertungen (einen oder zwei Punkt(e) auf der Likert-Skala) wurden nicht vergeben. QR- und Barcode-Erkennung wurde als gesonderter Punkt aufgenommen, da diese Komponente eine größere Herausforderung bei der Implementierung bezüglich Geschwindigkeit und Zuverlässigkeit darstellte. Die positiven Bewertungen zeigten, dass diese Herausforderung bei der Implementierung gelöst wurde. Mehrfach 7.4 Durchführung 63

64 Look & Feel Reaktionsverhalten Selbstbeschreibungsvermıgen QR- & Barcodeerkennung Schlecht Sehr gut Schlecht Sehr gut Schlecht Sehr gut Schlecht Sehr gut Abbildung 7.1: Usability Bewertungen äußerten Teilnehmer, dass sie diese Methode der Wegpunkt-Identifikation jederzeit einer manuellen Eingabe des Wegpunkt-Namens (beispielsweise die Raumnummer) vorziehen würden. Wie die Usability wurde das Tutorial innerhalb der Anwendung durchweg positiv bewertet. Unterschiedlicher Meinung waren die Teilnehmer in Bezug auf die Frage, ob die Anwendung mehr Möglichkeiten bei der Eingabe von Richtungsinformationen benötige. 53 Prozent der Teilnehmer wünschten sich zusätzliche Richtungsoptionen wie halb-rechts, halb-links. 47 Prozent sahen dagegen keine Notwendigkeit von weiteren Anweisungen, zusätzlich zu dem Minimalset von Treppe rauf, Treppe runter, links, rechts, gerade aus und zurück. 76 Prozent der Teilnehmer sahen sich mindestens einmal mit der Situation konfrontiert, dass sie unentschieden waren, welche Richtungsanweisung sie eingeben sollten. Dieses Ergebnis deckt sich mit den Aufzeichnungen der Think-aloud Protokolle und ist eine große Herausforderung bei der Aufzeichnung von Wegstrecken, darauf soll in diesem Abschnitt noch näher eingegangen werden. Wiederum 75 Prozent der Teilnehmer fanden die Gamification-Komponenten der Anwendung motivierend, wobei kein Teilnehmer die dazu gehörenden Benachrichtigungen als störend empfand. Insgesamt würden 76 Prozent der Teilnehmer die Anwendung weiter benutzen und Wegstrecken aufzeichnen. Ein kleiner Teil der Teilnehmer (12 Prozent) wünschte sich zusätzlich eine größere Anzahl zu erfüllender Missionen. Die abschließende Frage, wie leicht die App im Allgemeinen zu benutzen war, beantworteten alle Nutzer mit einem leicht zu benutzen oder besonders leicht zu benutzen Gamification Wie bereits bei der Auswertung der Befragung angeklungen ist, stießen die Gamification- Komponenten des Prototyps auf positive Resonanz. Im Prototyp wurde bereits das Tutorial mit Gamification versehen, sodass die Nutzer von Anfang an mit den Gamification-Elementen vertraut gemacht werden. Sukzessive werden die Nutzer bei jeder getätigten Aufzeichnung über ihren Fortschritt informiert. Die dazu erscheinenden Benachrichtigungen wurden von den Teilnehmern der Nutzerstudie nicht als störend empfunden. Die 25 Prozent der Nutzer, die von den Spielmechaniken nicht motiviert wurden, konnten diese Benachrichtigungen einfach ignorieren. Die weiteren Gamification-User-Interface-Komponenten wurden zudem separiert und drängen sich dem Nutzer nicht auf. Während der Nutzerstudie ließ sich vermehrt beobachten, dass die Teilnehmer durch die Rangliste und Missionen angespornt wurden. Mehrere Nutzer waren erst mit sich zufrieden nachdem sie alle Missionen absolviert hatten. Bei einigen Teilnehmern ließ sich eine gewisse Faszination erkennen. Ausgehend von den Gamification-Ereignissen entschieden sie sich wiederholt spontan 64 Kapitel 7 Evaluation

65 noch eine weitere Aufzeichnung zu tätigen. Bei einem Nutzer war dieser Effekt besonders stark, sodass dieser sich letztendlich an die Spitze der Rangliste spielte. Durch den frühen Stand der SAP Gamification Platform konnte keine stabile Version für den Einsatz im Prototyp genutzt werden. Dies hatte jedoch kaum negativen Einfluss auf den Ablauf der Nutzerstudie. Lediglich das Laden der Gamification-Informationen über GPRS bedeutete eine kurze Wartezeit für den Nutzer. Das System lief über den gesamten Testzeitraum absturzfrei Herausforderungen bei der Aufzeichnung Im Verlauf der Nutzerstudie ließen sich einige Herausforderungen erkennen, mit denen sich die Nutzer konfrontiert sahen. Wie schon bei der Auswertung der Fragebögen festgestellt wurde, ist die Definition von Kreuzungen nicht trivial. Die Teilnehmer der Studie handelten unterschiedlich beim Aufzeichnen von ein und derselben Wegstrecke. Besonders Ausgänge und Weggabelungen, bei denen der abzweigende Weg eine Sackgasse ist, wurden von einigen Nutzern ignoriert, von anderen wiederum aufgezeichnet. Besonders bemerkenswert ist, dass einige Teilnehmer inkonsistent handelten, beispielsweise einen Ausgang als Kreuzung aufzeichneten, den nächsten Ausgang jedoch ignorierten. Das Ignorieren oder Vergessen von Weggabelungen war jedoch nur zu beobachten, wenn die Teilnehmer ihre Bewegungsrichtung beibehielten und der aktuelle Weg des Nutzers nicht durchgehend von einem anderen Weg gekreuzt wird. Folglich trifft eine Grundannahme nicht mehr zu, nach der die Crowdsourcing Plattform das Wissen über alle Abzweigungen eines aufgezeichneten Weges hat. Die Definition von Kreuzungen beugt sich bei der Aggregation der Mehrheit. Innerhalb der Nutzerstudie wurden bei den bestätigten Aufzeichnungen alle Kreuzungen erfasst. Ignorierte oder vergessene Abzweigungen traten somit nur bei unbestätigten Aufzeichnungen einzelner Personen auf. Insgesamt bekommen die aufgezeichneten Laufzeiten der Nutzer so ein hohes Gewicht und sind bei der Navigation von Bedeutung. Auch wenn diese Laufzeiten von Person zu Person variieren, bieten sie eine Form der Distanzmessung, die wesentlich genauer als die Schrittzählung funktioniert. Besonders im Falle von unbestätigten Aufzeichnungen, bei denen die Fehlerwahrscheinlichkeit bei der Kreuzungsangabe höher ist, wird diese Distanzmessung benötigt. Eine weitere Beobachtung der Nutzerstudie war die Eingabe von mehreren Anweisungen für eine Kreuzung oder einen Wegpunkt. Beispielsweise anstelle einer Zurück Anweisung wurden zwei aufeinander folgende Anweisungen: Links und Links oder Rechts und Rechts aufgezeichnet, womit jeweils eine Drehung um die eigene Achse, um 180 Grad gemeint ist. Auch in diesen Situationen ist die Berücksichtigung der Zeit unabdingbar um die Verbindung zwei kurz aufeinander folgender Anweisungen zu erkennen. Die Nutzer wurden beim Benutzen der Anwendung instruiert die erste Richtungsanweisung in Blickrichtung zum QR- oder Barcode einzugeben, damit die Nutzer bei der Navigation die gleiche Startposition wie der vorangegangene Crowdsourcing-Nutzer einnehmen können. Die Anweisung wurde von einigen Teilnehmern unabsichtlich ignoriert. Stattdessen starteten diese Teilnehmer die Aufzeichnung intuitiv entweder mit Blick zur Tür oder mit dem Rücken zur Tür des Wegpunktes. Dies lässt sich durch die vorwiegende Platzierung der Barcodes im Türrahmen erklären so ist die Aufzeichnung ungewohnt vom Blick auf die Innenseite des Türrahmens zu starten. An Wegpunkten ohne Türen hielten sich die Nutzer an die Anweisung und starteten die Aufzeichnung in Blick auf den QR- oder Barcode, da diese intuitiv als Referenzpunkt anerkannt wurden. Da die Intuition der Nutzer jedoch verschieden ist, wie im Falle der Türen, sind Paradigmen wichtig. Dazu gehört die Festlegung einer Blickrichtung, das heißt Orientierung des Nutzers, beim Start der Aufzeichnung und Navigation. Bei der Nutzerstudie hätte eine durchgängige Platzierung der QR- oder Barcodes an oder neben der Tür für weniger Kollision zwischen der Intuition der 7.5 Auswertung 65

66 Teilnehmer und den vorgeschriebenen Paradigmen gesorgt. Das Konzept der infrastrukturlosen Navigation im Gebäude widersprach jedoch einer großflächigen Anbringung solcher Tags. Eine weitere Nutzerstudie könnte stattdessen das bestehende Paradigma parametrisieren, sodass bei Wegpunkten an Räumen die Aufzeichnung immer im Blick zur Tür beginnt unabhängig einer möglichen Tag-Platzierung. Die aufgezeichneten Laufzeiten enthielten bei der Nutzerstudie einen Anteil an Bedenkzeit. Bei der Navigation können somit die aufgezeichneten Zeiten nicht als reine Laufzeiten angenommen werden. Da die Teilnehmer der Nutzerstudie teilweise die Eingabe der letzten Richtungsanweisung vergaßen und stattdessen lediglich den QR- oder Barcode scannten, ist die Wahrscheinlichkeit für eine erfolgreiche Navigation des inversen Pfades niedrig. Ohne Abschlussanweisung würde dem inversen Pfad die erste und wichtigste Anweisung fehlen, die Navigation würde den Nutzer bei der Navigation folglich in eine falsche Richtung leiten. Auffällig bei der Nutzerstudie war die hohe Anzahl von Aufzeichnung mit demselben Start- und Zielwegpunkt aber unterschiedlichen Anweisungen. Offensichtlich neigen die Teilnehmer zu unterschiedlichen Vorgehensweisen beim Aufzeichnen von Wegstrecken, auch wenn sie auf gleicher Weise instruiert wurden. Bei der Aggregation ergibt sich so ein heterogenes Wegenetz. Im Sinne einer konsistenten Navigation sollte das Wegenetz jedoch möglichst einheitlich sein. Ein Ansatz dazu ist die Einführung einer Expertengruppe. Die Personen dieser Gruppe wurden speziell instruiert und sind mit den Abläufen bei Aggregation und Navigation vertraut. Dadurch bieten die Aufzeichnungen dieser Experten eine verlässliche Qualität. Die Expertengruppe soll dabei nur einen sehr geringen Prozentsatz der Gesamtanzahl der Nutzer ausmachen. Das grundsätzliche Prinzip von Laien-Nutzern soll dadurch nicht gebrochen werden. Der Nutzen der Expertengruppe liegt somit weniger in der Menge ihrer Aufzeichnungen, als in deren Qualität. Die Aufzeichnung der Experten können dazu benutzt werden, die Aufzeichnungen anderer Nutzer zu bewerten. Tätigt ein Nutzer eine Aufzeichnung, die identisch der Aufzeichnung eines Experten ist, erhöht sich die Bewertung des Nutzers. Trifft diese Übereinstimmung in mehreren Aufzeichnungen des Nutzers zu, kann der Nutzer selbst zum Experten erklärt werden, da er offensichtlich dieselbe Vorgehensweise wie ein Experte beherrscht. Wird ein Nutzer so zum Experten erklärt, können dessen Aufzeichnungen wiederum zum Bewerten anderer Nutzer verwendet werden, die dadurch möglicherweise auch zu Experten werden. Das Expertenkonzept gleicht einem Schneeballsystem. Die kleine Expertengruppe hat damit Auswirkungen auf einen größeren Teil der Nutzer. Ideal ist der Einsatz von Experten in Bereichen mit einer höheren Nutzerzahl, da in diesen Gebieten mehr übereinstimmende, jedoch auch konträre Aufzeichnungen existieren, sodass die Experten durch ihre Aufzeichnungen viele Nutzer evaluieren Verbesserungsvorschläge der Studienteilnehmer Im Anhang der Befragung hatten die Teilnehmer die Möglichkeit eigene Anmerkungen oder Verbesserungsvorschläge anzubringen. So wurde vorgeschlagen, dass der digitale Kompass des Endgeräts für die Bestimmung der Orientierung am Startwegpunkt der Aufzeichnung verwendet wird. Diese Funktion würde eine grundsätzliche Erweiterung des Konzept darstellen. Zur Feststellung der Gebrauchstauglichkeit des fundamentalen Konzepts wurde der Nutzer zunächst als Hauptinformationsquelle definiert. Eine anschließende Forschung könnte ein hybrides Konzept aus CINA und existierenden sensorbasierten Lösungen evaluieren, welches den Vorschlag des Nutzers einbezieht. 66 Kapitel 7 Evaluation

67 Gleich mehrere Male wurden Anmerkungen bezüglich des Bezugspunktes für Start und Ziel der Aufzeichnung gegeben. Ein Teilnehmer schlug vor, die Türen als Bezugspunkt zu benutzen, anstelle der Barcodes. Dieser Umstand wurde bereits eingehend im vorangegangenen Abschnitt betrachtet. Wiederum mehrmals wurde eine Fotofunktion vorgeschlagen. So könnten während der Aufzeichung Fotos von Kreuzungen gemacht werden, die bei der Navigation abrufbar sind. Dies kann besonders bei komplexen Kreuzungen hilfreich sein, beispielsweise im Foyer der Testumgebung. Zusätzlich sind Annotationen auf den Fotos denkbar. Da eine solche Fotofunktion maßgeblich den Arbeitsfluss der Aufzeichnung bremsen würde, ist diese Funktion im Basiskonzept nicht vorgesehen. Einen berechtigten Vorschlag gab es zu einer Rückgängig machen Funktionen beim Eingeben von Richtungsanweisungen. Da die Thinking-Aloud-Protokolle keine Fehlaufzeichnungen verzeichneten, war das Fehlen dieser Funktion im Prototyp nicht kritisch. Weiterhin zeigten die Protokolle, dass potentielle Fehleingaben nicht aus einem ungünstigen UI-Design resultieren, sondern aus der kognitiven Belastung bei der Entscheidung an Kreuzungen. Diese Herausforderung zeigte sich in dem Maße erst bei der Durchführung der Nutzerstudie. Das bereits angesprochene Hinzufügen von feiner abgestuften Richtungsanweisungen (halb-links und halb-rechts) wurde von einem Teilnehmer noch explizit vorgeschlagen. Gleichzeitig gab diese Person an, dass diese zusätzlichen Richtungsanweisungen bei der Nutzerstudie nicht zwingend nötig waren. Eine andere Person hätte zusätzlich gern eine Erweiterung zu einer hybriden Indoor- Outdoor-Lösung gesehen, durch Anweisungen zum Betreten und Verlassen von Gebäuden. Diese Funktionen lassen sich bislang nur durch eine Unterbrechung der Aufzeichnung an dem Ausoder Eingang erreichen. Der Start- oder Zielwegpunkt kann so als Ein-/Ausgang markiert werden. Teilweise wurden auch schwierigere Vorschläge angebracht. So wurde vorgeschlagen, dass die Anwendung Richtungsanweisungen nur an Kreuzungen entgegennimmt und den Nutzer dazu über das Erreichen einer Kreuzung informiert und schließlich an das Eingeben einer Anweisung erinnert. Dieser Vorschlag wurde offensichtlich durch ein Missverständnis des Konzepts hervorgerufen. Der Vorschlag betont jedoch die unterschiedlichen Kreuzungsinterpretationen der Nutzer und die damit einhergehende Herausforderung bei der Aufzeichnung. Die Think-Aloud-Protokolle bestätigen diese Schwierigkeiten speziell für diese Person Entstandenes Wegenetz Basierend auf den Daten aus der Nutzerstudie entstanden zwei Graphen, die das Wegenetz auf unterschiedliche Weise repräsentieren. Der erste Graph illustriert alle aufgezeichneten Wegstrecken in einer rohen Form (Abbildung 7.2). Die Knoten des Graphs repräsentieren die Wegpunkte. Die Kanten des Graphs stellen die Wegstrecken zwischen den Wegpunkten dar, wobei die Kanten gerichtet sind und so eindeutig Start- und Zielwegpunkt identifizieren. Das Gewicht der Kanten entspricht der Laufzeit für die Wegstecke. Insgesamt besitzt der Graph 71 Kanten und 34 Knoten, erstellt durch 17 Nutzer. Eine auffällige Eigenschaft ist, dass der Graph einen Multigraph repräsentiert. Besonders viele Mehrfachkanten existieren zwischen Wegpunkten, die Bestandteil von Missionen waren. Die sind somit die Wegstrecken, zu deren Aufzeichnung die Nutzer direkt aufgefordert wurden. Abseits dieser vorgegeben Wegstrecken existiert nur eine Mehrfachkante für ein Wegpunktpaar. Der zweite Graph illustriert die aggregierten Wegstrecken als Pfade (Abbildung 7.3). Die Anzahl der Kanten reduzierte sich deutlich auf 38. Aus der Datenbasis der Nutzerstudie ergaben sich keine Mehrfachkanten für den Pfad-Graph, wobei dies generell nicht ausgeschlossen ist. Die Zahl der 7.5 Auswertung 67

68 Abbildung 7.2: Visualisierung aller Aufzeichnungen als Graph bestätigten Pfade macht nur einen kleinen Teil der Pfade aus. Im Graph wurden die entsprechenden Kanten fett und schwarz hervorgehoben. Das Gewicht der Kanten entspricht der Bewertung des Pfades. Wie im Graph deutlich wird, besitzen die bestätigten Pfade eine wesentlich höhere Bewertung als die unbestätigten Pfade. Dies spiegelt sich auch in der Qualität der Pfade wider. So zeichnen sich die bestätigten Pfade durch eine hohe Qualität aus. Die unbestätigten Pfade besitzen hingegen eine gemischte Qualität, was durch die unterschiedlichen Bewertungen zum Ausdruck gebracht wird. Wie der Graph der Aufzeichnungen so ist auch der Pfad-Graph ein gerichteter nicht-transitiver Graph, gegeben durch die Aufzeichnungsrichtung der Pfade. Für die Navigation kann der Graph jedoch in einen transitiven Graphen überführt werden Fazit Durch die erfolgreiche Durchführung der Nutzerstudie wurde die Tauglichkeit des Konzepts bewiesen. Mit dem Prototypen waren die Teilnehmer in der Lage Wegstrecken im Gebäude aufzuzeichnen. Dafür war keine lange Einarbeitungszeit nötig. Durch die Selbstbeschreibungsfähigkeit der Client-Anwendung und aufgrund der Umsetzung für die ios-plattform liegt die potentielle Nutzerzahl im dreistelligen Millionenbereich. Die Befragung zeigte das grundsätzliche Interesse an einem Indoor-Navigationsassistenten. Dabei gaben die Nutzer des Prototypen an, dass sie freiwillig und selbstständig Wege aufzeichnen würden, was den Crowdsourcing-Ansatz bekräftigt. Das während der Nutzerstudie entstandene Wegenetz beweist, dass die einzelnen Beiträge der Nutzer in eine Datenbasis für die Navigation überführt werden können. Die parallele Arbeit von Wang [37] zeigt im Detail, wie dieses Wegenetz eine Navigation ermöglicht. Bedingt durch den Crowdsourcing-Ansatz besitzen die Daten eine schwankende Qualität. Eine entsprechend große Nutzerbasis trägt dabei zu einer Qualitätssteigerung und -sicherung bei. Zur Bestimmung der kritischen Masse ist eine anschließende Forschung nötig. 68 Kapitel 7 Evaluation

69 Abbildung 7.3: Pfad-Graph 7.6 OPTIMIERUNG DER AGGREGATION Aus den Beobachtungen während der Nutzerstudie und den daraus folgenden Erkenntnissen erfolgten Optimierungen für die Aggregationsalgorithmen der Crowdsourcing-Server-Anwendung des Prototypen. Als erster Schritt zur Optimierung wurde jeweils die erste Aufzeichnung der Nutzer um einen Punkt abgewertet, da diese eine grundsätzlich niedrigere Qualität aufwies. Dadurch erhalten diese Aufzeichnungen ein leicht niedrigeres Gewicht bei der Aggregation zu Pfaden und somit auch bei der Navigation. Wird ein Nutzer auf Basis einer solchen Aufzeichnung durch das Gebäude navigiert und erreicht erfolgreich sein Ziel, kann die entsprechende Aufzeichnung aufgewertet werden. Die Qualität der Aufzeichnung wurde somit bestätigt. Stimmt die erste Aufzeichnung jedoch mit einer Aufzeichnung eines anderen Nutzers überein, erfolgt keine initiale Abwertung, da auch in diesem Fall die Aufzeichnung bestätigt wurde. Der zweite Schritt zur Optimierung war die Einführung eines Rollenmodells für die Nutzer. Damit ist es möglich jedem Nutzer eine Rolle zuzuweisen. Zu den aktiven Rollen im Prototyp gehört der Experte und der Nutzer. Jede Rolle wird durch eine Fähigkeitenliste bzw. Berechtigungsliste definiert. Die Nutzer-Rolle ist die Voreinstellung für alle Nutzer, die Fähigkeitenliste beinhaltet die Berechtigung zum Übermitteln von Aufzeichnungen. Die Experten-Rolle besitzt zusätzlich die Berechtigung zum Bewerten von Aufzeichnungen. Bei der Aggregation wird die Bewertungsberechtigung geprüft. Besitzt ein Nutzer diese Berechtigung, wird er als Experte identifiziert. Bei der Bewertung des Nutzers geht die Anzahl der Aufzeichnungen im Fall eines Experten doppelt ein. Die Bewertung eines Experten ist entsprechend besser als bei einem normalen Nutzer. Bei der Bewertung von Aufzeichnungen und den daraus entstehenden Pfaden mit Hilfe von Experten gelten ähnliche Regeln wie sie bereits im vorangegangenen Abschnitt erwähnt wurden. Die Pfade, zu denen ein Experte beigetragen hat, erhalten so eine bessere Bewertung. Zudem erhalten reguläre Nutzer zusätzliche Bewertungspunkte, wenn sie Aufzeichnungen besitzen, die mit der Aufzeichnung eines Experten übereinstimmen. 7.6 Optimierung der Aggregation 69