Reisebegleitung auf mobilen Endgeräten im öffentlichen Verkehr

Transkript

1 Großer Beleg Reisebegleitung auf mobilen Endgeräten im öffentlichen Verkehr 02. April 2012 Tristan Heinig Mat.-Nr.: Betreuer Dipl.-Inf. Christine Keller Verantwortlicher Hochschullehrer Jun.-Prof. Dr. Thomas Schlegel

2

3 Erklärung Hiermit erkläre ich, die vorliegende Arbeit mit dem Titel Reisebegleitung auf mobilen Endgeräten im öffentlichen Verkehr selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate kenntlich gemacht habe. Dresden, den 02. April 2012 Tristan Heinig

4

5 Inhaltsverzeichnis 1 Einleitung Motivation Zielstellung Gliederung NEAR Field Communication NFC-Grundlagen Technische Grundlagen Energieversorgung Datenübertragung Mehrfachzugriff Betriebsarten NFC-Forum Das Forum NFC Forum Geräte NDEF Speicherung NFC-spezifische Typen SNEP NFC-Tags Überblick NFC Forum Tag Type Type Type Type

6 Speicherung Anwendungsfälle Smart Poster Definition Endverbrauchermotivation Herstellung eines Smart Posters Schreibschutz Design Nutzerszenarien/Anwendungsfälle Smart Poster von Verbrauchern NFC im Vergleich NFC und RFID NFC und Bluetooth NFC und WLAN NFC und Infrarot NFC und CWUSB Zusammenfassung Mobile Ticketing Technik Bestellverfahren Prüfungsverfahren Abrechnung Ticketing im öffentlichen Verkehr VDV-Kernapplikation Ticketing mit NFC Vorteile Zugangssysteme NFC-Tags im ÖPNV Herausforderungen Mobile Reisebegleitung Verwandte Arbeiten

7 1.1 Motivation 4.2 Kernszenario Erweiterung des Szenarios NFC Szenarien Konzeptionelle Analyse Benutzeroberfläche Ansichten Benutzerführung Datenmodell Systemkomponenten Systemzustände Plug-In Konzept Filter Technische Analyse Android Anwendungskomponenten Versionen NFC Tag Dispatch System Google Wallet Positionsermittlung Methoden Implementierung Austausch von Inhalten Prototypische Umsetzung Architektur GUI Realisierung NFC-Verarbeitung Service-Komponente Verbindungsimport über Öffi Wetter-Plugin

8 1 Einleitung 7.7 Hinweise Zusammenfassung und Bewertung Zusammenfassung Auswertung Ausblick Anhang Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Programmcodeverzeichnis Literaturverzeichnis

9 1 Einleitung 1.1 Motivation Die Entwicklungsanstrengungen im Bereich mobiler Endgeräte nehmen gegenwärtig kaum überschaubare Dimensionen an. Insbesondere das Smartphone, ein mobiles Telefon mit leistungsstarken Prozessor und computernaher Funktionalität, etabliert sich als Innovationsmotor und sorgt für das Aufkommen neuer Industriezweige und Softwarefirmen. Allein schon der Erfolg der Firmen Apple und Google mit mobilen Geräten und Betriebssystemen zeigt das Potential dieser Plattform [App12]. Das große Interesse an solchen Geräten ergibt sich zum einen aus den vielfältigen zentral integrierten Technologien und zum anderen aus dem mobilen Charakter des Systems. Dieses definiert sich durch orts- und zeitunabhängige Verbindungen, wodurch eine ebensolche Kommunikation angeboten wird. Kommunikation ermöglicht die Integration von Diensten verschiedenster Art. Insbesondere der Einsatz als mobiles Bezahlsystem motiviert zur Konzeption zahlreicher Szenarien. Der Gedanke dahinter sieht eine schnelle, flexible und robuste Realisierung mit Hilfe mobiler Geräte vor. Smartphones kombinieren diesen mit einem hohen Potential an Usability (Benutzerfreundlichkeit). Damit wird das Telefon zur elektronischen Geldbörse. Dafür muss allerdings geklärt werden, wie elektronisches Geld die Händler und Anbieter erreicht. Die Antwort darauf lautet immer öfters NFC, ein Kürzel für Nahfeld-Kommunikation. Dabei handelt es sich um eine Technik zur drahtlosen Datenübertragung auf kurzen Distanzen. Diese Technik wird zunehmend in mobilen Telefonen integriert [EET12] und Dokumente zu diesem Thema bestätigen die Zweckmäßigkeit der Nahfeld-Kommunikation [MPS12]. Daneben existieren bereits Realisierungen, die elektronisches Bezahlen erlauben. In diesem Kontext fällt oft der Begriff Mobile Ticketing. Das liegt daran, dass mobile Ticketing das Prinzip des elektronischen Zahlens in seinen Eigenschaften definiert. Im Raum stehen nur die Begriffe Mobile Ticketing, Nahfeldkommunikation und mobile Nutzergeräte, die in einer losen Verbindung existieren. Substanz erhält dieses Konstrukt, wenn ein Kontext geschaffen wird, der eine hohe Verwendung und Interaktion vorsieht. Hierfür

10 1 Einleitung eignet sich der Bereich des Öffentlichen Personennahverkehrs (ÖPNV). Der Mobilitätscharakter verbirgt sich bereits im Begriff ÖPNV, wodurch der Einsatz von mobilen Geräten erwägenswert ist. Im ÖPNV kommen konventionell Fahrscheine zum Einsatz, die durch mobile elektronische Tickets ersetzt werden können. Ein elektronisches Ticket kann auf elektronischem Weg bezogen und beglichen werden. Moderne Smartphones sind zunehmend mit NFC-Technik ausgerüstet. NFC ist in der Lage elektronische Daten, damit Ticket und reale Geldbeträge zu transferieren. Damit offenbart sich der Bereich des ÖPNV als relevante Basis für ein vitales Ökosystem aus den Systementitäten Mobile Ticketing, Nahfeldkommunikation und mobile Nutzergeräte. 1.2 Zielstellung Die folgende Arbeit sieht vor, einen detaillierten Überblick über Nahfeld-Kommunikation zu geben. Dabei wird insbesondere auf technische Merkmale anhand verfügbarer Spezifikationen eingegangen. Nicht selten reduzieren tangierende Ausarbeitungen diesen Abschnitt auf konzeptionelle Beschreibung. NFC bildet jedoch die Grundlage für eine geräte- und systemübergreifende Kompatibilität, die insbesondere in heterogenen ÖPNV-Strukturen zwischen Scheitern und Erfolg bestimmen kann. Die technische Basis soll ein Verständnis entwickeln für den Einsatz von NFC im mobile Ticketing. Dafür erfolgt ein Überblick über gängige Strukturen und Verfahren. Dieser ist notwendig, um derzeit noch vorhandene Hürden einschätzen zu können. Lösungsansätze können dadurch entwickelt werden. Auf eine konkrete Lösung wird verzichtet. Die Nahfeld-Kommunikation primär mit dem elektronischen Bezahlen in Verbindung zu bringen, ist im Grund nicht falsch, wird ihr aber nicht gerecht. Sie erweist sich als vielfältige Kommunikationsart. Dies wird zum einen durch eine Aufzählung verschieden Anwendungsfälle vermittelt. Dabei wird im Besonderen auf die Verwendung von kleinen Speicherbausteinen, den NFC-Tags eingegangen. Zum anderen wird sekundär ein Prototyp entwickelt, der anhand eines Reisebegleitungskonzept die Interaktion per NFC verdeutlicht. Die Anwendung legt gleichzeitig die Fähigkeiten mobiler Dienste im ÖPNV offen. Ziel ist dem Nutzer für eine gegebene Verbindung einen elektronischen Begleiter zur Verfügung zu stellen, der die Nutzung des ÖPNV erleichtert. NFC wird dabei als Erweiterung verstanden. Der Prototyp präsentiert sich als Referenzimplementation, bei der unterschiedliche Technologien, Quellen, Formate und Bedürfnisse auf mobilen Geräten kombiniert werden. 5

11 1.3 Gliederung 1.3 Gliederung Die Arbeit beginnt mit der Betrachtung der Nahfeldkommunikation. Es werden die vorhandenen Spezifikationen herangezogen und zusammengefasst, die physikalischen Grundlagen aufgeführt, Formate und Protokolle beschrieben. Ferner werden passive Tags betrachtet und aufbauend darauf Anwendungsbeispiele erläutert. Zur Vollständigkeit wird ein Vergleich mit anderen drahtlosen Kommunikationstechnologien aufgeführt. Im Anschluss (3. Kapitel) findet sich ein Überblick über Mobile Ticketing, der den aktuellen Stand, technische Grundlagen, sowie die Integration von NFC vermittelt. Der Bezug zum ÖPNV wird am Beispiel der VDV-Kernapplikation verdeutlicht. Kapitel 4 setzt sich mit den Anforderungen einer mobilen Reisebegleitung auseinander und beschreibt die Kernfunktionalitäten, ebenso wie denkbare Erweiterungen. Das folgende Kapitel 5 analysiert die Anforderungen hinsichtlich softwaretechnischer Aspekte und präsentiert das Konzept einer protypischen Reisebegleitung. Kapitel 6 geht auf die Umsetzung des Konzeptes ein, erklärt grundlegende Implementierungstechniken und beschreibt relevante Umsetzungsstrategien. Die Arbeit endet mit einer Zusammenfassung der gewonnenen Erkenntnisse, erfasst Schwierigkeiten und Herausforderungen, versucht sich in einer kritischen Analyse der prototypischen Umsetzung und zeigt Möglichkeiten für anschließende Untersuchungen auf. 6

12 1 Einleitung 7

13 2.1 NFC-Grundlagen 2 NEAR Field Communication 2.1 NFC-Grundlagen Die Entwicklung der Near Field Communication (NFC), zu Deutsch Nahfeldkommunikation, wurde primär vom Halbleiterhersteller NXP Semiconductors zusammen mit dem Elektronikkonzern Sony vorangetrieben. Diese beiden Akteure gelten mit den Produkten MIFARE 1 und FeliCa 2 als marktführend im Bereich der kontaktlosen Chipkartentechnik. Um die Kompatibilität zu diesen Standards zu gewährleisten, werden diese in den NFC- Spezifikationen unterstützt [STT09]. Im Unterschied zu NFC-Forum Standards basieren MIFARE und FeliCa nicht auf offenen Normen und beinhalten daher proprietäre Verschlüsselungsmethoden. Mit der Nahfeldkommunikation erfolgt eine Abgrenzung zur RFID Technologie in dem die strikte Trennung in Lesegeräte und Transponder 3 aufgehoben wird. Bei der Radio Frequency Identification gibt es eine feste aktive Einheit, welche eine passive Einheit mit Strom versorgt. Der Datenaustausch erfolgt nach dem Frage-Antwort-Prinzip, bei dem das Lesegerät die Kommunikation einleitet. NFC-Geräte verfügen ebenso über die Möglichkeit, kontaktlose Chipkarten mit Strom zu versorgen, mit anderen NFC-Geräten zu kommunizieren und selbst lesbare Chipkarten zu emulieren. Die Chipkartenkommunikation basiert auf der Norm ISO/IEC 14443, die Gerätekommunikation auf den Normen ISO/IEC und ECMA MIFARE von NXP Semiconductors ist die weltweit meistgenutzte kontaktlose Chipkartentechnik. Sie entspricht den ISO-Standards ISO 7816 bzw. ISO 14443A [Wik]. 2 FeliCa (Kurzform für Felicity Card) ist ein kontaktloses RFID Smartcard System von Sony und arbeitet auf ISO/IEC [Wik]. 3 Ein Transponder ist ein Funk-Kommunikationsgerät, das eingehende Signale aufnimmt und automatisch beantwortet bzw. weiterleitet [Wik]. 8

14 2 NEAR Field Communication Technische Grundlagen Die Nahfeldkommunikation orientiert sich zu großen Teilen an RFID-Standards. Das resultiert in ein gewisses Maß an Rückwärtskompatibilität und ermöglicht eine leichte Integration in bestehende Infrastrukturen. Dies ist ein Grund für das Interesse an NFC-Technik hinsichtlich bestehender Ticketing-Lösungen mit RFID. RFID lässt sich in drei Systemgruppen einteilen. Kapazitiv gekoppelte Systeme arbeiten auf einem hochfrequenten elektrischen Feld zur Energie und Datenübertragung. Induktiv gekoppelte Systeme dagegen nutzen ein hochfrequentes magnetisches Feld. Realisierungen der letzten Gruppe nutzen die elektromagnetische Wellenausbreitung und Reflektion von Energie und werden UHF (Ultra High Frequency) Backscatter-Systeme genannt. NFC basiert auf induktiv gekoppelten Systemen. Leiterspulen werden unter Strom gesetzt, wobei ein magnetisches Nahfeld erzeugt wird. Dieses ist geeignet, um eine Kopplung von Leseeinheit und Transponder herzustellen. Die standardisierte Arbeitsfrequenz beträgt 13,56 MHz, die Bandbreite +- 7 khz. NFC- Transponder müssen magnetische Feldstärken von Hmin = 1.5 Am -1 bis Hmax = 7.5 Am -1 unterstützen. Um Kollisionen zu vermeiden, ist eine Erkennung von Hochfrequenzfeldern mit einer minimalen Feldstärke von Hschwelle = Am -1 zu gewährleisten. NFC Geräte sind in der Lage mit Übertragungsraten von 106 kbps 4, 212 kbps und 424 kbps zu kommunizieren. Die Bitrate wird am Anfang einer Kommunikation vom Initiator festgelegt [RNP06] Energieversorgung Energie- und Datenübertragung basieren auf dem Funktionsprinzip von Transformatoren. Voraussetzung sind zwei gekoppelte Spulen. Eine Stromänderung in einer der Spulen hat zur Folge, dass sich der Magnetfluss in beiden ändert. Diese Änderung führt zur Induktion von Spannung in der zweiten Spule. In der Eigenschaft der Energieversorgung können drei Arten unterschieden werden. Aktive Transponder besitzen eine eigene Energieversorgung und erzeugen ein eigenes hochfrequentes Signal. Passive Transponder nutzen die Energie aus dem erzeugten Feld des Lesegeräts. Semipassive besitzen eine Energieversorgung größtenteils Batterien kommunizieren jedoch, wie passive Transponder über das Hochfrequenzfeld des Lesegerätes. 4 kbps (kilobit per second) Einheit für die Datenrate. 9

15 2.1 NFC-Grundlagen Datenübertragung Kommen (semi-) passive Systeme zum Einsatz, sind die Rollen von Lesegerät und Transponder fest verteilt. Die Übertragung von Daten findet dann auf zwei Kanälen statt, wobei jeder für eine Übertragungsrichtung zwischen den Kommunikationseinheiten reserviert ist. Bei aktiven Systemen gibt es keine Trennung der Kanäle. Es wird immer nur ein Kanal genutzt. Die Rolle von Lesegerät und Transponder kann wechseln. Beide Kommunikationseinheiten können aktiv lesen und schreiben. In der Nahfeldkommunikation kommen vorranging digitale Modulationsverfahren mit einem Träger zum Einsatz. Dabei wird das Hauptsignal mit einem Hilfssignal dem Träger der Nutzdaten - moduliert und an das Empfangsgerät gesendet [RNP06; RoL10]. n-ask bzw. n-ask (Amplitude-shift keying, engl. Amplitudenumtastung). Jede unterschiedliche Amplitude des Trägersignals repräsentiert eines von n Zeichen. n-psk (Phase-shift keying, engl. Phasenumtastung). Die Amplitude und Frequenz des Signals bleiben unverändert. Stattdessen repräsentiert eine unterschiedliche Phasenlage eines von n-zeichen. n-fsk (Frequency-shift keying, engl. Frequenzumtastung). Hier wird durch Änderung der Frequenz eines von n-zeichen repräsentiert. Abbildung 2.1: zeigt Ergebnisse der unterschiedlichen Modulationsverfahren. Das obere Signal repräsentiert Daten. Die unteren zeigen das Ergebnis nachdem die Daten auf ein Sinussignal dem Verfahren entsprechend moduliert wurden. Aus [DBF12] Vor dem Modulationsverfahren werden Nutzdaten codiert, um sie an das Verfahren anzupassen. Zum Einsatz kommen dabei folgende Codierungsverfahren. NRZ-L-Codierung (Non-return-to-zero level) [NRZ11] 10

16 2 NEAR Field Communication RZ-Codierung (Return-to-zero) [RZ11] Manchestercodierung [WMC11] Millercodierung [WDF11] Modifizierte Millercodierung [MFM11] Pulslagen-Codierung [LaR10] Erfolgt eine Datenübertragung vom Lesegeräte zum Transponder, spricht man vom Uplink, bei dem das Trägersignal, wie oben beschrieben, mit dem Datenstrom moduliert wird. Downlink hingegen wird die Übertragungsrichtung vom Transponder zum Lesegerät genannt. Dieser kommt bei (semi-) passiven Systemen zum Einsatz und nutz zur Dateneinspeisung die Lastmodulation. Diese unterscheidet sich in ohmsche und kapazitive Lastmodulation. Im Ersten Fall handelt es sich um eine Amplitudenmodulation und im zweiten Fall wird diese um eine Phasenmodulation erweitert. Um ein energiearmes Datensignal vom energiereichen Trägersignal zu extrahieren, wird eine Modulation mit einem Hilfsträger hinzugezogen [LaR10] Mehrfachzugriff Bei der drahtlosen Kommunikation können sich verschiedene Geräte bei der Kommunikation gegenseitig stören. In einem NFC-System kommt hinzu, dass die Trennung zwischen Lesegerät und Transponder wegfällt. Bei der Nutzung des geteilten Übertragungskanal kann es zu Kollisionen und Störungen kommen, indem sich Signale und Daten überlagern. Für die Behandlung dieser Störungen kommen Mehrfachzugriffsverfahren zum Einsatz. Diese lassen sich kategorisieren in FDMA ( Frequency Division Multiple Access). Mehrere Frequenzbereiche je ein Bereich pro Teilnehmer. TDMA ( Time Division Multiple Access). Zeitliche Trennung. Zeitbereich für exklusive Nutzung je Teilnehmer CDMA (Code Division Multiple Access). Gemeinsamer Frequenzbereich mit codierten Trägersignalen. Rekonstruktion bei Empfänger. SDMA (Space Division Multiple Access). Räumliche Trennung der Signale über Leistung und Ausrichtung. In der Nahfeldkommunikation kommen vorwiegend räumliche und zeitliche Verfahren zum Einsatz. Räumlich, da die Übertragungsdistanz sehr gering ist. Die zeitliche Trennung der Signale wird vom Lesegerät gesteuert. Kollisionserkennung und -Vermeidung sind möglich [LaR10]. 11

17 2.1 NFC-Grundlagen Betriebsarten Reader/Writer Mode Im Reader/Write Modus agiert das Gerät als aktiver Kommunikationsteilnehmer und kann passive Tags lesen und beschreiben. Es erfolgt in der Regel eine ungesicherte Datenübertragung. Die Informationen sind zum Teil statische geschlossene Einheiten, wie Texte oder Telefonnummern oder Beschreiben Aktionen, wie das Öffnen einer Webseite im Browser. Fernen beinhalten Tags auch Konfigurationsdaten für ein bestehendes WLAN-Netz oder eine mögliche Bluetooth-Verbindung. Das NFC-Forum hat über die Record Type Definitions eine Vielzahl von Varianten spezifiziert. Card/Tag Emulation Mode Dieser Modus erweitert ein NFC Gerät um die Möglichkeit kontaktlose Chipkarten zu emulieren. Solche Karten werden beim Bezahlen von Waren und Diensten verwendet, oder gewähren Zugang zu öffentlichen und ebenso nicht öffentlichen Bereichen. Geräte können mit kompatiblen RFID-Ticketautomaten und Bezahlpunkten kommunizieren, wodurch keine Erweiterung der Infrastruktur nötig ist. Im Vergleich zu herkömmlichen Chipkarten bietet der Emulationsmodus signifikante Vorteile. So kann der Nutzer bei der Identifikation, Authentifikation, Datenspeicherung mit Informationen zum aktuellen Vorgang bedient werden. Er erhält Hilfe und Fehlerbeschreibungen bei Problemen und kann generelle Angaben abrufen, wie zum Beispiel den Stand des aktuellen Guthabens. Des Weiteren ist er in der Lage, gezielt Dienste zu aktivieren oder abzuschalten und kann Nutzer- oder Kontoeinstellungen mühelos ändern. Von Dienstanbieter aus können zugeschnittene Informationen für Kunden bereitgestellt werden. Ebenso ist nun eine Koexistenz von verschieden Chipkarten-Anbietern auf einem Gerät möglich [STT09]. Peer-to-Peer Mode Bei Peer-to-Peer spricht man von einem Kommunikationsverbund von gleichgestellten Instanzen, welche Dienste bereitstellen und in Anspruch nehmen können. Im betrachteten Kontext handelt es sich um einen Verbund aus NFC-Geräte. Damit können nun zwei oder mehr Geräte miteinander kommunizieren und Daten unterschiedlichster Art austauschen. Dateien, elektronische Visitenkarten, Audiostücke, aber auch Handover-Parameter zum Aufbau einer schnelleren Verbindungsart, stellen Beispiele dar. [IRA] 12

18 2 NEAR Field Communication Abbildung 2.2: zeigt ein Schema der technischen Architektur. Dieses führt die Betriebsarten in Abhängigkeit von Datenformaten und Protokollen und OSI-Schichten 5 auf. Aus [NIn12] Der Datenaustausch zwischen NFC-Geräte kann aktive oder passive erfolgen. Erfolgt dieser passiv, so gibt es einen Initiator, der ein Hochfrequenzfeld aufbaut und die Energieversorgung des anderen Kommunikationsgerätes übernimmt. Dieses muss kein eigenes Feld aufbauen, sondern antwortet per Lastmodulation. Ein Verfahren, dass auch kontaktlose Chipkarten nutzen. Bei der passiven Kommunikation kann dadurch effizienter mit Energiereserven umgegangen werden. Aktive Kommunikation bedeutet, dass beide Geräte ein eigenes Feld aufbauen. Dabei kann die Rolle des Initiators wechseln. Im Peer-to- Peer Modus kommunizieren die Geräte standardmäßig aktiv. Informationen in passiven Tags, wie sie zum Beispiel in Smart Postet integriert sind, können von nur von NFC-Geräten im Reader/Writer Modus gelesen werden. Viele Geräte besitzen ein Display. Dadurch ist es dem Nutzer möglich, sich aktuelle Daten zum Produkt und Vorgang anzeigen zu lassen. 5 Als OSI-Schichtenmodell (Open Systems Interconnection Reference Model) wird ein Schichtenmodell der Internationalen Organisation für Normung (ISO) bezeichnet, das als Designgrundlage von Kommunikationsprotokollen in Rechnernetzen entwickelt wurde [Wik]. 13

19 2.2 NFC-Forum 2.2 NFC-Forum Das Forum Das NFC-Forum ist ein Industrie-Konsortium und gründete sich im Jahr Zu den Mitgliedern zählen Technologiehersteller, Anwendungsentwickler und Finanzdienstleistungsinstitute. Darunter befinden sich zum Beispiel Google Inc., Samsung Electronics Co./Ltd., Visa Inc., Infineon Technologies und Microsoft Corporation. Das Forum verfolgt das Ziel, die Entwicklung und Verbesserung der Nahfeldkommunikation voranzutreiben um Interoperabilität zwischen Technik und Diensten zu gewährleisten. Dazu wurden vielzählige Spezifikationen entworfen, eine modulare Architektur standardisiert, Datenformate und Zertifikationsrichtlinien eingeführt. Zurzeit sind 21 Spezifikationen verabschiedet (Stand März 2012). Darin werden definiert Das NDEF-Format Vier NFC Forum Tag Typen Record Type Definitionen Das Übertragen von Daten zwischen zwei NFC-Geräten Die Protokollebene Zertifikationsanforderungen für NFC Geräte Das NFC-Forum gliedert sich in drei beständige, nach ihren Zielsetzungen kategorisierte Gremien (Committees). Das Ecosystem Committee (früher Marketing Committee) ist zuständig für Vermarktung und Leitlinien der NFC-Technologie, sowie für die generelle Ausrichtung des NFC Forums. Es motiviert Hersteller und Entwickler Spezifikationen einzuhalten und arbeitet eng mit der Industrie zusammen, um Möglichkeiten einer plattformunabhängigen Technologie zu verbreiten. Das Compliance Committee spezifiziert Vorgaben und Geltungsbereich für das Forum- Zertifizierungsprogramm und regelt dessen Prozess und Durchführung. Das Technical Committee fasst die technisches Bemühungen der Mitglieder in Spezifikationen zusammen, wertet Datenstrukturen und Protokolle nach ihrer Geeignetheit aus, entwickelt eigene Protokolle und verantwortet ein umfangreiches Testprogramm. 14

20 2 NEAR Field Communication NFC Forum Geräte Das Forum unterscheidet zwischen kompatiblen und zertifizierten Geräten. NFC Forum kompatibel Ein als solches definiertes Gerät muss eine Reihe von Anforderungen erfüllen. Dazu zählen allgemein das korrekte Erkennen von NFC-Forum Tags und anderen NFC-Forum Geräten. Hinzu kommen Leistungsmerkmale im Bereich der Radiofeldtechnologie und Anforderungen an die drei zu unterstützenden NFC Betriebsarten, wobei der Card Emulation Mode als optional eingestuft wird [FDR]. NFC Forum Gerät (zertifiziert) Hersteller können ihre Geräte beim NFC Forum zertifizieren lassen. Somit wird ein hohes Maß an Kompatibilität zwischen verschieden Geräten ermöglicht und individuelle Anpassungen hinfällig. Für eine Zertifizierung muss ein Gerät standartmäßig im Listen Mode agieren und den Poll Modus unterstützen [FDR]. Im Listen Mode registriert ein Gerät andere Geräte, welche versuchen eine Verbindung aufzubauen. Das bedeute das Gerät baut im initialen Zustand keine Trägerverbindung auf. Im Poll Mode hingegen fragt das Gerät aktiv nach möglichen Kommunikationspartnern. Ferner müssen zertifizierte Geräte die Betriebsarten PEER Mode und Reader/Writer Mode implementieren und bestimmte daran gekoppelte Voraussetzungen erfüllen. Dazu zählen eine Reihe von Protokollen und Eigenschaften der Bitübertragungs- und Sicherungsschicht. Im Reader/Writer kommuniziert ein Gerät mit NFC-Tags, kann diese auslesen und beschreiben. In ist zusammengefasst, welche Komponenten im Reader/Writer Modus zu unterstützen sind, um den Zertifikationsprozess zu bestehen. Optional können NFC-Forum Geräte den Card Emulation Mode unterstützen. Falls implementiert, sind ebenso bestimmte Voraussetzungen zu erfüllen. Dabei muss das Gerät für ein gültiges Zertifikat mindestens das Emulieren von Tags des Typs 3 abdecken. 2.3 NDEF NDEF steht für NFC Data Exchange Format, früher unter NFC Transfer Interface Packet (NTIP) [LaR10] bekannt. Es handelt sich um ein Format für den Austausch von heterogenen Daten und die Kommunikation zwischen NFC-Geräten und NFC-Tags, sowie zwischen NFC- 15

21 2.3 NDEF Geräten untereinander. Es unterstützt URIs 6, MIME-Typen 7 und NFC-spezifische Daten. In NDEF- Nachrichten können zum Beispiel XML-Dokumente/Fragmente oder Bilder im GIFund JPEG-Format eingebunden werden. NDEF ist ein binäres Format und besonders leichtgewichtig und speichert ein oder mehrere Nutzdatensegmente (Payloads) in einer Nachricht. Ein Segment kann maximal 2 32 Zeichen (8 Bit pro Zeichen) lang sein und wird durch eine Typund Längenangabe beschrieben. Ferner ist die Vergabe eines optionalen Bezeichner/Identifikator möglich. Dieser wird genutzt um Daten zu referenzieren, welche auf mehreren logischen Speichersegmente (Payloads) verteilt liegen. Diese Segmente werden NDEF Records genannt. Das eindeutige Typattribut in einem Record ermöglicht es, mehrere verschiedene Datentypen in einer NDEF-Nachricht zu speichern. Abbildung 2.3: Zeigt den Aufbau eines NDEF-Records mit Header und Datenteil. Aus [RoL10] Die NDEF-Spezifikation schreibt nicht vor, wie der Datenaustausch stattzufinden hat, sondern definiert einzig die Datenstruktur [NDEF06]. Das NFC-Forum empfiehlt allerdings eine Kommunikation über das unterliegende Protokoll NFCIP-1 [23] und NFCIP-2 [EI04; EIn10], beziehungsweise über das intern entwickelte und auf NFCIP 1/2 aufbauende LLCP-Protokoll [LLCP11]. 6 Ein Uniform Resource Identifier (URI) ist ein Identifikator und besteht aus einer Zeichenfolge, die zur Identifizierung einer abstrakten oder physischen Ressource dient. URIs werden zur Bezeichnung von Ressourcen im Internet eingesetzt [Wik]. 7 Die Multipurpose Internet Mail Extensions (MIME) sind Erweiterungen des Internetstandards RFC 822. Die MIME schaffen Kompatibilität für zusätzliche Zeichen wie Umlaute bis hin zu Kombinationen verschiedenster Inhalte [Wik]. 16

22 2 NEAR Field Communication Speicherung Eine Nachricht kann über das Setzten von definierten Flags näher beschrieben werden. Die Spezifikation * enthält alle Informationen darüber. Die erstellte Nachricht kann direkt über NFC-Geräte ausgetauscht oder in einen NFC-Tag integriert werden. Abbildung 2.4: Zeigt eine NDEF-Nachricht, bestehend aus vielen NDEF-Records. Aus [RoL10] Ein NFC-Forum-Tag baut auf einer von vier NFC-Forum-Tag-Plattformen auf [T1T11; T2T11; T3T11; T4T11]. Eine Plattform dient als Container für die NDEF-Nachricht und ist produktabhängig. Diese Plattform darf nicht mit den Tag-Operationen verwechselt werden. Diese spezifizieren das Operieren auf den verschieden Tag-Typen NFC-spezifische Typen Für die Übertragung von Anwendungsdaten wurden NFC Record Type Definitions (RTD) 8 spezifiziert. Diese haben gegenüber MIME-Media Typen den Vorteil, dass sie ebenso Aufschluss über die Verarbeitung und Darstellung der Daten geben. Dies erhöht das Potential, verschiedenste NFC-Geräte miteinander interagieren zu lassen und ist ferner eine bedeutende Hilfe für Entwickler. Unterschieden wird in den Spezifikationen zwischen NFC Forum Well-known Types und External Types. Alle vom NFC-Forum entwickelten Typen werden als Well-known gekennzeichnet, sodass External Types von anderen Institutionen spezifiziert werden können. Es folgt eine Übersicht von bekannten Record Types. Text Record Type: Einfacher Text. Neben dem Text sind Informationen über Zeichencodierungen und Sprache enthalten. [FTR06] URI Record Type: Uniform Resource Identifier: -, Internetadressen, Telefonnummern oder auch elektronische Produkt Codes (EPC) [URI06] Smart Poster Record Type: Im Grunde ein Container für verschiedene NDEF- Nachrichten mit einer zugeordneten Aktion. Die NDEF-Nachricht besteht aus 8 Bei der Record Type Definition (RTD) handelt es sich um standardisierte Aufzeichnungstypen für NFC-konforme Geräte. 17

23 2.4 NFC-Tags einem URI-Record und optional weiteren Records. Ein Recommended Action Record beschreibt zum Beispiel eine Aktion. [FSP06] Generic Control Record: Ein Aktivator für Steueraufgaben. Es wird ein Target definiert (ein Text oder eine URI), ein optionaler Datensatz und eine Aktion. [FGC08] Signature Record Type: Mit diesem Typ können Sicherheitskriterien in Bezug auf Authentizität und Integrität verwendet werden, indem NDEF-Records signiert werden [NSi10]. Connection Handover: Ein Weiterreichen von Verbindungsparametern (Bluetooth-Konfiguration) um einen schnellen und einfachen Datenaustausch zwischen NFC-Geräten zu ermöglichen [FCH10] SNEP Im August 2011 verabschiedete das NFC-Forum eine Spezifikation für ein offenes NFCorientiertes Protokoll mit dem Namen NDEF Exchange Protocol (SNEP) [FEP11]. Es baut auf den Logical Link Control Protocol (LLCP) auf und steuert den Austausch von NDEF-Nachrichten zwischen Geräten im Peer-to-Peer Modus. Das Integrieren eines einheitlichen Protokolls soll die Interoperabilität in Zukunft gewährleisten. Es handelt sich um ein verbindungsorientiertes Request/Response-Protokoll. 2.4 NFC-Tags Tags sind passive Geräte. Sie besitzen daher keine eigene Stromversorgung, sondern werden vom einen NFC-Lesegerät mit Strom versorgt. Tags sind Speicherelemente mit integrieren Datencontainer. Diese kapseln Anwendungsdaten. Das NFC-Forum führt vier Typen von NFC-Tags, welche sich in Ausführung und Kapazität unterscheiden. Die Technologie basiert größtenteils auf bestehende RFID SmartCard Technologie. Zurzeit sind Produkte mit wenigen Bytes bis einem Megabyte Speicher zu bekommen. Tags sind technisch simpel. Sie sind besonders für schnelllebige Produkte geeignet. 18

24 2 NEAR Field Communication Tagformat RFID-Technologie Hersteller Norm Speichergröße Type 1 Topaz Innovision ISO 14443A Byte 9 Type 2 MIFARE Ultralight NXP ISO 14443A Byte 9 Type 3 FeliCa Sony JIS X Mbyte 10 Type 4 Smartcards 11, APDU-basiert - ISO 14443A, ISO Mbyte 10 Tabelle 2.1: Überblick über NFC-Forum-Tagformate und zugrundeliegenden RFID-Tags nach [RoL10] Überblick Mit der Klassifikation in Typen wurde versucht, bereits bestehende Nahfeldtechnologien in einen standardisierten Rahmen einzugliedern und eine Plattform zu schaffen, um Interoperabilität zwischen Herstellen, Geräten und Anwendungen zu gewährleisten. Die ISO A und B Normen bilden den internationalen Standard für kontaktlose SmartCards. Die Tags unterscheiden sich hinsichtlich Speichergröße, Konfiguration, Datensicherheit und Komplexität und Stückpreis. Im Allgemeinen gilt, je höher die Stückzahlen sind, umso günstiger ist der einzelne Tag. Zu beachten ist, dass einige Hersteller die Daten schon während der Produktion auf den Tag übertragen. Eine nachträgliche Änderung ist ausgeschlossen. Eine weitere wichtige Rolle spielt die Übertragungsgeschwindigkeit. Zwar beginnt eine Übertragung schon nach einer sehr kurzen Verbindungsaufbauzeit. Eine Verbindung kann jedoch schnell abbrechen, falls das Lesegerät den Tag nicht mehr über das Hochfrequenzfeld erreichen kann. Dies kann in mobilen Kontexten problematisch werden, wenn ein Tag im Vorbeigehen erfasst wird. Toleranzspanne und Fokussierzeit der Nutzer sind zu berücksichtigen. Eine Besonderheit von Typ 1: Alle Daten können in einem Block übertragen werden. Ja nach Anwendungsfall ist die Chipgröße ein weiterer wichtiger Faktor. Für Smart Poster eigenen sich einfache, kleine Chips, die in der Regel weniger aufdringlich und kostengünstiger sind. Ferner kann auf eine Langlebigkeit von Tags verzichtet werden, falls 9 Gesamter physikalischer Speicher. 10 Speicher für NDEF-Daten. 11 Type 4 Tags entsprechen keiner proprietären RFID-Technologie, sondern sind vollständig zu den Standards für kontaktlose Smartcards kompatibel. 19

25 2.4 NFC-Tags davon auszugehen ist, die beinhalteten Daten haben eine kurzfristige Relevanz, wie zum Beispiel Konzert- und Filmankündigungen. [LaR10; RET11] Tabelle 2.2: Weiterer Vergleich von Produkten der NFC-Forum Type-Plattformen aus [STT09] NFC Forum Tag Das NFC-Forum ordnet Tags in sogenannte Type-Tag Plattformen 1 bis 4. Das Forum spezifiziert nicht den Tag an sich, sondern legt fest, wie mit jedem Tag-Type zu operieren ist (Type Tag Operations Spezifikationen), wie sich der Zugriff eines Gerätes im Reader/Writer Modus realisiert [T1T11; T2T11; T3T11; T4T11]. Mit NDEF steht ein Format für Tags und für die allgemeine NFC-Kommunikation bereit. Im Allgemeinen basieren NFC-Forum Tags auf der bereits vorhanden kontaktlosen Chipkartentechnik und sind kompatibel zu dieser. Tags bieten einen neuen Raum für Anwendungsszenarien. Die häufigste Verwendung finden sie in Smart Poster, dienen zum einfachen und schnellen Informationsaustausch und können Konfigurationsdaten für Kommunikationsstrukturen (WLAN, Bluetooth) enthalten. Ein NFC-Forum Tag ist entweder zu einer der vier Tagplattformen kompatibel oder erfüllt den Standard der ISO/IEC Ein Forum-Tag damit in jedem Fall von einem NFC-Forum Gerät erkannt. NFC-Forum Tags können von beliebigen Herstellern erzeugt werden. Die Technologie ist auf keinen bestimmten Halbleitertyp beschränkt. Im Handel sind Produkte erhältlich. Dazu zählen MIFARE Ultralight (C), MIFARE DESFIRE SmarMX, Innovision Topaz oder Sony FeliCa. Neben den NFC-Forum Tag Typ Plattformen gibt es Plattformen von anderen Herstellen [MiC12]. 20

26 2 NEAR Field Communication Type 1 Tags vom Type 1 basieren auf den ISO A Standard. Der Type orientiert sich an Topaz- Tags der Firma Innovision Research & Technology. Diese nutzen ein proprietäres Verbindungsprotokoll und unterstützen neben ISO A, ebenso ISO/IEC und ISO/IEC Normen. NFC-A wird als Synchronisationsmechanismus eingesetzt, welcher ebenfalls in großen Teilen der ISO entspricht. Die Speicherstruktur lässt sich in ein statisches und dynamisches Speichermodell unterscheiden. Das statische Modell weist eine Kapazität von 120 Bytes auf, wobei nicht alle Bytes für Anwendungsdaten zur Verfügung stehen. Mit Abzug von Headerdaten und intern genutzten Speicher bleiben 96 Byte zur individuellen Belegung. Bei Dynamischen Modellen können bis zu zwei Kilobyte genutzt werden. Daten werden mit 106 kbps. übertragen Type 1 Tags könne gelesen und beschrieben und vor Überschreiben geschützt werden. Eine Kollisionserkennung erfolgt nur während der Initialisierungsphase. Es ist keine Antikollision möglich, um mehrere Tags in Lesereichweite getrennt zur verarbeiten. Typ 1 Tags sind wegen ihres relativ geringen Speichers und einfachen Technik kostengünstig. [T1T11; FDi11] Type 2 Zum Zeitpunkt der Arbeit ist NXP der einzige Hersteller von Typ 2 Tags [Het11]. Dieser Typ nutzt ein proprietäres Verbindungsprotokoll auf Basis der ISO A Norm. Die gängigen Produkte sind MIFARE Ultralight und MIFARE Ultralight C. Ein Type 2 Tag kann gelesen, beschrieben und als schreibgeschützt deklariert werden. Im Unterschied zum Typ 1 sind Antikollisionsverfahren möglich. Damit können sich mehrere Tags gleichzeitig im Feld eines Lesegeräts befinden. Die Technologie entspricht dem NFC-A Standard. Unterstützt werden wiederum zwei Speichermodelle. Statisch sind 48 Byte beschreibbar, dynamisch bis zu zwei Kilobyte. Daten werden mit einer Datenrate von 106 kbps übertragen. Abbildung 2.5 zeigt einen Trikker BT43 Tag. Dieser entspricht dem Type 2 Format und besitzt einen Schutz gegen Nässe, Schmutz und Sonnenstrahlen [FDi11; T2T11]. 21

27 2.4 NFC-Tags Abbildung 2.5: Trikker-UL BT43 Tag (NFC Forum Type 2) NFC Tag aus [Het11] Type 3 Mit dem Typ 3 werden Tags aus der Sony FeliCa Produktreihe unterstützt. Dieser Tag ist in Japan weit verbreitet und durch den Japanese Industrial Standard (JIS) X spezifiziert. Dabei kommen ein proprietäres Protokoll und eine proprietäre Modulationsverfahren zum Einsatz. Der Typ basiert auf NFC-F und ist les- und beschreibbar. Die Speichergröße beträgt in der Regel zwei Kilobyte. Einige Varianten können bis zu einem Megabyte speichern. Die Daten werden mit 212 kbps übertragen. Ein NFC-Reader/Writer kann mehrere Typ 3 Tags in einem Lesefeld über Antikollisionsverfahren verarbeiten. Generell sind mit dem Typ 3 komplexere Anwendungen möglich [FDi11; T3T11] Type 4 Ein Tag vom Typ 4 ist kompatibel zu den ISO14443 A und B Standards. Kommuniziert wird, abhängig vom Produkt, über die Technologien NFC-A oder NFC-B. Dieser Tag Typ wird von verschieden Herstellern vertrieben. Beispiel sind Mifare Classic Tags und Chipkarten von NXP. Wie beim Type 2 und 3 kommen Antikollisionverfahren zum Einsatz. Ein Tag kann gelesen und beschrieben werden und einen schreibgeschützten Zustand annehmen. Die Datenraten betragen 106 kbps, 212 kbps und 424 kbps. Typische Speichergrößen starten beginnen bei einem Kilobyte und enden bei 32 Kilobyte. Das Speichermodell ist prozessorbasiert und damit komplexer als bei andern Typen [FDi11; T4T11] Speicherung Ein NFC-Forum-Tag speichert Informationen im NDEF-Format oder herstellerspezifischen Formaten. Bei letzteren können Kompatibilitätsprobleme auftreten. Die Daten sind in einer 22

28 2 NEAR Field Communication Tag-Typ-Plattform integriert, welche eine Datenstruktur definiert. NDEF speichert unterschiedlichste Datentypen Anwendungsfälle Generell können Tags dort eingesetzt werden, wo geringe Datenmengen und eine Übertragung auf mobile Geräte vorgesehen sind. In vielen Fällen werden Tags als Smart Poster verwendet. Im folgenden Abschnitt wird darauf näher eingegangen. Tags können vielzählige unterschiedliche Daten speichern. Oftmals werden URIs, einfache Texte, Handover Parameters, Business Cards und Signaturen aufgespielt. Es folgen Beispiele für den Einsatz von Tag-Technologie. Konventionelle Visitenkarten können durch elektronische Visitenkarten im vcard- Format ersetzt und auf einem Tag gespeichert werden. Es ist ebenso möglich Bilder hinzuzufügen. Ein NFC-fähiges Mobiltelefon überträgt die Kontaktdaten ins Adressbuch. Ein Poster mit integriertem Tag ist ein Smart Poster. Der Nutzer kann über sein Gerät auf die Daten zugreifen. Das können ergänzende Informationen zum dargestellten Gegenstand oder eine URL sein, um auf eine zugehörige Webseite zu gelangen. Vorstellbar sind ebenso Gutscheine und Rabatte. Tags können Konfigurationsdaten für Schnittstellen enthalten. Ein Nutzer erhält über das Berühren eines Tags die notwendigen Daten zur Einrichtung eines Zugangs zum verfügbaren Funknetz. Diese Aktion wird als Handover bezeichnet. Flyer und andere Printmedien können Träger von NFC-Tags sein. Ein Tag ist nicht an einen Ort gebunden. Er kann mitgenommen werden. Informationen können somit von stationären NFC-Readern gelesen werden, indem ein Flyer an die NFC- Schnittstelle eines Desktopcomputers gehalten wird. Nutzer können NFC-Tags für eigene Vorstellungen verwenden. Da ein NFC- Forum Gerät das Beschreiben von Tags unterstützen muss, sind zertifizierte Mobiltelefone in der Lage Nachrichten auf Tags zu übertragen. Mögliche Anwendungen sind vordefinierte SMS, die über eine Berührung abgesendet werden. Ähnlich können Telefongespräche eingeleitet werden. Die Fotos eines Albums enthalten Tags mit Telefonnummern der gezeigten Person. Bei Berührung wird ein Anruf gestartet. Ferner können Telefonnummern in Handbücher oder in Produkte integriert werden. 23

29 2.4 NFC-Tags Tabelle 2.3: zeigt den Vergleich von Tag-Typen hinsichtlich ihrer Geeignetheit für einen bestimmten Anwendungsfall aus [1] Tabelle 2.3 vergleicht Tag-Typen in Abhängigkeit von Anwendungsfällen. Es wird deutlich, welche Produkte sich besonders und welche weniger für einen konkreten Anwendungsfall eignen, sowie welche Besonderheiten ein Tag Typ aufweist [STT09]. Innovision Research & Technology nehmen einen ähnlichen Vergleich vor [IRT]. Deren Anwendungsfälle führen ebenfalls Smart Poster und Handover (Bluetooth Pairing) auf, führen SMS und Call Request zusammen und erweitern die Szenarien um das Angebot von MMS oder Klingeltöne, wobei sich die Daten für Bilder und Audio vollständig auf dem Tag befinden. 24

30 2 NEAR Field Communication 2.5 Smart Poster Definition Nach NFC-Forum Definition sind Smart Poster Objekte, auf oder in denen lesbare Tags integriert sind. Ein NFC-Smart Poster kann in unterschiedlichen Formen auftreten, es kann ein Poster, Werbeschild, eine Zeitschriftseite, ebenso ein dreidimensionales Objekt sein. [FSP11] Die wichtige gemeinsame Eigenschaft ist der integrierte Tag, ein passiver NFC-fähiger RFID-Chip. Dieser wird beim Berühren eines NFC-Gerätes gelesen. Das Forum führt als weitere wichtige Gemeinsamkeit ein einheitliches Symbol auf, das den Ort der Datenübertragung signalisieren soll. Smart Poster sind eine neue interessante Marketingmöglichkeit Für Händler, Dienstanbieter, Transportunternehmen, generell jeden, der Information anbieten möchte. Eine Produktion von großen Mengen ist ohne weiteres möglich und reduziert gleichzeitig den Stückpreis. Zu einem gewissen Grad können Smart Poster dynamische Daten enthalten. Informationen werden gegebenenfalls überschrieben, oder bei verlinkten Informationen aktualisiert. Mittlerweile gibt es eine Vielzahl von Größen und Ausführungen Endverbrauchermotivation Die Wirkung eines Smart Poster ist von bestimmten Faktoren abhängig. Verbraucher interessieren sich für die NFC Smart Poster hinsichtlich Präzision Smart Poster können Objekte markieren. Die Positionsinformation ist äußerst genau und entspricht mit hoher Wahrscheinlichkeit der verlangten Information des Nutzers. Die Aktivierung eines Tags geschieht durch Berührung per Mobiltelephon und ähnelt einem darauf zeigen. Damit lassen sich einzelne Elemente relativ präzise aus Mengen identifizieren. Einfache Nutzung Der Einsatz von Nahfeldkommunikation kann den Umgang mit digitalen Informationen erleichtern. Das Berühren von NFC-Tags führt zu sofortiger Übertragung. Diese Interaktion ersetzt komplexe Instruktionen. Die mehrstufige Einrichtung eines Zugangs zur örtlichen WLAN-Infrastruktur kann umgangen werden. Ferner ist die Information direkt lesbar oder verlinkt, wodurch sich ein Suchen danach erübrigt. 25

31 2.5 Smart Poster Umweltfreundlich NFC Technik gilt allgemein als umweltfreundlich. Das lässt sich am Beispiel Mobile Ticketing verdeutlichen. Dabei werden herkömmliche Papiertickets durch virtuelle ersetzt. Diese sind auf dem Nutzergerät gespeichert und können über Reader/Writer verifiziert werden. Ebenso können digitale Gutscheine und Flyer verbreitet werden. Komfort Ein NFC-fähiges Mobiltelephon ist ein Verzeichnis von beliebigen unterschiedlichen Informationen. Es speichert unzählige Daten, Gutscheine, Tickets etc. in einem Medium. Das ermöglicht einen einheitlichen und einfachen Zugang. Zudem können erweiterte Funktionen angeboten werden. Spaß/Freude NFC ist eine intuitive und neuartige Technik. Richtig umgesetzt kann dadurch die Nutzerzufriedenheit gesteigert und Schwellen beim Anwenden unbekannter Technik gesenkt werden Herstellung eines Smart Posters Smart Poster lassen sich auf unterschiedlichen Wegen herstellen. Es stehen zahlreiche Designs und Ausführungen zur Verfügung. Ein Tag kann direkt in ein Objekt eingearbeitet sein oder auf dessen Oberfläche angebracht werden. Alle nötigen Bestandteile sind über den Handel erhältlich. Benötigt werden ein beliebiges Objekt, ein NFC-Tag, ein Berührungskennzeichen, ein NFC-Reader/Writer und natürlich die digitale Information. Material In die Überlegung sollte die Angemessenheit des Materials einfließen. Es gibt Materialien, welche die Leistung der NFC-Kommunikation beeinträchtigen können. Die Materialen Objekten und Tags sollten genügend robust sein. Dies gilt besonders für den Einsatz im Freien, wo extreme Umweltbedingungen, Wetter, Sonneneinstrahlung und Schmutz auftreten. Falls notwendig, sollte geprüft werden, ob der Tag sich wiederbeschreiben lässt. Ein Tag wird auf unterschiedliche Weise mit einem Objekt kombiniert - geklebt, eingebettet, eingenäht, aufgeheftet, auf das Objekt, an das Gehäuse. Die Art der Anbringung kann sich auf die Funktionalität des Tags auswirken. Klebstoffe können Substanzen enthalten, welche das Hochfrequenzfeld beeinflussen. Smart Poster, Tags sind oft im öffentlichen Raum zu finden. Damit steigt das Risiko von Attacken und Manipulation. Der komplette Tag kann ersetzt, der Inhalt überschrieben oder gelöscht werden. Darüber hinaus sind komplexe Angriffe möglich [NSP08; VAA09]. 26

32 2 NEAR Field Communication Schreibschutz Das NFC-Forum fügt der NDEF-Spezifikation eine Signature Record Type Definition hinzu. Damit können Integrität und Authentizität geprüft werden. Ferner lassen sich Tags durch Setzten eines bestimmten Flags vor dem Wiederbeschreiben und Ändern der Nachricht schützen. Dieser Schutz kann zu zwei Zeitpunkten aktiviert werden. Zum einen direkt während der Produktion beim Integrieren der Nachricht. Dabei wird die Nachricht auf eine verhältnismäßig große Zahl von Tags geschrieben. Eine spätere Änderung ist nicht mehr möglich und der Inhalt muss schon bei der Produktion bekannt sein. Zum anderen kann nach dem individuellen Beschreiben ein Befehl an den Tag gesendet werden. Daraufhin wird ein bestimmtes Bit gesetzt und der Tag ist schreibgeschützt. Ein Nachteil: Ist der Tag einmal schreibgeschützt, können unbemerkte Fehler nicht mehr korrigiert werden. In ungünstigen Fällen ist damit eine komplette Produktion unbrauchbar und muss ersetzt werden Design Die folgenden Punkte sind essentielle Hinweise für die Gestaltung eines Smart Posters Der Berührungspunkt für NFC-Geräte muss klar erkennbar und eindeutig sein. Es muss erkenntlich sein, welche Information sich auf dem Tag befindet. Werden Dienste hinzugezogen, ist eine Beschreibung dieser und eventueller Konditionen hinzuzufügen. Sind mehrere Tags in das Poster integriert, ist ausrechend Abstand einzuhalten. Ebenso darf die Zuordnung der Tags zu den Inhalten keine Schwierigkeiten bereiten. Für die Kennzeichnung des Berührungspunktes steht als Symbol das N-Mark zu Verfügung. Es kann über die Forum-Webseite samt Nutzungshinweise heruntergeladen werden [FNM10]. Damit wird ein einheitliches Symbol für die Nutzung der NFC-Kommunikation bereitgestellt. Das N-Mark sollte dabei nicht kleiner als 3 Millimeter und nicht größer als das Logo des eigenen Unternehmens sein. Für jeden Tag ist ein N-Mark anzubringen. 27

33 2.5 Smart Poster Abbildung 2.6: N-Mark des NFC-Forum für NFC-Tags aus [FNM10] Nutzerszenarien/Anwendungsfälle Einen ersten Überblick über Einsatzmöglichkeiten gibt das Smart Poster White Paper des NFC- Forums [FSP11]. Es fasst einfache bis komplexe Realisierungen in unterschiedlichen Kontexten zusammen. Smart Poster werden in Museen eingesetzt. Sie erweitern den Informationsgehalt und ermöglichen interaktive Führungen und bieten Zugang zu anderen Medien. Ferner reduzieren sie die Notwendigkeit von Printmaterial. Smart Poster sind auch für Bildungszwecke sinnvoll. In einem finnischen Projekt werden sie für Stadtrundgänge eingesetzt, welche mit Aufgaben verbunden war [FSP11]. Die NFC-Tags sind über eine Applikation mit einem Backendsystem verbunden, welches den Fortschritt der Teilnehmer aufzeichnet und später einem Betreuer zur Verfügung stellt. Nicht wenige Szenarien integrieren NFC-Technik in Bestellabwicklungen. Lieferdienste händigen Flyer mit eingearbeiteten Tags aus. Mit dem Mobiltelefon werden diese Tags gelesen und somit die Bestellung zusammengestellt. Gleiches gilt für Speisekarten in Restaurants. Die Order wird über eine passende Applikation an ein Backendsystem verschickt und bearbeitet. Mit Smart Poster sich Produkte bewerben. Kunden können beim Auslesen und Betrachten Informationen beziehen. Ebenso können Rabatte auf das NFC-Gerät übertragen werden. Aus den Daten ein Nutzer berührt nur den Tag des Produkts, das ihn auch tatsächlich interessiert können persönliche Profile generiert werden. Die Kombination mit Mobiltelefonen befähigt den Nutzer, aktuelle Angaben über Guthaben abzurufen, weitere Dienste hinzuzuziehen oder abzustellen. Er kann ermitteln, wo Gutscheine einzulösen sind und wo Bezahlen per NFC möglich ist. 28

34 2 NEAR Field Communication In einem Projekt in Kuweit können Kunden Prepaidkarten eines Finanzinstituts auf ihr NFCfähiges Mobiltelefon laden [FSP11]. Das Telefon kann im Emulationsmodus eine übliche Smartcard simulieren. Damit kann der Kunde überall dort zahlen, wo auch die konventionelle Kreditkarte unterstützt wird Smart Poster von Verbrauchern Zahlreiche Szenarien ergeben sich für private Zwecke. Eigens erstellte Tags, beziehungsweise Smart Poster können beliebte Webadressen, die Konfiguration des eigenen WLAN- Funknetzes speichern, zu Übersichten von Aktien oder Wetterdaten verlinken, wichtige Telefonnummern beinhalten. Der Verbraucher benötigt zum Beschreiben von Tags ein Reader/Writer-Gerät. Solche Geräte sind im Handel erhältlich. Im Grunde genommen sollte jedoch ein NFC-fähiges Telefon bereits die Möglichkeit zum Beschreiben von Tags unterstützen. Der Handel führt Starter-Kits mit einer Sammlung von verschiedenen Tags. Es ist darauf zu achten, dass Tags und Reader mit NFED-Nachrichten und Übertragungsstandards umgehen können. 2.6 NFC im Vergleich Ein Vergleich der Nahfeldkommunikation mit anderen drahtlosen Verbindungstechniken kann auf zwei Ebenen stattfinden, welche sich im Betrachtungsgegenstand unterscheiden, aber nicht unabhängig voneinander sind. Grundlegend ist eine Gegenüberstellung der technischen Merkmale. Darauf aufbauend ergeben sich abgeleitete Anwendungsbereiche NFC und RFID RFID (Radio Frequency Identifikation) und NFC sind Techniken zur Übertragung von Daten mit Hilfe von elektromagnetischen Wellen. Dabei kommen kleine Elektrochips zum Einsatz, auch Tags genannt. Diese enthalten Informationen und werden über Lesegeräte angesteuert. Die Übertragungsdistanz kann bis zu mehrere Meter betragen. Für solche Entfernungen kommen in der Regel Tags mit aktiver Stromversorgung zum Einsatz. NFC kann als Untermenge von RFID gesehen werden, da die Übertragungsdistanz auf zehn Zentimeter reduziert wird. Richtig ist ebenso von einer Erweiterung zu sprechen. 29

35 2.6 NFC im Vergleich Grundsätzlich bauen NFC und RFID auf identische Standards auf. Die NFC-Technologie wird ergänzend um einen Betriebsmodus (Peer-to-Peer) erweitert, der eine Kommunikation zwischen NFC-Geräten ermöglicht und so nicht in der (ISO 14443) definiert ist, welche nur eine Kommunikation zwischen Gerät und passiven Tag spezifiziert. Im Folgenden wird NFC mit den Übertragungsstandards Bluetooth, Infrarot, WLAN (Wireless Local Area Network) und CWUSB (wireless USB) für Wireless Personal Area Networks (WPAN) verglichen. NFC Bluetooth Infrarot w-usb WLAN Peer-to-Peer Netzwerktyp Point-to- Multipoint Peer-to-Peer Peer-to-Peer, Cluster Peer-to-Peer, Bridge, Wireless distribution system Reichweite bis 0,1m Bis 10m Bis 1m Bis 3m Bis 100 m Geschwindigkeit Einrichtungszeit Bis 424kkbps Bis 3Mbps 115kbps Bis 480Mbps Bis 300 Mbit/s Ca. 0,1s Ca. 5s Ca 0,5s - Einige Sekunden Sicherheit Software und Hardwarelösungen Software Nein (außer IRFM) Software Software, Hardware Kommunikationsarten Active-Active Active-Passive Active-Active Active-Active Active-Active Active-Active Infrastruktur Kontaktloses Ticketing, e- Zahlung Mobile Telefone, Verbraucherelektronik Verbaucherelektronik, PC, mobile Telefone Verbaucherelektronik, PC Verbaucherelektronik, PC, Industrie, Großflächig Kosten gering moderat gering moderat hoch Tabelle 2.4: Vergleich von gängigen drahtlosen Kommunikationstechniken. NFC eignet sich für die Übertragung von kritischen Daten - Geldbeträgen oder persönlichen Informationen - auf kurzen Distanzen. Dank der drei unterstützen Arbeitsmodi ergeben sich zahlreiche Möglichkeiten für die Verwendung der NFC-Technologie. Eine wichtige zu beachtende Voraussetzung ist eine sichere Verbindung zusammen mit einer garantierten gültigen Authentifizierung der Verbindungsstellen. 30

36 2 NEAR Field Communication NFC fügt sich in die Liste von Techniken zur Erstellung von WPAN ein, sogenannter Wireless Personal Area Networks. Solche persönlichen Netzwerke werden nicht selten ad-hoc auf- und abgebaut und verbinden elektronische Endgeräte von Verbrauchern. In der Regel kommunizieren teilnehmende Geräte über kurze Entfernung mit Point-to-Point oder Point-to- Multipoint Strategie. Eine Integration in ein größeres Netzwerk ist möglich und wird als Uplink bezeichnet. Eine weitere wichtige Anforderung ist ein hoher Grad an Selbstorganisation der Technik, um für den Endverbrauchermarkt geeignet zu sein NFC und Bluetooth Bluetooth ist ein Funkstandard, der sich technisch zwischen NFC und WLAN-Netzen eingliedert. Bluetooth ermöglicht höhere Datenraten innerhalb größerer Reichweiten. Dadurch sind komplexere Anwendungen möglich. Geräte können zu einem Piconetz 12 und Piconetze zu Scatternetze 13 zusammengeschaltet werden. Ein Aufbau von Verbindungen über Bluetooth ist vergleichsweise langwierig und umständlich. Fünf bis sechs Sekunden kann ein solcher Prozess benötigen. Eine NFC-Verbindung dagegen ist nach ungefähr 100 Millisekunden hergestellt. Dieser Zeitgewinn ergibt sich teilweise aus dem übersichtlichen Protokoll, das für einfache Anwendungen mit direkten Verbindungen konzipiert wurde. Eine wichtige Eigenschaft besteht darin, dass beide Technologien miteinander kombinierbar sind. NFC kann eingesetzt werden, um den Aufbau einer Bluetooth-Verbindung deutlich zu beschleunigen, indem notwendige Verbindungsparameter ausgetauscht werden, welche sonst manuell eingeben werden müssen. Der Nutzer muss nicht eingreifen bei einer Kopplung von Geräten. Die angesprochene Koexistenz beider Standards ist möglich, da unterschiedliche Frequenzbänder bedient werden NFC und WLAN Mit NFC und WLAN verhält es sich ähnlich. Auch mit WLAN sind komplexe Anwendungsfälle realisierbar, welche allerdings einen größeren Einrichtungsaufwand mit sich ziehen. Dieser kann mit NFC automatisiert werden. Tags speichern Einstellungen, um sich ohne weiteres in ein verfügbares WLAN-Netz anzumelden. Die Übertragung der Daten erfolgt dann über das leistungsstärkere und flexiblere (größere Reichweite) WLAN-Funknetz. 12 Ein Piconetz ist ein kleines (pico) Personal Area Network von Endgeräten [Wik]. 13 Unter einem Scatternetz versteht man eine Gruppe von unabhängigen und asynchronen Piconets [Wik]. 31

37 2.6 NFC im Vergleich NFC und Infrarot Der Unterschied zwischen Infrarot und NFC ist, dass bei der Übertragung von Daten über ein Infrarotsignal ein direkter Sichtkontakt zwischen Sender und Empfänger notwendig ist. Infrarot-Verbindungen beruhen auf Prinzipien der Strahlenoptik. Daher kann das Signal keine massiven Gegenstände durchdringen. Die Reichweite ist bis maximal einem Meter begrenzt. Daraus ergeben sich NFC-ähnliche Sicherheitsmerkmale, aufgrund der geringen Übertragungsreichweite. Ein Abhören durch Dritte ist stark eingegrenzt NFC und CWUSB Certified Wireless USB ist ein weiterer Funkstandard zur Übertragung beliebiger Daten, der auf bekannter USB- Technologie aufbaut. CWUSB dient zum schnellen Aufbau von kleinen kabellosen Funknetzen und orientiert sich an den konventionellen Anwendungsfällen üblicher USB-Geräte. Der Standard bietet hohe Übertragungsraten bei Reichweiten bis zehn Meter. NFC kann dazu eingesetzt werden, CWUSB Verbindungen aufzubauen. Das gilt insbesondere für den Austausch von Sicherheitskonfigurationen, die ohne NFC entweder über ein Kabel oder manuell vom Nutzer bedient werden müssen Zusammenfassung Nahfeldkommunikation darf nicht als Ersatz von bestehenden Vertretern im Bereich Funkkommunikationstechniken gesehen werden. Sie unterscheidet sich signifikant von aufgeführten Lösungen und kann aufgrund eines separat genutzten Frequenzbandes und sehr geringer Reichweite mit WLAN, Bluetooth, Infrarot und CWUSB koexistieren 32

38 2 NEAR Field Communication 33

39 2.6 NFC im Vergleich 3 Mobile Ticketing Mobile Ticketing gehört mit Mobile Payment und Mobile Banking zu den Möglichkeiten, mit Hilfe eines mobilen Gerätes und drahtloser Kommunikation, elektronischen Handel zu betreiben. Zusammengefasst werden diese Fähigkeiten und Arten geschäftlicher Transaktionen unter dem Begriff Mobile Commerce (oder auch Mobile Business). Es handelt sich ferner um Möglichkeiten des Kaufens und Verkaufens von Gütern über elektronischem Wege, sodass eine Einordnung in den Elektronischer Handel (Electronic commerce) erfolgt. Mobile Ticketing fasst den Bezug von Tickets und deren Validierung als Prozess zusammen. Alle notwendigen Informationen liegen in digitaler Form bereit. Ein konventionelles Papierticket wird hinfällig und durch ein virtuelles ersetzt. Damit verringern sich Kosten in der Herstellung und Verteilung. Die Auslieferung der Tickets kann in und auf verschiedenen Formen und Kommunikationswegen geschehen. Etablierte Techniken wie SMS, Bluetooth, UMTS, RFID stehen zur Verfügung. Mobile Ticketing ist für zahlreiche Anwendungsfelder geeignet und eröffnet zudem neue Dienstformen. Zum Einsatz kommen virtuelle Tickets bereits im öffentlichen Personennahverkehr (ÖPNV), auf gebührenpflichtigen Parkplätzen, im Flug- und Bahnverkehr sowie bei Sport- und Kulturveranstaltungen. Ein mobiles Ticket muss einige Voraussetzungen erfüllen. Neben regelmäßigen, geplanten und registrierten Veranstaltungen und Reisen, sind ad-hoc Verbindungen denkbar, bei denen der Nutzer sich in einer fremden Stadt bewegt, den ÖPNV nutzt und kein Zeitticket und keine Registrierung bei dem zuständigen Transportunternehmen besitzt. Tickets können von derselben Person oder von unterschiedlichen Personen gekauft und genutzt werden. Für Gruppen müssen entsprechende Verteilungs- und Authorisierungsmechanismen vorhanden sein. Heterogene Gerätetypen und Bezugsquellen erfordern ausreichend Kompatibilität. Mit dem Halten von virtuellen Tickets auf mobilen Geräten, üblicherweise Smartphones, können nun alle Schritte, von Erwerb bis Validierung über eine Plattform stattfinden, unabhängig von Zeit und Ort. Damit stellt sich eine ungebundene Benutzererfahrung ein. Das Smartphone ermöglicht das Abrufen und Anzeigen von Ticketdaten und kann umfangreiches Feedback über Vorgänge geben. Zurückliegende Fahrten und Veranstaltungen können in 34

40 3 Mobile Ticketing können statistisch ausgewertet werden. Moderne Mobiltelefone bieten darüber hinaus umfangreiche Möglichkeiten für Marketingmaßnahmen und sind so insbesondere für Mehrwertdienstleister und Werbetreibende von Interesse. Nach GSMA 14 wird zwischen Smart Ticketing - dem elektronischen Erwerb von Tickets, deren Einsatz und Zahlung und Integrated Ticketing unterschieden der Koordination von Ticketvorgängen zwischen verschiedenen Ticketausstellern. Die Übertragung von Tickets zwischen Mobilfunknetzbetreiber (MNO) zählt zu den Herausforderung von Smart Ticketing. Problematisch wird es, wenn virtuelle Tickets auf einer Universal Integrated Circuit Card (UICC 15 ) gespeichert werden. Sie wird oft als Subscriber Identity Module (SIM) bezeichnet, wobei SIM eine Anwendung auf einer UICC darstellt. Beim Wechsel des Netzbetreibers wird eine neue UICC notwendig. Tickets müssen daher transferierbar sein. Ferner sollte der Nutzer in der Lage Tickets effektiv zu verwalten, im Falle von Gruppenfahrten weiterzugeben, sofort einzusetzen und zu stornieren, insbesondere bei Verlust oder Diebstahl des mobilen Gerätes. Es ist sicherzustellen, dass Nutzer- und Ticketdaten sicher sind. Integrated Ticketing bezeichnet Querverbindungen von Ticketing zwischen Funknetz- und Dienstbetreibern. Darunter fällt das Akzeptieren von Tickets über Verbundsgrenzen hinweg. Dies gestaltet sich schwierig, aufgrund jeweiliger Marktinteressen. Die Wahrscheinlichkeit für ein internationales Reiseticket ist gegenwärtig und in naher Zukunft gering *. Ebenso steuert das Fehlen einer einheitlichen Implementierung von Ticketinganwendungen dagegen. 3.1 Technik Virtuelle Tickets basieren oftmals auf 2D-Barcodes. In der Zukunft geht man davon aus, dass vermehrt Funktechniken, insbesondere NFC zum Einsatz kommen. Die Basis bildet dabei die bereits erwähnte UICC-Komponente. Funknetzwerkbetreibern sind Herausgeber dieser Karten und nehmen hinsichtlich der Entwicklung von Frameworks und dem Ökosystem eine wichtige Rolle ein. Technisch gesehen sind Gerätehersteller in der Lage, eine erforderliche Infrastruktur zu installieren oder in bestehende Strukturen zu integrieren. Für Nutzer kann es notwendig werden, ihre bisherige UICC zu ersetzen. 14 Die GSM Association (kurz GSMA) ist eine weltweite Industrievereinigung der GSM- Mobilfunkanbieter. [Wik]. 15 UICC (Universal Integrated Circuit Card) ist eine Chipkarte und garantiert Integrität und Sicherheit von persönlichen Daten [Wik]. 35

41 3.1 Technik Abbildung 3.1: Aktuell gängige Repräsentationen mobiler Tickets. Links: einfacher Text; Mitte: 2D Barcode; Rechts: Integration mit Secure Element [OWe12; Eur12; ANe12] Ein wichtiger Punkt für den Übergang zur NFC-Technik liegt in der Sicherheit. Es muss garantiert werden, dass Anwendungen eine UICC-Karte nicht zerstören, beschädigen oder Daten von dieser kopieren können. Als geeignete Lösung wird eine Kombination mit Single Wire Protocol vorgeschlagen *. Damit wird mindestens das Sicherheitsniveau von der weit verbreiteten Smart-Card Technologie erreicht. * Standards sind von weitrechender Bedeutung. Für einheitliche und kompatible heterogene Kommunikation sind offene Regelungen vorzuziehen. Relevant sind hier insbesondere die erwähnten Normen ISO 14443, aber auch die überwiegend im asiatischen Raum vertretene ISO MiFare [Mif12], Calypso [CAL12] und ITSO [IT] gehören zu einer Reihe von Industrieprodukten bestehender Strukturen, denen man Beachtung schenken sollte Bestellverfahren Software Kunden können auf ihrem Mobiltelefon eine bestimmte Applikation installieren, mit der ein elektronisches Ticket erworben werden kann. Dabei kommuniziert das Gerät über drahtlose Verbindungstechniken mit einer Gegenschnittstelle der Dienst- und Produktanbieter. Das Ticket wird in der Regel verschlüsselt auf dem Telefon abgelegt. Eine mobile Applikation bietet ergänzend Möglichkeiten zur Betrachtung von Ticketinformationen und eine abgestimmte Benutzerführung. Bei der Installation und Abwicklung können Probleme aufgrund unterschiedlicher Geräte- und Tarifkonfigurationen der Hersteller und Netzbetreiber auftreten. Das HandyTicket-Projekt [HTD12] sei als Vertreter erwähnt, da es aufbauend auf einem bundesweiten Standard (VDV-Kernapplikation), mehrere Verkehrsverbünde in einer Applikation bedient. 36

42 3 Mobile Ticketing Per SMS oder MMS Der Ticketbezug erfolgt durch Senden einer festgelegten Nachricht an eine Betreiber- Nummer. Daraufhin erhält der Kunde ein virtuelles Ticket per SMS/MMS. Es kann sich dabei um Text oder einen 2D-Barcode handeln. Ein entsprechendes Kontrollgerät validiert die Gültigkeit. Eine spezielle Software ist nicht notwendig. Nachteile dieser Technik sind nicht immer verständliche Ticketangaben und anfallende Mobilfunknetzkosten für Kunden und Transportbetreiber. Per Web-Portal Ähnlich zum SMS-Verfahren, wird das Ticket als SMS oder MMS auf das Gerät des Kunden geliefert. Allerdings erfolgt die Bestellung über eine Internetseite. Damit fallen die Kosten für den Versandt weg. Ja nach Vertragskonditionen können Kosten für die Internetnutzung anfallen, insbesondere wenn der Kauf im mobilen Netz erfolgt und nicht immer steht eine Internetverbindung zur Verfügung. Mit dem Kaufzeitpunkt erfährt ein Ticket Gültigkeit. Vorausbestellungen sind selten möglich. Reisen müssen daher umgehend nach dem Ticketerwerb angetreten werden. Per Telefonnummer Eine Bestellung von Tickets kann über den Anruf einer Telefonnummer erfolgen. Jeder Tickettyp besitzt eine eigene Nummer. Das Ticket wird später per SMS/MMS ausgeliefert Prüfungsverfahren Onlineprüfung Die Prüfung von elektronischen Tickets übernimmt ein Hintergrundsystem. Die Prüfparameter, eine eindeutige Ticketnummer oder Personalausweisnummer werden vom Kontrolleur an das System übertragen. Die an den Kontrolleur gesendete Antwort gibt Auskunft über die Gültigkeit. Die Schwierigkeit besteht darin, eine ständige Verbindung mit dem Hintergrundsystem zu gewährleisten. Offlineprüfung Der Fahrkartenprüfer führt alle notwendige Soft- und Hardware mit sich, um die Gültigkeit eines Tickets zu bestätigen. Verschiedene Ausleseverfahren können zum Einsatz kommen. Auch ein manuelles Eingeben von Parameter kann notwendig sein. Die Prüfung erfolgt oft in Abgleich mit einer Identitätsbestätigung des Fahrgastes. 37

43 3.2 Ticketing im öffentlichen Verkehr Abrechnung Mobilfunkrechnung Erst seit 2008 können Dienstleistungen von Drittanbietern über Mobilfunkbetreiber abgerechnet werden. Der zu zahlende Betrag erscheint auf der Telefonrechnung und wird an den Drittanbieter in dieser Betrachtung ein Ticketingdienst - transferiert. Durch dieses Vorgehen ist es nicht mehr notwendig, sich beim Anbieter direkt zu registrieren. Für den Ticketanbieter bedeutet es in der Regel eine weitere finanzielle Abgabe an die Netzbetreiber. Finanzdienstleister Die Übertragung der fälligen Beträge geschieht über Dienstleister mit Banklizenzen. Dazu müssen an den Verbraucher Rechnungen er- und ausgestellt werden. Die Abrechnung erfolgt über konventionelle Transaktionswege bis hin zu Prepaid-Abbuchungen. 3.2 Ticketing im öffentlichen Verkehr Wo liegen nun die Vorteile vom Mobile Ticketing im öffentlichen Verkehr? Zum einen gibt es signifikante Aufwertungen in der Benutzerfreundlichkeit. Der Ticketkauf ist nicht mehr an einen bestimmten Ort gebunden. Tickets können bereits auf den Weg zu einer bevorstehenden Fahrt erworben werden. Ebenso ist es möglich, Fahrkarten zu jeder Zeit zu beziehen. Nutzer sind nicht an Öffnungszeiten von konventionellen Erwerbsstellen gebunden. Vorgänge sind überall und zu jeder Zeit möglich. Ticketinformationen können auf dem Speichergerät entsprechend aufbereitet werden. Der Nutzer kann den aktuellen Status des Tickets erfahren, abgleichen wenn es sich zum Beispiel um Mehrfahrten-Karten handelt - und er kann ein Protokoll aller gekauften Tickets erstellen. In zeitkritischen Situationen ist ein Erwerb auch dann noch möglich, wenn der Nutzer bereits das Transportmittel bestiegen hat. Mit den vorhanden Ticket/Fahrinformationen können Dienste zugeschalten werden, welche Begleitszenarien realisieren, ortsabhängige Informationen anbieten oder Werbung kommunizieren. Zusammengefasst zeichnet sich Mobile Ticketing durch Benutzerfreundlichkeit, Zuverlässigkeit, angemessene Preisgestaltung und Komfort aus. Durch die mobile Interaktion reduzieren sich Warteschlangen an Ticketschaltern. Das Erwerben, Erhalten und Bezahlen erfolgt Over The Air (OTA) 16. Der Nutzer ist nicht mehr auf 16 Over-the-Air (OTA) - Fern-Konfiguration - Eine Möglichkeit Daten ohne Kabel auf ein Gerät zu senden. Die Daten können zum Beispiel direkt über das Mobilfunknetz geschickt werden. 38

44 3 Mobile Ticketing Bargeld oder Geldkarten angewiesen. Vergisst er konventionelle Geldmittel oder hat schlichtweg nicht genügend dabei Bargeld, kann er mobile Zahlmethoden nutzen. Kosteneinsparungen ergeben sich aus geringeren Infrastrukturkosten. Der Umwelt kommt man entgegen, indem das bekannte Papierticket ersetz wird. Speziell die Verwendung von Magnetstreifen stellt einen hohen Recyclingaufwand dar. Mit der Etablierung eines attraktiven mobilen Ticketing-Dienstes könnte das Nutzungsvolumen von öffentlichen Verkehrsmitteln wachsen. Weniger physisches Geld im Ticketingprozess bedeutet weniger Angriffsziele für Kriminalität. Marketing und Werbung kann effizienter und individualisierter gestaltet werden VDV-Kernapplikation Der Verband deutscher Verkehrsunternehmen (VDV) hat im Jahre 2005 ein Forschungsprojekt für einen deutschen elektronischen Ticket-Standard abgeschlossen. Daraus ging die VDV- Kernapplikation hervor. [Sie] ist technischer Stand für alle Formen eines elektronischen Tickets, die in der Nahverkehrswelt heute geplant werden und damit technischer Standard und technische Lösung zugleich. Kernelement ist das elektronische Fahrgeldmanagement (EFM): 1. Bargeldloses Zahlen 2. Elektronischer Fahrschein 3. Automatisiertes Preisfinden Unter Bargeldlosem Zahlen werden elektronische Finanzierungsmöglichkeiten zusammen gefasst. Dazu zählen Geldkarten oder Mobilfunkverträge. Mit dem elektronischen Fahrschein ist eine Umstellung vom Papierticket zum elektronischen Ticket vorgesehen. Das Ticket hält der Kunde auf einem kompatiblen Gerät. Gewöhnlich wählt er beim Kauf das Ticket eigenständig aus. Das automatisierte Preisfinden ändert dies. Dafür werden konventionelle Tarife durch die elektronische Tariffindung abgelöst. Der Preis wird auf Grundlage von An- und Abmelden beziehungsweise durch die Erfassung des Kunden im Verkehrsmittel bestimmt. Wesentliches Projektziel besteht darin, Kundenschnittstellen zu den einzelnen EMF-Stufen zu standardisieren und gegenseitig interoperabel zu gestalten, um vielfältige Nutzungsszenarien zu gewährleisten. Alle EFM-Stufen werden betrachtet, die Tarifhoheit bleibt allerdings bei den Verkehrsunternehmen. Interoperabilität bedeutet für den Fahrgast, dass durchgehende Reisen ebenso garantiert werden, wie punktuelle Einzelfahrten. Für alle teilnehmenden Netzwerke steht eine Applikation zur Benutzung bereit, auf die alle Betreiber Zugriff haben. Voraussetzung sind eine einheitliche Datenhandhabung, eine identische Interpretation dieser Daten und ein einheitliches Verschlüsselungsverfahren für den sicheren Zugriff. 39

45 3.2 Ticketing im öffentlichen Verkehr Implementiert wird die Kernapplikation auf Geräten mit entsprechenden Mikroprozessoren und standardisierten Schnittstellen ISO 7816 für kontaktbehaftete und ISO IEC für kontaktlose Schnittstellen. Dazu zählen die erwähnte Geldkarte, von Verkehrsunternehmen herausgegebene Karten, UICC-Komponenten und Mobiltelefone. Mobiltelefone können die Kernapplikation implementieren und für alle drei EFM-Stufen verwendet. Mobile Zahlungen sind über den NFC-Standard möglich. Falls nicht vorhanden, steht mit dem konventionellen Telefonnetz eine Alternative zur Verfügung. Bei der Fahrtregistrierung kommen Check In/Check Out - (CICO) und Be In/Be Out - (BIBO) Strukturen zum Einsatz. Für CICO wird eine eticket Deutschland 17 - Chipkarte oder NFC- Mobiltelefon an ein Terminal im Zugangsbereich gehalten. Ein Hintergrundsystem berechnet den Fahrpreis. Als kritischer Punkt erweist sich die notwendige Registrierung des Ausstiegs. BEBO bedeutet die automatische Erfassung des Fahrgasts über Funktechniken. Ergänzend kann eine Prüfung auf Gültigkeit erfolgen. Die Applikation muss beim Kunden installiert sein und für Abo- und Zeitkarten sind ein gültiges Ticket und dessen Aktivierung erforderlich. Abbildung 3.2: Der Verkehrsverbund Rhein-Ruhr betreibt ein Chipkarten-Ticketsystem, basierend auf dem EFM- Standard mit knapp 1,3 Millionen Kunden und einer Vielzahl an Tarifvarianten. [etd] In anderen Ländern existieren ähnliche Implementierungen. Tokio führt die Suica-Card [Sui12], London die Oyster-Card [OC12], Hongkong die Octopus-Karte [OK12] und die Niederlande die OV-Chipkaart [OVC12] 17 Das eticket Deutschland, ist eine elektronische Fahrkarte für den ÖPNV in Deutschland. Es kann sowohl als Chipkarte als auch als Mobiltelefon-Applikation vertrieben werden und basiert auf der VDV-Kernapplikation [Wik]. 40

46 3 Mobile Ticketing 3.3 Ticketing mit NFC Nahfeldkommunikation gilt als schnelles und einfaches Ticketingverfahren mit umgehender Validierung. In Kombination mit mobilen Geräten sind Erweiterungen möglich. Dank kompatiblen Schnittstellen kann NFC in vorhandenen RFID-Strukturen eingesetzt werden. In der Regel wird NFC-Ticketing über eine Applikation auf dem Nutzergerät und einer Registrierung beim Ticketdienst gesteuert. Darüber können Fahrscheine erworben, heruntergeladen und Zugriffe verwaltet werden. Für Betreiber ergeben sich Kosteneinsparungen im Equipment- und Verteilungsbereich, für den Nutzer eine gesteigerte Zufriedenheit, für den Handel neue Ertragsströme. NFC arbeitet auf kurzen Entfernungen, ermöglicht einen schnellen Verbindungsaufbau und bewirkt eine intuitive Benutzererfahrung und kann ohne weiteres in existierende Transportumgebungen angewandt werden. Nahfeldkommunikation bedient drei primäre Prozesse - Verbindung, Zugang und Transaktion *. Alle drei finden sich auch im öffentlichen Nahverkehr wieder. Mobiltelefone verbinden sich mit einem Automaten und beziehen und bezahlen Tickets. Alternativ kann der Ticketbezug auch Over The Air erfolgen. Für den Zugang zu einen Transportsystem wird das Mobiltelefon an Autorisierungsstellen über ein Lesegerät validiert und auf gültige Tickets oder Verträge geprüft Vorteile Nahfeldkommunikation und elektronische Tickets sind ohne Weiteres kombinierbar. Daher sind die gleichen Vorteile gegenüber Papiertickets vorhanden. Ein NFC-fähiges Mobiltelefon macht ein Suchen und Mitführen unterschiedlicher kontaktloser Karten überflüssig. Das Gerät hält alle registrierten Karten und erkennt automatisch die geforderte Implementierung oder lässt den Nutzer entscheiden. Für ein Aufladen oder Ändern von Konten- und Vertragskonditionen sind keine Wege zu Verkaufsstellen notwendig. NFC-Tags und Smart- Poster sind einer der erwähnten neuen Kommunikationskanäle. Über diese können Fahrpläne und Serviceleistungen kommuniziert, gleichermaßen Werbeangebote und ortsabhängige Informationen und Attraktionen angeboten werden. NFC eignet sich als Mechanismus für Schließfächer und beim Verleih von zum Beispiel Fahrrädern. Dort, wo NFC-Terminals zur Ticketvalidierung zur Verfügung stehen, erhöht sich der Durchlass. Zustiegszeiten werden verringert, Betriebs- und Verwaltungskosten reduzieren sich. Durch das Wegfallen von Papiertickets vermindert sich der Bedarf an Ticketautomaten, - Verkäufern und Kontrolleuren. Papiertickets müssen produziert, gelagert und verteilt werden. Dafür braucht es Infrastrukturen, Verwaltung und Personal. Daher sind Papiertickets 41

47 3.3 Ticketing mit NFC teuer, umweltbelastend und können das Firmen-Image schädigen. Über mobile Anwendungen können Betreiber ihren Kunden Mehrwertdienste anbieten. Ein Vorteil zeigt sich bereits in der freien Wahl der Nutzersprache. Neue Produkte können beworben, Information effizient geliefert werden. Einfach zu realisierende Angebote binden den Nutzer zusätzlich. Ein Gerät kann über drahtlose Kommunikation blockiert und aktualisiert werden. Dieser Zeitgewinn vermindert den Missbrauch und die Fehleranfälligkeit gegenüber konventionellen Smart-Cards. Ferner ist es möglich Positionen von Nutzern zu bestimmen und zu verfolgen Zugangssysteme Der Einsatz von Nahfeldtechnik orientiert sich an Art, wie der Nutzer Zugang zum Nahverkehrsstruktur erhält. Offene Systeme Konventionelle Strukturen sind in der Regel offene Systeme. Es gibt keine Ein- oder Ausgangsschleusen und zum Einsatz kommen Papiertickets. Eine einfache NFC- Implementierung besteht aus NFC-Tags. Anwendungen lesen diese aus und interpretieren deren Inhalt. Ein Tag könnte zu einer Webseite für Fahrscheine navigieren und die Information des Startortes gleich mitliefern. Über die Telefonnummer des Nutzers wird dieser eindeutig referenziert. Ein Backendsystem erstellt die Verbindung und sendet das Ticket per SMS, Barcode oder spricht direkt das Secure Element im Nutzergerät an. Die Abrechnung erfolgt über eine separate Rechnung oder per Vereinbarung mit dem Mobilfunknetzanbieter. Das Szenario entspricht einem CICO-System. Eine Registrierung und Festlegung der Zahlungsabwicklung ist notwendig. Kontrollierte Systeme Ausgehend von NFC-fähigen Nutzergeräten stehen elektronische Validatoren am Eingang von Fahrzeugen oder Gebäudestrukturen bereit. Diese NFC-Lesegeräte prüfen die Gültigkeit von elektronischen Tickets. Automaten sind zum Erwerb von Tickets und Aufladen von Kontoständen installiert. Das Halten der Tickets auf dem Mobiltelefon lässt Verwaltungsaktionen und OTA-Dienste zu. Geschlossene Systeme Fahrkosten können in geschlossenen Systemen automatisch erfasst werden. Grundlage sind Durchgangsschleusen zusammen mit SmartCard-Technologie. Der Nutzer meldet allein das Betreten und Verlassen der Verkehrsmittel. Heutige Realisierungen basieren auf Verträgen mit Telefonherstellern und Transportunternehmen. Eine Applikation wird in das Secure Element des Gerätes integriert. Diese Applikation funktioniert nur im Netz des 42

48 3 Mobile Ticketing Transportunternehmens. Derzeit ist es umständlich, mehrere Anwendungen auf dem Element zu unterstützen * NFC-Tags im ÖPNV ÖPNV findet, wie der Name bereits verrät, im öffentlichen Raum statt. Dort befindet sich eine der Kernanwendungen der Nahfeldkommunikation. NFC-Tags, insbesondere in Kombination als Smart Poster ermöglichen die kostengünstige Verbreitung digitaler Information in öffentlichen Umgebungen. Welche Informationen aus dem ÖPNV-Kontext lassen sich nun auf Smart Poster übertragen? An und für sich unbegrenzt viele, da sich der Kontext beliebig erweitern und verändern lässt. Es scheint daher sinnvoll, eine Klassifikation aufzubauen, die Szenarien zusammenfasst. Das folgende Beispiel zeigt einen ersten Klassifikationsversuch für den Einsatz von NFC-Tags im öffentlichen Personennahverkehr. Dafür werden wichtige Eigenschaften beschrieben und per Symbol referenziert. 43

49 3.3 Ticketing mit NFC Bild Bezeichnung Beschreibung Applikationsabhängig Ortsabhängig Zeitabhängig Informations-Einheit Informations-Link Global Lokal Verkehrsunternehmen Information wird typischerweise mit einer dafür entwickelnden Applikation bezogen Information bezieht sich auf einen konkreten Ort in der Nähe (Hotel, Museum, etc.) Information ist in einem bestimmten Zeitraum gültig (Konzert) Information ist vollständig hinterlegt (Telefonnummern, etc.) Weiterleitung zu Information (Webseite, etc.); Internetzugang notwendig Information ist überall die selbe (Kontaktdaten des Verkehrsunternehmens) Information ist an Entitäten gebunden (Fahrzeug- Kennung/ID) Information stammt von Verkehrsunternehmen Drittanbieter Information stammt von Drittanbieter Statisch Information ändert sich nicht/selten (Haltestellenname) Dynamisch Kritisch Information ändert sich unter bestimmten Bedingungen (Ersatzfahrpläne) Kritische Tätigkeiten Tabelle 3.1: Klassifikation um den Einsatz von NFC-Tags im ÖPNV zu beschreiben. Diese Angaben können in Form einer Legende verwendet werden. Diese eignet sich insbesondere bei der visuellen Darstellung von Szenarien. So können zahlreiche Einsatzmöglichkeiten von Tags aufgeführt und beschrieben werden. 44

50 3 Mobile Ticketing Abbildung 3.3: Anwendung der Klassifikation am Beispiel einer Haltestelle und deren Umgebung. 3.4 Herausforderungen Derzeit werden drei Optionen für die sichere Speicherung eines elektronischen Tickets auf einem Mobiltelefon in Betracht gezogen. Ticketanwendungen werden auf die integrierte UICC/Sim-Karte übernommen. Neben der konventionellen UICC/SIM- Karte fügen Telefonhersteller ein separates sicheres Element hinzu. Telefone können über einen Steckplatz mit einer Secure Digital Karte (SD-Karte 18 ) erweitert werden, auf der Tickets hinterlegt werden. Es ist darauf zu achten, dass Entwicklungen sich in existierende Technik integrieren lassen. Das gilt insbesondere für Anwendergeräte und Infrastrukturen. Geräte sollten in der Lage 18 Eine SD Memory Card (Secure Digital Memory Card) ist ein digitales Speichermedium, das nach dem Prinzip der Flash-Speicherung arbeitet [Wik]. 45

51 3.4 Herausforderungen sein, mehrere Tickets auf einer einzelnen UICC zu halten. Momentan steh keine Standardlösung für das Verwalten von verschiedenen Ticketinganwendungen zur Verfügung. Dazu zählt die automatische Wahl des passenden Tickets an Kontrollsystemen. Eine Vielzahl von Lesegeräten unterstützt keinen Battery-Off Modus. Sie können passive NFC-Geräte nicht mit Strom versorgen. Daher braucht ein Telefon immer eine aktive Stromquelle für das Emulieren von Smart Cards. Wie oft ein Ticket genutzt wird, ist leicht zu ermitteln. Schwerer verhält es sich mit der Limitierung der Benutzung auf eine bestimmte Person. Für eine sichere Übertragung empfiehlt es sich SWP in NFC-Geräten zu integrieren. Ungeklärt ist ebenso, wie Ticketinganwendungen in Zukunft einheitlich auf eine UICC implementiert, wie OTA-Aktualisierungen und Übertragungen realisiert und wie OTA- Schnittstellen zwischen Funknetzbetreibern und Ticketing-Organisationen verhandelt werden. Die Frage nach einem adäquaten Geschäftsmodells wird überdies in der Literatur diskutiert [MTS10; MPS12]. Für proprietäre NFC-Produkte, wie MIFARE, sind Lizenzmodelle zu entwerfen. Zusammengefasst fehlt es an einem ausgereiften Standard für Mobile Ticketing. Hier sind Standardisierung-Instanzen gefragt, um proprietäre Lösungen zu verhindern oder abzulösen. 46

52 3 Mobile Ticketing 47

53 4.1 Verwandte Arbeiten 4 Mobile Reisebegleitung Eine Reisebegleitung ist unmittelbar an zwei Systementitäten gebunden: dem Nutzer und der Reise selbst. Primärer Gedanke ist, dass der Nutzer anhand der Reiseinformationen über bestimmte Vorgänge informiert wird. Nach der Betrachtung hilfreicher Arbeiten, wird ein Kernszenario entwickelt, welches Grundfunktionalitäten, Abhängigkeiten, Bedingungen und Herausforderungen identifiziert. Zum besseren Verständnis werden wir unseren Nutzer von im späteren Verlauf Lukas nennen. 4.1 Verwandte Arbeiten KAMO ist ein mobiler Reiseführer einer finnischen Forschergruppe. Die Applikation bietet die Möglichkeit der integrierten Reiseplanung und Verbindungsauskunft. Nutzer können sich Echtzeitdaten zu den Haltepunkten von Fahrzeugen anzeigen lassen. Ferner ist es möglich die Fahrtkosten mit Hilfe der Anwendung zu zahlen. KAMO übermittelt dem Nutzer Informationen über Probleme und Änderungen im ÖPNV-Fahrplan. Zum Projekt gehört ebenso die Echtzeitpositionierung von Fahrzeugen. Die Autoren integrieren NFC in ihre Applikation um Fahrplandaten an Haltestellen zu beziehen. Nutzer können sich, kurz vor dem Erreichen einer Haltestelle, warnen lassen. Dafür muss vorher aus einer Liste möglicher Haltestellen die gewünschte gewählt werden. Die Arbeit beschäftigt sich mit der Versorgung der Nutzer mit relevanten ÖPNV-Informationen mit Berücksichtigung der Nutzerzufriedenheit. Ein Nutzertest bescheinigt, dass die Probanden in der NFC-Technik eine einfache und intuitive Interaktion sehen [KAMO08]. Die Applikation DB Navigator der Deutschen Bahn ist zusammengefasst eine Verbindungsauskunft mit Navigationsfunktionen. Für die Planung einer Reise können konkrete Adressen oder auch Kontakteinträge aus dem Telefonbuch ausgewählt werden. Es gibt die Möglichkeit, gewählte Verbindungen in den Telefonkalender einzutragen. Eine integrierte Karte zeigt Haltestellen in der Umgebung an. Nutzer können elektronische Tickets 48

54 4 Mobile Reisebegleitung per MMS beziehen. Direkt aus der Applikation heraus können Fahrräder und Mietwagen reserviert werden. Grundlage der Applikation ist das Zeitplaninformationssystem HAFAS der Firma HaCon [HAF12]. Eine andere Arbeit beschäftige sich mit der Nahfeldkommunikation und deren Verwendung für mobile Ticketing. Anhand einer prototypischen Anwendung werden Probleme bei der Gestaltung und Handhabung identifiziert und Empfehlungen im Umgang mit NFC-basierten Mobile Ticketing formuliert [GSMM09]. Ein Ziel dieser Arbeit ist es, ein Gefühl dafür zu entwickeln, wie die oftmals eigenständigen Bereiche Ticketing, NFC-Kommunikation, Reiseplanung und Reisebegleitung in einem System kombiniert werden können. Einen ähnlichen Versuch auf abstrakter Ebene zeigt folgende Abbildung 4.1 [LMET09]. Abbildung 4.1: System aus Reiseplanung, Mobile Ticketing und Drittanbieter-Dienste aus [LMET09]. 49

55 4.2 Kernszenario 4.2 Kernszenario Verbindungsauskunft Ausgangspunkt ist eine Reise, besser gesagt, das Vorhaben eine Reise zu unternehmen und damit das Planen einer Verbindung mit öffentlichen Verkehrsmitteln. Verbindungsauskünfte können über unterschiedliche Dienste bezogen werden. Dazu zählen die Webseiten der Verkehrsunternehmen, mobile Anwendungen, aber auch konventionelle Möglichkeiten über Telefonanfragen. Da die spätere Reisebegleitung Daten in digitaler Form verarbeiten wird, konzentriert sich die Betrachtung auf Dienste, welche auf mobilen Geräten zur Verfügung stehen und in irgendeiner Form digitale Informationen austauschen können. Lukas nutzt daher eine mobile Anwendung des örtlichen Verkehrsnetzbetreibers und lässt sich eine Verbindung vorschlagen. Registrierung Daraufhin registriert er die gewählte Verbindung für eine Reisebegleitung. Die mobile Applikation bietet ihm die Möglichkeit über wenige Aktionen die Daten der Verbindung in den mobilen Reisebegleiter einzuladen. Er aktiviert die Erinnerungsfunktion und speichert die Konfiguration ab. Reisestart Lukas wird vor Fahrbeginn per Mitteilung an diesen erinnert. Zudem bekommt er vermittelt, dass der Fußweg zur Haltestelle fünf Minuten in Anspruch nimmt. Da ihm die Haltestelle bekannt ist, verzichtet er auf eine Navigationshilfe. An der Haltestelle angekommen, nutzt er die Reisebegleitung, um Linie und Richtung abzugleichen und die verbleibende Zeit bis zum Fahrbeginn zu erfahren. Wenige Augenblicke vor Beginn erhält er den Hinweis, dass die Fahrt unmittelbar bevorsteht. Nach dem Einstieg bestätigt er diesen. Er bekommt nun Informationen zum nachfolgenden Ereignis angezeigt. Umstieg Ein weiterer Hinweis signalisiert Lukas ein kommendes Ereignis. Er erfährt von einem bevorstehenden Umstieg. Er steigt an der entsprechenden Haltestelle aus. Da die sich anschließende die momentane Haltestelle nicht bedient, lässt er sich zu der entsprechenden Haltestelle navigieren. Er kann über die Karte seine Position nachvollziehen und bekommt Rückmeldung über die verbleibende Zeit bis zum Anschluss. Den folgenden Einstieg registriert er wiederrum in der Applikation. Reiseziel Ähnlich wie die vorherigen Ereignisse, wird auch das Ende der Reise über einen Hinweis vermittelt. Nach dem Ausstieg quittiert Lukas das Erreichen des Ziels. Er nutzt die Möglichkeit der Applikation, eine Rückreise zu planen. Er legt Datum und Zeit fest. Die 50

56 4 Mobile Reisebegleitung Applikationen leitet diese Informationen zusammen mit dem Wissen über Start und Ziel an einen Dienst für Verbindungsauskünfte weiter. Lukas bestätigt die Verbindung und registriert sie für eine Reisebegleitung. 4.3 Erweiterung des Szenarios Das Szenario ist nun soweit beschrieben, dass es Grundfunktionen einer Reisebegleitung ableiten lässt. Es ist sinnvoll, unseren Reisebegleiter mit einer Vielzahl von sekundären Funktionen auszustatten. Die folgenden sollen daher als Beispiel genannt sein. Verbindungsänderung Eine Verbindung kann zu jeder Zeit hinfällig werden. Gründe kann es dafür zahlreiche geben. Dabei wird es notwendig, eine neue Verbindung zu ermitteln. Entweder geschieht dies über externe Quellen, wodurch eine alte Verbindung verworfen und eine neue im System registriert wird, oder eine interne Realisierung ermöglicht Verbindungsauskünfte über Webservices der Verkehrsnetzbetreiber. Der Startort einer Auskunft kann aus der Ereigniskette übernommen, die bestehende Verbindung angepasst und damit Verbindungen aggregiert werden. Anschlussauskunft Eine abgeschwächte Variante erzeugt keine neue Verbindung, sondern zeigt Anschlussverbindungen an Haltepunkten der aktuellen Verbindung an. Haltestellen und Zeiten sind in den Basisdaten beschrieben. Störungen Eine Störung kann ebenfalls dazu führen, dass eine neue Verbindungsauskunft notwendig wird. Allein die Meldung einer Störung stellt ein signifikantes Plus in der Benutzerfreundlichkeit dar. Weiterführend scheint es sinnvoll, das Erstellen und Senden von Störungen an ein Backendsystem zu integrieren. Verbindungen favorisieren Das Speichern von Verbindungen eignet sich, falls der Nutzer diese oft, zu selben Zeiten und in einem konstant bleibenden Linienfahrplan nutzt. Für eine verlässliche Aussage ist es notwendig, Daten abzugleichen. Webservices von Verkehrsverbünden können dafür herangezogen werden. 51

57 4.4 NFC Szenarien Statistiken Eine hilfreiche Funktion stellen Auskünfte über vergangene Reisen dar. Ein Nutzer kann darüber die Frequenz seiner Fahrten ermitteln und darüber Rückschlüsse ziehen, ob sich gewisse Tarifvarianten im Ticketingbereich als günstig oder ungünstig erweisen. 4.4 NFC Szenarien Bereits im Kapitel über Ticketing-Techniken * wurde beschrieben, in welcher Form Nahfeldkommunikation im öffentlichen Verkehr eingesetzt werden kann. Neben den betrachteten sind weitere Anwendungsfälle vorstellbar. Eine alternative Engine kann NFC- Ereignisse und Verbindungsereignisse abgleichen und damit auf den zu Grunde liegenden Zustandsautomat einwirken. Ein Beispiel: In ÖPNV-Fahrzeugen werden NFC-Tags integriert. Diese können verschiedene Daten speichern, unter anderem eine eindeutige Fahrzeugkennung. Fahrgäste lesen diese Kennung mit NFC-fähigen Geräten aus. Die aktive Reisebegleitung erkennt die Fahrzeugkennung, gleicht diese mit der Reiseroute ab und stellt fest, in welchem Fahrzeug und damit auf welchem Punkt der Reise sich der Nutzer befindet. Die eindeutige Fahrzeugkennung ermöglicht eine hohe Validität der Aussage. Der Einsatz von Nahfeldkommunikation wird im Folgenden konzentriert. Ähnliche Betrachtungen bietet der Artikel von * Ticketing NFC eignet sich für das Beziehen von virtuellen Tickets an Automaten und Terminals. Virtuelle Tickets werden von elektronischen Kontrollgeräten ausgelesen. Die Kontrolle ist entsprechend den strukturellen Merkmalen realisiert (Kapitel *). Tickets können zwischen Nutzern getauscht werden. Elektronischer Handel NFC-Geräte können Geldkarten emulieren. Damit ist es möglich, Tickets, Waren und Dienste zu begleichen. In Zügen können Zeitschriften, auf Bahnhöfen Getränke bezogen werden. Ferner kann ein NFC-Gerät Quittungen von Zahlvorgängen speichern. Hinzukommen mobile Werbekanäle mit Gutscheinen, Rabatten und Kundenbindungsangeboten. Informationsaustausch Die Betriebsart Peer-to-Peer erlaubt den Austausch von Daten zwischen Nutzern und Geräten. 52

58 4 Mobile Reisebegleitung Informationsbezug NFC-Tags bieten die Möglichkeit nahezu überall zu geringen Kosten unzählige Arten digitaler Information zu hinterlegen. Je nach Anforderung können damit unterschiedliche Bedingungen hinsichtlich Beschaffenheit und Konfiguration verbunden sein. 53

59 5.1 Benutzeroberfläche 5 Konzeptionelle Analyse 5.1 Benutzeroberfläche Die Gestaltung der Oberfläche, sowie deren Bedienungskonzept stellen eine besondere Herausforderung bei mobilen Geräten dar. In der vorliegenden Arbeit konzentriert sich die Betrachtung auf berührungsempfindliche Smartphones. Die Entwicklung aktueller Geräte zeigt einen deutlichen Trend hin zur Verwendung von Touchscreens. Die dadurch resultierende Auswahl und Eingabe über Gesten und Berührungen, ebenso wie mobile Kontexte, erfordern dafür konzipierte Gestaltungs- und Interaktionsparadigmen [GO05; Sch09; WPR11; Nie]. Unter Berücksichtigung dieser erfolgt zusammen mit offiziellen Android Guidelines [ADe09; AUI12] ein Konzept für die Gestaltung einer mobilen Reiseapplikation und deren Bedienung Ansichten Mobile Applikationen bestehen aus einzelnen Ansichten. Zu einer Ansicht gelangt man in der Regel über Schaltflächen. Damit entsteht eine Verbindung von relativ abgeschlossenen Komponenten. Dieses Prinzip ähnelt dem Aufbau von Webseiten. Damit unterscheiden sich mobile Applikation von Anwendungen konventioneller Rechner (Desktop-PCs). Das liegt zum einen an den deutlich kleineren Bildschirm, wodurch die Anzahl dargestellter Elemente drastisch reduziert wird, zum Anderen auch am Fehlen von Maus und Tastatur als Eingabegeräte. Jede Ansicht einer mobilen Applikation sollte in sich abgeschlossen sein und nur die wichtigsten Funktionen anzeigen. Sekundäre Funktionen können in Kontextmenüs eingegliedert werden. Selten ist zu verhindern, dass mobile Anwendungen aus einer Vielzahl von Ansichten bestehen. Daher ist es wichtig die Verschachtelung der einzelnen Ansichten verständlich und in Tiefe und Breite ausgeglichen zu gestalten. 54

60 5 Konzeptionelle Analyse Startbildschirm Der Startbildschirm der Reisebegleitung orientiert sich am Dashboard-Design von Android. Ein Dashboard ist ein gängiges Muster für Startbildschirme von mobilen Anwendungen und zeigt die wichtigsten Funktionen an. Dafür werden Symbole mit Beschriftungen gleichmäßig verteilt. Das Dashboard ist Teil der Android UI Patterns [AUI12] Sammlung. Die Anzahl der dargestellten Funktionen ist variabel. In Anbetracht der kognitiven Verarbeitungsleistung des Kurzzeitgedächtnisses * lohnt sich eine Festlegung auf ungefähr fünf, sechs Möglichkeiten. Für die Reisebegleitung ergeben sich Neue Begleitung: für das Hinzufügen und Importieren von Fahrtinformationen. Alle Fahrten: ein Informationsüberblick über bevorstehende und zurückliegende Fahrten. Sharing: für den Austausch von Fahrten, Begleitungen oder sonstigen Daten. Plugins: für die Verwaltung (Hinzufügen, Entfernen) von Plugins. Einstellungen: zur individuellen Konfiguration der Applikation. Abbildung 5.1: Dashbard - Startansicht der Anwendung. Neue Begleitung Die Ansicht für das Einladen einer neuen Verbindung besteht aus drei Fragmenten. Im oberen Fragment befinden sich Schaltflächen für bestimmte Importfunktionen. Die Anzahl der 55

61 5.1 Benutzeroberfläche Möglichkeiten ist variabel und kann erweitert werden. Darunter befinden sich zwei Listen, die jeweils die bevorstehenden und zurückliegenden Reisen in zeitlicher Reihenfolge darstellen. Abbildung 5.2: Ansicht: Neue Begleitung. Alle Fahrten Die Ansicht aller Fahrten ähnelt der einer neuen Begleitung. Im Gegensatz dazu werden die Importschaltflächen durch Statistikfunktionen ersetzt und die Listen zusammengeführt und in der Länge nicht begrenzt. Der Nutzer kann über die Statistiken Informationen über längerfristige Zeiträume abrufen und damit zum Beispiel erfahren, wie viel Zeit er mit öffentlichen Verkehrsmitteln unterwegs ist und welche Ausgaben er dabei aufbringt. Sharing Dieser Punkt wird für die Konzipierung des Prototypens nicht weiter ausgearbeitet. Hinter diesen Punkt versteckt sich der Gedanke unterschiedliche Daten und Formate mit anderen mobilen Nutzern, Geräten, aber auch Firmen auszutauschen. Dazu zählt das Weiterleiten von Quittungen bei Dienstreisen, das Übertragen von Tickets auf Dritte, oder das Verbreiten von Informationen in sozialen Netzwerken. Plugins Auch die konkrete Betrachtung der Plugin-Verwaltung würde den Umfang der Arbeit überschreiten. Es handelt sich jedoch um ein interessantes Thema, dass sich für eine 56

62 5 Konzeptionelle Analyse aufbauende Untersuchung eignen würde. Zur Plugin-Verwaltung zählt das Installieren, Entfernen und Konfigurieren von Plugins, sowie das Beziehen dieser von zentraler Stelle. Für die Reisebegleitung wird beispielhaft eine Wetterauskunft realisiert. * Einstellungen Dieser Unterpunkt konzentriert Möglichkeiten die Applikation individuell zu konfigurieren. Dazu zählen Sprach- und Erinnerungseinstellungen. Für diese Aufgaben stellt Android eine eigene Komponente bereit. Eine PreferenceActivity [ACR] übernimmt die Darstellung und Organisation der Parameter. Bis hier hin ist die grobe Struktur, wie es der Startbildschirm vorgibt, bekannt. Im Folgenden sollen insbesondere die Merkmale der Reisebegleitung aufgezeigt werden. Hinter jeder importierten Verbindung verbirgt sich eine Begleitung. Verbindungen können über die erwähnten Listen ausgewählt und betrachtet werden. Daraufhin bekommt der Nutzer eine detaillierte Ansicht der Verbindung beziehungsweise der Begleitung angezeigt. * Verbindungsanzeige Im oberen Teil des Bildschirmes befindet sich eine Tableiste, mit der von Verbindung zu Verbindung gesprungen werden kann. Im unteren Teil befindet sich eine Statusanzeige. In der Mitte werden einzelne Ereignisse einer Reise dargestellt. Das bevorstehende Ereignis wird entsprechend gekennzeichnet. Eine Berührung öffnet das Ereignis. 57

63 5.1 Benutzeroberfläche Abbildung 5.3: Verbindungsanzeige. Zusammenfassung der Ereignisse einer Reise. Ereignisanzeige Zu jedem Ereignis gibt es eine Ansicht für die Betrachtung relevanter Daten. Ähnlich zur Verbindungsanzeige gibt es eine Tableiste, um zwischen Ereignissen zu springen und im unteren Teil eine Statusanzeige der aktuellen Begleitung. Zu den dargestellten Informationen zählen der Typ des Ereignisses, der Zeitpunkt des Eintretens, sowie Orts- und Transportmitteldaten. 58

64 5 Konzeptionelle Analyse Abbildung 5.4: Ereignisanzeige. Alternative Anzeigen Für Ereignisse und Verbindungen besteht die Möglichkeit, sich diese auf einer Karte darstellen zu lassen. Damit kann der Nutzer auch den räumlichen Verlauf der Reise erfassen. Die ideale Anzeige sieht vor, die Strecke der Verbindung, sowie die aktuellen Position anzuzeigen. Abgesehen davon kann eine zeitliche Ansicht ergänzt werden. Diese zeigt Ereignisse relativ zur Uhrzeit an. Somit ist der Nutzer in der Lage, kritische und kurzfristig aufeinander folgende Aktionen innerhalb geringer Zeitfenster zu erkennen. Die Darstellung orientiert sich an einer Arbeit über Visualisierungskonzepte von Fahrplandaten [Men12]. Die darin erarbeitete Balkendarstellung für zeitliche Verläufe ist nicht in jeder Hinsicht auf das Begleitungskonzept übertragbar. Ein Problem stellen die Übergänge zwischen einzelnen Fahrten, sprich Umstiege dar. Ein Umstieg besteht aus einem Aus- und Einstieg eines jeweiligen Fahrtabschnitts. Ein Balken repräsentiert jedoch keinen Ein- oder Ausstieg, sondern nur den Abschnitt als Ganzes. Um den Nutzer nun die Möglichkeit zu geben Umstiege konkret anzuwählen, werden die Balken durch Punkt-zu-Punkt Verbindungen ersetzt. Damit kann nun der Anfang und das Ende einer Fahrt gewählt werden und damit repräsentativ ein Umstieg. 59

65 5.1 Benutzeroberfläche (a) (b) (c) Abbildung 5.5: Alternativansichten: (a) Kartenansicht der Reiseroute. (b) Zeitliche Darstellung der Ereignisse nach [Men12]. (c) Erweiterte Ansicht von (b) Auftrennung von Fahrten in Anfang und Ende, um Ereignisse konkret auswählen zu können. Actionbar Bei der Actionbar handelt es sich um ein weiteres Konzept aus Android UI Patterns Sammlung [AUI12]. Actionbars realisieren kontextsensitive Funktionen an zentraler Stelle. Für die geplante Reisebegleitung wird dieses Element für jede Ansicht im oberen Teil platziert und ermöglicht zum Beispiel das Aufrufen des Startbildschirms oder das Wechseln zwischen alternativen Ansichten Benutzerführung Nachdem die einzelnen Ansichten nun konzipiert wurden, sind diese nun in einer nutzerfreundlichen und verständlichen Struktur anzuordnen. Dabei soll geklärt werden, wie der Nutzer zu einer Ansicht gelangt und wohin er von dort aus navigieren kann. Die Interaktionsfolge kann im folgenden Diagramm nachvollzogen werden. 60

66 5 Konzeptionelle Analyse Abbildung 5.6: Interaktionskonzept zur Beschreibung der Navigation durch die Anwendung. 5.2 Datenmodell Aus dem Kernszenario können bereits Grundfunktionalitäten für eine mobile Reisebegleitung abgeleitet werden. Dazu zählen das Importieren von Verbindungsdaten aus unterschiedlichen Quellen, das aktive Erinnern des Nutzers an bevorstehende Ereignisse, das Steuern des Programmablaufs über Bestätigungen von Ereignissen (Quittieren), das Navigieren zu unbekannten Orten und die Echtzeitangabe von reiserelevanten Informationen. Die Gewährleistung dieser Funktionskomponenten hängt von der Beschaffung konkreter heterogener Daten ab. Es ist daher sinnvoll einen Überblick zu erarbeiten, der die Bezugsquellen berücksichtigt. 61

67 5.2 Datenmodell Komponente Beschreibung Daten Bezug Import/Regist rierung Grundlage der Reisebegleitung ist eine Verbindungsauskunft, die über Schnittstellen eingelesen wird. Haltestellen, Zeiten und Verkehrsmittel für Start, Ziel und Umstiege. Mobile Applikation mit Exportfunktion * Webseite mit Exportfunktion * Auslesen von , SMS, Kalender Direktes Ansprechen eines Webservice für Verbindungen Auslesen von Ticket- Daten im Rahmen von eticketing Erinnerung Der Nutzer wird über bevorstehende Ereignisse informiert. Ereignisse, aktuelle Zeit, aktuelle Nutzerposition, Ereignispositionen Ereignisposition wird beim Import mitgeliefert wird über Drittdienst ermittelt Nutzerposition wird über GPS- und Funknetzortung ermittelt Uhrzeit ist verfügbar, Zeiten der Ereignisse über Import vorhanden Quittieren Erfolgreich abgeschlossene Ereignisse werden bestätigt für eine exakte, zuverlässige Begleitung. Ereignisse, aktuelle Zeit, Nutzer und Ereignisposition Siehe oben Navigation Wo sinnvoll, wird eine Kartennavigation angeboten. Ereignisse, aktuelle Zeit, Nutzer und Ereignisposition Siehe oben 62

68 5 Konzeptionelle Analyse Echtzeitinfor mation Relative Angaben zur aktiven Reise und bevorstehenden Ereignissen Ereignisse, aktuelle Zeit, Nutzer und Ereignisposition Verspätungen, Störungen Siehe oben Webdienste für Anfragen nach Störungen, < Tabelle 5.1: Zusammenfassung des Kernszenarios hinsichtlich benötigter Daten und deren Bezug. Aus den Beschreibungen werden nun Kerndaten extrahiert. Diese Kerndaten bilden die Grundlage der Komponenten. Dazu gehören Positions- und Zeitangaben zu den Haltepunkten, die während einer Reise erreicht werden. Solche Punkte können Start/Ziel einer Reise oder ein Umstieg sein. Im weiteren Verlauf werden Punkte als Knoten zusammengefasst. Jeder dieser zu erreichenden Knoten ist unmittelbar mit einer Zeitangabe verbunden, aber nicht direkt davon abhängig. Eine Zeitangabe kann variieren ohne dass dabei der Knoten Veränderung erfährt. Es wird der Begriff Ereignis eingeführt, das später im System getrennt vom Knoten existiert, allerdings eine Relation mit diesem eingeht. Ein Ereignis beschreibt neben der Zeit ebenso den Vorgang. Ein Umstieg ist ein Ereignis. Bis hierhin besteht eine Reise aus Knoten, die einen Ort kennzeichnen und zeitlichen Ereignissen, welche den Vorgang näher beschreiben. Für eine einfache Reisebegleitung fehlen dem Nutzer noch Angaben über ÖPNV-Linien. Diese Informationen kapseln wir im Begriff Verkehrsmittel. (a) (b) (c) Abbildung 5.7: Grundlegende Datenmodelle der Reisebegleitung. (a) Modell Knoten, (b) Modell Verkehrsmittel, (c) Modell Ereignis. Auf diesem Modell können Funktionen des Kernszenarios realisiert, Entscheidungen getroffen und komplexere Strukturen gebildet werden. Eine Fahrtverbindung lässt sich zum Beispiel aus Sequenzen von ÖPNV-Ereignissen formen. Das Modell orientiert sich nicht an bestehende Ansätze zu Beschreibung von Infrastrukturen im öffentlichen Verkehr, aufgrund der exklusiven Verwendung im späteren Prototyp. 63

69 5.3 Systemkomponenten 5.3 Systemkomponenten Im nächsten Schritt erfolgen eine Betrachtung der wichtigsten Systemfunktionalitäten und deren Aktivierung. Am Anfang steht die Einspeisung von heterogenen Verbindungsangaben über ebenso heterogenen Quellen. Jeder Quelle steht eine dafür entwickelte Importkomponente zur Verfügung. Diese Komponente analysiert die Daten und wandelt diese in eine interne Datenstruktur zur Repräsentation einer Verbindung um. Daraufhin registriert sich die Verbindung im System und erhält einen Begleiter. Damit ist jeder Verbindung ein eigenständiger Begleiter zugeordnet. Abbildung 5.8: Abstrakte Beschreibung der Systemkomponenten und Aktivierung. Ein Begleiter kennt die Verbindung und damit alle zugeordneten Ereignisse. Aufgrund dessen ist er in der Lage, Ereignisse zu propagieren in Form von Erinnerungen an den Nutzer. Um Mehrdeutigkeiten zu reduzieren, sollte ein Begleiter über das Wissen verfügen, relevante von irrelevanten, sowie betrachtete von nicht betrachteten Ereignissen zu unterscheiden. Dieses Wissen lässt sich durch Zustände modellieren. Dementsprechend kann ein Ereignis folgende Zustände annehmen. 64

70 5 Konzeptionelle Analyse 5.4 Systemzustände Ruhend: Initialzustand, den jedes Ereignis nach der Registrierung annimmt. Bevorstehend: Signalisiert dem System, dass es sich um ein relevantes Ereignis handelt, dass kurzfristig aktiv werden kann. Aktiv: Ein aktives Ereignis, dass unmittelbar stattfindet Quittiert: Ein Ereignis, das durch den Nutzer bestätigt wird. Er meldet dem System eine erfolgreiche Ausführung. Verpasst: Ein unbestätigtes Ereignis kann getrennt behandelt werden. Nicht alle Zustände können in einen beliebigen anderen Zustand übergehen. Das folgende Diagramm zeigt einen dafür entwickelten Automaten. Die großen Pfeile beschreiben den Grundzyklus, in dem ein ruhendes Ereignis in einen bevorstehenden, danach aktiven Zustand wechselt. Daraufhin kann das Ereignis über eine Nutzerbestätigung quittiert werden. Falls dies nicht geschieht, wechselt es in den verpassten Zustand. Sekundäre Übergänge sind ebenso möglich und dargestellt. Ruhend beschreibt den Initialzustand, Quittiert den Endzustand. Abbildung 5.9: Zusandsmodell von Ereignissen. Die kräftigen Pfeile beschreiben die übliche Übergangsfolge. Alle verbunden Übergänge können eintreten. Nicht verbundene bedeuten einen Fehler im System. Das Wissen über Ereigniszustände befähigt die Begleiterkomponente dazu, den Zuständen entsprechend zu reagieren. Primärer Anwendungsfall sind Rückmeldungen an den Benutzer über eintretende oder verpasste Ereignisse. Ein Begleiter ist darüber hinaus in der Lage, selbst Zustandswechsel einzuleiten. Konkrete Aktionen werden später, ebenso wie der oben 65

71 5.5 Plug-In Konzept beschriebene Zustandsautomat, in einem eigenständigen Element gekapselt. Dementsprechend können Begleiter variabel gestaltet werden. Abbildung 5.10: Arbeitsweise der Begleitkomponente. Über das Wissen aktueller Ereignisse werden Rückmeldungen erzeugt. Ein Ereignis kann seinen Zustand durch Nutzereingaben ändern, oder in Abhängigkeit von Kontexten. Der einfachste Kontext ist die Zeit. Über ein ermitteltes Intervall zwischen Ereignis und der aktuellen Zeit können Zustände beschrieben werden. Damit erhält eine Begleiterkomponente einen gewissen Grad an Autonomie. Der dahinterliegende Algorithmus wird im System als Engine deklariert. Eine Engine arbeitet in und gegen einen Kontext und ermöglicht dem Begleiter, aktiv zu agieren. Ein weiterer Kontext ist die Nutzerposition in Relation zu den GPS-Koordinaten der Ereignisse. Daraus resultierende Echtzeitentfernungen lassen Aussagen zu. 5.5 Plug-In Konzept Es stellt sich die Frage, wie und wo Erweiterungen im System und im Interaktionskonzept integriert werden. Der Fokus sollte auf dem Grundszenario liegen, da oben genannte Szenarien unregelmäßig eintreten. Dort, wo Erweiterungen separat vom Nutzer verlangt werden, ist es sinnvoll eine Aktivierung über die Benutzeroberfläche zu realisieren. Unter Berücksichtigung der Benutzerfreundlichkeit sollte dies an einer zentralen, bekannten Stelle geschehen. Ferner ist es notwendig, dass ausreichend Informationen für Erweiterungen zur 66

72 5 Konzeptionelle Analyse Verfügung stehen. Im Modell eignet sich insbesondere das Ereignis dazu, da es Zeit-, Orts-, und Zustandsinformationen enthält und an eine Verbindung gekoppelt ist. Der daraus resultierende Vorschlag sieht vor, Erweiterung aus der konkreten Ereignisanzeige aufrufen zu können. Abbildung 5.11: Beschreibung eines simplen Konzeptes zur Erweiterung des Funktionsumfangs. Jede Erweiterung ist in sich abgeschlossen und kann als primitive Plugin Komponente verstanden werden. Damit sind ergänzende verbindungsferne Funktionen vorstellbar. Der im Ereignis gespeichert Ort kann in Kombination mit der Zeitangabe als Grundlage für eine Wetterauskunft dienen, um eine Auskunft für den Zielort zu erhalten. Das dazugehörige Plug-In kommuniziert mit einem dafür bereitstehenden Webservice. Darüber hinaus können die Daten als Grundlage für eine Kostenstatistik dienen, bei welcher der Nutzer Zahlungen und Ausgaben registriert, wenn er exemplarisch Einkäufe auf Bahnhöfen erledigt. Ein letztes Beispiel stellt dem Nutzer lokale Ortskarten mit beliebigen Informationen zur Verfügung. 5.6 Filter Eine importierte Verbindung ist nicht in jedem Fall eine geeignete Verbindung für den Nutzer. Bei körperlichen Einschränkungen ist ein Nutzer auf barrierefreie Zugänge angewiesen. Eine Prüfung dahingehend ist aufwendig. Im optimalen Fall integriert die externe Verbindungsauskunft bereits diese Option. Andernfalls wäre eine Integration in den 67

73 5.6 Filter Prototypen möglich. Das Prüfen gegen bestimmte Kriterien erfordert einen Zugang zu Datenquellen. Das können dafür eingerichtete Webservices von Verkehrsunternehmen oder bereitgestellte Datenbanken sein. Das OpenStreetMap-Projekt listet zu Haltestellen bestimmte Meta-Daten [OMS12]. Darunter fallen Auskünfte über Barrierefreiheit, obgleich es sich um unvollständige Datensätze handelt. Abbildung 5.12: Konzept zur Bewertung von importierten Verbindungsdaten hinsichtlich kontextsensitiver Filterparameter. 68

74 5 Konzeptionelle Analyse 69

75 6.1 Android 6 Technische Analyse 6.1 Android Android ist ein auf Linux 19 basiertes Betriebssystem für mobile Geräte, welches zugleich Middleware-Lösungen und Basisapplikationen bereitstellt [AAn12]. Für die Entwicklung des Systems ist die Open Handset Alliance zuständig, ein Konsortium von zurzeit 86 Hardware-, Software- und Telekommunikationsunternehmen. Als Hauptmitglied agiert Google Inc. in leitender Funktion. Der Name Android geht aus einer 2003 gegründeten Softwarefirma für mobile Betriebssysteme hervor. Android wurde 2005 von Google aufgekauft und 2007 mit der Gründung der Open Handset Alliance offiziell als Projekt und Name für ein kommendes mobiles Betriebssystem bekanntgegeben. Das Betriebssystem ist ein Open-Source-Projekt mit offenem Quelltext und als solches entsprechend lizensiert (Apache Software License, 2.0). Für die Bereitstellung und Verwaltung des Quelltextes ist das Android Open Source Project zuständig. Software für Android wird in der Regel in der objektorientierten Programmiersprache Java entwickelt. Android Klassenbibliotheken basieren auf einer Untermenge der Apache Harmony Java-Implementation und sind nicht mit den Java SE, JAVA ME Profilen konform, da einige Bibliotheken fehlen und eigens entwickelte hinzugekommen sind. Allerdings steht für Android nicht die bekannte Virtuelle Maschine (VM) für Java, sondern eine speziell dafür entwickelte VM (Dalvik 20 ) bereit. Zudem wird kein Java-Bytecode ausgeführt, sondern ein daraus just in time kompilierter Dalvik-Dexcode. Die VM ist eine Software, die Applikationen auf den Gerät ausführt und dabei insbesondere für ressourcenarme Geräte konzipiert wurde und relativ geringen Speicher belegt. Ferner können mehrere Instanzen einer VM auf dem Gerät ausgeführt werden. Jede Applikation wird in ihrer eigenen abgesicherten Sandbox verwaltet. Dabei stehen einer Applikation nur die Ressourcen zur Verfügung, die sie explizit 19 Als Linux oder GNU/Linux werden in der Regel freie, unix-ähnliche Mehrbenutzer- Betriebssysteme bezeichnet, die auf dem Linux-Kernel basieren [Wik]. 20 Dalvik Virtual Machine (abgekürzt Dalvik VM oder DVM) ist eine für mobile Geräte entwickelte virtuelle Registermaschine und ein Hauptbestandteil der Android-Plattform von Google [Wik]. 70

76 6 Technische Analyse in einer Manifest-Datei angefordert hat. Vor einer Installation kann der Nutzer alle Zugriffe auf Systemkomponenten einsehen. Abbildung 6.1: Hauptbestandteile des Betriebssystems Android [AAn12]. Obige Abbildung zeigt die Architektur des Betriebssystems. Die einzelnen Ebenen sind in der Online-Dokumentation näher beschrieben [AAn12]. Die geplante Reisebegleitung baut wesentlich auf dem gezeigten Framework auf. Die Klärung der wichtigsten Komponenten hilft, die spätere Implementierung effektiv zu gestalten. 6.2 Anwendungskomponenten Eine Anwendung muss nicht zwingend eine Benutzeroberfläche besitzen. Auch kann deren Steuerung von Benutzeraktionen abgekoppelt sein. Für unterschiedlichste Anwendungsfälle stehen dem Entwickler vier Grundkomponenten zu Verfügung. Jede von ihnen repräsentiert einen Eintrittspunkt in eine Applikation. Jede Komponente ist für einen bestimmten Zweck konzipiert und besitzt einen individuellen Lebenszyklus. Activities Hinter Benutzeroberflächen verbergen sich Activities. Eine Activity übernimmt die Darstellung von Daten auf dem Bildschirm und hält eine konkrete Ansicht. Das Aufrufen einer neuen 71

77 6.3 Versionen Ansicht startet eine neue Activity. Jede Activity ist unabhängig, wodurch eine beliebige Initialisierung möglich ist. Services Ein Service ist eine im Hintergrund laufende Routine und für zeitaufwendige nebenläufige Operationen zuständig. Ein Service besitzt keine graphische Oberfläche, kann aber zur Interaktion an Activities gekoppelt werden. Ein Service kann für Musikwiedergabe und Netzwerkkommunikation eingesetzt werden. Content Provider Die Verwaltung von verteilten Anwendungsdaten übernehmen Content Provider. Damit lassen sich Dateien im System oder im Internet speichern, Datenbanken ansprechen und sonstige Möglichkeiten der Persistenz-Verwaltung realisieren. Broadcast Receiver Die letzte wichtige Komponente bietet die Möglichkeit, auf systemweite Ereignisse zu reagieren, beziehungsweise diese zu publizieren. Falls der Akkuladestand einen kritischen Wert erreicht hat, kann dieses Ereignis über ein Broadcast vermittelt und empfangen werden. Obendrein ist es möglich eigene Broadcasts aus einer Applikation heraus zu senden. Intents Ein Intent bildet das Aktivieren einer Komponente ab. Activities, Services und Broadcast Receivers können über diese asynchronen Nachrichten aufgerufen werden. Intents verbinden getrennte Komponenten zur Laufzeit. Manifest Datei Diese Datei dient dazu, Abhängigkeiten im Betriebssystem zu registrieren. In ihr werden alle Anwendungskomponenten der Applikation gelistet. Ebenso kann ermittelt werden, welche Software- und Hardwareanforderungen notwendig sind und insbesondere welche Nutzerberechtigungen verlangt werden. Dazu zählen beispielsweise der Internetzugang oder das Auslesen von Kontaktdaten. 6.3 Versionen Erstmalig wurde das Betriebssystem im Beta-Status im November 2007 veröffentlicht. Seit April 2009 erhält jede neue Version den Beinamen einer Süßspeise - Cupcake, Donut, Eclair, Froyo, Gingerbread, Honeycomb und Ice Cream Sandwich. Die aktuellste trägt die Versionsnummer (Stand März 2012). 72

78 6 Technische Analyse 6.4 NFC Die Nahfeldkommunikation wurde bereits in vorherigen Kapiteln ausführlich beschrieben. Zusammengefasst handelt es sich um eine Kommunikationsmethode, bei der Daten auf kurzer Distanz über ein elektromagnetisches Feld übertragen werden. Verbindungen werden dabei unmittelbar aufgebaut und das Datenvolumen ist niedrig, da keine großen Bandbreiten erreicht werden können und es sich bei der dieser kontaktlosen Kommunikation um eine flüchtige Interaktion handelt. Google unterscheidet für sein Betriebssystem zwei primäre Anwendungsfälle: das Lesen von NDEF-Nachrichten von einem NFC-Tag und das Senden von NDEF- Nachrichten von Gerät zu Gerät. Letzteres ist auch unter dem Begriff Android Beam bekannt. Das Lesen von NDEF- Inhalten wird über ein Tag Dispatch System gesteuert. Es analysiert vom Gerät erkannte Tags, kategorisiert entsprechend die Daten und gibt diese Daten einer korrespondierenden Anwendung weiter. Eine einfache Möglichkeit Interesse an bestimmten Daten zu signalisieren besteht in der Deklarierung von Intent-Filtern [Int12]. Bei der Analyse von Tag-Inhalten findet eine Prüfung auf MIME Media Types oder URIs statt. Daraufhin kapselt Android das Ergebnis in einen Intent, worauf entsprechende Anwendungen reagieren können. Mit der Priorisierung des NDEF-Datenstandards entspricht Android der Empfehlung des NFC-Forums und garantiert damit einen offenen plattformunabhängigen Kommunikationskanal. Für andere Typen können müssen Protokollstapel bereitgestellt werde. Welche Typen und zugehörigen Inhalte konkret Unterstützung finden, listen Tabellen- 1 und -2 in der Online-Dokumentation [NBa12] Tag Dispatch System Um verlässlich auf NFC-Ereignisse reagieren zu können, ist es wichtig zu verstehen, wie diese vom System im Detail behandelt werden. Ereignisse werden in drei Kategorien zusammengefasst. Sie beschreiben entweder das Erkennen eines NDEF-formatierten (NDEF- DISCOVERED) Tags, einer unterstützten NFC-Plattform (TECH-DISCOVERED) oder eines unbekannten Tags (TAG-DISCOVERED). Die Implementation prüft zuerst, ob es sich um einen NDEF-Tag handelt. Falls dem so ist, erfolgt die Suche nach passenden Anwendungen. Findet sich keine, wird das Ereignis zu einem TECH-DISCOVERED-Ereignis herabgestuft. Dieses Ereignis tritt ebenso ein, falls im ersten Schritt die NDEF-Prüfung fehlschlug. Daraufhin erfolgt eine weitere Ermittlung von in Frage kommenden Anwendungen. Bei keiner Übereinstimmung erfolgt die Umwandlung in das niedrigste TAG_DISCOVER-Ereignis mit der Prüfung auf dafür registrierte Applikationen. Kommt es in einen der genannten 73

79 6.4 NFC Schritte zu einer Übereinstimmung zwischen Ereignis und Anwendung, bricht der Standardalgorithmus ab und die Übermittlung der Daten zur Anwendung erfolgt. Im Falle von mehreren möglichen Anwendungen erfolgt eine Auswahl durch den Nutzer. Das folgende Diagramm zeigt den Vorgang schematisch. Abbildung 6.2: Tag Dispatch System [NBa12] NFC steht ab der Android API-Version 10 zur Verfügung. Die BEAM-Erweiterung ab der Version 14. Um die drahtlose Kommunikation nutzen zu können, sind folgende Einträge in der Manifest-Datei notwendig. 1 <uses-permission android:name="android.permission.nfc" /> 2 <uses-sdk android:minsdkversion="10"/> 3 <uses-feature android:name="android.hardware.nfc" android:required="true" /> Listing 6.1: Manifestkonfiguration zur Verwendung von NFC-Technologie. Wie angesprochen stehen Intent-Filter bereit, um dem Betriebssystem das Interesse an NFC- Ereignissen zu signalisieren. Das Beispiel filtert einfache Textnachrichten, welche per NDEF- Standard gespeichert wurden, 1 <intent-filter> 2 <action android:name="android.nfc.action.ndef_discovered"/> 3 <category android:name="android.intent.category.default"/> 4 <data android:mimetype="text/plain" /> 5 </intent-filter> Listing 6.2: Intent-Filter, um NFC-Ereignisse und Nachrichten eines bestimmten Typs empfangen zu können. und zeigt den notwendigen Quellcode, um den Inhalt des Intents und damit des Tags zu lesen. 74

80 6 Technische Analyse 6 public void onresume() { 7 super.onresume(); if 10 NfcAdapter.ACTION_NDEF_DISCOVERED.equals(getIntent().getAction())) { 11 Parcelable[] rawmsgs = 12 ntent.getparcelablearrayextra(nfcadapter.extra_ndef_messages); 13 if (rawmsgs!= null) { 14 msgs = new NdefMessage[rawMsgs.length]; 15 for (int i = 0; i < rawmsgs.length; i++) { 16 msgs[i] = (NdefMessage) rawmsgs[i]; 17 } 18 } 19 } 20 } Listing 6.3: Auf NFC-Ereignisse im Programm reagieren. NDEF-Nachrichten auslesen. Das Konzept hinter Android Beam entspricht im Grunde dem Peer-to-Peer Modus der NFC- Spezifikation und ist somit eine interne Programmierschnittstelle dafür. Aktiviert wird dieser durch Aneinanderhalten von NFC-fähigen Geräten. Als Voraussetzung muss die sich im Vordergrund befindende Anwendung die Beam-Schnittstelle ansprechen. Nach einer Nutzerbestätigung werden Daten übertragen Google Wallet Wallet steht für eine elektronische Geldbörse auf Basis der Nahfeldkommunikation. Es handelt sich um eine Applikation und ein Mobile Payment System. Mit Wallet ist es möglich, Kredit-, Kundenkarten, Gutscheine und Ähnliches auf dem Gerät zu speichern. Wie üblich erfolgen Authentifizierungen in Kombination mit PIN 21 dem Secure Element auf dem Gerät. Momentan ist Google Wallet nur in der Vereinigten Staaten verwendbar. Das System basiert auf einer Kooperation zwischen Google und den Finanzdienstleistern Citi und MasterCard. In der Summe sind Händler in den USA in der Lage Wallet-Zahlungen zu bearbeiten [Ham11]. Google bietet neben MasterCard eine eigene Prepaidkarte an. Das Projekt ist Anfang 2012 wegen Sicherheitsmängeln in die Schlagzeilen gekommen [Gol12]. 21 Eine Persönliche Identifikationsnummer (PIN) ist eine Zahl, mit der sich Personen gegenüber einer Maschine authentisieren können [Wik]. 75

81 6.5 Positionsermittlung 6.5 Positionsermittlung Die Ermittlung der aktuellen Position des Nutzers ist von großer Bedeutung für ein Begleitszenario. Einen gewünschten Ort zu erreichen ist das vorrangige Ziel. Nicht weniger bedeutsam ist dies möglichst komfortabel und benutzerfreundlich zu gestalten. Die aktuelle Position kann zur Laufzeit validiert werden. Damit lassen sich Abweichungen erkennen und mit der bekannten Ortsinformation ebenso Lösungen finden - eine erneute Reiseplanung, um das Ziel ohne Aufwand dennoch zu erreichen. Allein die Darstellung der aktuellen Position und die damit verbundene Rückmeldung an den Nutzer verbessert die Nutzererfahrung Methoden GPS (Global Positioning System) gilt als eine gängige Möglichkeit, Positionen im Freien zu bestimmen. Wie der Name andeutet, ist die Ermittlung nahezu auf dem gesamten Erdball möglich. Da es sich um ein satellitengestütztes System handelt ist Sichtkontakt zum Erdempfänger notwendig. Daher funktioniert GPS in Gebäuden nicht oder nur unzureichend. Ehemals als militärisches System für die US-Marine initiiert, ist es später für die zivile Nutzung freigegeben worden und ermöglicht unter guten Bedingungen eine Ortsbestimmung bis auf wenige Meter. Unter Differential-GPS fasst man Verfahren zusammen, die über den simultanen Einsatz mehrerer Empfänger die Genauigkeit bis in den Zentimeterbereich steigern können. Galileo beschreibt ein alternatives Satellitenprojekt, getragen von der Europäischen Union und der Europäischen Weltraumorganisation (ESA). Zur Ortung werden die Signale von mindestens drei Satelliten benötigt. In der Praxis zeigen sich allerdings erst mit vier Satelliten brauchbare Ergebnisse. Die Berechnung erfolgt auf dem Empfängergerät selbst und basiert auf den gesendeten Positionsdaten der Satelliten. Neben GPS ist die mobilfunkbasierte Positionsbestimmung eine verbreitete Methode [GSM12]. Die Messverfahren basieren auf der Infrastruktur des Funknetzes, insbesondere dessen Sendestationen und zellularen Aufbaus. Eine Zelle hat eine ID. Ein Mobiltelefonnutzer kann diesen Zellen zugeordnet werden. Dies beschreibt die einfachste Variante und liefert wenig genaue Werte. Nimmt man die Laufzeiten der Signale hinzu und gleicht sie ergänzend mit mehreren benachbarten Stationen ab, können genauere Ergebnisse erzielt werden, jedoch in der Regel ist die mobilfunkbasierte Lösung GPS unterlegen. Um auch in Innenräumen brauchbare Aussagen zur Position treffen zu können, sind alternative Varianten notwendig. Ansätze basieren auf der Infrastruktur eines WLAN-Netzes und sind ähnlich zum Mobilfunkansatz realisiert [IMP06; PFT06]. Ein Zugangspunkt ist im System eindeutig identifizierbar. Darüber kann ein Nutzer einem oder mehreren in seiner 76

82 6 Technische Analyse Reichweite befindlichen Punkten zugeordnet werden. Statt dem Zeitfaktor nimmt man die Signalstärke als relatives Vergleichskriterium. Je Stärker das Signal, umso kürzer die Distanz zwischen Nutzer und Zugangspunkt Implementierung In Android wurden alle drei oben genannten Verfahren realisiert, wobei in der Implementierung in Funk- und GPS-basierte Ermittlung unterschieden wird. Dafür stehen die Bibliotheken GPS Provider und Network Location Provider bereit. Positionsermittlungen werden von vielen Faktoren beeinflusst, welche zu unterschiedlichen und fehlerhaften Resultaten führen kann. Herausforderungen stellen die unterschiedlichen Bezugsquellen der Ortsinformation, Positionswechsel des Nutzers oder die variierende Genauigkeit der erhaltenen Informationen dar. Möchte man in seiner Anwendung Positionsdaten ermitteln, registriert man diese bei einen dafür vorgesehen Dienst, welcher dann über Callback-Funktionalitäten Informationen übermittelt. Dafür wird ein Listener 22 implementiert, welcher auf Positions- und Zustandsänderungen reagieren kann. Zustände sind dabei in Zusammenhang mit Bezugsquellen, wie GPS zu verstehen. Bezugsquellen stehen nicht zu jedem Zeitpunkt zur Verfügung. 21 // Acquire a reference to the system Location Manager 22 LocationManager locationmanager = (LocationManager) 23 his.getsystemservice(context.location_service); 24 // Define a listener that responds to location updates 25 LocationListener locationlistener = new LocationListener() { 26 public void onlocationchanged(location location) { 27 // Called when a new location is found by the network location 28 provider.makeuseofnewlocation(location); 29 } public void onstatuschanged(string provider, int status, Bundle 32 extras) {} 33 public void onproviderenabled(string provider) {} 34 public void onproviderdisabled(string provider) {} 35 }; 36 // Register the listener with the Location Manager to receive location 37 updates 38 locationmanager.requestlocationupdates(locationmanager.network_provider 39 0, 0, locationlistener); 22 Der Observer (Beobachter, Listener) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung [Wik]. 77

83 6.6 Austausch von Inhalten Listing 6.4: GPS-Daten im Programm empfangen und verarbeiten. Im obigen Beispiel repräsentiert der LocationManager eine Komponente, um Ortsinformationen zu empfangen. Im nächsten Schritt wird ein konkreter Listener registriert. Dieser erhält nun Positionen. Der gleiche Aufruf kann mit LocationManager.GPS_PROVIDER geschehen, um eine Satellitengestützte Ortung zu aktivieren. Für die Nutzung von Ortsbestimmungs-Diensten muss eine Berechtigung erlangt werden. Diese wird per entsprechenden Eintrag in der manifest-datei erlangt. 40 <manifest> 41 <uses-permission 42 android:name="android.permission.access_fine_location" /> 43 </manifest> Listing 6.5: Manifestkonfiguration zur Verwendung von GPS-Empfängern. 6.6 Austausch von Inhalten Im Folgenden geht es um den Austausch von Inhalten zwischen Applikationen. Für das gedachte Begleitszenario genüg die Betrachtung von Textinformation. Diese können zum Beispiel Verbindungsdetails für eine geplante Reise enthalten. Der Austausch macht es möglich, bereits vorhandene Applikationen auf den Mobiltelefon zu nutzen und auf eigene Implementierung der benötigen Funktion zu verzichten. So kann eine vorhandene ÖPNV- Applikation zur Ermittlung möglicher Verbindungen herangezogen werden. Ist eine Anfrage erfolgt, sendet der Nutzer die gewählte Fahrt als Text an die Reisebegleitungsapplikation. Diese analysiert und interpretiert den Text und erstellt eine aktive Begleitung zur gewählten Verbindung. Ebenso denkbar wäre das Importieren von kompletten Reisebegleitungen in einem bestimmten Format, beziehungsweise der Export von Reisebegleitungen aus der Anwendung heraus. Begleitungen können so in Kalender eingetragen, als verschickt oder als SMS versendet werden, ohne selbst diese Funktion implementieren zu müssen. Android ermöglicht das Delegieren von Inhalten über Intents und das Empfangen von Nachrichten über Intent-Filter. Ein Intent ist eine Art Auslöser für eine Aktion, in unserem Fall für die Aktion Senden, welche durch den Typ ACTION_SEND identifiziert wird. Inhalte werden zwischen Activities ausgetauscht und über Prozessgrenzen hinweg. Daher ist es 78

84 6 Technische Analyse möglich, Nachrichten zwischen unterschiedlichen Applikation zu verschicken. Dafür müssen die Daten und der Typ spezifiziert werden. Die Typinformation hilft dabei nur relevante Applikationen mit der Nachricht zu versorgen, welche in ihrer Manifest-Datei einen entsprechenden Intent-Filter für den Typ deklariert haben. 44 Intent sendintent = new Intent(); 45 sendintent.setaction(intent.action_send); 46 sendintent.putextra(intent.extra_text, "This is my text to send."); 47 sendintent.settype("text/plain"); 48 startactivity(sendintent); Listing 6.6: Inhalte mit unbestimmten Anwendungen tauschen. Das Beispiel zeigt das Senden von Textinhalten. Wie beschrieben wird ein Intent erstellt, diesem eine Aktion (ACTION_SEND), ein Typ ( text/plain ) und die Nachricht selbst zugewiesen. Ebenfalls ist zu erkennen, dass keine bestimmte Anwendung oder Activity direkt aufgerufen wird. Die Methode startactivity erhält den Intent. Das Betriebssystem ermittelt anhand der manifest-dateien aller Anwendungen, welche einen entsprechenden Intent-Filter aufweisen. Ist auf dem Gerät nur eine passende Anwendung installiert, wird diese aufgerufen. Im Falle von mehreren Möglichkeiten wird ein Dialog zu Auswahl aufgerufen. Gibt es keine Übereinstimmung, erfolgt eine Meldung. Um Nachrichten erhalten zu können, muss die Manifest-Datei wie unten angepasst werden. Innerhalb einer Activity-Definition wird ein Filter eingefügt, der die Aktion und den Typ näher beschreibt. Erfolgt ein Intent, wird die im Activity-Tag geführte Activity aufgerufen und der Intent delegiert. 49 <activity android:name=".ui.myactivity" > 50 <intent-filter> 51 <action android:name="android.intent.action.send" /> 52 <category android:name="android.intent.category.default" /> 53 <data android:mimetype="image/*" /> 54 </intent-filter> 55 </activity> Listing 6.7: Auf Anwendungen reagieren, die Daten eines bestimmten Typs tauschen wollen. Nun kann die Abarbeitung des Intents erfolgen. Wie zu sehen, werden Aktion und Typ aus dem Intent gelesen und geprüft. 56 void oncreate (Bundle savedinstancestate) { // Get intent, action and MIME type 79

85 6.6 Austausch von Inhalten 59 Intent intent = getintent(); 60 String action = intent.getaction(); 61 String type = intent.gettype(); 62 if (Intent.ACTION_SEND.equals(action) && type!= null) { 63 if ("text/plain".equals(type)) { 64 handlesendtext(intent); // Handle text being sent 65 } 66 } 67 } 68 void handlesendtext(intent intent) { 69 String sharedtext = intent.getstringextra(intent.extra_text); 70 if (sharedtext!= null) { 71 // Update UI to reflect text being shared 72 } 73 } Listing 6.8: Verarbeiten von empfangenen Daten. 80

86 6 Technische Analyse 81

87 7.1 Architektur 7 Prototypische Umsetzung Das anstehende Kapitel fasst nennenswerte Aspekte der Implementierung zusammen. Zu Beginn wird auf die aus der Analyse resultierende Architektur eingegangen. Anschließend erfolgt eine Vorstellung der umgesetzten Benutzeroberfläche. Ergänzend wird auf kennzeichnende Kernfunktionen eingegangen. 7.1 Architektur Da bekannt ist, dass Android keine vollständige Plattformunabhängigkeit trotz der Verwendung von Java bietet, erfolgte eine Trennung von internen Kernfunktionalitäten und androidspezifischen Verhalten. Die aus der Analyse bekannten Komponenten, Engine mit Zustandsautomat und Eventhandler, Imports, sowie Datenmodelle werden als reine Java- Klassen realisiert ohne Bibliotheken aus der Androidwelt zu verwenden. Kompatibilität und Flexibilität werden über Schnittstellen, konkret Java-Interfaces ermöglicht. Für die mobile Applikation bedeutet das: GUI-Ereignisse (Dialoge, Statusbarnachrichten) werden über Androidbibliotheken erzeugt. Diese werden in einer konkreten Klasse gekapselt, welche die Schnittstellen des abstrakten Handlers erbt. Dieser ist plattformunabhängig implementiert. Das untere Architekturdiagramm veranschaulicht den Ansatz. Zwei externe Frameworks werden verwendet, Simple XML und Joda-Time. Diese reduzieren den Implementierungsaufwand, können jedoch entfernt und selbständig implementiert werden. Simple XML erzeugt aus XML-Dokumenten Java-Objekthierarchien und umgekehrt, Joda-Time stellt eine flexible und flexible Bibliothek für Datums- und Zeitoperationen dar. 82

88 7 Prototypische Umsetzung Abbildung 7.1Architekturkonzept des Prototypens. 83

89 7.2 GUI Realisierung 7.2 GUI Realisierung In Kapitel 5 wurde eine konzeptionelle Benutzeroberfläche für eine Reisebegleitung vorgestellt. Abbildung 7.2 zeigt nun, in wie weit das Konzept umgesetzt wurde. Auf einer Implementierung der grau hinterlegten Komponenten wurde verzichtet, da der Fokus der Implementierung auf der Grundfunktionalität und Erweiterbarkeit lag. Eine spätere Arbeit könnte diesen Punkt aufgreifen und die Umsetzung der verbleibenden Komponenten realisieren und evaluieren. Abbildung 7.2: Überblick der realisierten Ansichten. Grau hinterlegte Ansichten wurden nicht umgesetzt (vlg. Abbildung 5.6 ) Im Folgenden sind die Ansichten im Detail dargestellt. 84

90 7 Prototypische Umsetzung (a) (b) (c) Abbildung 7.3: Implementierte Ansichten. (a) Startbildschirm und Dashboard mit den wichtigsten Funktionen im Überblick. (b) Neue Begleitung - Ansicht mit der Möglichkeiten Verbindungen einzulesen und Begleitungen aus den Listen zu wählen. (c) Detailansicht zu Ereignissen. Über die Tabs kann zwischen Ereignissen gewechselt werden. Die Schalfläche im unteren Teil (Puzzlestück) öffnet die Wetterabfrage. 7.3 NFC-Verarbeitung Angelehnt an die Vorgaben im Abschnitt über NFC-Verarbeitung (Abschnitt 6.4.1) existiert für den Protopyen ein Intent-Filter, der für das Erkennen von NFC-Tags sorgt und eine bestimmte Komponente der Anwendung aufruft. 74 <activity android:name=".nfc.nfcactivity" > 75 <intent-filter> 76 <action android:name="android.nfc.action.ndef_discovered" /> 77 <category android:name="android.intent.category.default" /> 78 <data android:mimetype="text/plain" /> 79 </intent-filter> 80 </activity> Listing 7.1: Registriert eine Anwendung für das Erhalten von NDEF-Nachrichten im "text/plain" Format. 85

91 7.4 Service-Komponente Diese Komponente erzeugt lediglich eine Rückmeldung an den Nutzer, dass der Tag erkannt wird. Der eigentliche Inhalt wird an den NFCController weitergereicht. Dieser stellt das zentrale Verarbeitungselement dar. 81 NFCController.instance().parse(intent.getParcelableArrayExtra( NfcAdapter.EXTRA_NDEF_MESSAGES)); Listing 7.2: Eine zentrale Komponente übernimmt die Verarbeitung von erkannten NFC-Intents. Der NFCController stellt Methoden zum Interpretieren von Tag-Nachrichten (Records) bereit und delegiert diese an registrierte NFCEngines. Dies ermöglicht eine einfache Behandlung von NFC-Ereignissen. 82 NFCEngine nfc = new NFCEngine(); 83 NFCController.instance().registerNFCEngine(nfc); Listing 7.3: Ermöglicht das Empfangen von NDEF-Records. Die Anwendung nutzt diese Möglichkeit, um die ID des Verkehrsmittels auszulesen, in welchem sich der Nutzer befindet. Die ID ist auf einen NFC-Tag gespeichert und wird beim Berühren übertragen. Anschließend erfolgt ein Vergleich der gelesenen ID mit denen der Fahrzeuge aus dem Datensatz. Stimmen beide überein, kann davon ausgegangen werden, dass der Nutzer sich in diesem Moment in dem zugehörigen Fahrzeug befindet. Fahrzeuge sind an Ereignisse gebunden. Verschiedene Ereignisse können das gleiche Fahrzeug teilen. Zum Beispiel beim Ein- und Aussteigen aus einem Fahrzeug. Findet dabei eine Registrierung statt, wird hintereinander eine identische Fahrzeug-ID gelesen. Um eine bessere Aussage treffen zu können, wird neben der NDEF-Nachricht auch die Anzahl der Registrierungen übertragen. 7.4 Service-Komponente Wie in der Konzeption und Analyse aufgezeigt wurde, ist unser Reisebegleiter in der Lage, Rückmeldung zu erzeugen. Er reagiert nicht allein auf Eingaben, sondern agiert selbständig. Dies geschieht über Engine-Komponenten, die auf Kontexten arbeiten. Neben der Zeit werden Positionsveränderungen und NFC-Ereignisse als Kontexte erkannt. Die Zeit lässt sich relativ einfach in einem technischen System ermitteln. Orts- und NFC-Daten stellen dagegen eine komplexere Aufgabe dar. Diese Daten werden von Android-Prozeduren bereit gestellt. Damit 86

92 7 Prototypische Umsetzung die Informationen zentral abrufbar sind, werden diese in einem Service implementiert. Wie im Abschnitt 6.2 besprochen, ist ein Service unabhängig, besitzt einen eigenen Lebenszyklus und eignet sich für Hintergrundoperationen. Jede Komponente, die entsprechende Informationen verlangt, verbindet sich mit dem Service und registriert entsprechende Abfrageobjekte (Listener). Die Handhabung von Services wird in der Online-Dokumentation beschrieben [ASe12]. Folgende Funktionalitäten stellt der implementierte Service bereit: GPS-Position des Nutzers ermitteln. Letzte bekannte GPS-Position ausgeben. Benachrichtigungen (Notifications) in der Statusleiste erzeugen. Starten von beliebigen Ansichten (Activities). Abspielen von Warntönen. Gerät vibrieren lassen. 7.5 Verbindungsimport über Öffi Grundlage der Reisebegleitung sind Verbindungsdaten, die als gegeben angenommen werden. Für die Entwicklung der aufgeführten Funktionalitäten wurde eine Datensatz entwickelt und in ein XML-Struktur überführt (Anhang 1). Das Konzept sieht ergänzend den Import von Verbindungsdaten vor. Exemplarisch soll dies am Beispiel der Verbindungsauskunft Öffi gezeigt werden. Öffi ist eine mobile Applikation für Androidgeräte, welche Verbindungen für eine große Vielzahl von Verkehrsverbünden zulässt [Öff12]. 87

93 7.6 Wetter-Plugin Abbildung 7.4: Zeigt den Importvorgang aus Öffi heraus. Ein Nachteil dieser Importvorgänge besteht darin, dass überlieferte Datensätze unvollständig sind. Damit sind nicht alle Funktionen des Prototypens nutzbar. Alle notwendigen Daten sind in der erwähnten XML-Datei geführt. 7.6 Wetter-Plugin Für das beschriebene Plugin-Konzept (Abschnitt 5.5) wird exemplarisch eine Erweiterung zur Darstellung von Wetterdaten erstellt. Das Plugin arbeitet auf den Daten eines Ereignisses, der Orts- und Zeitinformation. Diese werden an einen Webservice gesendet und die erhaltenen Ergebnisse, wie dargestellt, präsentiert. Als Datenschnittstelle dient der Weather RSS Feed von Yahoo [YWe12]. Bei einer Anfrage ist eine WOEID-Kennzeichnung notwendig (Parameter w) Listing 7.4: Request zur Abfrage von Wetterdaten. 88

94 7 Prototypische Umsetzung Diese bildet einen Ort auf der Welt ab, ist jedoch nicht eindeutig. Die Ermittlung der Kennzeichnung kann über folgenden Request geschehen. Dafür müssen die Parameter für Land und Ort gesetzt werden ces%20where%20text%3d%22dresden%20deutschland%22 Listing 7.5: Request zur Abfrage einer WOEID Die Antworten werden als XML-Struktur ausgeliefert und in der Applikation für die Darstellung aufgearbeitet. Abbildung 7.5: Ansicht der Erweiterung zur Wettervorhersage. Über eine Schaltfläche im oberen Teil kann zwischen registrierten Reisen gewechselt werden. 7.7 Hinweise Es stellt sich heraus, dass bei der Trennung der Komponente in einen unabhängigen Java- Kern und darauf aufbauende Android-Komponenten, wie im Architektur-Abschnitt besprochen, Besonderheiten zu berücksichtigen sind. Zum einen können Aktionen der Benutzeroberfläche, zum Beispiel das Anzeigen eines Dialoges, immer nur im Kontext einer Anwendung erfolgen. Für das Erstellen von Rückmeldungen an den Nutzer sind EventHandler 89