projekt-nummer: i1169 communication smart helmet - …web.fhnw.ch/personenseiten/taoufik.nouri/smart...

Projekt-Nummer: I1169

Communication Smart Helmet -

Mobile Phone

Thesis für den Bachelor in Computer Science

Eingereicht an der Fachhochschule Nordwestschweiz

Diplomanden

RAJIB MITRA und DANIEL MEYER

Prof. Dr. Taoufik Nouri, Studienleiter Beat Schär, Referent

2009

3

Kontaktinfos

Autoren Rajib Mitra Röttelerstrasse 23

4058 Basel +41 61 681 85 13 [email protected]

Daniel Meyer

Bodenackerstrasse 45

5200 Brugg + 41 78 611 54 00 [email protected]

Auftraggeber & Tutor FHNW Institut für Mobile und Verteilte Systeme

Taoufik Nouri Prof. Dr. Dipl. Ing. Elec./Phys. + 41 79 218 38 55

Experte Beat Schär

Dipl. Ing. ETH,

Pilgerweg 10 3007 Bern + 41 31 339 32 27 [email protected]

Projekthomepage http://web.fhnw.ch/technik/projekte/i/fruehling09/MeyerMitra

Copyright by FHNW Windisch, August 2009

5

Danksagung

An dieser Stelle möchten wir uns bei Prof. Dr. Nouri speziell für seine Unterstützung während des

Projektes danken. Wir haben seine Unterstützung jederzeit sehr geschätzt und es hat uns Freude bereitet, Ihn als Coach an unserer Seite haben zu dürfen. Einen weiteren Dank geht an unseren Experte

Herr Schär. Er hat uns in Bern freundlich willkommen geheissen und grosses Interesse an unserem Projekt gezeigt.

7

Zusammenfassung

Der Smart-Helm basiert auf einem mit optischen Glasfasern und Laser versehenem System. Er

ermittelt bei einem Aufprall in der Kopfregion die Stelle und Intensität des Stosses. Über ein mit USB oder Bluetooth verbundenes Mobiltelefon, wird in einer personalisierbaren Applikation - anhand eines medizinischen Referenzmodells - die genaue Aufprallregion sowie die Aufprallintensität berechnet. Im Notfall wird eine Nachricht an eine Notrufzentrale versandt. Diese soll u.a. die GPS-Koordinaten des

Unfallortes enthalten. Die Bachelorarbeit umfasst die Erweiterung des im P5 entwickelten Smart-Helm

Simulators und die Entwicklung einer Mobiltelefon-Applikation. Zusätzlich sollen noch PC-Client-Applikationen entwickelt werden, die sich über Bluetooth/WLAN beim Smart-Helm registrieren

lassen, um ebenfalls die Daten eines Aufpralls zu erhalten. Diese Arbeit entsteht im Rahmen einer Machbarkeitsstudie. Die Technologie im Smart-Helm kann auch in anderen Kleidungsstücken

eingesetzt werden.

9

Inhalt

Zusammenfassung ........................................................................................................................7

Inhalt .............................................................................................................................................9

1 Einleitung ............................................................................................................................ 13

1.1 Motivation...................................................................................................................................... 13

1.2 Aufbau............................................................................................................................................ 13

2 Projektauftrag ...................................................................................................................... 15

2.1 Auftrag ........................................................................................................................................... 15

2.2 Ausgangslage.................................................................................................................................. 15

2.3 Anforderungen .............................................................................................................................. 15

3 Ziele ..................................................................................................................................... 17

4 Planung................................................................................................................................ 19

4.1 Wichtige Ereignisse....................................................................................................................... 19

4.2 Verbesserungsvorschläge.............................................................................................................. 20

5 Vorgehensweise ................................................................................................................... 21

5.1 Methodik........................................................................................................................................ 21

5.1.1 Konzeptionsphase (Inception) ................................................................................................ 21

5.1.2 Analyse- und Designphase (Elaboration) ............................................................................... 21

5.1.3 Implementierung (Construction)............................................................................................. 22

5.1.4 Inbetriebnahme (Transition).................................................................................................... 22

5.2 Smart-Helm Applikation .............................................................................................................. 23

5.3 Mobiltelefon-Applikation ............................................................................................................. 25

5.3.1 Analyse....................................................................................................................................... 25

5.3.2 Entwicklungsplattform............................................................................................................. 26

5.3.3 Prototyping................................................................................................................................ 26

6 Technologie .........................................................................................................................27

6.1.1 Sprachen .................................................................................................................................... 27

6.1.2 Entwicklungstools..................................................................................................................... 27

Inhalt

10

6.1.3 Libraries ..................................................................................................................................... 27

7 Resultat ................................................................................................................................29

7.1 Erreichte Ziele............................................................................................................................... 29

7.1.1 Anforderungen an die Mobiltelefon Applikation................................................................... 29

7.1.2 Anforderungen an den Smart-Helm Simulator ...................................................................... 29

7.1.3 Anforderungen an der Data Receiver Applikation ................................................................ 30

7.1.4 Anforderungen an der Notrufzentrale .................................................................................... 30



7.3.1 Willkommens-Bildschirm......................................................................................................... 31

7.3.2 Hauptmenü................................................................................................................................ 31

7.3.3 Gerätesuche............................................................................................................................... 31

7.3.4 Servicesuche .............................................................................................................................. 32

7.3.5 Verbindungsbildschirm ............................................................................................................ 32

7.3.6 Benutzereinstellungen............................................................................................................... 33

7.3.7 Programmeinstellungen............................................................................................................ 33

7.3.8 Notrufnummer.......................................................................................................................... 33

7.3.9 Alarmlevel.................................................................................................................................. 34

8 Implementierung.................................................................................................................35


8.1.1 Netzwerk Adapter..................................................................................................................... 35

8.1.2 Medical-Controller.................................................................................................................... 39

8.1.3 Funktionsabläufe....................................................................................................................... 42

8.1.4 Medizinisches Referenzmodel ................................................................................................. 43

8.1.5 Konfiguration............................................................................................................................ 45


8.2.1 Java ME ..................................................................................................................................... 46

8.2.2 Java Requirements Specifications (JSR) .................................................................................. 47

8.2.3 Datenverwaltung....................................................................................................................... 49

8.2.4 GUI Design............................................................................................................................... 51

8.2.5 Standortbestimmung ................................................................................................................ 52

8.2.6 Nachrichtenversand.................................................................................................................. 53

8.2.7 Kommunikation mit der Smart-Helm Applikation................................................................ 53

8.2.8 Deployment............................................................................................................................... 54

Inhalt

11

9 Testen ..................................................................................................................................55




9.2.1 Unit Testing............................................................................................................................... 56

10 Aufgabenverteilung .............................................................................................................57

11 Reflexion..............................................................................................................................59

12 Ehrlichkeitserklärung .......................................................................................................... 61

13 Literatur ...............................................................................................................................63

14 Abbildungsverzeichnis ........................................................................................................65

15 Anhang.................................................................................................................................67

Anhang A – Pflichtenheft zur Bachelor Thesis ....................................................................................... 67

Anhang B – UML Diagramme.................................................................................................................. 67

Anhang C – Source Code Dokumentation .............................................................................................. 67

Anhang D – DVD...................................................................................................................................... 67

13

1 Einleitung

Dieses Dokument gehört zur Bachelor-Thesis von Daniel Meyer und Rajib Mitra an der

Fachhochschule Nordwestschweiz, Studiengang Informatik. Der Inhalt dieses Dokumentes umfasst die Aufgabenstellung, eine Beschreibung des Vorgehens, Erläuterungen zur Entwicklungs-Methodik sowie die erreichten Ziele. Dazu findet sich im Anhang der Ausdruck der Java-Doc. Weitere Kapitel dienen ergänzend zur Vollständigkeit. Auf der letzten Seite

befindet sich eine DVD, welche unter anderem die während der Thesis entwickelten Applikationen

enthält. Für eine genauere Angabe des auf der DVD enthaltenen Inhaltes siehe Anhang D.

1.1 Motivation

Im Rahmen von diversen Modulen hatten wir schon vorher die Gelegenheit kleinere Java-

Applikationen zu entwickeln. Der Smart-Helm gab uns die Gelegenheit, das in der Theorie gelernte, auch praktisch in einer grossen Arbeit erfolgreich einzusetzen und erforderte dafür ein hohes abstraktes

Denkvermögen. Unser besonderes Interesse galt der grafischen Darstellung von Modellen im dreidimensionalen Raum. Daher sprach uns die Aufgabe, eine solche Simulation zu entwickeln, sehr an.

Dieses Projekt gab uns den grösstmöglichen Handlungsfreiraum, verlangte aber im Gegenzug ein hohes Mass an Eigenverantwortung und eine analytische Vorgehensweise.

Schlussendlich hatten wir alleine schon dadurch grosses Interesse an einer funktionierenden Simulation,

da diese Arbeit im Rahmen einer Machbarkeitsstudie entstand, und zu einem realen Prototyp des Smart-Helm führen kann.

1.2 Aufbau

• Abstrakt

• Ausgangslage

Erläuterung über die im Projekt 5 entwickelte Applikation.

• Applikationsentwicklung

Dieses Kapitel erklärt die Methodik welche zur Softwareentwicklung angewandt wurde und

• Technologie Enthält eine Auflistung der verwendeten Technologien die verwendet wurden.

• Resultat

Dieses Kapitel gibt eine Übersicht über die definierten Ziele und deren Erfüllungsgrad.

Weiterführend geben die Konzepte und Umsetzungen Beschreibungen wie die Ziele erreicht wurden.

15

2 Projektauftrag

2.1 Auftrag

Für eine Machbarkeitsstudie soll eine Applikation erstellt werden, die den Smart-Helm visuell darstellt und sich interaktiv bedienen lässt. Nach einem simulierten Stoss soll die Position und Intensität des

Aufpralls ermittelt werden und an eine auf einem Mobiltelefon laufenden, mobilen Applikation per

Bluetooth oder USB übermittelt werden. Die mobile Applikation entscheidet anhand eines medizinischen Referenzmodells ob eine Nachricht an eine Notrufzentrale gesendet werden soll.

2.2 Ausgangslage

Im vorangegangenen Projekt 5 wurde bereits ein Teil der Smart-Helm Applikation realisiert. Aufbauend

auf dieser Arbeit soll die Applikation nun entsprechend erweitert und eine Mobiltelefon-Applikation entwickelt werden.

2.3 Anforderungen

Für eine detaillierte Auflistung aller Aufgaben und Anforderungen verweisen wir auf Seite 11ff des

Pflichtenhefts im Anhang.

17

3 Ziele

Das Hauptziel ist die Entwicklung einer personalisierbaren Handy Applikation und deren Anbindung

an die im P5 entwickelte Smart‐Helm Applikation. Die zu erweiternde Smart‐Helm Applikation

übermittelt die Stelle und Intensität eines simulierten Aufschlages an die Handy-Applikation. Dort wird anhand der Morphologie eines medizinischen Referenzmodelles entschieden, ob eine SMS mit der

Verletzungsgefahr und den aktuellen GPS‐Daten an eine Notrufzentrale abgesetzt werden soll.

Zusätzlich können sich PC-Client‐Applikationen über WLAN/Bluetooth beim Smart‐Helm

registrieren und erhalten im Falle eines Aufschlages die entsprechenden Daten zur weiteren Verarbeitung zugeschickt.

Dem Auftraggeber soll die Simulation, bestehend aus der Smart-Helm Applikation, der Mobiltelefon-

Applikation und der Client-Applikationen, Schlüsse über die Machbarkeit des Smart-Helms geben. In einer nächsten Phase könnte dann ein realer Prototyp gebaut und getestet werden.

19

4 Planung

Zu Projektbeginn wurde eine Grobplanung erstellt mit den verschiedenen Projektphasen sowie den

wichtigen Meilensteinen.

Nr. Vorgangsname Anfang Ende

1 Planung Mo 16.02.09 Fr 27.03.09

2 Pflichtenheft Fr 27.03.09 Fr 27.03.09

3 Entwurf Mo 30.03.09 Fr 01.05.09

4 Schnittstellen Mo 04.05.09 Mo 04.05.09

5 Implementierung Mo 04.05.09 Fr 31.07.09

6 Testen Mo 04.05.09 Fr 31.07.09

7 Applikation / Tests Mo 03.08.09 Mo 03.08.09

8 Dokumentation Mo 16.02.09 Fr 14.08.09

9 Projektabschluss Mo 17.08.09 Mo 17.08.09

26.01. 23.02. 23.03. 20.04. 18.05. 15.06. 13.07. 10.08.

Abb. 1: Projektplanung

4.1 Wichtige Ereignisse

Nachfolgend eine tabellarische Auflistung der wichtigsten Ereignisse während der Bachlor-Arbeit und

deren Datum.

Datum Ereignis Smart-Helm

Applikation

Mobiletelefon-

Applikation

23.02.2009 Kickoff-Meeting

09.03.2009 Meeting mit Prof. Dr. Nouri

21.03.2009 Erste Version des Pflichtenhefts fertig

06.04.2009 Schnittstellen für Versand der Aufpralldaten x

18.04.2009 Erster Prototyp x

20.04.2009 Erste Version LAN Client x


28.04.2009 Finale Version des Pflichtenhefts

06.05.2009 GPS-Funktionalität hinzugefügt x

08.05.2009 RecordStore-Funktionalität hinzugefügt x

10.05.2009 Bluetooth Server x

15.05.2009 Bluetooth Client x

20.05.2007 Bluetooth Discovery hinzugefügt x

22.05.2009 Bluetooth Verbindung mit Server steht x

4 Planung

20

27.05.2009 Medizinisches Referenzmodell x

01.06.2009 XML Parser Funktionalität in Java ME x

07.06.2009 Portierung von Formelevaluator/ Hashmap/ Iterator

x

13.06.2009 Funktionierende Auswertung der Aufschlag-region implementiert

x

29.06.2009 Funktionierender SMS Versand x

13.07.2009 Unit-Tests x x

20.07.2009 Smart-Helm Display erweitert um Textanzeige-funktionalität und die Farbe ändernde LEDs.

x



01.08.2009 JavaDoc nachgeführt x x

03.08.2009 Plakat erstellt

05.08.2009 Webseite erstellt

07.08.2009 Meeting mit Herrn Schär in Bern

10.08.2008 Flyer erstellt

09.08.2009 Source Cleanup x x


13.08.2009 Dokumentation abgeschlossen


14.08.2009 Projekt-Präsentation

09.09.2009 Bachelor-Thesis Verteidigung

Die Dokumentation wurde während der ganzen Thesisdauer fortlaufend nachgeführt. Die Planung wurde grösstenteils eingehalten. Der Testaufwand wurde mit einem viel zu grossem

Zeitbudget eingeplant. Die dafür nicht aufgewendete Zeit floss dafür in die Implementation ein.

4.2 Verbesserungsvorschläge

Verbesserungswürdig ist die Schätzung des Zeitaufwands für die Entwicklung und Tests der

Applikationen. Für eine genauere Bestimmung des Testbudgets könnte man evtl. in der Analysephase konkrete, zu erfüllende Tests definieren und dadurch den Zeitaufwand besser abschätzen.

Der Zeitaufwand für die Entwicklung wurde unterschätzt. Die Einarbeitungsphase in die

Kommunikation über Bluetooth und die Applikationsentwicklung auf Java ME nahm mehr Zeit in Anspruch als angenommen. Die Planung sollte um eine von der Thesis-Dokumentation abgegrenzte Phase für die Erstellung des

Materials der Thesis-Ausstellung (Homepage, Plakat, Flyer) erweitert werden.

21

5 Vorgehensweise

Dieses Kapitel beschreibt das Vorgehen bei der Entwicklung der Erweiterung der Smart-Helm

Applikation sowie der Mobiltelefon-Applikation.

5.1 Methodik

Die Software wird nach der Vorgehensweise des strukturierten Prozess von Rational Unified Process

(RUP) entwickelt. RUP beschreibt eine inkrementelle Entwicklung, die in vier Phasen zerlegt ist (Zeitachse). Jede dieser Phase ist in eine oder mehrere Iterationen zerlegt und weist unterschiedliche

Ausprägungen der Aktivitäten auf.

Abb. 2: Grafische Darstellung von Rational Unified Process (RUP)

5.1.1 Konzeptionsphase (Inception)

In dieser Phase wurde das Pflichtenheft entwickelt. Für eine Definition der Anforderungen, Systemabgrenzung, Planung und Vorgehen verweisen wir auf das Pflichtenheft im Anhang. Zur

Qualitätssicherung wurden Unit-Tests definiert, dazu mehr später in Kapitel 9 Testen.

5.1.2 Analyse- und Designphase (Elaboration)

Während dieser Phase werden die Probleme analysiert und die Architektur erstellt.

5 Vorgehensweise

22

5.1.3 Implementierung (Construction)

In dieser Phase liegt das Hauptaugenmerkmal auf der Entwicklung von Komponenten und deren

Eingliederung in die bestehende Software. Dieser Teil wird ausführlich in Kapitel 8 Implementierung beschrieben.

5.1.4 Inbetriebnahme (Transition)

In diese Phase gehört die Paketierung und Verteilung der Software. Mehr dazu im Kapitel 8.2.8

Deployment

5 Vorgehensweise

23

5.2 Smart-Helm Applikation

5.2.1.1 Architektur

Der bestehende Simulator ist nach dem Model-View-Controller (MVC) Pattern implementiert worden.

Bei MVC unterscheidet man die drei in der Bezeichnung benannten Komponenten. Das Model repräsentiert die Business-Logik und Daten, die View ist das Benutzerinterface und der Controller dient

zur Verarbeitung der Benutzeraktion.

Abb. 3: Das Model View Controller Pattern

Um die Wiederverwendbarkeit der Komponenten und eine dynamische Konfiguration zu garantieren verwenden wir Spring. Das Kernkonzept von Spring benutzt Dependency Injection. Die

Abhängigkeiten zwischen Komponenten werden dabei über die Konfigurationsdatei festgelegt. Alle Komponenten sind normale Java Beans deren Abhängigkeiten explizit gemacht werden müssen.

Die Erweiterung wird in die bestehende Architektur integriert.

Pakete

Die Komponenten werden in den folgenden Paketen organisiert.

Abb. 4: Paket-Erweiterung der bestehenden Applikation

5.2.1.2 GUI Design

Die Applikation ist wie in Abb. 5: Anordnung der GUI-Elemente aufgebaut.

1) Menu-Liste

2) 3D-Panel

Das Panel stellt den Smart-Helm in drei Dimensionen dar. Innerhalb davon werden Aufschläge simuliert und dargestellt.

3) Tool-Panel

Die Applikation verfügt über eine Reihe von Tools. Das Hinzufügen, Entfernen oder Ersetzen

5 Vorgehensweise

24

von Tools kann durch die Konfigurations-Datei springContext.xml definiert werden. Jedes Tool lässt sich Expandieren und wieder Minimieren durch einen Klick auf dessen Namen.

4) Smart-Helm Display

Der Smart-Helm verfügt zwar über ein eigenes Display ist aber für die Anzeige der nötigen Informationen etwas zu klein. Dieses Display soll die Informationen in lesbarer Schrift darstellen.

Abb. 5: Anordnung der GUI-Elemente

5 Vorgehensweise

25

5.3 Mobiltelefon-Applikation

5.3.1 Analyse

In dieser Phase befassten wir uns unter anderem mit der Architektur der mobilen Anwendung. In einem ersten Schritt wurden die in Frage kommenden Plattformen aufgelistet.

5.3.1.1 Plattformen zur Auswahl

Zur Auswahl standen folgende Plattformen: Java ME Entwickler Sun Microsystems Webseite http://java.sun.com/javame/ Programmiersprache Java Kurzbeschrieb Für mobile Geräte angepasstes Java Android Entwickler Google / Open Handset Alliance Webseite http://www.android.com/ Programmiersprache Java Kurzbeschrieb Open Source OS von Google

iPhone OS Entwickler Apple Inc. Webseite http://developer.apple.com/iphone/ Programmiersprache Objective-C Kurzbeschrieb Auf iPhone portierte Version von Mac OS X Windows Mobile Entwickler Microsoft Webseite http://microsoft.com/windowsmobile/ Programmiersprache Visual C++, .NET Compact Framework Kurzbeschrieb Auf Win32-API basierendes Mini-Windows Symbian OS Entwickler Symbian Foundation Webseite http://www.symbian.com/ Programmiersprache C++ Kurzbeschrieb Handheld OS von Symbian. Mittlerweile Open

Source Alle genannten Plattformen bieten gut dokumentierte APIs, aktive Communities und viele hilfreiche Beispielapplikationen.

5 Vorgehensweise

26

5.3.2 Entwicklungsplattform

Der nächste Schritt bestand in der Auswahl der Entwicklungsplattform. In Absprache mit Prof. Dr. Nouri entschieden wir uns für die Entwicklung einer auf Java ME basierten Applikation. Die Gründe dafür waren hauptsächlich beschaffungstechnischer Natur, da uns kein auf den anderen Plattformen basiertes Gerät zur Verfügung stand. Da dieses Projekt den Rahmen eine Machbarkeitsstudie darstellt, waren eine optisch schöne Benutzeroberfläche und grosse Verbreitung eher nebensächlich.

5.3.3 Prototyping

Die Bildschirm-Menüs wurden anhand von Papierskizzen vorgezeichnet. Auf diese Weise konnte man

auch den Programmablauf grafisch darstellen.

Abb. 6: Paperbased Prototyp der Mobiltelefon-Applikation

27

6 Technologie

6.1.1 Sprachen

Hier ist eine kurze Zusammenfassung über die Technologien und Programmiersprachen die für dieses Projekt verwendet werden.

Name Beschreibung URL Version

Plattformunabhängige Programmiersprache

www.sun.com 1.6

Für die Darstellung von drei Dimensionalen Objekte.

www.opengl.org

Zur Entkoppelung von Komponenten

www.spring.com

XML

6.1.2 Entwicklungstools


Entwicklungstool für Simulator www.eclipse.org 3.4.1

Entwicklungstool für Mobiltelefon Applikation

www.netbeans.org IDE 6.5

6.1.3 Libraries

Zweck Bezeichnung Beschreibung Bluetooth Bluecove-2.1.0.jar

comm.jar Java Bluetooth Referenzimplementierung

OpenGL gluegen-rt.jar gogl.jar jogl_awt.dll jogl_cg.dll jogl.dll

Datenmodell vecmath.jar Zur Verwendung von 3D-Objekten für den Datenaustausch.

Referenzmodell meval.jar Mit dieser Bibliothek lässt sich eine mathematische Formel als String (z.B. „-cos(0)*(1+2)“)

6 Technologie

28

angeben, eine Variable setzen und die Formel danach auflösen [LSC].

Spring Integration spring.jar log4j-1.2.14.jar commons-logging-1.0.4.jar

29

7 Resultat

7.1 Erreichte Ziele

Die folgenden Tabellen geben eine Übersicht über die im Pflichtenheft spezifizierten Anforderungen mit deren Prioritäten und Erfüllungsgrad.

7.1.1 Anforderungen an die Mobiltelefon Applikation

Anforderung Priorität Status

Verbindung zum Smart-Helm über USB und Bluetooth. hoch Nur Bluetooth

Positions- und Intensitätserkennung des Aufschlages am Helm. hoch komplett erfüllt

Entwicklung einer personalisierten Mobiltelefon Applikation um die Helm-Daten auszuwerten.

hoch komplett erfüllt

Positions- und Intensitätsdaten eines Aufschlages verbinden mit der Morphologie eines menschlichen Kopfes anhand eines medizinischen Referenzmodelles.


Basierend auf der Morphologie des medizinischen Referenzmodelles Entscheidungen über den Verletzungsgrad des Aufpralles treffen.


Übermittlung des Verletzungsgrades an den Smart-Helm. hoch komplett erfüllt

Im Notfall, senden der ausgewerteten Helm-Daten und GPS-Information an eine Notrufzentrale.


Sicherheitsfunktionalitäten stellen sicher, dass die Verbindung zwischen Mobiltelefon und Helm jederzeit aktiv und verfügbar ist.


7.1.2 Anforderungen an den Smart-Helm Simulator


Verbindung zum Mobiltelefon über USB und Bluetooth. hoch Nur Bluetooth

Übermittlung der Positions- und Intensitätsdaten eines Aufschlages an die Mobiltelefon Applikation.


Übermittlung der Positions- und Intensitätsdaten eines Aufschlages durch Bluetooth oder WLAN an diverse Empfänger, ausgestattet mit Smart-Helm Data Receiver Applikation.


Warnanzeige mit Ton auf dem Helm nach einem Aufprall. Falls dieser Hinweis nach 30s (oder nach einem anderen konfigurierbaren Intervall) nicht gestoppt wurde, wird über das Mobiltelefon eine Alarm-SMS gesendet.


7 Resultat

30

Anzeigen des Verletzungsgrades und Position auf der Helm-Anzeige.


7.1.3 Anforderungen an der Data Receiver Applikation


Registrieren beim Smart-Helm Simulator als Empfänger. hoch komplett erfüllt

Empfang der Positions- und Intensitätsdaten. hoch komplett erfüllt

7.1.4 Anforderungen an der Notrufzentrale


Empfang der Auswertung, GPS-Position und User Identifikation.



Während einer ersten Iteration wurde das Medical-Tool in die Applikation integriert. Dies soll das

Verbinden von Positions- und Intensitätsdaten eines Aufschlages mit der Morphologie eines menschlichen Kopfes ermöglichen.

Parallel dazu wurde ein erster Prototyp der Mobiltelefon-Applikation erstellt, für die ebenfalls dieselbe Funktionalität während der zweiten Iteration implementiert wurde. Die meisten Komponenten und Konzepte aus dem Kapitel 1 wurden während der ersten Iteration implementiert und getestet.

Abb. 7: Erweiterung durch das Medical-Tool und Helm-Display

Nach dem Abschluss der zweiten Iteration wurde das Medical-Tool um zusätzliche Funktionalitäten erweitert. Ein Refactoring der ganzen Applikation war nötig um eine verbesserte Robustheit und

Wiederverwendbarkeit zu erzielen.

7 Resultat

31


Wir möchten hier auf die erbrachten Resultate in Bezug auf die Mobiltelefon-Applikation eingehen. Die Screenshots stammen aus dem im Sun Wireless Toolkit 2.5.2 enthaltenen Java ME Simulator.

7.3.1 Willkommens-Bildschirm

Beim Aufstarten der Smart-Helm Mobiltelefon-Applikation wird man von einem Willkommens-Bildschirm begrüsst,

der nach 2s automatisch wieder verschwindet.

7.3.2 Hauptmenü

Nach dem Willkommens-Bildschirm erscheint das

Hauptmenü. Von hier aus kann man die Verbindung starten oder zu den Benutzer- und Programm-einstellungen

wechseln.

7.3.3 Gerätesuche

Nach Auswahl von „Start Application“ wird die Umgebung nach sichtbaren Bluetooth-Geräten abgesucht. Gefundene Geräte erscheinen als Eintrag auf dem Bildschirm. Diese Suche kann

mehrere Sekunden dauern. Ist die Suche noch nicht abgeschlossen,

erscheint zuoberst im Bildschirm ein Ticker mit der Meldung das noch nach Bluetooth-Geräten gesucht wird. Nach abgeschlossenem

Suchvorgang verschwindet diese Anzeige. Mit einem Druck auf „Refresh“ lässt sich die Gerätesuche nochmals neu starten.

Abb. 8: Willkommens-Bildschirm

Abb. 9: Hauptmenu

Abb. 10: Untermenu

Abb. 11: Gerätesuche

7 Resultat

32

Nach Auswahl des gewünschten Gerätes, gelangt man zum nächsten Bildschirm oder per Druck auf „Back“ wieder zurück zum Hauptmenü.

7.3.4 Servicesuche

Bei der Servicesuche wird auf dem im Gerätesuche-

Bildschirm ausgewähltem Gerät nach Bluetooth-Services gesucht.

Mit einem Druck auf Back gelangt man zurück zur

Gerätesuche.

Der Smart-Helm Bluetooth-Servicename ist “Smart-Helm”.

Damit dieser gefunden wird, muss die Smart-Helm Applikation am Laufen sein.

Mit einem Druck auf „Connect“ startet die Verbindung zum Smart-Helm Service.

7.3.5 Verbindungsbildschirm

Nach erfolgreicher Verbindung zum Smart-Helm-Bluetooth Service, erscheinen Ereignismeldungen auf dem

Bildschirm, die über den aktuellen Status informieren.

Hier erscheinen auch alle von der Smart-Helm erhaltenen Nachrichten und die Auswertungen dazu.

Mit der

Auswahl von „Back“ gelangt man zurück zum

Hauptmenü.

Abb. 12: Servicesuche

Abb. 14: Statusmeldungen

Abb. 13: Verbindungsbilschirm

7 Resultat

33

7.3.6 Benutzereinstellungen

In den Benutzereinstellungen lässt sich die UID eingeben, mit der sich die Mobiltelefon-Applikation personalisieren

lässt. Zusätzlich haben wir noch ein Feld für das Alter des Benutzers eingefügt. Diese steht stellvertretend für weitere

Benutzerinputs, die man noch hinzufügen könnte.

Mit der Auswahl von „Save“ lassen sich die Änderungen speichern, mit „Back“ werden sie verworfen und zum

Hauptmenü gewechselt.

7.3.7 Programmeinstellungen

Die Programmeinstellungen wurden in weitere Selektionen

unterteilt. Dies wurde mit Hinblick auf die spätere Erweiterbarkeit gemacht, da sich so einfach weitere nach

Kategorie zusammengestellte Programmeinstellungen einfügen lassen. Wenn es nur einen Bildschirm für alle

Programmoptionen gäbe, wäre dieser schnell überfüllt und unübersichtlich. Mit „Select“ lässt sich ein Eintrag anwählen.

7.3.8 Notrufnummer

Unter diesem Menü haben wir die Programmeinstellungen zum Versand der

Notrufnachricht zusammengefasst. Unter „Emergency Number“ steht die Nummer, an welche die

Notrufnachricht verschickt wird. Bei „Send SMS“ kann man auswählen ob eine Notrufnachricht versandt

werden soll oder nicht (zu Testzwecken) und die unter „GPS Timeout“ kann man die Wartezeit in Sekunden, bis der bei der GPS-Standortbestimmung auf eine

Antwort gewartet wird ehe es ein Timeout gibt, eingeben.

Mit „Save“ werden die Änderungen gespeichert, mit „Back“ kehrt man zum Hauptmenü zurück und die

Abb. 15: Benutzereinstellungen

Abb. 16: Programmeinstellungen

Abb. 17: Notrufnummer

7 Resultat

34

neuen Eingaben werden verworfen.

7.3.9 Alarmlevel

In diesem Bildschirm lässt sich der Gefahrenlevel angeben, ab welchem der Smart-Helm den Countdown zum Notrufnachrichten-Versand starten

soll. Es lassen sich Werte von 0 bis 10 einstellen, wobei 0 bedeutet, dass ein Alarm bei jedem noch so

kleinen Aufprall initiiert wird. Die 10 entspricht einer Aufprallgefahr, die absolut fatalen Unfall ist. Die

Gefahrenwerte werden von der Applikation mit Hilfe eines medizinischen Referenzmodelles berechnet. Mehr dazu im Kapitel 8.1.4 Medizinisches

Referenzmodel.

Abb. 18: Alarmlevel

35

8 Implementierung


8.1.1 Netzwerk Adapter

Damit die Intensität und dessen örtliches Zentrum vom Helm aus auf andere Geräte wie Mobiltelefon

übertragen werden kann, benötigt man entsprechende Netzwerk Adapter. Der Helm übernimmt die Server-Rolle und die Geräte, die sich an diesen Daten interessieren, werden Clients genannt.

Abb. 19: Paket Erweiterung für die Netzwerk-Kommunikation

Für die Implementierung der unterschiedlichen Server gibt es ein Interface ComAdapter, wovon abgeleitet werden muss damit eine Server-Komponente später vom Medical-Controller verwendet

werden kann.

8 Implementierung

36

Abb. 20: Interface für Netzwerk-Server Komponenten

Der Client interagiert lediglich mit dem LAN- oder Bluetooth-Server und ist als aussenstehende Komponente, im Hinblick auf den Simulator, zu betrachten. Daher muss er keine Software-Schnittstellen implementieren aber das Kommunikations-Protokoll. Man unterscheidet nun zwischen

Bluetooth- und LAN-Client von denen der erstere auch Informationen an den Server senden kann.

In den folgenden beiden Kapiteln wird der Verbindungsaufbau zwischen Client und Server genauer erläutert.

8.1.1.1 Bluetooth Client-Server

Handshake

1. Der Client sendet dem Server ein HELLO.

2. Der Server antwortet mit einem ACK. Datenaustausch

1. Sobald vom Medical-Controller Daten an die Server zum Versenden weitergereicht werden, sendet unter anderem der Bluetooth Server diese

an den Client. Die Sequenznummer davon dient nur der Zählung dieser

Daten. 2. Der Client antwortet daraufhin mit einem ACK und beginnt mit der Auswertung. 3. Das Resultat der Auswertung wird an den Server gesendet.

4. Falls es sich um einen kritischen Verletzungsgrad handelt, wartet der

Client bis vom Server ein ALERT oder QUIT kommt. ALIVE Channel

Um festzustellen, ob die Verbindung zwischen Client und Server noch besteht, wird im vordefinierten Intervall ein ALIVE zwischen den beiden

Partnern hin- und zurückgesendet.

ServerClient

HELLO

ACK

[#] DATA

ALIVE

ACK

CALC

ALERT / QUIT

ALIVE

8 Implementierung

37

8.1.1.2 Bluetooth Sicherheit

Die Bluetooth-Technologie stellt verschiedene Sicherheitsebenen für eine Bluetooth-Verbindung zur

Verfügung. Es gibt vier Bluetooth Sicherheitstypen: pairing (Paarung), authentication (Authentifizierung), encryption (Verschlüsselung) und authorization (Autorisation).

Pairing ist der erste Schritt der Bluetooth-Sicherheit. Werden zwei Geräte zum ersten Mal miteinander verbunden und wollen die Bluetooth-Sicherheit verwenden, müssen sie einen gemeinsamen

Geheimcode, eine sogenannte PIN (Persönliche Identifikationsnummer) vereinbaren. Danach wird dieser auf beiden Seiten eingegeben und abgespeichert um in Zukunft eine Authentifizierung ohne erneutes Pairing zu ermöglichen.

Abb. 21: Bluetooth Pairing

Bluetooth Authentifizierung stellt die Identität eines Gerätes mit einem anderen Gerät über ein

Challenge-Response-Verfahren fest. Will Gerät A Gerät B authentifizieren, sendet es eine Challenge an

Gerät B. Dieses wiederum sendet nach dem Empfang eine mit seinem entsprechenden PIN modifizierte Response zurück an Gerät A. Gerät A kombiniert die Challenge dies es geschickt hat,

ebenfalls dem lokalen PIN und vergleicht das Resultat mit der von Gerät B stammenden Response. Dieses Verfahren muss von beiden Seiten ausgeführt werden um beidseitig authentifiziert zu werden.

Abb. 22: Bluetooth Authentifizierung

Nachdem der Authentifizierungs-Prozess abgeschlossen ist, kann die Verschlüsselung eingeschaltet

werden. Dazu setzt ein Gerät eine Abfrage an das verbundene Gerät ab. Falls die Gegenstelle die Anfrage akzeptiert, werden alle Pakete zwischen diesen Geräten nun verschlüsselt. Falls das andere

Gerät aber ablehnt, wird die Verbindung geschlossen. Die Verschlüsselung wird dazu verwendet, um einen eventuellen Mithörer daran zu hindern etwas von der Kommunikation mitzubekommen.

8 Implementierung

38

Abb. 23: Bluetooth Verschlüsselung

Eine asynchrone, nur einseitig verschlüsselte Verbindung ist nicht möglich.

Die letzte Option zur Bluetooth-Sicherheit ist die Autorisation. Bei diesem Prozess wird festgestellt ob eine Verbindungsanfrage eines bestimmten Bluetooth-Gerätes angenommen werden soll. Dieser Prozess wird bei jeder Verbindung wiederholt. In der Bluetooth-Spezifikation wird auch eine

sogenannte „trusted device“ spezifiziert. Dies ist ein Gerät, das bei einer Autorisationsanfrage

automatisch Zugriff erhält.

Sicherheit Smart-Helm

Unser Bluetooth-Verbindungsmodell macht von der Bluetooth-Sicherheit keinen Gebrauch. Die Meldungen werden alle ungesichert verschickt. Der sichere Versand von Daten war in dieser

Machbarkeitsstudie. Die oben genannten Sicherheitsoptionen lassen sich später relativ trivial einbauen. Dazu müssen nur zwei Anpassungen gemacht werden.

Im BluetoothServer muss die Zeile

String url = "btspp://localhost:" + uuid + ";name=" + serviceName;

geändert werden in

String url = "btspp://localhost:" + uuid + ";authenticate=true;encrypt=true;name=" + serviceName;

und im BluetoothClient von

protected int connectionsOptions = ServiceRecord.NOAUTHENTICATE_NOENCRYPT;

auf

protected int connectionsOptions = ServiceRecord.AUTHENTICATE_ENCRYPT;

Hiermit wird die Verschlüsselung und Authentizierung aktiviert. Damit der Verbindungsaufbau nun klappt, müssen die kommunizierenden Geräte allerdings schon miteinander bekannt (paired) sein.

Bluetooth Fehlerkorrektur

Bluetooth unterstützt drei verschiedene Verfahren für die Fehlerkorrektur. 1/3 FEC (Forward Error

Correction), 2/3 FEC und ARQ (Automatic Repeat Request). Bei den FEC-Verfahren wird versucht den Fehler zu korrigieren (bis 1-Bit), bei ARQ werden fehlerhafte Daten wiederholt angefordert.

8 Implementierung

39

8.1.1.3 LAN Client-Server

Im Hinblick auf das vorherige Protokoll kann der LAN-Client keine Auswertung der Daten zurück an

den Server senden. Handshake

1. Der Client sendet dem Server ein HELLO.

2. Der Server antwortet mit einem ACK. Datenaustausch

1. Sobald vom Medical-Controller Daten an die Server zum Versenden weitergereicht werden, sendet unter anderem der LAN Server diese an den Client. Die Sequenznummer davon dient nur der Zählung dieser

Daten. 2. Der Client antwortet daraufhin mit einem ACK.

ALIVE Channel

Um festzustellen, ob die Verbindung zwischen Client und Server noch

besteht, wird im vordefinierten Intervall ein ALIVE zwischen den beiden Partnern hin- und zurückgesendet.

8.1.1.4 LAN-Sicherheit

Für die Datenübertragung verwenden wir die Klasse Socket, die auf dem TCP-Protokoll aufbaut. Dieses enthält Methoden zur Detektierung von defekten Paketen sowie Algorithmen zur

Retransmission von verlorenen/defekten Paketen. So wird die Datenintegrität gesichert. Die Nachrichten über Ethernet werden standardmässig unverschlüsselt verschickt. Es ist aber eine

Erweiterung denkbar, um die Daten per SSL verschlüsselt zu transferieren. Eine per WEP/WPA gesicherte Übertragung per WLAN wird unterstützt.

Eine sichere Datenübertragung war in dieser Machbarkeitsstudie keine Anforderung.

8.1.2 Medical-Controller

8.1.2.1 Netzwerk Integration

Der Medical-Controller kann auf den Servern Funktionsaufrufe über die Schnittstelle ComAdapter tätigen. Um auf Änderungen von Servern zu reagieren, wird er als ComAdapterListener bei den Servern

registriert. Diese paarweise Referenzierung ist in der Konfiguration festgelegt.

8 Implementierung

40

Abb. 24: Medical-Controller als Listener bei Netzwerkkomponenten

8.1.2.2 Medizinischer Aspekt Integration

Der Medical-Controller ist einerseits als Event-Quelle und anderseits als Event-Listener im

medizinischen Aspekt zu betrachten. Das Interface Medical-Event-Source wird zum Versenden von Nachrichten verwendet, die nach der Berechnung des Verletzungsgrades an die registrierten Listener

versendet werden. Ein solcher Listener ist unter anderem das Smart-Helm Display, das zur Informationsanzeige am Helm dient.

Abb. 25: Medical-Controller als Events-Sender und Listener

Um beispielsweise den Timeout für einen Notruf am Helm zu stoppen, wird dies dem Medical-Controller über die Schnittstelle Medical-Event-Listener mitgeteilt.

8 Implementierung

41

Abb. 26: Medical-Controller und JoglContext3D mit den gemeinsamen Schnittstellen

8.1.2.3 View Kommunikation Integration

Die stetig wechselnden Parameter für die Berechnungen werden dem Medical-Controller über die

View-Listener Schnittstelle mitgeteilt und nicht über die Medical-Event-Listener Schnittstelle. Der Grund dafür ist, dass diese Daten von einer View-Komponente generiert werden, die in keinem

Zusammenhang medizinischer Art stehen. Zudem gibt es Tools, die nur an diesen Roh-Daten interessiert sind, wie beispielswiese der Fiber Identificator.

Abb. 27: Interface und konkrete Tools

Betrachtet man hingegen das Medical-Tool (Abb. 28), so sieht man, dass dieses nur auf Medical-Events reagieren kann. Dies ist beispielsweise dann der Fall, nachdem der Verletzungsgrad berechnet wurde,

denn eine solche Nachricht steht im direkten Zusammenhang medizinischer Aspekte.

8 Implementierung

42

Abb. 28: Interface für Medical-Tool und konkrete Implementierung

8.1.3 Funktionsabläufe

8.1.3.1 Aufschlag ohne Verbindung zum Mobiltelefon

Das folgende und auch im Anhang enthaltene Sequenzdiagramm erläutert den Ablauf bei einem simulierten Aufschlages. Die View-Komponente für die Anzeige der Intensität liefert dem PressureController einen reellen Wert im Interval [0,1].

Siehe Anhang B – Sequenzdiagramm „Aufschlag ohne Verbindung zum Mobiltelefon“

Der Pressure-Controller benachrichtigt (1) alle bei ihm registrierten Listener wie der Jogle3DContext. Die View-Komponente JogleContext3D (1.1) erstellt nun aus der Intensität und den 3D-Koordinaten

auf dem Helm ein ForceModel-Objekt. Danach informiert auch diese View-Komponente seine

Listener (1.1) mit diesem Objekt. Die bereits angeschnittenen View-Komponenten, Fiber Identificator und Pressure History sowie auch der Medical-Controller, erhalten diese Information.

Jetzt werden alle Server (1.1.1.1), der LAN-Server (1.1.1.1.1) und Bluetooth-Server (1.1.1.1.2) darüber informiert. Der Medical-Controller startet nun seine eigene Auswertung (1.1.1.2) und informiert darüber das

Medical-Tool (1.1.1.2.1). Das Medical-Tool zeigt dem Benutzer die Auswertung des Controllers an (1.1.1.2.1.1).

Nach jedem Aufschlag lässt der Medical-Controller für fünf Sekunden das gelbe LED am Helm blinken (1.1.1.3). Darüber hinaus werden alle View-Listener über dieses Ereignis informiert (1.1.1.3.1 und

1.1.1.3.1.1).

8.1.3.2 Aufschlag in Verbindung mit Mobiltelefon

In diesem Fall ist der Ablauf mit einem erhöhten Verletzungsgrad dargestellt.

Siehe Anhang B – Sequenzdiagramm „Aufschlag mit Verbindung zum Mobiltelefon“

8 Implementierung

43

Der Pressure-Controller benachrichtigt (1) alle bei im registrierten Listener wie der Jogle3DContext. Die View-Komponente JogleContext3D (1.1) erstellt nun aus der Intensität und den 3D-Koordinaten

auf dem Helm ein ForceModel-Objekt. Danach informiert auch diese View-Komponente seine

Listener (1.1) mit diesem Objekt. Die bereits angeschnittenen View-Komponenten, Fiber Identificator und Pressure History sowie auch der Medical-Controller, erhalten diese Information. Jetzt werden alle Server (1.1.1.1), der LAN-Server (1.1.1.1.1) und Bluetooth-Server (1.1.1.1.2) darüber informiert.

Das Bluetooth Device ermittelt aus den erhaltenen Daten einen kritischen Verletzungsgrad und sendet

(1.1.1.1.1.1) die Nachricht „ALERT“ an den Medical-Controller. Dieser erstellt einen AlertTask (1.1.1.1.1.1.1) um nach Ablauf einer Quittierungszeit automatisch den Notruf auszulösen. Nach Ablauf

dieser Zeit werden alle Server (1.1.1.1.1.1.1.1) über den Notruf informiert. Die Nachricht „ALERT “ wird an den Bluetooth-Client gesendet (1.1.1.1.1.1.1.1.1).

Der AlertTask informiert nun alle Medical-Listener (1.1.1.1.1.1.1.2), dass die Rote LED ständig

leuchten soll (1.1.1.1.1.1.1.2) und der Notruf an die Kommunikations-Adaptern versandt wurde (1.1.1.1.1.1.1.3).

Der Medical-Controller startet nun seine eigene Auswertung (1.1.1.2) und informiert darüber das Medical-Tool (1.1.1.2.1). Das Medical-Tool zeigt dem Benutzer die Auswertung des Controllers an (1.1.1.2.1.1).

Nach jedem Aufschlag lässt der Medical-Controller für fünf Sekunden das gelbe LED am Helm blinken (1.1.1.3). Darüber hinaus werden alle View-Listener über dieses Ereignis informiert (1.1.1.3.1 und

1.1.1.3.1.1).

8.1.4 Medizinisches Referenzmodel

Anfangs Projektes war die Rede, dass wir von einem Spital ein Referenzmodel bekämen. Da dies leider nie der Fall war, haben wir in Absprache mit Prof. Dr. Nouri ein eigenes erstellt.

Für unser medizinisches Referenzmodel haben wir im Internet nach unterschiedlichen Hirnregionen

gesucht und haben die Veranschaulichung (Abb. 29) für die Einteilung der Regionen gewählt. Um die Regionen auf den Helm zu übertagen, haben wir Referenzpunkte auf dem ganzen Helm festgelegt, die wir danach beliebig zu Region gruppieren können. Um jeder Region ihrer eigenen Sensitivität gerecht zu werden, kann dazu eine Formel angegeben werden womit der Aufschlag verrechnet wird. Das heisst,

jede Region hat ihre eigene Empfindlichkeit und führt bei gleich bleibendem Aufprall zu

unterschiedlichen Verletzungsgraden. Diese Informationen haben wir im XML-Format in der Datei /res/medical/points.xml zusammengestellt.

Weiter haben wir den Wertebereich der Druckanzeige mit dem Intervall [0,1] festgelegt. Die Zwischenschritte und Geschwindigkeit des Hochzählens lassen sich einstellen. Diese Intensität wird

mit der Sensitivität der betroffenen Region verrechnet und ergibt den Verletzungsgrad. Ab welchem Verletzungsgrad einen Notruf ausgelöst wird, lässt sich in der Mobiltelefon-Applikation einstellen.

Die Einbindung eines realeren Referenzmodells ist jederzeit möglich und erfolgt durch das

Überschreiben der oben benannten XML-Datei. Hierbei muss die XML-Datei well-formed sein, das heisst, nach dem dazugehörigen Schema aufgebaut sein.

8 Implementierung

44

1 Abb. 29: Grafisches Referenzmodel mit definierten Regionen

8.1.4.1 Beispiel

Die Region „Primary Visual Cortex“ besteht aus den Referenzpunkten 155, 156, 157 und 158. Dessen

Empfindlichkeit wird mit dem erzielten Schlag und der Formel (x+0.5)*5 verrechnet, wobei x die Variable für die Aufprallstärke darstellt.

<GROUP name="primary visual cortex"> <REF id="155" polygon="1" /> <REF id="156" polygon="2" /> <REF id="157" polygon="4" /> <REF id="158" polygon="3" /> <FORMULA exp="(x+0.5)*5" /> </GROUP>

Weiss in Abb. 30 dargestellt der Primary Visual Cortex und der Aufschlagsfaktor 0.2.

Abb. 30: Simulierter Aufprall

1 Quelle: http://emsnews.wordpress.com/2009/06/02/infamy-tv-dr-skinner-and-the-cia-experiments/

8 Implementierung

45

Die berechnete Intensität ist somit: Die Region „Parietal Lobe“ hat in unserem Model eine etwas niedrigere Empfindlichkeit, die durch den

Formelausdruck x*5 zu erkennen ist.

Weiss in Abb. 31 dargestellt die Parietal Lobe und der Aufschalgsfaktor 0.2.

<GROUP name="parietal lobe"> <REF id="91" polygon="1" /> <REF id="92" polygon="2" /> <REF id="154" polygon="3" /> <REF id="153" polygon="4" /> <REF id="69" polygon="5" /> <REF id="70" polygon="6" /> <FORMULA exp="x*5" /> </GROUP>

Abb. 31: Simulierter Aufprall

Die berechnete Intensität ist somit:

8.1.5 Konfiguration

Die Konfiguration wird ausschliesslich mittels Spring gemacht. Die Konfigurations-Datei ist unter src/

springContext.xml zu finden.

8 Implementierung

46


In diesem Kapitel wollen wir genauer auf die Implementierung der Mobiltelefon-Applikation eingehen

und diese näher beschreiben.

8.2.1 Java ME

Die Java ME Plattform umfasst folgende Schichten.

8.2.1.1 Connected Limited Device Configuration (CLDC)

Die CLDC definiert das Grundgerüst an APIs und die Anforderungen an die Kilobyte Virtual Machine (KVM, eine abgespeckte JVM) für ressourcenlimitierte Geräte wie Mobiltelefone und PDAs. Für unsere Applikation verwenden wir CLDC-1.1. CLDC-1.1 bietet gegenüber CLDC-1.0 u.a. folgende wesentliche Neuerungen2: Unterstützung für Gleitkommazahlen (Klassen Float und Double wurden hinzugefügt). Die minimale Speicherzuweisung der VM wurde von 160 auf 192KB erhöht.

8.2.1.2 Mobile Information Device Profile (MIDP)

Basieren auf der CLDC definieren die MIDPs zusätzliche APIs zur Anwendungserstellung. Zum Beispiel definiert das MIDP die APIs für die GUI-Elemente und die Persistierung von Daten (RecordStore). In unserer Applikation verwenden wir MIDP in der Version 2.0.

8.2.1.3 Optionale APIs

Die Funktionalität von Java (ME) kann durch weitere, optionale APIs erweitert werden. Diese APIs werden in sogenannten Java Specification Requests (JSR) spezifiziert. Wir verwenden für unsere Mobilapplikation diverse optionale JSR um die Anforderungen an die Applikation zu erfüllen. Mehr dazu im Kapitel 8.2.2 Java Requirements Specifications (JSR).

8.2.1.4 Architektur

Somit erhalten wir zusammen mit der Applikationsschicht die 4 Schichten Java ME Architektur:

2 http://jcp.org/aboutJava/communityprocess/final/jsr139/

8 Implementierung

47

Abb. 32: Java ME Implementierung

8.2.2 Java Requirements Specifications (JSR)

Eine JSR ist eine Spezifikation von optionalen APIs, welche auf Java basierenden Applikationen eine

erweiterte Funktionalität ermöglicht (z.B. SMS Versand oder GPS-Standortbestimmung). Es gibt hunderte solcher Spezifikationen3 und einige Implementierungen davon wurden auch für Java ME

umgesetzt. Im folgenden Abschnitt werden die zusätzlichen JSRs, die von der Mobiltelefon-

Applikation verwendet und benötigt werden, mit einer kurzen Beschreibung aufgelistet.

Mobiltelefone müssen diese JSR implementieren, bzw. Unterstützung dafür bieten, andernfalls bricht die Applikation beim Aufstarten mit einer entsprechenden Fehlermeldung ab. Leider unterstützen nicht alle Mobiltelefone alle JSR und sind nur in den seltensten Fällen einmal erweiterbar.

8.2.2.1 SMS

JSR-120 definiert die API zum Zugriff auf die drahtlosen Kommunikations-Technologien Short Message Service (SMS), Unstructured Supplementary Service Data (USSD), sowie Cell Broadcast Service (CBS). Es lassen sich somit unter anderem SMS verschicken und empfangen. Mehr zur

Implementation diesr JSR im Kapitel 8.2.6 Nachrichtenversand.

8.2.2.2 GPS

Für die Anforderung aktuelle GPS-Daten vom Mobiltelefon auszulesen, benötigen wir JSR-179. Dieses

JSR schreibt eine CLDC-Version von mindestens 1.1 vor. Mehr zur Implementierung dazu in Kapitel 8.2.5 Standortbestimmung.

8.2.2.3 USB4

Die API zur Verbindung über USB wird in JSR-80 definiert. Bisher existieren allerdings nur Linux und BSD Implementationen dieser Spezifikation. Weder eine Windows, noch eine Java ME Implementation

sind bisher erhätlich. Mehr dazu später im Kapitel 8.2.7 Kommunikation mit der Smart-Helm

Applikation.

3 siehe http://jcp.org/en/jsr/overview 4 http://javax-usb.org

8 Implementierung

48

8.2.2.4 XML5

Für das Einlesen und Verarbeiten von XML Dateien benutzen wir die API, die in JSR-172 definiert

wurde. Der darin enthaltene XML Parser Implementation baut auf JAXP 1.2 auf. Mehr zur Verwendung dieser JSR später in Kapitel 8.2.3.2 Medizinisches Referenzmodel.

8.2.2.5 Bluetoooth6

Die Kommunikation über Bluetooth wird in JSR-82 spezifiziert. Mehr dazu später im Kapitel 8.2.7 Kommunikation mit der Smart-Helm Applikation.

5 https://jaxp.dev.java.net/ 6 http://jcp.org/en/jsr/detail?id=82

8 Implementierung

49

8.2.3 Datenverwaltung

Die Daten in unserer Mobilapplikation sind auf zwei verschiedene Arten abgespeichert. Die medizinischen Referenzmodelle sind in einer XML-Datei abgelegt. Auf sie wird nur lesend zugegriffen. Die Programm-Einstellungen werden im RecordStore abgelegt. Auf diese Daten kann lesend- wie auch schreibend zugegriffen werden.

8.2.3.1 Programm-Einstellungen

Die Programm-Einstellungen sind die in der Mobiltelefon-Applikation veränderbaren Parameter wie die Notrufnummer, die User-ID, der GPS-Timeout, usw. Für die Persistierung dieser Einstellungen verwenden wir die Klasse RecordStore, die von MIDP zur Verfügung gestellt wird. Dazu müssen die Daten in einem Byte-Array vorliegen. Jede Java ME Anwendung kann mehrere dieser RecordStores verwalten, deren Anzahl und Grösse ist von Java ME Gerät zu Java ME Gerät unterschiedlich. Um die Datenverwaltung kümmert sich unsere Klasse RecordStoreService. Für eine genaue Beschreibung der Funktionsweise aller Methoden dieses Service, verweisen wir auf die auf der DVD beigelegten Java-Doc.

Abb. 33: RecordStoreService

Die Datenstruktur, bzw. wie diese in einem Byte-Array auf den RecordStore geschrieben wird, haben wir wie folgt festgelegt:

Abb. 34: Datenstruktur des Tupels

Wie sich erkennen lässt, kommt dabei jeder Eintrag genau einmal vor. Die Daten im RecordStore „überleben“ ein Beenden der Mobilapplikation und stehen beim nächsten Programmstart wieder zur Verfügung.

8 Implementierung

50

8.2.3.2 Medizinisches Referenzmodel

Als medizinisches Referenzmodell bezeichnen wir die Vergleichsdaten zur Ermittlung der Region sowie dem dazugehörigen Risikofaktor eines Aufpralls. Als Input für diese Berechnung liefert uns der Smart-Helm eine Raumkoordinate und die Aufschlagsintensität des Aufpralls. Diese Informationen werden mit dem Referenzmodell verglichen und ausgewertet. Abgespeichert werden die Daten des Referenz-modells in einer XML-Datei. Java ME stellt für die XML-Verarbeitung mit der JSR 172 einen entsprechenden XML-Parser bereit, der auf der JAXP API 1.2 und den SAX 2.0 Interfaces basiert. Das XML-Dokument wird hierbei sequentiell durchlaufen. Wir haben unseren eigenen CallBackHandler implementiert um die XML-Datei zu verarbeiten.

Abb. 35: Klassen für die Berechnung der Region

Die Methode getRegion(Point3d p) in HitLocationMatcher, welche die Aufprall-Region zurückgibt, benötigt zur Berechnung auf dem Mobiltelefon zwischen 8-11s. Der Grund dafür sind mehrere hundert quadratische Gleichungen mit Wurzel, um die Distanz zwischen 2 Punkten im Raum zu erhalten. Für die Berechnung des Risikofaktors benutzen wir den Java Math Expression Evaluator. Mit dieser Bibliothek lässt sich eine mathematische Formel als String (z.B. „-cos(0)*(1+2)“) angeben, eine Variable setzen und die Formel danach auflösen. Da der der Evaluator für Java SE entwickelt wurde und Java ME nicht alle benötigten Funktionen zur Verfügung stellen, mussten wir die Bibliothek zuerst portieren, damit sie überhaupt lief.

8 Implementierung

8.2.4 GUI Design

Die GUI-Verwaltung in Java ME / MIDP 2.0 lässt nur eine sehr beschränkte Möglichkeit zum

Umgestalten zu. So lässt sich zwar der Inhalt der einzelnen Bildschirme bestimmen, das Aussehen der

einzelnen Elemente lässt sich aber nicht verändern (weder Grösse, Design, noch Font). Beim Layout lässt sich nur angeben in welcher Reihenfolge die Elemente erscheinen sollen. Auf die Reihenfolge der

Commands kann kein Einfluss genommen werden. Diese erscheinen je nach Mobiltelefon in einer anderen Reihenfolge.

8.2.4.1 GUI Elemente

Für die Bildschirmmasken benutzen wir folgende, von MIDP-2.0 zur Verfügung gestellte, Bildschirmelemente in unserer Mobiltelefon-Applikation:

Form

Die Form ist das Zentrale Element einer Bildschirmmaske. Auf ihr

lassen sich alle unten beschriebenen Elemente anbringen und kombinieren. Die Form wird von allen Bildschirmen verwendet um die Elemente darauf zu plazieren.

Liste

Die Liste enthält Texteinträge, die jeweils Zeilenweise untereinander

stehen. Auf einer Liste lassen sich Einträge markieren. Die Liste

wird für Menueinträge verwendet um für die Anzeige der Ereignisse

bei Verbindung mit der Smart-Helm Applikation.

Alert

Alert ist eine Art Pop-Up Fenster, die über einer Bildschirmmaske eingeblendet wird und sich nach einem bestimmten Zeitintervall

wieder ausblendet.

TextBox

Die TextField wird verwendet um den Benutzer Eingaben machen zu lassen. Beim Erstellen lassen sich Restriktionen erstellen, was für

Eingaben die TextField annehmen soll. So kann man z.B. bei einer TextField für Telefonnummern angeben, dass sie nur

alphanumerische Werte annehmen soll.

ChoiceGroup

Die ChoiceGroup wird für die Selektion aus mehreren Elementen verwendet. Dabei kann nur eines, aber auch mehrere Elemente

gleichzeitig selektiert werden.

8 Implementierung

66

Ticker

Der Ticker zeigt einen vorbeiscrollenden Text an. Wird verwendet

um den Benutzer über den aktuelle Status zu informieren.

Command

Ein Command stellt eine Knopfeingabe auf dem Mobiltelefon dar. So lassen sich damit z.B. Eingaben bestätigen oder abbrechen.

8.2.4.2 Java ME GUI Frameworks

Für Java ME existieren auch GUI-Frameworks, mit denen sich die einzelnen Bildschirmelemente und

Bildschirme über die Grenzen des Standard-GUIs verändern lassen. Als Beispiel seien hier LWUIT von Sun (https://lwuit.dev.java.net/) genannt, sowie Polish

(http://www.j2mepolish.org) von Enough Software. Der Vorteil dieser Frameworks liegt auf der Hand:

Mit wenig Aufwand lassen sich grafisch ansprechende Anwendungen schreiben, die auf allen unterstützten Mobiltelefonen identisch aussehen. Der Nachteil ist allerdings, dass die darin enthaltenen

Libraries die Applikation um einige Kilobyte bis mehrere Kilobytes aufbläht.

8.2.5 Standortbestimmung

Eine Anforderung an die Mobiltelefon-Applikation war, den aktuellen Standort des mobilen Gerätes in

der Notrufnachricht mitzusenden. Dazu greifen wir auf die Java Specification Request 179 zurück,

welche die Entwicklung von Location Based Mobile Applications auf der Java ME Plattform

standardisiert. Dabei wird auf dem Mobiltelefon auf ein GPS-Modul zugegriffen. Unterstützt wird dabei die Standortbestimmung über Satellit und über das Mobiltelefonnetz (AGPS), bei dem der Standort über die Zelleninformationen bestimmt wird.

Abb. 36: Service-Klassen zu GPS-Bestimmung

Falls die Applikation nach einer bestimmten Zeitspanne keine Antwort vom GPS-Modul erhält, gibt es ein Timeout. Die bis zum Timeout gewartete Zeit lässt sich in den Programmoptionen einstellen (siehe 0 Projekt-Nummer: I1169

8 Implementierung

53


Mobile Phone

Thesis für den

Bachelor in Computer Science

Eingereicht an der

Fachhochschule Nordwestschweiz

Diplomanden RAJIB MITRA und DANIEL MEYER

Prof. Dr. Taoufik Nouri, Studienleiter Beat Schär, Referent

2009

8 Implementierung

21

Kontaktinfos



Daniel Meyer





Experte Beat Schär

Dipl. Ing. ETH,




8 Implementierung

21

Danksagung




8 Implementierung

21

Zusammenfassung






eingesetzt werden.

8 Implementierung

21

Inhalt


Inhalt .............................................................................................................................................9

1 Einleitung ............................................................................................................................ 13

1.1 Motivation...................................................................................................................................... 13

1.2 Aufbau............................................................................................................................................ 13

2 Projektauftrag ...................................................................................................................... 15

2.1 Auftrag ........................................................................................................................................... 15

2.2 Ausgangslage.................................................................................................................................. 15

2.3 Anforderungen .............................................................................................................................. 15

3 Ziele ..................................................................................................................................... 17

4 Planung................................................................................................................................ 19



5 Vorgehensweise ................................................................................................................... 21

5.1 Methodik........................................................................................................................................ 21







5.3.1 Analyse....................................................................................................................................... 25


5.3.3 Prototyping................................................................................................................................ 26

6 Technologie .........................................................................................................................27

6.1.1 Sprachen .................................................................................................................................... 27


Inhalt

66

6.1.3 Libraries ..................................................................................................................................... 27

7 Resultat ................................................................................................................................29

7.1 Erreichte Ziele............................................................................................................................... 29








7.3.2 Hauptmenü................................................................................................................................ 31

7.3.3 Gerätesuche............................................................................................................................... 31

7.3.4 Servicesuche .............................................................................................................................. 32




7.3.8 Notrufnummer.......................................................................................................................... 33

7.3.9 Alarmlevel.................................................................................................................................. 34







8.1.5 Konfiguration............................................................................................................................ 45


8.2.1 Java ME ..................................................................................................................................... 46



8.2.4 GUI Design............................................................................................................................... 51




8.2.8 Deployment............................................................................................................................... 54

Inhalt

53

9 Testen ..................................................................................................................................55




9.2.1 Unit Testing............................................................................................................................... 56


11 Reflexion..............................................................................................................................59


13 Literatur ...............................................................................................................................63


15 Anhang.................................................................................................................................67




Anhang D – DVD...................................................................................................................................... 67

21

9 Einleitung





9.1 Motivation







9.2 Aufbau

• Abstrakt

• Ausgangslage





• Resultat



21

10 Projektauftrag

10.1 Auftrag




10.2 Ausgangslage



10.3 Anforderungen



21

11 Ziele









21

12 Planung




1 Planung Mo 16.02.09 Fr 27.03.09


3 Entwurf Mo 30.03.09 Fr 01.05.09



6 Testen Mo 04.05.09 Fr 31.07.09




26.01. 23.02. 23.03. 20.04. 18.05. 15.06. 13.07. 10.08.




deren Datum.


Applikation

Mobiletelefon-

Applikation















4 Planung

66




x


x




x






















21

13 Vorgehensweise



13.1 Methodik










5 Vorgehensweise

66






Deployment

5 Vorgehensweise

53


13.2.1.1 Architektur








Pakete



13.2.1.2 GUI Design


5) Menu-Liste

6) 3D-Panel


7) Tool-Panel


5 Vorgehensweise

66





5 Vorgehensweise

53


13.3.1 Analyse



Zur Auswahl standen folgende Plattformen: Java ME Entwickler Sun Microsystems Webseite http://java.sun.com/javame/ Programmiersprache Java Kurzbeschrieb Für mobile Geräte angepasstes Java Android Entwickler Google / Open Handset Alliance Webseite http://www.android.com/ Programmiersprache Java Kurzbeschrieb Open Source OS von Google iPhone OS Entwickler Apple Inc. Webseite http://developer.apple.com/iphone/ Programmiersprache Objective-C Kurzbeschrieb Auf iPhone portierte Version von Mac OS X Windows Mobile Entwickler Microsoft Webseite http://microsoft.com/windowsmobile/ Programmiersprache Visual C++, .NET Compact Framework Kurzbeschrieb Auf Win32-API basierendes Mini-Windows Symbian OS Entwickler Symbian Foundation Webseite http://www.symbian.com/ Programmiersprache C++ Kurzbeschrieb Handheld OS von Symbian. Mittlerweile Open Source Alle genannten Plattformen bieten gut dokumentierte APIs, aktive Communities und viele hilfreiche Beispielapplikationen.

5 Vorgehensweise

26



13.3.3 Prototyping




35

14 Technologie

14.1.1 Sprachen




www.sun.com 1.6


www.opengl.org


www.spring.com

XML






14.1.3 Libraries






6 Technologie

66



35

15 Resultat

15.1 Erreichte Ziele


























7 Resultat

66


















7 Resultat

53




Beim Aufstarten der Smart-Helm Mobiltelefon-Applikation wird man von einem Willkommens-Bildschirm begrüsst, der nach 2s automatisch wieder verschwindet.

15.3.2 Hauptmenü

Nach dem Willkommens-Bildschirm erscheint das Hauptmenü. Von hier aus kann man die Verbindung starten oder zu den Benutzer- und Programm-einstellungen wechseln.

15.3.3 Gerätesuche

Nach Auswahl von „Start Application“ wird die Umgebung nach sichtbaren Bluetooth-Geräten abgesucht. Gefundene Geräte erscheinen als Eintrag auf dem Bildschirm. Diese Suche kann mehrere

Sekunden dauern. Ist die Suche noch nicht abgeschlossen, erscheint zuoberst im Bildschirm ein Ticker mit der Meldung das noch nach Bluetooth-Geräten gesucht wird. Nach abgeschlossenem Suchvorgang

verschwindet diese Anzeige. Mit einem Druck auf „Refresh“ lässt sich die Gerätesuche nochmals neu

starten.


15.3.4 Servicesuche

Bei der Servicesuche wird auf dem im Gerätesuche-Bildschirm ausgewähltem Gerät nach Bluetooth-

Services gesucht.

7 Resultat

66

Mit einem Druck auf Back gelangt man zurück zur Gerätesuche.


Damit dieser gefunden wird, muss die Smart-Helm Applikation am Laufen sein. Mit einem Druck auf „Connect“ startet die Verbindung zum Smart-Helm Service.


Nach erfolgreicher Verbindung zum Smart-Helm-Bluetooth Service, erscheinen Ereignismeldungen auf

dem Bildschirm, die über den aktuellen Status informieren.


Mit der Auswahl von „Back“ gelangt man zurück zum Hauptmenü.


In den Benutzereinstellungen lässt sich die UID eingeben, mit der sich die Mobiltelefon-Applikation personalisieren lässt. Zusätzlich haben wir noch ein Feld für das Alter des Benutzers eingefügt. Diese

steht stellvertretend für weitere Benutzerinputs, die man noch hinzufügen könnte.

Mit der Auswahl von „Save“ lassen sich die Änderungen speichern, mit „Back“ werden sie verworfen und zum Hauptmenü gewechselt.


Die Programmeinstellungen wurden in weitere Selektionen unterteilt. Dies wurde mit Hinblick auf die

spätere Erweiterbarkeit gemacht, da sich so einfach weitere nach Kategorie zusammengestellte Programmeinstellungen einfügen lassen. Wenn es nur einen Bildschirm für alle Programmoptionen

gäbe, wäre dieser schnell überfüllt und unübersichtlich. Mit „Select“ lässt sich ein Eintrag anwählen.

Notrufnummer)

15.3.8 Nachrichtenversand

Der Nachrichtenversand geschieht über einen SMSService. Die dazugehörenden API für Java ME wird

in der JSR-120 definiert. Die Zielnummer wird in den Programmoptionen eingegeben (siehe 0 Projekt-Nummer: I1169


Mobile Phone

Thesis für den

Bachelor in Computer Science

7 Resultat

66

Eingereicht an der

Fachhochschule Nordwestschweiz

Diplomanden RAJIB MITRA und DANIEL MEYER

Prof. Dr. Taoufik Nouri, Studienleiter

Beat Schär, Referent

2009

21

Kontaktinfos



Daniel Meyer





Experte Beat Schär

Dipl. Ing. ETH,




21

Danksagung




21

Zusammenfassung






eingesetzt werden.

21

Inhalt


Inhalt .............................................................................................................................................9

1 Einleitung ............................................................................................................................ 13

1.1 Motivation...................................................................................................................................... 13

1.2 Aufbau............................................................................................................................................ 13

2 Projektauftrag ...................................................................................................................... 15

2.1 Auftrag ........................................................................................................................................... 15

2.2 Ausgangslage.................................................................................................................................. 15

2.3 Anforderungen .............................................................................................................................. 15

3 Ziele ..................................................................................................................................... 17

4 Planung................................................................................................................................ 19



5 Vorgehensweise ................................................................................................................... 21

5.1 Methodik........................................................................................................................................ 21







5.3.1 Analyse....................................................................................................................................... 25


5.3.3 Prototyping................................................................................................................................ 26

6 Technologie .........................................................................................................................27

6.1.1 Sprachen .................................................................................................................................... 27


Inhalt

66

6.1.3 Libraries ..................................................................................................................................... 27

7 Resultat ................................................................................................................................29

7.1 Erreichte Ziele............................................................................................................................... 29








7.3.2 Hauptmenü................................................................................................................................ 31

7.3.3 Gerätesuche............................................................................................................................... 31

7.3.4 Servicesuche .............................................................................................................................. 32




7.3.8 Notrufnummer.......................................................................................................................... 33

7.3.9 Alarmlevel.................................................................................................................................. 34







8.1.5 Konfiguration............................................................................................................................ 45


8.2.1 Java ME ..................................................................................................................................... 46



8.2.4 GUI Design............................................................................................................................... 51




8.2.8 Deployment............................................................................................................................... 54

Inhalt

53

9 Testen ..................................................................................................................................55




9.2.1 Unit Testing............................................................................................................................... 56


11 Reflexion..............................................................................................................................59


13 Literatur ...............................................................................................................................63


15 Anhang.................................................................................................................................67




Anhang D – DVD...................................................................................................................................... 67

21

16 Einleitung





16.1 Motivation







16.2 Aufbau

• Abstrakt

• Ausgangslage





• Resultat



21

17 Projektauftrag

17.1 Auftrag




17.2 Ausgangslage



17.3 Anforderungen



21

18 Ziele









21

19 Planung




1 Planung Mo 16.02.09 Fr 27.03.09


3 Entwurf Mo 30.03.09 Fr 01.05.09



6 Testen Mo 04.05.09 Fr 31.07.09




26.01. 23.02. 23.03. 20.04. 18.05. 15.06. 13.07. 10.08.




deren Datum.


Applikation

Mobiletelefon-

Applikation















4 Planung

66




x


x




x






















21

20 Vorgehensweise



20.1 Methodik










5 Vorgehensweise

66






Deployment

5 Vorgehensweise

53


20.2.1.1 Architektur








Pakete



20.2.1.2 GUI Design


9) Menu-Liste

10) 3D-Panel


11) Tool-Panel


5 Vorgehensweise

66





5 Vorgehensweise

53


20.3.1 Analyse



Zur Auswahl standen folgende Plattformen: Java ME Entwickler Sun Microsystems Webseite http://java.sun.com/javame/ Programmiersprache Java Kurzbeschrieb Für mobile Geräte angepasstes Java Android Entwickler Google / Open Handset Alliance Webseite http://www.android.com/ Programmiersprache Java Kurzbeschrieb Open Source OS von Google iPhone OS Entwickler Apple Inc. Webseite http://developer.apple.com/iphone/ Programmiersprache Objective-C Kurzbeschrieb Auf iPhone portierte Version von Mac OS X Windows Mobile Entwickler Microsoft Webseite http://microsoft.com/windowsmobile/ Programmiersprache Visual C++, .NET Compact Framework Kurzbeschrieb Auf Win32-API basierendes Mini-Windows Symbian OS Entwickler Symbian Foundation Webseite http://www.symbian.com/ Programmiersprache C++ Kurzbeschrieb Handheld OS von Symbian. Mittlerweile Open Source Alle genannten Plattformen bieten gut dokumentierte APIs, aktive Communities und viele hilfreiche Beispielapplikationen.

5 Vorgehensweise

26



20.3.3 Prototyping




35

21 Technologie

21.1.1 Sprachen




www.sun.com 1.6


www.opengl.org


www.spring.com

XML






21.1.3 Libraries






6 Technologie

66



35

22 Resultat

22.1 Erreichte Ziele


























7 Resultat

66


















7 Resultat

53




Beim Aufstarten der Smart-Helm Mobiltelefon-Applikation wird man von einem Willkommens-Bildschirm begrüsst, der nach 2s automatisch wieder verschwindet.

22.3.2 Hauptmenü

Nach dem Willkommens-Bildschirm erscheint das Hauptmenü. Von hier aus kann man die Verbindung starten oder zu den Benutzer- und Programm-einstellungen wechseln.

22.3.3 Gerätesuche

Nach Auswahl von „Start Application“ wird die Umgebung nach sichtbaren Bluetooth-Geräten abgesucht. Gefundene Geräte erscheinen als Eintrag auf dem Bildschirm. Diese Suche kann mehrere

Sekunden dauern. Ist die Suche noch nicht abgeschlossen, erscheint zuoberst im Bildschirm ein Ticker mit der Meldung das noch nach Bluetooth-Geräten gesucht wird. Nach abgeschlossenem Suchvorgang

verschwindet diese Anzeige. Mit einem Druck auf „Refresh“ lässt sich die Gerätesuche nochmals neu

starten.


22.3.4 Servicesuche

Bei der Servicesuche wird auf dem im Gerätesuche-Bildschirm ausgewähltem Gerät nach Bluetooth-

Services gesucht.

7 Resultat

66

Mit einem Druck auf Back gelangt man zurück zur Gerätesuche.


Damit dieser gefunden wird, muss die Smart-Helm Applikation am Laufen sein. Mit einem Druck auf „Connect“ startet die Verbindung zum Smart-Helm Service.


Nach erfolgreicher Verbindung zum Smart-Helm-Bluetooth Service, erscheinen Ereignismeldungen auf

dem Bildschirm, die über den aktuellen Status informieren.


Mit der Auswahl von „Back“ gelangt man zurück zum Hauptmenü.

8 Implementierung

117


In den Benutzereinstellungen lässt sich die UID eingeben, mit der sich die Mobiltelefon-Applikation personalisieren lässt. Zusätzlich haben wir noch ein Feld für das Alter des Benutzers eingefügt. Diese

steht stellvertretend für weitere Benutzerinputs, die man noch hinzufügen könnte.

Mit der Auswahl von „Save“ lassen sich die Änderungen speichern, mit „Back“ werden sie verworfen und zum Hauptmenü gewechselt.


Die Programmeinstellungen wurden in weitere Selektionen unterteilt. Dies wurde mit Hinblick auf die

spätere Erweiterbarkeit gemacht, da sich so einfach weitere nach Kategorie zusammengestellte Programmeinstellungen einfügen lassen. Wenn es nur einen Bildschirm für alle Programmoptionen

gäbe, wäre dieser schnell überfüllt und unübersichtlich. Mit „Select“ lässt sich ein Eintrag anwählen.

Notrufnummer).

Abb. 37: Service-Klasse für SMS Versand

Der Text der SMS besteht aus der UID wie er in den Benutzereinstellungen angegeben wurde (siehe

7.3.6 Benutzereinstellungen), die Aufprallregion und –gefahr, sowie die aktuelle GPS-Position. Falls bei

der GPS-Standortbestimmung ein Timeout stattgefunden hat, werden keine GPS-Daten verschickt.

22.3.8 Kommunikation mit der Smart-Helm Applikation

Ein Anforderung der Mobiltelefon-Applikation forderte eine Kommunikation mit der Smart-Helm Applikation über USB und Bluetooth.

22.3.8.1 USB

Die Verbindung über USB wird in JSR-80 spezifiziert. Bis zur Ausarbeitung der Bachelorarbeit gab es aber noch keine Windows-Implementierung dieser Spezifikation und nur experimentelle Versionen für

Linux. Es gibt bisher nur wenige Mobiltelefone welche diese Spezifikation unterstützen, keine unserer zur Verfügung stehenden Mobiltelefone bot hierfür Unterstützung.

22.3.8.2 Bluetooth

Die Kommunikation über Bluetooth wird in JSR-82 spezifiziert. Die Klasse BluetoothClient ist verantwortlich für den Kommunikationsablauf.

7 Resultat

66

Abb. 38: Bluetooth-Client

Im Unterschied zu Java SE, unterstützt die abgespeckte Java Version in Java ME keinen BufferedReader oder BufferedWriter. Deshalb wird der Inputstream Byteweise gelesen und

geschrieben. In Java SE könnte man bequem zeilenweise lesen. Um nun auf das Ende eines Wortes zu prüfen, vergleichen wir den Input mit dem Hex-Code für Newline (0x0a). Im Gegenzug müssen wir

um das Ende eines Wortes beim Versand anzugeben, zusätzlich den Charakter für Newline versenden

(‚\n‘).

22.3.9 Deployment

Im Ordner „Mobile/Deploy“ auf der DVD findet sich das fertig kompilierte Jar File der Mobiltelefon-Applikation. Dieses kann einfach z.B. über Bluetooth auf jedes kompatible Mobiltelefon kopiert und dort installiert und ausgeführt werden.

Damit die Mobiltelefon-Applikation läuft, muss das Mobiltelefon mindestens Unterstützung für die in

Kapitel 8.2.2 Java Requirements Specifications (JSR) angegebenen JSRs bieten. Ist dies nicht der Fall, verweigert die Applikation mit einer entsprechenden Fehlermeldung den Start.

119

23 Testen


Wir verwenden JUnit für den Komponenten-Test der Smart-Helm-Applikation. Der Usability- und Performance-Test scheiden im Rahmen dieser Machbarkeitsstudie aus. In unserem Fokus liegt die

Korrektheit der Ermittlung der Region und Verletzungsgrad.

23.1.1 Medical-Controller

Der Medical-Controller ist zuständig für die Berechnung der Region und Verletzungsgrades. Dessen

Korrektheit war von enormer Bedeutung, denn davon hing die Machbarkeit bzw. der weitere Verlauf des Projektes ab. Analog davon soll die Mobiltelefon-Applikation auf Basis von JavaME mit derselben

Berechnung zum gleichen Resultat führen. Die dazugehörige Test-Klasse befindet sich unter

/test/ch/fhnw/smarthelm/medical/MedicalControllerTest.

23.1.1.1 Test 1 & 2: Nächstliegende Punkt und dessen Region

Wie bereits erwähnt, wurden auf dem Helm Referenzpunkte aufgenommen. Dieser Test soll anhand der aktuellen 3D-Mauskoordinate den am nächsten liegende Punkt überprüfen. Zum Ersten testeten

wir diese Funktionalität mit einer von den Referenzpunkten unterscheidende Koordinate und danach

mit einem Referenzpunkt selbst. Beide Tests waren erfolgreich.

23.1.1.2 Test 3 & 4: Region und Verletzungsgrad

Der nächste logische Schritt führt zur Bestimmung des Verletzungsgrades. Da jede Region eine

unterschiedliche Empfindlichkeit vorweist, müssen mindestens zwei Tests durchgeführt werden. Auch hier waren beide Tests erfolgreich.

9 Testen

120


In diesem Kapitel wollen wir genauer darauf eingehen wie und was wir auf der Mobilapplikation testen. Wir beschränken uns beim Testen auf Unit-Tests. Der Grund warum wir auf Performance-, Usability,

und weitere Tests verzichteten, ist dass dieses Projekt eine Machbarkeitsstudie darstellt und diese Tests dafür nicht von Bedeutung wären. Ein korrekte Funktionsweise ist allerdings unbedingt notwendig.

23.2.1 Unit Testing

Als Test-Famework für die Mobilapplikation benutzen wir JMUnit (http://jmunit.sourceforge.net/), das auf Junit basiert. Da JUnit für die Testausführungen auf die Reflection API zugreift und diese unter

Java ME nicht verfügbar steht, können wir nicht einfach JUnit für die Tests nehmen. In JMUnit erben alle Test-Klassen von MIDlet. Das hat zur Folge, dass die Unit-Tests auf dem WTK-

Emulator ebenso laufen wie auf dem Mobiltelefon.

Abb. 39: Vererbungshierarchie von Tests für MIDlets

Eine zentraler Bestandteil unserer Mobilapplikation ist die Verbindung über Bluetooth zum Smart-

Helm und die darüber laufende Kommunikation. Den Verbindungsauf- und Abbau können wir mit

JMUnit nicht testen. Wir testen aber die entsprechenden Methoden zur Berechnung der Aufprallposition und -intensität. Hierbei spielen die Methoden der Klasse HitLocationMatcher eine

wichtige Rolle.

Das korrekte Datenhandling ist ebenfalls von grösster Wichtigkeit. Hierfür testen wir den

RecordStoreService auf dessen korrekte Funktionsweise. Wir verzichten auf einen Test aller Setter- und Getter-Methoden, es sei denn diese sind nicht trivial.

Die Klassen für den SMS-Versand und die GPS-Positionsbestimmung lassen sich nicht per Unit-Tests auf Korrektheit überprüfen. Wir verifizieren deren korrekte Funktionsweise durch praktische Tests.

Die JMUnit-Tests finden sich im Source-Ordner tests.

121

24 Aufgabenverteilung

Daniel Meyer Rajib Mitra

Planung Grobplanung und Feinplanung 50% 50% Architektur Smart-Helm 100% Mobiltelefon-Applikation 100% Implementierung Medizinisches Referenzmodel 100% Smart-Helm Erweiterung 90% 10% Mobiltelefon-Applikation 100% Tests Smart-Helm Erweiterung 100% Mobiltelefon-Applikation 100% Dokumentation Einleitung 50% 50% Abstrakt 100% Ausgangslage 50% 50% Applikationsentwicklung Methodik 100% Smart-Helm 100% Mobiltelefon-Applikation 100% Technologie 100% Resultat Erreichte Ziele 100% Smart-Helm 100% Mobiltelefon-Applikation 100% Bluetooth-/LAN-Sicherheit 100% Testen Smart-Helm 100% Mobiltelefon-Applikation 100% Zusammenstellung 100%

123

25 Reflexion

Alle Haupt-Anforderungen, bis auf die Verbindung Smart-Helm – Mobiltelephon über USB, was wir

aufgrund von mangelnder Hardware nicht umsetzen konnten, wurden erfüllt. Zusätzlich wurden auch noch einige optionale Anforderungen implementiert. Durch die Projektrealisation konnten wir umfassende Einblicke in die Welt der 3D-Darstellung

erarbeiten, ein Themengebiet, dass Herrn Mitra auch später beruflich weiterverfolgen wird.

Herr Meyer konnte seine Erfahrung im Umgang mit dem Spring Framework und der GUI-Entwicklung mit Swing vertiefen, auch er wird nach dem Studium davon profitieren können.

Eine grosse Herausforderung war die Berechnung der Aufprallregionen durch das medizinische

Referenzmodell. Die Entwicklung einer - auf der ressourcenlimitierten und funktional eingeschränkten

Plattform Java ME basierenden - mobilen Applikation stellte sich manchmal ebenfalls weniger trivial dar als zu Beginn angenommen.

Die fortlaufende, während dem ganzen Semester nachgeführte Dokumentation, verhinderte den grossen Stress zum nahenden Abgabetermin. Die Anfangs aufgestellte Planung wurde grösstenteils

eingehalten, die festgelegten Meilensteine wurden alle am festgelegten Datum erreicht.

Bei Fragen oder Unklarheiten konnten wir jederzeit auf die Hilfe und Erfahrung von Prof. Nouri zählen.

Die Arbeit am Smart-Helm war herausfordernd, lehrreich und höchst interessant. Die Gelegenheit an einer Machbarkeitsstudie mitzuwirken für ein Produkt, das später einmal global vermarktet werden und

Menschen helfen könnte, war einmalig.

Wir hoffen mit der Bachelorarbeit unseren Teil für eine erfolgreiche Realisation des Smart-Helms beigetragen zu haben.

125

26 Ehrlichkeitserklärung

Wir erklären hiermit, dass wir die vorliegende Arbeit selbständig, ohne Mithilfe Dritter und nur unter

Benutzung der angegebenen Quellen verfasst haben.

Rajib Mitra Windisch, 14.08.2009

Daniel Meyer Windisch, 14.08.2009

127

27 Literatur

[Fre] Thomas Frenken. JSR-179: Location Based Mobile Applications auf der JavaME-

Plattform

http://www.mi.fh-wiesbaden.de/~barth/mobile/ws0607/Location.pdf , 2007

[Gos] Soma Ghosh. Add XML parsing to your J2ME applications,

http://www.ibm.com/developerworks/library/wi-parsexml/ , 2003

[LSC] The-Son LAI, V. Singh, V. Tad Christiansen, Java Math Expression Evaluator,

http://lts.online.fr/dev/java/math.evaluator/ , 2008

[OE07] Daniel Oltmanns, Stefan Edlich, Spring 2 für Grünschnäbel. Books on Demand, 2007

[Ris] Ray Rischpater, Beginning Java ME Platform, Apress, 2008

[Sch] Klaus-Dieter Schmatz, Java 2 Micro Edition - Entwicklung mobiler Anwendungen

mit CLDC und MIDP, dpunkt.verlag, 2004

[Sie] Johannes Siedersleben, Moderne Software-Architektur. dpunkt.verlag, 2004

[TKK] Timothy J. Thompson, Paul J. Kline, C Bala Kumar. Bluetooth Application

Programming with the Java APIs, Morgan Kaufmann Publishers, 2008

[Vli] Eric van der Vlist, XML Schema, The W3C's Object-Oriented Descriptions for XML.

O’Reilly, 2002

129

28 Abbildungsverzeichnis

Abb. 1: Projektplanung .................................................................................................................................. 19

Abb. 2: Grafische Darstellung von Rational Unified Process (RUP)........................................................ 21

Abb. 3: Das Model View Controller Pattern................................................................................................ 23

Abb. 4: Paket-Erweiterung der bestehenden Applikation........................................................................... 23

Abb. 5: Anordnung der GUI-Elemente ....................................................................................................... 24

Abb. 6: Paperbased Prototyp der Mobiltelefon-Applikation ...................................................................... 26

Abb. 7: Erweiterung durch das Medical-Tool und Helm-Display.............................................................. 30

Abb. 8: Willkommens-Bildschirm................................................................................................................... 1

Abb. 9: Hauptmenu.......................................................................................................................................... 1

Abb. 10: Untermenu......................................................................................................................................... 1

Abb. 11: Gerätesuche ....................................................................................................................................... 1

Abb. 12: Servicesuche....................................................................................................................................... 1

Abb. 13: Verbindungsbilschirm....................................................................................................................... 1

Abb. 14: Statusmeldungen ............................................................................................................................... 1

Abb. 15: Benutzereinstellungen....................................................................................................................... 1

Abb. 16: Programmeinstellungen .................................................................................................................... 1

Abb. 17: Notrufnummer.................................................................................................................................. 1

Abb. 18: Alarmlevel .......................................................................................................................................... 1

Abb. 19: Paket Erweiterung für die Netzwerk-Kommunikation................................................................ 35

Abb. 20: Interface für Netzwerk-Server Komponenten ............................................................................. 36

Abb. 21: Bluetooth Pairing ............................................................................................................................ 37

Abb. 22: Bluetooth Authentifizierung .......................................................................................................... 37

Abb. 23: Bluetooth Verschlüsselung............................................................................................................. 38

Abb. 24: Medical-Controller als Listener bei Netzwerkkomponenten ...................................................... 40

Abb. 25: Medical-Controller als Events-Sender und Listener .................................................................... 40

Abb. 26: Medical-Controller und JoglContext3D mit den gemeinsamen Schnittstellen.......................... 41

Abb. 27: Interface und konkrete Tools......................................................................................................... 41

Abb. 28: Interface für Medical-Tool und konkrete Implementierung ....................................................... 42

Abb. 29: Grafisches Referenzmodel mit definierten Regionen .................................................................. 44

Abb. 30: Simulierter Aufprall......................................................................................................................... 44

Abb. 31: Simulierter Aufprall......................................................................................................................... 45

Abb. 32: Java ME Implementierung ............................................................................................................. 47

Abb. 33: RecordStoreService ......................................................................................................................... 49

Abb. 34: Datenstruktur des Tupels ............................................................................................................... 49

14 Abbildungsverzeichnis

66

Abb. 35: Klassen für die Berechnung der Region........................................................................................ 50

Abb. 36: Service-Klassen zu GPS-Bestimmung........................................................................................... 52

Abb. 37: Service-Klasse für SMS Versand.................................................................................................... 53

Abb. 38: Bluetooth-Client.............................................................................................................................. 53

Abb. 39: Vererbungshierarchie von Tests für MIDlets............................................................................... 56

131

29 Anhang

Anhang A – Pflichtenheft zur Bachelor Thesis

Anhang B – UML Diagramme

Anhang C – Source Code Dokumentation

Anhang D – DVD

Anhang A Pflichtenheft zur Bachelor Thesis Dieses Dokument enthält die Anforderungen die am Anfang der Bachelor Thesis erstellt wurden.

Anhang B UML Diagramme Dieses Kapitel enthält Sequenzdiagramme der Erweiterung am Smart-Helm.

Anhang C Source Code Dokumentation Dieses Kapitel enthält Erklärungen von Klassen und der Methoden.

Anhang D DVD

projekt-nummer: i1169 communication smart helmet - …web.fhnw.ch/personenseiten/taoufik.nouri/smart...

Documents