Post on 20-Sep-2019
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 rajib@gmx.net
Daniel Meyer
Bodenackerstrasse 45
5200 Brugg + 41 78 611 54 00 meyerdaniel.ch@gmail.com
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 beat.schaer@wifag.ch
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.2 Smart-Helm Applikation .............................................................................................................. 30
7.3 Mobiltelefon-Applikation ............................................................................................................. 31
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 Smart-Helm Applikation .............................................................................................................. 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 Mobiltelefon-Applikation ............................................................................................................. 46
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.1 Smart-Helm Applikation .............................................................................................................. 55
9.1.1 Medical-Controller.................................................................................................................... 55
9.2 Mobiltelefon-Applikation ............................................................................................................. 56
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
23.04.2009 Meeting mit Prof. Dr. Nouri
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
21.07.2009 Meeting mit Prof. Dr. Nouri
29.07.2009 Meeting mit Prof. Dr. Nouri
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
12.08.2009 Meeting mit Prof. Dr. Nouri
13.08.2009 Dokumentation abgeschlossen
14.08.2009 Meeting mit Prof. Dr. Nouri
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
Name Beschreibung URL Version
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.
hoch komplett erfüllt
Basierend auf der Morphologie des medizinischen Referenzmodelles Entscheidungen über den Verletzungsgrad des Aufpralles treffen.
hoch komplett erfüllt
Übermittlung des Verletzungsgrades an den Smart-Helm. hoch komplett erfüllt
Im Notfall, senden der ausgewerteten Helm-Daten und GPS-Information an eine Notrufzentrale.
hoch komplett erfüllt
Sicherheitsfunktionalitäten stellen sicher, dass die Verbindung zwischen Mobiltelefon und Helm jederzeit aktiv und verfügbar ist.
hoch komplett erfüllt
7.1.2 Anforderungen an den Smart-Helm Simulator
Anforderung Priorität Status
Verbindung zum Mobiltelefon über USB und Bluetooth. hoch Nur Bluetooth
Übermittlung der Positions- und Intensitätsdaten eines Aufschlages an die Mobiltelefon Applikation.
hoch komplett erfüllt
Übermittlung der Positions- und Intensitätsdaten eines Aufschlages durch Bluetooth oder WLAN an diverse Empfänger, ausgestattet mit Smart-Helm Data Receiver Applikation.
hoch komplett erfüllt
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.
hoch komplett erfüllt
7 Resultat
30
Anzeigen des Verletzungsgrades und Position auf der Helm-Anzeige.
hoch komplett erfüllt
7.1.3 Anforderungen an der Data Receiver Applikation
Anforderung Priorität Status
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
Anforderung Priorität Status
Empfang der Auswertung, GPS-Position und User Identifikation.
hoch komplett erfüllt
7.2 Smart-Helm Applikation
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
7.3 Mobiltelefon-Applikation
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 Smart-Helm Applikation
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
8.2 Mobiltelefon-Applikation
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
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
8 Implementierung
21
Kontaktinfos
Autoren Rajib Mitra Röttelerstrasse 23
4058 Basel +41 61 681 85 13 rajib@gmx.net
Daniel Meyer
Bodenackerstrasse 45
5200 Brugg + 41 78 611 54 00 meyerdaniel.ch@gmail.com
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 beat.schaer@wifag.ch
Projekthomepage http://web.fhnw.ch/technik/projekte/i/fruehling09/MeyerMitra
Copyright by FHNW Windisch, August 2009
8 Implementierung
21
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.
8 Implementierung
21
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.
8 Implementierung
21
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
66
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.2 Smart-Helm Applikation .............................................................................................................. 30
7.3 Mobiltelefon-Applikation ............................................................................................................. 31
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 Smart-Helm Applikation .............................................................................................................. 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 Mobiltelefon-Applikation ............................................................................................................. 46
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
53
9 Testen ..................................................................................................................................55
9.1 Smart-Helm Applikation .............................................................................................................. 55
9.1.1 Medical-Controller.................................................................................................................... 55
9.2 Mobiltelefon-Applikation ............................................................................................................. 56
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
21
9 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.
9.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.
9.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.
21
10 Projektauftrag
10.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.
10.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.
10.3 Anforderungen
Für eine detaillierte Auflistung aller Aufgaben und Anforderungen verweisen wir auf Seite 11ff des
Pflichtenhefts im Anhang.
21
11 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.
21
12 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
12.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
23.04.2009 Meeting mit Prof. Dr. Nouri
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
66
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
21.07.2009 Meeting mit Prof. Dr. Nouri
29.07.2009 Meeting mit Prof. Dr. Nouri
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
12.08.2009 Meeting mit Prof. Dr. Nouri
13.08.2009 Dokumentation abgeschlossen
14.08.2009 Meeting mit Prof. Dr. Nouri
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.
12.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
13 Vorgehensweise
Dieses Kapitel beschreibt das Vorgehen bei der Entwicklung der Erweiterung der Smart-Helm
Applikation sowie der Mobiltelefon-Applikation.
13.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)
13.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.
13.1.2 Analyse- und Designphase (Elaboration)
Während dieser Phase werden die Probleme analysiert und die Architektur erstellt.
5 Vorgehensweise
66
13.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.
13.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
53
13.2 Smart-Helm Applikation
13.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
13.2.1.2 GUI Design
Die Applikation ist wie in Abb. 5: Anordnung der GUI-Elemente aufgebaut.
5) Menu-Liste
6) 3D-Panel
Das Panel stellt den Smart-Helm in drei Dimensionen dar. Innerhalb davon werden Aufschläge simuliert und dargestellt.
7) Tool-Panel
Die Applikation verfügt über eine Reihe von Tools. Das Hinzufügen, Entfernen oder Ersetzen
5 Vorgehensweise
66
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.
8) 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
53
13.3 Mobiltelefon-Applikation
13.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.
13.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
13.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.
13.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
35
14 Technologie
14.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
14.1.2 Entwicklungstools
Name Beschreibung URL Version
Entwicklungstool für Simulator www.eclipse.org 3.4.1
Entwicklungstool für Mobiltelefon Applikation
www.netbeans.org IDE 6.5
14.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
66
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
35
15 Resultat
15.1 Erreichte Ziele
Die folgenden Tabellen geben eine Übersicht über die im Pflichtenheft spezifizierten Anforderungen mit deren Prioritäten und Erfüllungsgrad.
15.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.
hoch komplett erfüllt
Basierend auf der Morphologie des medizinischen Referenzmodelles Entscheidungen über den Verletzungsgrad des Aufpralles treffen.
hoch komplett erfüllt
Übermittlung des Verletzungsgrades an den Smart-Helm. hoch komplett erfüllt
Im Notfall, senden der ausgewerteten Helm-Daten und GPS-Information an eine Notrufzentrale.
hoch komplett erfüllt
Sicherheitsfunktionalitäten stellen sicher, dass die Verbindung zwischen Mobiltelefon und Helm jederzeit aktiv und verfügbar ist.
hoch komplett erfüllt
15.1.2 Anforderungen an den Smart-Helm Simulator
Anforderung Priorität Status
Verbindung zum Mobiltelefon über USB und Bluetooth. hoch Nur Bluetooth
Übermittlung der Positions- und Intensitätsdaten eines Aufschlages an die Mobiltelefon Applikation.
hoch komplett erfüllt
Übermittlung der Positions- und Intensitätsdaten eines Aufschlages durch Bluetooth oder WLAN an diverse Empfänger, ausgestattet mit Smart-Helm Data Receiver Applikation.
hoch komplett erfüllt
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.
hoch komplett erfüllt
7 Resultat
66
Anzeigen des Verletzungsgrades und Position auf der Helm-Anzeige.
hoch komplett erfüllt
15.1.3 Anforderungen an der Data Receiver Applikation
Anforderung Priorität Status
Registrieren beim Smart-Helm Simulator als Empfänger. hoch komplett erfüllt
Empfang der Positions- und Intensitätsdaten. hoch komplett erfüllt
15.1.4 Anforderungen an der Notrufzentrale
Anforderung Priorität Status
Empfang der Auswertung, GPS-Position und User Identifikation.
hoch komplett erfüllt
15.2 Smart-Helm Applikation
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
53
15.3 Mobiltelefon-Applikation
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.
15.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.
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.
Nach Auswahl des gewünschten Gerätes, gelangt man zum nächsten Bildschirm oder per Druck auf „Back“ wieder zurück zum Hauptmenü.
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.
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.
15.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ü.
15.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.
15.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.
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
Communication Smart Helmet -
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
Autoren Rajib Mitra Röttelerstrasse 23
4058 Basel +41 61 681 85 13 rajib@gmx.net
Daniel Meyer
Bodenackerstrasse 45
5200 Brugg + 41 78 611 54 00 meyerdaniel.ch@gmail.com
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 beat.schaer@wifag.ch
Projekthomepage http://web.fhnw.ch/technik/projekte/i/fruehling09/MeyerMitra
Copyright by FHNW Windisch, August 2009
21
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.
21
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.
21
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
66
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.2 Smart-Helm Applikation .............................................................................................................. 30
7.3 Mobiltelefon-Applikation ............................................................................................................. 31
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 Smart-Helm Applikation .............................................................................................................. 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 Mobiltelefon-Applikation ............................................................................................................. 46
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
53
9 Testen ..................................................................................................................................55
9.1 Smart-Helm Applikation .............................................................................................................. 55
9.1.1 Medical-Controller.................................................................................................................... 55
9.2 Mobiltelefon-Applikation ............................................................................................................. 56
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
21
16 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.
16.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.
16.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.
21
17 Projektauftrag
17.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.
17.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.
17.3 Anforderungen
Für eine detaillierte Auflistung aller Aufgaben und Anforderungen verweisen wir auf Seite 11ff des
Pflichtenhefts im Anhang.
21
18 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.
21
19 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
19.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
23.04.2009 Meeting mit Prof. Dr. Nouri
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
66
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
21.07.2009 Meeting mit Prof. Dr. Nouri
29.07.2009 Meeting mit Prof. Dr. Nouri
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
12.08.2009 Meeting mit Prof. Dr. Nouri
13.08.2009 Dokumentation abgeschlossen
14.08.2009 Meeting mit Prof. Dr. Nouri
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.
19.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
20 Vorgehensweise
Dieses Kapitel beschreibt das Vorgehen bei der Entwicklung der Erweiterung der Smart-Helm
Applikation sowie der Mobiltelefon-Applikation.
20.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)
20.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.
20.1.2 Analyse- und Designphase (Elaboration)
Während dieser Phase werden die Probleme analysiert und die Architektur erstellt.
5 Vorgehensweise
66
20.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.
20.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
53
20.2 Smart-Helm Applikation
20.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
20.2.1.2 GUI Design
Die Applikation ist wie in Abb. 5: Anordnung der GUI-Elemente aufgebaut.
9) Menu-Liste
10) 3D-Panel
Das Panel stellt den Smart-Helm in drei Dimensionen dar. Innerhalb davon werden Aufschläge simuliert und dargestellt.
11) Tool-Panel
Die Applikation verfügt über eine Reihe von Tools. Das Hinzufügen, Entfernen oder Ersetzen
5 Vorgehensweise
66
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.
12) 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
53
20.3 Mobiltelefon-Applikation
20.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.
20.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
20.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.
20.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
35
21 Technologie
21.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
21.1.2 Entwicklungstools
Name Beschreibung URL Version
Entwicklungstool für Simulator www.eclipse.org 3.4.1
Entwicklungstool für Mobiltelefon Applikation
www.netbeans.org IDE 6.5
21.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
66
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
35
22 Resultat
22.1 Erreichte Ziele
Die folgenden Tabellen geben eine Übersicht über die im Pflichtenheft spezifizierten Anforderungen mit deren Prioritäten und Erfüllungsgrad.
22.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.
hoch komplett erfüllt
Basierend auf der Morphologie des medizinischen Referenzmodelles Entscheidungen über den Verletzungsgrad des Aufpralles treffen.
hoch komplett erfüllt
Übermittlung des Verletzungsgrades an den Smart-Helm. hoch komplett erfüllt
Im Notfall, senden der ausgewerteten Helm-Daten und GPS-Information an eine Notrufzentrale.
hoch komplett erfüllt
Sicherheitsfunktionalitäten stellen sicher, dass die Verbindung zwischen Mobiltelefon und Helm jederzeit aktiv und verfügbar ist.
hoch komplett erfüllt
22.1.2 Anforderungen an den Smart-Helm Simulator
Anforderung Priorität Status
Verbindung zum Mobiltelefon über USB und Bluetooth. hoch Nur Bluetooth
Übermittlung der Positions- und Intensitätsdaten eines Aufschlages an die Mobiltelefon Applikation.
hoch komplett erfüllt
Übermittlung der Positions- und Intensitätsdaten eines Aufschlages durch Bluetooth oder WLAN an diverse Empfänger, ausgestattet mit Smart-Helm Data Receiver Applikation.
hoch komplett erfüllt
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.
hoch komplett erfüllt
7 Resultat
66
Anzeigen des Verletzungsgrades und Position auf der Helm-Anzeige.
hoch komplett erfüllt
22.1.3 Anforderungen an der Data Receiver Applikation
Anforderung Priorität Status
Registrieren beim Smart-Helm Simulator als Empfänger. hoch komplett erfüllt
Empfang der Positions- und Intensitätsdaten. hoch komplett erfüllt
22.1.4 Anforderungen an der Notrufzentrale
Anforderung Priorität Status
Empfang der Auswertung, GPS-Position und User Identifikation.
hoch komplett erfüllt
22.2 Smart-Helm Applikation
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
53
22.3 Mobiltelefon-Applikation
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.
22.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.
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.
Nach Auswahl des gewünschten Gerätes, gelangt man zum nächsten Bildschirm oder per Druck auf „Back“ wieder zurück zum Hauptmenü.
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.
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.
22.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ü.
8 Implementierung
117
22.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.
22.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.
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
23.1 Smart-Helm Applikation
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
23.2 Mobiltelefon-Applikation
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