BIOcomfort Health Assistant for Android Plattform

Transcription

Fakultät für Elektrotechnik und Informationstechnik
Fachgebiet Verteilte Multimodale Informationsverarbeitung
Prof. Dr. Matthias Kranz
BIOcomfort Health Assistant for Android
Plattform
Andreas Wallner
Studienarbeit
Verfasser:
Andreas Wallner
Anschrift:
Matrikelnummer:
Professor:
Prof. Dr. Matthias Kranz
Betreuer:
Dipl.-Ing. Luis Roalter
Beginn:
01.10.2011
Abgabe:
31.03.2012
Kurzfassung
Diese Studienarbeit befasst sich mit der Untersuchung verschiedener mobiler Health Manager Systeme. Ein solches System ermöglicht es dem Benutzer, Vitaldaten von bevorzugt mobilen Sensoren
aufzunehmen. Dabei liegt der Schwerpunkt auf den Systemen, welche möglichst mit existierenden Smartphones funktionieren. Auf dem Markt exisitieren bereits verschiedene Sensoren, von
denen Vitaldaten digital abrufbar sind. Diese Sensoren sind jedoch nicht durchgehend kompatibel
und verwenden verschiedenste Technologien und Übertragungsstandards. Als Schnittstelle zum
Datenempfang am Endgerät werden dabei oft USB-Dongles eingesetzt.
Das erste Ziel dieser Arbeit liegt darin, prorietäre Hardware in Form von USB-Dongles über
die meist am Smartphone vorhandene USB-Schnittstelle (über OTG) anzubinden. Damit ist es
möglich existierende Systeme auch für Smartphones zu verwenden.
Ein mobiles Health Manager System sollte sich deshalb nicht auf einzelne Standards und Hersteller
beschränken, sondern offen, flexibel und erweiterbar sein. Außerdem sollen empfangene Vitaldaten
einfach an andere berechtigte Dienste und Applikationen weitergereicht werden können. Derzeit
vorhandene Systeme erfüllen die genannten Anforderungen nicht vollständig.
In dieser Arbeit wird nun der Biocomfort Health Assistant für Android vorgestellt, welcher versucht
diese Anforderungen zu erfüllen. Da diese Anwendung zum Datenempfang immer verfügbar sein
muss, läuft diese im Hintergrund und besitzt deshalb keine grafische Benutzeroberfläche. Zur
Visualisierung wurde zudem eine Beispiel-Applikation erstellt, welche die empfangenen Vital- und
Gerätedaten darstellen kann.
ii
Abstract
This thesis addresses the examination of various mobile health manager systems. Such a system
enables the user to gather vital data from preferred mobile sensors. Thereby the focus is on systems, which work with existing smartphones. Miscellaneous sensors already exist on the market,
on which vital data can be retrieved digitally. However, those sensors are not throughout compatible und use various technologies and transmission standards. Thereby oftenly USB dongles are
used as interface for receiving data.
The first goal of this thesis lies in linking proprietary hardware in terms of USB dongles to the
mostly available USB port (via OTG). So it is possible to use existing systems also for smartphones.
A mobile health manager system should not be limited to single standards or manufacturers, but
open, flexible and expandable. Besides, it should be possible easily to share received vital data
with other authorized services and applications. Presently available Systems do not completely
fulfill the mentioned specifications.
This thesis introduces the Biocomfort Health Assistant for Android, which attempts to meet
those requirements. Given that the application must be available all the time it is running in the
background and has no graphical user interface. Additionally an application to visualize received
vital and device data was created.
iii
Inhaltsverzeichnis
Inhaltsverzeichnis
iv
1 Einführung
1
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Healthmanager
3
2.1
Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Vorhandene Softwarelösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Garmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.2
Ubiquitous Personal Health Surveillance and Management System . . . .
4
2.2.3
ECG Monitoring System mit mobilem Barcode-Decoder . . . . . . . . . .
5
2.2.4
Blutdruck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.5
Blutdruck Logbuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.6
WiThings WiScale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Biocomfort Health Manager Plattform . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.1
Messgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.2
Biocomfort Health Manager Software Development Kit . . . . . . . . . .
8
2.3
3 Applikationsentwicklung unter Android
3.1
3.2
3.3
10
Android-Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.1
Das Betriebssystem Android . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.2
Android-Applikationen
. . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Applikationsspezifische Vorbereitungen am Gerät . . . . . . . . . . . . . . . . .
14
3.2.1
Rooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2.2
Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Geräte- und Applikationssetup . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.1
Gerätesetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.2
Applikationssetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4 Android Implementierung
4.1
20
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
20
v
INHALTSVERZEICHNIS
4.2
4.3
4.4
Implementierung Biocomfort Health Assistant für Android . . . . . . . . . . . .
21
4.2.1
Service Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.2
GUI Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.2.3
MockSDK Gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3.1
Android Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3.2
Biocomfort Resourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Beschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.4.1
Stabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.4.2
Mobilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.4.3
Funktionsumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.4.4
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.4.5
Bediencomfort und Akzeptanz . . . . . . . . . . . . . . . . . . . . . . .
33
5 Zusammenfassung und Ausblick
34
5.1
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.2
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.2.1
Hardware
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.2.2
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
Abbildungsverzeichnis
39
Literaturverzeichnis
40
Kapitel 1
Einführung
Die Arbeit wurde im Fachgebiet Verteilte Multimodale Informationsverarbeitung (VMI) der Technischen Universität München verfasst. Sie beschäftigt sich mit der Entwicklung eines Health
Manager Systems für die Android Smartphone-Plattform. Dabei werden anfangs vorhandene Implementierungen untersucht.
In dieser Einleitung wird zunächst die Motivation der Arbeit erläutert, danach der Aufbau der
Arbeit angegeben.
1.1 Motivation
Die Überwachung von persönlichen Gesundheitsdaten, wie Blutdruck, Blutzucker und anderen
Vitalwerten im Alltag wird immer häufiger eingesetzt. Besonders aussagekräftig sind Messdaten,
wenn sie regelmäßig, sowie auch langfristig aufgenommen werden. Um solche Messungen zu
verwalten, kann ein Rechner mit einer entsprechender Software verwendet werden, der die Daten
speichert und bei Bedarf weitergibt.
Hier ist es praktisch, statt eines Personal Computers (PC) oder Laptops ein Smartphone, wie z.B.
ein Android-Mobiltelefon zu verwenden. Mobiltelefone sind im Idealfall immer für den Benutzer
verfügbar, deshalb kann durch Erinnerungsfunktionen die regelmäßige Vitalwertsmessung unterstützt werden. Dies ermöglicht es die gemessenen Daten sofort zu archivieren und visualisieren.
Da Smartphones über eine permanente Internetverbindung verfügen, können die gemessenen Daten außerdem standortunabhängig an Sachverständige verschickt werden. Das hat z.B. am Telefon
den Vorteil, sofort unabhängige Meinungen unter Berücksichtigung eines Werteverlaufs zu erhalten oder Hilfe verständigen zu können. Auch für ältere oder pflegenbedürftige Menschen ist eine
derartige Datenaufnahme per Mobiltelefon eigenständig durchführbar. Bei Problemen kann die
Bedienung durch Verwandte oder Pfleger unterstützt werden.
Ein weiterer Vorteil der Messung am Smartphone ist die ständige Präsenz der Gesundheitsdaten,
die gesundheitswirksame Aspekte wie z.B. sportliche Betätigung oder gesunde Ernährung sichtbar
1
Kapitel 1 Einführung
2
machen können. Außerdem ist es möglich, Daten gezielt mit einem Mobile Personal Trainer zu
teilen, um Trainingseinheiten gezielt auf persönliche Sequenzen abzustimmen. Somit können z.B.
bei zu hohem Blutdruck entsprechende Trainings empfohlen oder bei schlechten Blutzuckerwerten
passende Ernährungstips gegeben werden. Eine ständige Erinnerung kann das Gesundheitsbewusstsein im Positiven beeinflussen, Erfolge und Misserfolge eine motvierende Wirkung erzeugen.
Dies kann durch den Vergleich mit alten Messdaten oder auch mobil mit anderen Benutzern
erfolgen, was somit auch einen sozialen Aspekt bieten kann.
Beim mobilen Einsatz ist nun eine drahtlose Übertragung der Messdaten sinnvoll. Smartphones
besitzen intern diverse Schnittstellen zur Drahtloskommunikation mit mobilen Sensoren. Aufgebaut wird eine Verbindung oft über WLAN, Bluetooth und Infrarot, außerdem werden teilweise
auch proprietäre Standards wie ANT/ANT+ unterstützt. Um Schnittstellen verwenden zu können, die vom Chip nicht direkt unterstützt werden, können diese per USB-Anschluss nachgerüstet
werden. Um USB-Peripheriegeräte als USB Slave Geräte verwenden zu können, muss die Firmware
des Telefons mit USB-Anschluss den USB On The Go Modus unterstützen. Dies ermöglicht, die
Applikation am Mobiltelefon ortsunabhängig zu nutzen.
1.2 Aufbau der Arbeit
Die Arbeit beginnt mit der Analyse aktueller Health Manager Systeme. Dabei werden sowohl
Geräte als auch bestehende Softwaresysteme erläutert. Außerdem wird das Biocomfort Health
Manager SDK vorgestellt.
In Kapitel 3 wird zunächst der Aufbau des Android-Systems und dessen Applikationen erklärt.
Dann wird die Konfiguration und Einrichtung des Health Manager Systems erläutert, wozu Änderungen am System vorgenommen wurden.
In Kapitel 4 wird dann die entwickelte Implementierung vorgestellt. Dabei wird deren grundlegender Aufbau, wie auch Besonderheiten beschrieben. Abschließend werden in Kapitel 5 Ergebnisse
zusammengefasst und mögliche Erweiterungen vorgestellt.
Kapitel 2
Healthmanager
Im hektischen Alltag nimmt bei vielen Menschen die persönliche Gesundheit nur noch eine
nachrangige Rolle ein. Bei immer mehr Menschen diagnostiziert der Arzt Berufskrankheiten [1]
und Herzkrankheiten [2]. Eine Überwachung der persönlichen Gesundheit erfolgt oft erst, wenn
schwerwiegende Symptome auftreten. Unter anderem viele Herz- und Zuckerkranke benutzen
deshalb tragbare Sensoren, um gewünschte Werte jederzeit messen zu können. Dabei existiert
jedoch eine große Zahl von Geräten von unterschiedlichen Herstellern. Gemessene Daten sind bei
einer größeren Palette von Sensoren entsprechend verstreut und damit schwierig zu verwalten.
Health Manager Systeme versuchen dieses Problem zu lösen, und bilden somit eine zentrale Instanz für persönliche Gesundheitsdaten. Solche Systeme ermöglichen dem Benutzer, jederzeit
seine Vitalwerte zu überwachen. Dies kann damit sowohl im Krankheitsfall, als auch vorbeugend
erfolgen.
Dabei werden in diesem Kapitel zunächst Eigenschaften von Health Manager Systemen genannt.
Unter Abschnitt 2.2 werden dann vorhandene Softwarelösungen für Health Manager Systeme
erläutert. Zuletzt wird in Abschnitt 2.3 die Biocomfort Health Manager Plattform vorgestellt.
2.1 Eigenschaften
Um persönliche Gesundheitsdaten aufzunehmen, können im privaten Bereich tragbare Sensoren
verwendet werden.
Diese oft sehr günstigen Geräte besitzen meist nur schlechte Darstel-
lungsmöglichkeiten, begrenzten Speicherplatz und keine Sicherung gegen Geräteverlust oder Defekt.
Deshalb ist es wünschenswert, aufgenommene Daten zu einem zentralen Datenspeicher zu transferieren. Der Datentransfer kann kabelgebunden oder drahtlos erfolgen. Diese Rolle nimmt der
sogenannte Health Manager ein, einer auf einem Rechner installierten Software-Platform. Als
ganzheitliches System versucht der Health Manager möglichst alle gesundheitsrelevanten Vital-
3
4
Kapitel 2 Healthmanager
werte zu erfassen. Dies hat den Vorteil, dass eventuelle Parallelen zwischen verschiedene Werten
erkannt werden können. Außerdem kann auch der Messwertverlauf über kürzere oder längere
Zeiträume dargestellt werden. Dieser ist meist wichtiger als Einzelwerte.
Einem Datenverlust kann durch Synchronisation mit Onlinediensten vorgebeugt werden. Dies
hat außerdem den Vorteil, dass Daten von überall abrufbar sind. Da so gemessene Daten leicht
an andere Instanzen, also z.B. Ärzte oder Therapeuten, weitergegeben werden können, ist eine
deratige Datenaufnahme Grundlage für Telemedizin. Im Folgenden werden zunächst existierende
Lösungen beschrieben, dann die Biocomfort Health Manager Plattform vorgestellt.
2.2 Vorhandene Softwarelösungen
Sowohl für Smartphone als auch am PC existiert bereits eine sehr große Zahl von Health Manager Applikationen. Im folgenden werden einige ausgewählte unter Android lauffähige Systeme
vorgestellt und deren Merkmale genannt.
2.2.1 Garmin
Die Trainingsdaten- und Healthmanagerplattform Garmin Connect ist auf Fitnesstraining
fokussiert.
Die Daten werden vom jeweiligen Fitness- oder Medizinmessgerät hochgeladen
und online gespeichert.
Hier können per Webinterface die Daten graphisch analysiert und
Trainingspläne erstellt werden. Geplant werden können auch Lauf- oder Fahrradstrecken, sowie
Trainingsziele und andere Aktivitäten. Momentan existieren diverse Trainingsgeräte, sowie als
medizinisches Messgerät eine Waage. Außer durch hochladen können Vitalwerte auch manuell
eingegeben werden. Mit Garmin Fit existiert auch eine Applikation für Android, die Daten von
Garmin Connect anzeigen kann.
2.2.2 Ubiquitous Personal Health Surveillance and Management System
Das Ubiquitous Personal Health Surveillance and Management System
[3] ist ein
Healthmanagement-System für Android-Mobilgeräte, das Gesundheitsdaten von drahtlosen
Sensoren empfängt. Dies erfolgt über einen ZigBee-Empfänger, der entweder über USB oder
Bluetooth die Daten an das Smartphone weiterleitet.
Die empfangenen Daten werden dabei verschlüsselt über die Internetverbindung des Smartphones
zu einem zentralen Datenspeicher übertragen.
Um die gespeicherten Serverdaten zu teilen,
kann man Berechtigungen an zugelassene Personen wie Ärzte, Verwandte, Freunde und Pfleger
vergeben. Außerdem werden bei Überschreitung gesundheitskritischer Grenzwerte automatisch
Alarmmeldungen versandt, versehen mit entsprechenden Standortdaten des Smartphones.
5
Als systemkompatible Sensoren werden verschiedene gewerblich erhältliche Sensoren genannt.
Das sind sowohl ein Sensor für Elektrokardiogramme, Elektromyographien und Elektroenzephalografien, die Aktivität von Herz, Gehirn und Muskeln messen. Außerdem kann ein Blutzucker-,
Blutdruck- sowie ein Atmungssensor verwendet werden.
Auf dem Smartphone besteht keine Möglichkeit zur Visualisierung der Daten, dies geschieht dann
am Rechner, der UPHSM Agent dient lediglich zur Datenaufnahme und Datenübergabe. Außerdem ist eine Weiterleitung der Vitaldaten an kompatible Applikationen direkt am Smartphone so
nicht vorgesehen. Das UPHSM ist somit vornehmlich an pflegebedürftige, chronisch Kranke und
Senioren gerichtet.
2.2.3 ECG Monitoring System mit mobilem Barcode-Decoder
Abbildung 2.1: ECG Monitoring Applikation [4]
Weiterhin bieten P. Cheng und W. Chung [4] ein Ubiquitous Healthcare System für die Android
Plattform an. Das System fokussiert sich auf die Aufnahme und Analyse elekotrokardiographischer
Daten unter der Verwendung eines Wireless Sensor Networks (WSN).
Der im Brustgürtel des Health Shirt enthaltene ECG-Sensor überträgt die Daten drahtlos unter
Verwendung des Standard IEEE 802.15.4. Die Empfangsstation am Mobiltelefon ist als Wireless
Dongle ausgeführt und wird über ein serielles RS-232 Communication Interface verbunden.
In einer grafischen Android-Anwendung werden die empfangenen Messdaten, wie in Abbildung 2.1
zu sehen, angezeigt. Die Übertragung und Anzeige geschieht in Echtzeit, außerdem kann zwischen
bloßer Darstellung der Wellenform und Datenanalyse gewählt werden.
Das System bietet weiterhin mit der Personalied Medicine Care Assistance einen personalisierten
QR-Code Scanner speziell für Medikationen an. Entsprechend an der Medikation angebrachte
Codes kann man dabei über die im Mobiltelefon integrierte Kamera dekodieren und somit identifizieren. Durch Verlinkung auf die entsprechende Url werden auch nichtvisuelle Inhalte wie
6
Audiodateien dargestellt. Dies kann eine hilfreiche Stütze für Blinde oder visuell eingeschränkte
Menschen sein.
Mit dem ECG als derzeit einzigem Sensor ist das System vornehmlich zur Vorbeugung von
Herzkrankheiten und für chronisch Kranke interessant. Um ein ganzheitlicheres System zu bieten,
sollten noch weitere Sensoren verfügbar gemacht werden.
2.2.4 Blutdruck
Die Applikation Blutdruck [5] dient vornehmlich der Visualisierung und Speicherung von Blutdruckwerten.
Dabei müssen gemessene Daten manuell am Smartphone eingegeben werden.
Berichte können im Tabellenformat via Email an den Hausarzt übermittelt werden. Außerdem
ist es mit dieser Applikation möglich die Daten statistisch auszuwerten. Zusätzlich existiert eine
Erinnerungsfunktion, die regelmäßige Messungen unterstützt. Die Applikation ist dabei jeweils
als Lite- und Vollversion erhältlich. Ein Funktion zur direkten Datenaufnahme von drahtlosen
Sensoren ist nicht vorhanden.
2.2.5 Blutdruck Logbuch
Ähnlich wie die Blutdruck-Applikation Blutdruck aus Abschnitt 2.2.4 müssen auch im BlutdruckLogbuch [6] Daten manuell eingegeben werden. Bei einer Messung werden dabei neben Messdaten
und Messzeit auch der Messort abgespeichert. Außerdem ist es auch möglich Herzfrequenz und
Gewicht hinzuzufügen. Die Datenexportfunktion unterstützt verschiedene Formate und kann zur
Darstellung der Vitaldaten in Fremdprogrammen genutzt werden. Eine kostenpflichtige Pro Version bietet zusätzlich weitere Analysetools für die Messdaten.
2.2.6 WiThings WiScale
Die Applikation WiThings WiScale [7] ermöglicht es, Vitaldaten einer Personenwaage zu empfangen und darzustellen. Bei der Messung wird dabei auch das Verhältnis zwischen Fett- und
Muskelmasse bestimmt. Dabei werden der Body Mass Index (BMI) berechnet und Orientierungsbereiche angezeigt. Die Messwerte werden unter Nutzung von IEEE 802.11b/g per Wlan übertragen. Die Waage beherrscht die Verschlüsselungsmethoden WEP, WPA und WPA2-personal.
Nach der Speicherung am Smartphone können die Daten entweder über eine Website oder direkt
auf dem Onlinedienst Twitter veröffentlicht werden. Neben der Android-Applikation existiert auch
entsprechende Software für Mac, PC, iPhone oder iPad.
7
2.3 Biocomfort Health Manager Plattform
Nach den bisher genannten Health Manager Lösungen wird nun auf die Biocomfort Health Manager Plattform eingegangen. Biocomfort bietet mit der Health Manager Plattform ein umfassendes
System zur Erfassung von Gesundheitsdaten an. Dieses besteht aus einer Familie von Messgeräten
zur Aufnahme und Softwareprogrammen- und Diensten zur weiteren Verarbeitung der medizinischen Messdaten. Zur drahtlosen Datenübertragung mit dem IEEE 802.15.4 Standard wird ein
Wireless Gateway genutzt.
Biocomfort bietet dabei im Gegensatz zu allen anderen Lösungen offene Programmierschnittstellen
an. Mit diesen Programmierschnittstellen, dem Biocomfort Health Manager SDK, können variabel
Benutzerprogramme für verschiedene Plattformen erstellt werden. Dieses SDK wurde bei der
Entwicklung des Biocomfort Health Assistant für Android genutzt.
2.3.1 Messgeräte
Abbildung 2.2: Wireless USB-Dongle zum mobilen Datenempfang, Blutdruckmessgerät zur Messung am Handgelenk, Blutzuckermessgerät mit mitgelieferter Einstichhilfe zur hygienischen Messung, sowie Diagnosewaage zur Bioelektrischen Impedanzanalyse
Zur Messung von Vitaldaten sind unter der Biocomfort Health Manager Plattform verschiedene
Mobilsensoren zur Datenaufnahme verfügbar.
Dies sind derzeit sowohl ein Blutdruck- und
Blutzuckermessgerät, sowie eine Diagnosewaage zur Bioelektrischen Impedanzanalyse. Den Messgeräten liegt ein einheitliches Bedienkonzept zugrunde, das die Bedienung für den Erstbenutzer
vereinfacht. Alle Geräte besitzen ein LCD-Display zur Darstellung von Geräte-, Mess- und Benutzerdaten. Messdaten können dort einzeln oder als Durchschnittswert für 7, 14, 21 oder 28 Tage
dargestellt werden. Bei überhöhten Werten werden nach der Messung Warnungen am jeweiligen
Messgerät ausgegeben. Zur Verwaltung von Messwerten für verschiedene Personen können bis zu
8 verschiedene Benutzerprofile auf den Geräten erstellt werden. Die Messwerte werden jeweils bei
der Messung mit einem Zeitstempel und entsprechender Benutzernummer versehen.
8
Blutdruckmessgerät
Die Blutdruckmessung mit dem tenso-comfort Blutdruckmessgerät erfolgt im oszillometrischen
Messverfahren am Handgelenk. Dabei pumpt das Gerät bei der Messung automatisch Luft zu
oder ab. Der intere Messwertspeicher kann mehr als 112 Messungen abspeichern. Ein einzelner
Messwert besteht dabei (neben Zeitstempel und Benutzernummer) je aus systolischem Blutdruck,
diastolischem Blutdruck sowie dem gemessenen Puls. Bald ist alternativ auch ein Sensor zur
Blutdruckmessung am Oberarm erhältlich.
Blutzuckermessgerät
Das gluco-comfort Blutzuckermessgerät bestimmt den quantitativen Blutzuckerwert im amperometrischen Messverfahren.
Zur hygienischen Gewinnung eines Blutstropfens ist neben dem
eigentlichen Messgerät eine Stechhilfe mit austauschbaren Einstichnadeln vorhanden. Die Messung
erfolgt durch Einführung von Messstreifen und dauert etwa 10 Sekunden. Der interne Messwertspeicher von gluco-comfort reicht für 122 Messungen.
Diagnosewaage
Die scaleo-comfort Diagnosewaage nimmt bei der Messung neben dem Gewicht weitere Vitalwerte auf. In der Bioelektrischen Impedanzanalyse werden über den Wiederstandswert Körperfett,
Körperwasser und Muskelmasse bestimmt. Diese sind für die Ermittlung eines aussagekräftigeren
Gewichtswertes nützlich, da z.B. durch Wasseraufnahme bzw. Abgabe die Körpermasse verfälscht
wird. Gespeichert werden können bis zu 44 Messungen, der Messbereich bewegt sich zwischen 10
und 150 kg.
2.3.2 Biocomfort Health Manager Software Development Kit
Für vergleichbare Peripheriegeräte mit Softwareanbindung, wie die drahtlosen Messgeräte von
Biocomfort, wird zur Datenaufnahme und Kommunikation lediglich ein proprietäres Softwarepaket
angeboten. Derartige Softwarepakete sind oft auf wenige Plattformen und auf Peripheriegeräte
der beteiligten Partner beschränkt. Dadurch ist die Integration von Hardwarekomponenten Dritter
nicht möglich, was eine Einschränkung auf Geräte des Herstellers bedeutet.
Als Alternative dazu werden von Biocomfort öffentliche Programmierschnittstellen in Form des
Health Manager Software Development Kit angeboten. Diese sind in den auf vielen Plattformen
verbreiteten Programmiersprachen C und Java vorhanden. Das SDK bietet dabei Funktionen zur
Kommunikation mit den Medizingeräten. Damit können Geräte- und Messdaten abgerufen werden.
Außerdem werden weitere Daten, wie z.B. Informationen bei Übertragungsfehleren oder anderen
9
Problemen, weitergeleitet. Darüberhinaus kann über das SDK die Konfiguration der Medizingeräte
eingestellt,der interne Gerätespeicher gelöscht oder die Gerätezeit verändert werden.
Die Dokumentation zum SDK ist online abrufbar, außerdem sind nach Registrierung Beispielprogramme verfügbar. Auf der Basis dieser Schnittstellen wird die Implementierung einer Softwarelösung unter Android ermöglicht.
Kapitel 3
Applikationsentwicklung unter Android
In diesem Kapitel werden Grundlagen für die Entwicklung und den Aufbau von AndroidSmartphones beschrieben. Weiterhin wird auf Eingriffe ins Android-System eingegangen, die
speziell für die entwickelte Anwendung erforderlich waren.
3.1 Android-Smartphones
Smartphones sind weltweit immer weiter verbreitet [8]. Durch die Übernahme von Android Inc.
im Jahr 2005 stieg auch Google in diese Branche ein. 2007 gründete Google zusammen mit
mehreren Hardware- und Softwareanbietern, sowie Mobilfunkpartnern, die Open Handset Alliance.
Diese veröffentlichte am 1. Oktober 2008 das unter der Federführung von Google entwickelte
Smartphone-Betriebssystem Android. Das Android-Betriebssystem (fortan “Android” genannt)
steht unter der quelloffenen Apache-Lizenz. Neben dem Betriebssystem stellt Google das Android
Software Development Kit (SDK) und das Android Native Development Kit (NDK) bereit. Das
SDK bietet neben einer Reihe von Entwicklungstools eine in Java implementierte Programmierschnittstelle (Application Programming Interface - API). Zusätzlich dazu können Applikationen
mit dem NDK um Nativen Code ergänzt werden. Android-Mobiltelefone werden derzeit von
Smartphone-Herstellern wie Samsung, HTC, LG, Dell, außerdem von Google selbst in Kooperation mit anderen Herstellern, angeboten. In den USA machen Android-Mobiltelefone derzeit
knapp mehr als die Hälfte des Smartphone-Marktes aus [9].
3.1.1 Das Betriebssystem Android
Das Betriebssystem Android kann in folgende Komponenten unterteilt werden: Kernel, Bibliotheken, Laufzeitumgebung, Application Framework und Anwendungen. Dieser Aufbau ist in Abbildung 3.1 dargestellt.
10
Kapitel 3 Applikationsentwicklung unter Android
11
Abbildung 3.1: Architektur des Android-Betriebssystems
Kernel
Der Android-Kernel basiert auf Mainline-Linux [10] und kann als GPLv2-Software [11] frei
heruntergeladen [12] und modifiziert werden. Der Kernel ist dabei für die Speicherverwaltung,
Prozessverwaltung, Sicherheit, Lastverteilung und E/A-Operationen zuständig. Der Kernel stellt
außerdem als unterste Schicht Treiber zur Einbindung von Hardware zur Verfügung.
Bibliotheken und Laufzeitumgebung
Die Standardbibliotheken des Systems sind in C/C++ geschrieben und bilden zusammen mit
der Android-Laufzeitumgebung die Schicht oberhalb des Kernels. Diese Bibliotheken werden
12
zur Beschleunigung rechenintensiver Anwendungen von höher gelegenen Schichten aufgerufen.
Rechenintensive Anwendungen sind z.B. das Abspielen von Medien, Seitenrendering im Web oder
beschleunigte 3D-Anwendungen.
Statt der regulären C-Standardbibliothek wird eine für Android optimierte Version eingesetzt.
In der Android-Laufzeitumgebung findet sich neben den Java-Standardbibliotheken die Dalvik
Virtual Machine (VM). Diese registerbasierte Virtuelle Maschine ersetzt die Standard Java VM.
Durch die hardwarespezifische Optimierung des Java-Bytecodes ist die Ausführung mehrerer VMInstanzen resourcenschonender und benötigt weniger Speicher als die Java VM.
Android Application Framework
Das Android Application Framework bildet einen Satz von Systemkomponenten, die zur Anwendungsentwicklung genutzt werden. Diese liegen als Klassenbibliotheken in der Programmiersprache
Java vor. Enthalten sind unter anderem Klassen für GUI, Datenaustausch, Einbindung von Resourcen, Systemdienste und Hardwarekomponenten.
Applikationen
Anwendungen bilden die für den Benutzer sichtbare höchste Schicht im Betriebssystem. Als
Zugriffsschutz zwischen Anwendungen wird für jede neue Anwendung ein neuer Benutzer erstellt.
Applikationen werden normalerweise in Java entwickelt, können jedoch auch mit C/C++-Code
ergänzt werden. Mit Android Lighthouse [13] existiert auch die Möglichkeit, native Applikationen
mit Qt/C++ zu erstellen.
3.1.2 Android-Applikationen
Der Android Application Framework stellt einige Grundkomponenten zur Applikationserstellung
und Android bereit. Hier werden einige ausgewählte erklärt.
Activities
Eine Activity ist eine Komponente der Benutzeroberfläche. Normalerweise repräsentiert eine Activity eine einzelne Bildschirmseite der Applikation. Diese beinhaltet einzelne User Interface (UI)
Elemente, über die der Benutzer mit der Applikation interagieren kann. Der sichtbare Teil der Anwendung besteht aus Activities, zwischen denen man während der Ausführung wechseln kann. Für
jede Anwendung ist zwar eine Einstiegs-Activity definiert, im Gegensatz zu Desktopanwendungen
13
gibt es jedoch keine Main-Funktion. Jede Activity kann über Intents von anderen Anwendungen
aufgerufen werden, sofern diese die entsprechende Berechtigung besitzt.
Services
Zur Ausführung von Aufgaben im Hintergrund kann ein Service definiert werden. Rechenintensive
Prozesse können hier ausgelagert werden, um das UI nicht zu blockieren. Services werden nach
Beendigung der Anwendung, die ihn startete, nicht gestoppt. Es wird zwischen Started Services
und Bound Services unterschieden.
Started Der Started Service wird von einer Applikation gestartet und arbeitet, bis er die ihm
übergebene Aufgabe erfüllt hat. Er übergibt dabei keinen Rückgabewert. Ergebnisse können z.B.
über Broadcasts versendet werden.
Bound Wenn sich eine Anwendung mit einem Started Service verbindet spricht man von einem
Bound Service. Diese Client-Server Verbindung ermöglicht eine zweiseitige Kommunikation. Auch
applikationsfremde Services oder Activities können sich so mit dem Service verbinden und Daten
mit ihm austauschen.
Intents
Intents sind Nachrichten, die zum Starten von Activities und Services vom System oder von Anwendungen verschickt werden. Es ist möglich, serialisierte Anwendungsdaten an diese anzuhängen. Intents können sowohl Komponenten der eigenen Anwendung als auch externe Komponenten
starten. Somit können anwendungsfremde Komponenten in die eigene Applikation eingebaut werden, ohne diese neu zu implementieren. Zum Export kann man mit Intent-Filtern dem System
mitteilen, welche Intents durch die Applikation bearbeitet werden können.
AIDL-Interfaces
Das Android Interface Definition Language (AIDL) erlaubt es eine Programmierschnittstelle zu
erstellen, auf die sich sowohl Client, als auch Server einigen, um mit IPC miteinander zu kommunizieren. In AIDL-Dateien können Remote Procedure Calls (RPCs) vereinbart werden, die von
einem Client aus aufgerufen werden können.
14
Resourcen
Resourcen werden zur deklarativen Gestaltung bestimmter Anwendungskomponenten verwendet.
Android kennt verschiedene Arten von Resourcen, meist in XML-Dateien formuliert, die die Programmierung und Wiederverwendbarkeit des Codes steigern sollen.
Android bietet unter anderem Resourcen für Animationen, Farbdefinitionen, Rastergrafiken, Layouts, Menüs, Strings und Styledefinitionen. Auch ist es möglich, benutzerdefinierte Resourcen,
sog. RAW-Resourcen, einzubinden.
Manifest
Android summiert alle anwendungsrelevanten Eigenschaften in einer XML-Datei. Diese Datei wird
Manifestdatei (AndroidManifest.xml) der Anwendung genannt.
In dieser werden Activities, Services und weitere Komponenten registriert und Berechtigungen
deklariert. Zusätzlich können hier die Eigenschaften der Anwendung selbst oder auch ihrer Komponenten (Activity oder Services) festgelegt werden. So kann z.B. eingestellt werden, ob die
Anwendung den vollen Bildschirm benutzt (Fullscreen), oder Hardwarebeschleunigung benötigt.
3.2 Applikationsspezifische Vorbereitungen am Gerät
Generell ist der Biocomfort Health Assistant für Android unter jeder Android Plattformversion und
jedem Androidgerät lauffähig, jedoch unter einigen Vorraussetzungen. Momentan ist die Applikation auf API-Version 14 und neuer (entsprechend Plattformversion 4.0 und späteren) beschränkt.
Um frühere Android-Versionen verwenden zu können, müssen vorhandene C-Bibliotheken von Biocomfort für die entsprechende Hardware kompiliert werden. Außerdem muss der Kernel des Geräts
die Biocomfort-Hardware in Form des USB-Gateways unterstützen. Damit ist das Vorhandensein
entsprechender Treiber und Treibermodi erforderlich. Der größte Teil der Entwicklung erfolgte
neben anfänglichen Tests im Emulator am Samsung Nexus S, das alle besagten Vorraussetzungen
erfüllt.
3.2.1 Rooting
Android benutzt das Rechtemanagement des Linux-Kernels applikationsbezogen, d.h. für jede
Applikation wird bei der Installation ein neuer User erstellt. Die Applikation kann somit nur auf
applikationseigene, nicht jedoch auf Systemdaten, oder die Daten anderer Applikationen zugreifen.
Die Kommunikation zwischen Applikationen erfolgt über Schnittstellen des Android Application
Framework. Nun existiert unter unixoiden System neben normalen Usern immer auch ein User, der
15
Berechtigungen hat auf alle Dateien zuzugreifen. Bei den meisten Desktop-Linuxdistributionen
ist der Zugriff auf Systemadministratorrechte über Dienstprogramme wie su oder sudo möglich.
Unter Android jedoch ist der Root User in Standardkonfiguration deaktiviert.
Im normalen Betrieb ist das Rooten des Telefons nicht erforderlich, außerdem ein erhebliches
Sicherheitsrisiko. Einerseits besteht dabei die Gefahr, dass das System durch Eingriffe unbenutzbar
wird. Andererseits kann die Sicherheit der in Applikationen gespeicherten Benutzerdaten nicht
mehr garantiert werden. Beim Rooten erlischt meist die Herstellergarantie, somit ist bei NichtEntwicklungsgeräten davon abzuraten.
Das Rooting ist bei der Entwicklung in vielerlei Hinsicht nützlich, als auch erforderlich. Einige
Applikationen können erst nach erfolgtem Rooting genutzt werden. Darüberhinaus kann mit Administratorrechten auch per Shell auf Applikationsdaten, wie im hier beschriebenen Anwendungsfall,
z.B. der Zugriff auf SQLite-Messwertdatenbanken zugegriffen und diese zu Debugging-Zwecken
inspiziert werden. Nur bei erfolgtem Rooting kann außerdem auf Gerätedateien zugegriffen werden,
Rechte geändert oder Dateisysteme ein- und ausgehängt werden.
Bei Entwicklung des Biocomfort Health Assistant war das Rooting aus verschiedenen Gründen
erforderlich. Zunächst mussten Konfigurationsdateien auf der Systempartition eingespielt werden.
Außerdem wurde dort auch das FTDI-Kernelmodul abgelegt, um dies beim Systemstart automatisch zu laden. Weiterhin war es nötig, Geräteknoten neu zu erstellen und zu verlinken. Ohne
Root-Rechte ist außerdem kein Wireless Debugging möglich, was die Entwicklung sehr stark behindern würde. Am wichtigsten jedoch werden die Root-Rechte bei der Nutzung von USB-On-the-go
(USB-OTG). Da der benutzte Treiber nicht automatisch zwischen Client und On-the-go Modus
umschalten kann, muss dies als Root manuell erledigt werden.
Für verschiedene Geräte existieren verschiedene Methoden zum Rooten. Eine Möglichkeit wäre
z.B., eine modifizierte Firmware mit Rootrechten zu flashen. Beim Nexus S ist die einfachste
Methode, ein Recoveryprogramm zu installieren, über das manuelle Systemupdates eingespielt
werden können. Als Recoverytool dient meist ClockworkMod (siehe Abbildung 3.2), über das ein
Superuser-Paket installiert wird.
3.2.2 Kernel
Die gesamte Gerätekommunikation erfolgt bei Android als linuxbasiertem System über Treiber im
Linuxkernel. Da der Linuxkernel eine große Masse von Hardware unterstützt, würde die Größe des
Kernels bei der Integration aller Treiber sehr stark anwachsen.
Deshalb können Treiber über sog. Module aus dem Kernel ausgelagert werden, die erst im laufenden Betrieb geladen werden. Vor der Kompilierung des Kernels wird eine Konfiguration festgelegt.
Diese bestimmt für jeden Treiber, ob dieser im Kernel integriert, als Modul ausgelagert, oder nicht
kompiliert wird.
16
Abbildung 3.2: Über Clockworkmod können manuelle Updates wie z.B. ein Superuser-Paket zum
Rooten des Telefons installiert werden [14]
Die Drahtloskommunikation des Biocomfort Healthmanager-SDK erfolgt über einen USB-Dongle,
die (De-)Serialisierung der Sende- und Empfangsdaten übernimmt ein FTDI-Chip. Zur Verwendung des USB-Gateways unter Android ist somit einerseits ein Treiber für externe USB-Geräte
generell, außerdem ein Treiber für den FTDI-Chip nötig. Da beide Treiber in ICS-Standard nicht
vorhanden sind, musste ein nicht-standard Kernel verwendet werden.
Wenn auch von Google für Android 4.0 angekündigt [15], ist aktuell noch kein offizieller lauffähiger
Treiber für USB-Gadgets im Host-Modus vorhanden. Deshalb wurde ein modifizierter Kernel vom
User sztupy des XDA-Developers Forum [16] benutzt. Der USB-Hostmode Treiber ist offiziell
zwar derzeit noch nicht verfügbar, jedoch in den Kernelquellen für einige Tablets von Samsung
unter 2.x und 3.x vorhanden. Dieser Treiber wurde nach Android 4.0 portiert und damit in den
Kernel integriert. sztupy stellt sowohl vorkompilierte Images, als auch Kernelquellen unter [17]
zur Verfügung.
Die hochgeladenen Builds konnten wegen fehlendem FTDI-Modul so nicht eingebunden werden.
Anstelle dessen wurde der Kernel mitsamt entsprechendem Modul neu erstellt. Die Kernelkonfiguration und Kompilierung erfolgt analog zu Standard-Linux, jedoch muss die Kompilierung mit
der Crosscompiler-Toolchain aus dem Android NDK, den Android-Entwicklungstools für nativen
Code und für die entsprechende Gerätearchitektur erfolgen.
17
Zum dynamischen Umschalten zwischen beiden Treibermodi(USB-OTG/Client) kann die Applikation USB Host Controller aus dem Android Market installiert werden (Abbildung 3.3).
Abbildung 3.3: Mit der USB-Host-Controller Applikation kann im laufenden Betrieb zwischen
On-the-go und Client Modus umgeschalten werden
3.3 Geräte- und Applikationssetup
Aufgrund anderer Bedingungen am Android-System auf Mobilgeräten waren einige Anpassungen
nötig. Das war einerseits das Setup vorhandener Hardwarekomponenten, andererseits die Handhabung der Gerätekommunikation.
3.3.1 Gerätesetup
Zum Betrieb von USB-A-Geräten ist eine USB-A Buchse notwendig. Einige Tablets verfügen
bereits über einen USB-Anschluss, Mobiltelefone werden standardmäßig ohne hergestellt. Wie
das Nexus S verfügen die meisten stattdessen über eine MicroUSB-Buchse, die in Verbindung mit
einem Adapter genutzt wird.
Darüberhinaus versorgt die MicroUSB-Buchse an das Nexus S angeschlossene Geräte (wie andere
USB-Host-Geräte, also z.B. PC’s) nicht mit Strom. Dies ist im Betrieb als USB-Client auch nicht
notwendig, da das Mobilgerät vom Host versorgt wird.
Diesen Zweck erfüllte am Nexus S stattdessen ein USB-Split-Kabel, wobei der zweite USBMale Stecker an externe Stromversorgung angeschlossen wird. Außerdem ist mit dem genutzten
18
Hostmode-Treiber laut Entwicklerangaben ein Hub nötig. An diesen kann nun der Biocomfort
USB-Dongle angeschlossen werden. Der ganze Aufbau ist in 3.4 ersichtlich.
Abbildung 3.4: Übersicht Hardwarekonfiguration
3.3.2 Applikationssetup
Der Biocomfort Health Assistant kommuniziert zur Laufzeit über das USB-Gateway mit den drahtlosen Medizingeräten ( Abbildung 3.5 ). Dazu muss er Daten über das Gateway senden, empfangen
und den Status des Gateways abrufen können. Der Zugriff auf das Gateway erfolgt nicht direkt,
sondern über einen Treiber im Kernel.
Linux bildet dabei Peripheriegeräte (wie das Gateway) auf eine korrespondierende Gerätedatei ab.
Zum Senden können nun Daten in diese spezielle Datei /dev/ttyUSB0 geschrieben, zum Empfang solche gelesen werden. Das Kommunikationsprotokoll ist hierbei in einer low-level Bibliothek
(libibeanapi) festgelegt. Zusätzlich wird von Biocomfort eine high-level Bibliothek (libhmcsdk)
zur Verfügung gestellt, die intern Funktionen aus libibeanapi aufruft. Der gesamte Aufbau ist in
Abbildung 3.6 dargesellt.
Abbildung 3.5: USB-Dongle und Medizingeräte
Abbildung 3.6: Übersicht der Programmfunktion
19
Kapitel 4
Android Implementierung
In diesem Kapitel werden erst die Anforderungen an den Biocomfort Health Assistant genannt.
Dann wird in Sektion 4.2 das Wesentliche der Implementierung auf der Android-Plattform erklärt.
Weiterhin wird in Sektion 4.3 auf die Probleme eingegangen, die dabei auftauchten. Zuletzt
werden Beschränkungen des Systems diskutiert.
4.1 Anforderungen
Ein Healthmanager muss bestimmte Anforderungen erfüllen. In erster Linie geht es bei einem
Healthmanager um die Haltung der persönlichen Vitaldaten. Hierbei macht es keinen Unterschied, ob die Daten am Telefon, am Rechner oder in der Cloud gespeichert werden. Für die
Implementierung mit Android sollen deshalb folgende Anforderungen erfüllt werden:
• Der Healthmanager soll Daten von den Biocomfort Medizingeräten aufnehmen und abspeichern. Das soll automatisch und zuverlässig geschehen.
• Es soll eine Möglichkeit zur Visualisierung vorhanden sein, diese soll jedoch von der Datenaufnahme und Verwaltung getrennt werden.
• Die Benutzeroberfläche soll intuitiv und leicht bedienbar sein.
• Über die UI-Komponente kann mit den Medizingeräten kommuniziert werden. Dabei können
Gerätekonfigurationen geändert oder abgerufen werden.
• Auch andere Applikationen oder Dienste können Daten vom Health Manager abrufen und
weiterverwenden.
• Die Software soll erweiterbar sein.
20
Kapitel 4 Android Implementierung
21
4.2 Implementierung Biocomfort Health Assistant für Android
Der Biocomfort Health Assistant setzt sich aus einer Service Application (Dienstanwendung) und
einer GUI-Anwendung mit grafischer Oberfläche zusammen. Dabei ist die Service Application für
die Aufnahme von Messdaten und die Kommunikation mit der mobilen Sensorik zuständig. Die
GUI-Anwendung ruft empfangene Daten über ein AIDL-Interface von der Service Application ab.
Zu Testzwecken kann der Biocomfort Health Assistant auch mit in Software simulierten Medizingeräten, statt den tatsächlichen Sensoren, kommunizieren. Zur Steuerung dieser vorgetäuschten
Sensoreinheiten wird das zusätzlich entwickelte MockSDK GUI eingesetzt.
4.2.1 Service Application
Die Service Application handhabt die Kommunikation mit den medizinischen Messgeräten. Da
neue Daten ständig eintreffen, sollte der Dienst permanent verfügbar sein, um diese aufnehmen
zu können. Dies können Messdaten oder Konfigurationsdaten der Medizingeräte sein. Die Daten
sollten im Anschluss dauerhaft abgespeichert werden, wozu bei der Implementierung SQLite verwendet wurde. Eine weitere Anforderung ist, dass die Service Application mit anderen abrufenden Anwendungen kommuniziert. Der Dienst interagiert mit einer unterschiedlichen Anzahl von
Applikationen, weshalb das Interface variabel erstellt werden muss. Eine sinnvolle Lösung für
diese Anforderung ist, bei neuen Daten Broadcast-Meldungen an alle derartigen Applikationen zu
schicken, um Updates zu signalisieren. Dann können diese über ein AIDL-Interface abgerufen werden. Anfangs wurde die Kommunikation mit den Medizingeräten durch das Mock SDK emuliert.
Später wurde an dieser Stelle das SDK Interface zur tatsächlichen Gerätekommunikation eingefügt. Zur low-level Kommunikation wurden C-Bibliotheken eingesetzt. Diese können in Java unter
Verwendung von Java Native Interface direkt angesprochen werden.
Datenbank Management
Zur Speicherung aller Daten auch nach Beendigung des Dienstes bzw. Ausschalten des Geräts
werden diese in einer SQlite-Datenbank abgelegt. Dies geschieht je in einer Tabelle für BenutzerGeräte- und die verschiedenen Typen von Messdaten.
Benutzerdaten Benutzereinträge, die über die UI-Applikation oder auch andere Applikationen
erstellt wurden, werden hier abgelegt. Da die Biocomfort-Medizingeräte auf derzeit 8 Einträge
beschränkt sind, wurde dies auch in der Datenbank berücksichtigt. Beim Löschen eines Benutzers
werden alle zugehörigen Messdaten aus den entsprechenden Tabellen gelöscht.
22
Abbildung 4.1: Aufbau der Service Application des Biocomfort Health Assitant for Android.
Gerätedaten Von den Geräten eingehende Geräteparameter werden in dieser Tabelle gespeichert. Die Identifikation geschieht hierbei über die eindeutige Geräte-Identifikationsnummer. Bei
neu erhaltenen Geräteparametern, also z.B. eine aktualisierte Gerätezeit, die bereits in der Datenbank vorhanden sind, werden diese entsprechend ersetzt.
Messdaten Da sich die Messdaten durch die Zahl der gemessenen Parameter, bzw. den Datentyp unterscheiden, wurden die Messdaten in verschiedenen Tabellen gespeichert. Bei neuen
Messdaten wird zuvor die Datenbank auf bereits vorhandene identische Datensätze befragt, um
Doppeleinträge zu vermeiden.
Mock SDK
Der MockSDK bildet sowohl das Wireless Gateway als auch die Biocomfort-Medizingeräte in
Software nach. Er stellt die selben Schnittstellen zur Verfügung wie die Java-Implementierung des
Health Manager SDK. Außerdem werden auch auftretende Übertragungsfehler simuliert. Mit ihm
kann auch ohne passende Bibliotheken und Treiber die Datenbank, Interprozesskommunikation
und GUI getestet werden. Das MockSDK kann vor allem für die Erweiterung auf andere Geräte
nützlich sein.
Eine vorhandene Implementierung findet sich online zum Download [18]. Diese wurde nach An-
23
droid portiert und um ein GUI zur Steuerung ergänzt, die unter Abschnitt 4.2.3 vorgestellt wird.
Communication Service
Der Communication Service kommuniziert mit Applikationen, die Gesundheitsdaten abrufen
wollen. Außerdem ist eine Schnittstelle zur Kommunikation mit dem MockSDK vorhanden. Daten
können dort nach der Öffnung einer Verbindung über ein AIDL-Interface abgerufen werden. Wenn
neue Daten von den Geräten eintreffen, oder Daten in der Datenbank verändert werden, werden
per Broadcast Update-Benachrichtigungen verschickt.
SDK Interface
Das SDK-Interface kommuniziert mit den Medizingeräten. Dies geschieht über JNI und die
Schnittstellen des Health Manager C SDK. Die Geräte werden hier in einer Geräteliste zwischengespeichert und bei Bedarf neue Einträge erstellt. Bei Empfang neuer Messdaten, Gerätekonfigurationen oder Fehler wird der SDK-Manager über Events benachrichtigt. Diese Komponente kann
zum Testen durch das MockSDK ausgetauscht werden.
SDK Manager
Der SDK-Manager nimmt Events vom SDK-Interface an und reagiert auf diese. Intern kommuniziert er über Listener mit dem Communication Service und bearbeitet die dort ankommenden
Anfragen weiter. Dabei verwaltet er die SQLite-Datenbank, d.h. er erstellt neue Datenbankeinträge, löscht Einträge oder aktualisiert vorhandene Einträge. Außerdem prüft der SDK Manager
die Datenbank auf bereits vorhandene Einträge.
Java Native Interface
Als Kompatibilitätsschicht zwischen C und Java wurde “Java Native Interface” (JNI) (Abbildung
4.2) gewählt. Hier wird nur auf die grundlegende Rolle von JNI eingegangen, Details können in
[19] und [20] eingesehen werden.
JNI ist für Situationen entworfen, in denen Nativer Code mit Java-Anwendungen kombiniert werden muss. Da JNI ein zweiseitige Schnittstelle ist, unterstützt es sowohl native Bibliotheken als
auch native Anwendungen (Abbildung 4.2 ).
Java-Anwendungen rufen native Methode in der gleichen Art wie in Java implementierte Funktionen auf, im Unterschied dazu jedoch liegen diese Funktionen in Nativen Bibliotheken vor.
Javaklassen werden dabei mit spezieller Namenskonvention auf native Funktionen abgebildet.
24
Abbildung 4.2: Funktion von Java Native Interface als Anbindung für Nativen Code in JavaApplikationen
Eine einfaches Interface zum nativen Methodeaufruf ist in Listing 4.1 dargestellt. Dabei wird
zunächst eine native Methode in C implementiert und diese dann von Java aus aufgerufen.
Listing 4.1: Aufruf von nativen Methoden über JNI
∗ Native Implementierung in C
∗/
#i n c l u d e < j n i . h>
jb oo le an Java_com_biocomfort_jni_JavaClass_nativeMethod ( . . . ) {
return true ;
}
/∗
∗ N a t i v e Methode im Java−Code a u f r u f e n
∗/
p a c k a g e com . b i o c o m f o r t . j n i ;
public class JavaClass {
p r i v a t e n a t i v e boolean nativeMethod ( ) ;
p r i v a t e s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
boolean r e t v a l = nativeMethod ( ) ;
}
}
JNI unterstützt es außerdem, die Java Virtual Machine Implementation in nativen Code einzubinden. Native Programmteile können mit der JavaVM kommunizieren, und eine Schnittstelle zum
Ausführen von Java-Softwarekomponenten und Funktionen nutzen. Wie in Listing 4.2 gezeigt,
können aus der nativen Anwendung sogenannte Callbacks aufgerufen werden. Dabei müssen vor
dem Aufruf unter anderem die JavaVM und die aufzurufenden Java-Methoden gefunden werden. Beim Aufruf muss sich das native Programm den neuen Programmthread zunächst bei der
25
laufenden Instanz der JavaVM registrieren, sowie danach wieder abmelden.
Listing 4.2: Native Callbacks
/∗
∗ Methode i n J a v a d e f i n i e r e n
∗/
public class JavaClass {
p r i v a t e v o i d j a va M ethod ;
}
/∗
∗ J a v a Methode a u s n a t i v e r Anwendung a u f r u f e n
∗/
#i n c l u d e < j n i . h>
// Z e i g e r a u f JavaVM , muss i n d e r n a t i v e n Anwendung i n i t i a l i s i e r t werden
JavaVM ∗g_vm ;
void callback () {
// JNI i n t e r f a c e P o i n t e r
JNIEnv ∗ g_env ;
// R e g i s t r i e r e n b e i d e r A k t u e l l e n I n s t a n z d e r JavaVM
( ∗g_vm)−>A t t a c h C u r r e n t T h r e a d ( g_vm , &g_env , NULL ) ;
// N a t i v e r M e t h o d e n a u f r u f
( ∗ g_env)−>C a l l V o i d M e t h o d ( . . . , javaMethod , a r g u m e n t s ) ;
// D e r e g i s t r i e r e n
( ∗g_vm)−>D e t a c h C u r r e n t T h r e a d ( ) ;
}
v o i d main ( ) {
// JavaVM i n i t i a l i s i e r e n und Java−Methoden f i n d e n
init ();
// J a v a Methode ü b e r C a l l b a c k a u f r u f e n ;
callback ();
}
Somit kann die Java-Applikation aktiv Gerätedaten mit Methodenaufrufen im Health Manager
C-SDK abfragen (Abbildung 4.3, 1 ). Diese Methoden können sowohl Java-Standarddatentypen,
als auch eigene Datentypen enthalten. Die Daten können über Rückgabewerte, nicht jedoch über
in Java verbotene Zeiger ausgelesen werden.
26
Mit diesem Mechanismus alleine können nur durch Polling der SDK-Zustand oder z.B. Informationen über neue Geräte eingeholt werden. Darum definiert die HMCSDK-Bibliothek einige Events,
die durch Hardware-Interrupts getriggert werden (Abbildung 4.3, 4 ). Diese Events können nun
durch SDK-Funktionen an ensprechende Java-Events gebunden werden (Abbildung 4.3, 2 ). Da
diese sogenannten “Callbacks” von der Nativen Applikationen gesteuert sind, müssen sie in einem
eigenen Thread gestartet werden. Um dies zu ermöglichen, muss der neue Thread manuell bei der
Java VM registriert werden. Nun können Callbacks ausgeführt werden (Abbildung 4.3, 3 ).
Abbildung 4.3: Einsatz von Java Native Interface in der Service Applikation. Dabei können sowohl
native C-Funktionen in Java, als auch umgekehrt Java-Funktionen über Callbacks
in C ausgeführt werden
4.2.2 GUI Application
Die GUI-Applikation stellt die von der Service Application empfangenen Daten grafisch dar. Smartphones werden, anders als Personal Computer, meist nur von einem Benutzer, nämlich dem Besitzer bedient. Dies sollte auch bei Endbenutzeranwendungen berücksichtigt werden.
Deshalb werden in der Applikation nie alle Benutzerdaten gleichzeitig angezeigt, da beim Start ein
Benutzer gewählt werden muss. Daraufhin werden die Daten des gewählten Benutzers angezeigt.
Ein zentraler Hintergrunddienst verwaltet die Daten der Applikation.
27
Hintergrunddienst
Der Hintergrunddienst ist für den Datenabruf und deren Verwaltung zuständig. Da z.T. identische Daten in den verschiedenen Visualisierungen dargestellt werden, wäre ein direkter Abruf
redundant. Der Dienst bildet die Schnittstelle zur Service Applikation und empfängt UpdateBenachrichtigungen über Intents. Daraufhin werden die neuen Daten über ein AIDL-Interface
abgerufen und an gerade laufende Programmkomponenten weitergegeben.
Benutzerauswahl
Die Benutzerauswahl wird anfangs aufgerufen, um den entsprechenden Benutzer zu selektieren (4.4
links). Nicht mehr benötigte Benutzer können bei Bedarf gelöscht werden. Außerdem besteht die
Möglichkeit, neue Benutzer zu erstellen. Dazu müssen die Daten des neuen Benutzers eingegeben
werden (4.4 rechts).
Abbildung 4.4: Benutzerauswahl und Benutzererstellung
Viewpager
Zur Visualisierung der von der Service Applikation empfangenen Daten wird ein Viewpager eingesetzt, der eine intuitive Bedienung ermöglicht. Damit kann die Bildschirmseite per Wischgeste
28
gewechselt werden. Der Viewpager beinhaltet verschiedene Ansichten für Gerätedaten (4.5a ),
Messdaten sowie Geräte/Kommunikationsprobleme.
Die empfangenen Messdaten werden dabei als Liste (4.5c ), in Detailansicht (4.5b ) und in Diagrammansicht dargestellt. Derzeit existiert je ein Diagrammtyp für Blutdruck (4.6a ), Blutzucker
(4.6b ) sowie für empfangene Daten der Diagnosewaage (4.6c ). In den Diagrammen werden die
gemessenen Werte in Reihenfolge der Messung dargestellt. Die dargestellte Datenmenge kann bei
allen Vitaldatendiagrammen über eine Zoomfunktion variiert werden.
Abbildung 4.5: Geräteübersicht, Messungsdetails und Messungsliste
4.2.3 MockSDK Gui
Um das MockSDK extern steuern zu können, wurde für diesen Zweck eine graphische Oberfläche
erstellt (4.7). Diese kommuniziert über eine Server-Client-Verbindung mit der Service Applikation.
Dabei läuft diese extern am PC. Somit können neue Events getriggert werden, ohne am AndroidGerät zwischen verschiedenen Applikationen umschalten zu müssen.
Bei der Verwendung kann zunächst die IP des Zielgeräts eingegeben und dann eine Verbindung
erstellt werden. Nach Verbindung ohne Fehler können nun verschiedene Events im MockSDK
ausgelöst werden. Per Klick kann z.B. das Anstecken bzw. Abziehen des USB-Gateways simuliert
werden. Außerdem ist ein An- und Abschalten der Medizingeräte im MockSDK möglich. Zusätzlich können nach Auswahl eines Benutzers neue Messungen erstellt werden.
Für die GUI zur Steuerung des MockSDK wurde Qt-Jambi, sowie das in Java enthaltene TCP/IP-
Abbildung 4.6: Diagrammansicht je für Blutdruck-, Blutzucker und Waagenmessung
Abbildung 4.7: User Interface zur Steuerung des MockSDK
29
30
Interface genutzt.
4.3 Probleme
In diesem Abschnitt wird auf Schwierigkeiten eingegangen, die während der Entwicklung aufgetreten sind. Diese ergaben sich sowohl wegen der speziellen Hardwarekonfiguration, andererseits
durch Einsatz von plattformfremden Softwarekomponenten. Weitere traten wegen nicht behobener
Fehler in Android selbst auf.
4.3.1 Android Umgebung
Wireless Debugging
Kabelgebundenes Debugging ist bei Verwendung des USB-Gateways und einem USB-Slot nicht
mehr möglich. Deshalb wurde zum Debugging stattdessen die drahtlose Android Debug Bridge
(ADB-Wireless) verwendet [21]. Nach langwieriger drahtloser Programminstallation weißt auch
der Debugger lange Reaktionszeiten und viele Abbrüche auf. Vor allem das Übertragen von
größeren Datenmengen wird stark verlangsamt.
Geräteberechtigungen
Um auf die Gerätedatei des Gateways zugreifen zu können, müssen entsprechende Berechtigungen für die Applikation vorhanden sein. Da die Gerätedateien bei jeder Einbindung neu erstellt
wird, muss direkt bei der Einbindung eine solche Berechtigung vergeben werden. Standardmäßig
kann nur root auf beliebige Geräte zugreifen, für weitere Berechtigungen können normalerweise
(GNU/Linux) über Regeln in udev, dem Linux Gerätemanager, vergeben werden.
Unter Android als eingebettetem linuxbasiertem System wird aus Performancegründen und zur
Einsparung von Speicherplatz auf den udev-Dienst verzichtet. Stattdessen werden Berechtigungen über den uevent-daemon gesetzt.
Jedoch liegen die Konfigurationsdateien für den uevent-daemon bereits auf der ininitialen Ramdisk
(initramfs), die als anfängliches Dateisystem beim Bootvorgang dient. Um die benötigten Berechtigungen zu setzen, musste das gepackte initramfs des Android-Gerätes modifiziert und neu aufgespielt werden.
31
Application Framework
Neben dem regulären Application Framework können in Applikationen zusätzliche Bibliotheken
zur Rückwärtskompatibilität (Support-Packages) eingebunden werden. Dabei werden einige Komponenten des Application Framework reimplementiert, um die Funktionalität auf älteren AndroidVersionen zu garantieren. Dabei existieren Support-Packages je für einschließlich API-Version 4
und API-Version 13.
Die Reimplementierung oder Ersetzung dieser Klassen kann dabei zu Doppeldeutigkeiten und
Inkompatibilitäten führen. Dies tritt z.B. bei der Verwaltung von Fragments zu Problemen.
Außerdem beinhalten die Support-Packages teilweise noch Programmfehler, die zu schwierig behebbaren Programmabstürzen führen. Um diese zu beseitigen, wurden die Support-Packages neu
erstellt. Somit werden derzeit leicht modifizierte Bibliotheken verwandt, wobei die manuellen
Fehlerbehebungen (Bugfixes) bei jedem Update neu eingespielt werden müssen. Die Benutzung
eines Viewpagers, wie in Sektion 4.2.2 genannt, erfordert die Einbindung der Support-Packages
für einschließlich API-Version 4.
4.3.2 Biocomfort Resourcen
Health Manager SDK
Da bereits eine Java-Implementierung des Health Manager SDK existiert, war anfangs geplant,
diese unter Android zu verwenden.
Aufgrund bestehender Abhängigkeiten könnte diese je-
doch nicht eingesetzt werden, was eine Umstrukturierung der Applikation zur Folge hatte. Die
stattdessen genutzte C-Implementierung bedurfte manueller Einbindung mit JNI.
Das SDK-Interface jedoch bietet die identischen Schnittstellen des Health-Manager Java SDK.
Im Falle einer zukünftigen Portierung des Health Manager Java SDK nach Android kann diese
nahtlos im Biocomfort Health Assistant eingesetzt werden.
4.4 Beschränkungen
Der Biocomfort Health Assistant stellt ein funktionsfähiges Health Manager System dar. Jedoch
unterliegt die aktuelle Implementierung Beschränkungen in einigen Punkten. Diese sind einerseits
durch den begrenzten Rahmen einer Studienarbeit, andererseits durch die Neuentwicklung auf der
Android-Plattform bedingt. Im folgenden werden einige erläutert.
32
4.4.1 Stabilität
Der Biocomfort Health Assistant läuft im allgemeinen stabil. Probleme verursachen Abstürze des
Android-Systems und des USB-Hostmode Treibers.
Android
Das während der Entwicklung eingesetzte Android 4.0.3 sowie der Kernel weißen noch relativ
viele Programmfehler (Bugs) auf. Dies zeigt sich noch recht häufig durch Einfrieren des Systems
oder ungewollte Neustarts. Da Fehler durch Bugfixes und Systemupdates relativ schnell behoben
werden, ist eine baldige Besserung zu erwarten. Schon im vor kurzem erschienene Update zu 4.0.4
wurden viele Bugs entfernt.
USB-Hostmode Treiber
Der genutzte Hostmode-Treiber ist nicht besonders stabil, außerdem bei der Geräteerkennung noch
recht unzuverlässig. Einige USB-Geräte werden nicht erkannt, außerdem muss zwischen USB2.0
und USB1.1-Geräten umgeschaltet werden. USB-Geräte müssen teils mehrfach angeschlossen und
wieder entfernt werden, bis vom Kernel ein Gerät erstellt und eingebunden wird.
Der dauerhafte Betrieb des Biocomfort USB-Gateway ist mit diesem Treiber momentan nur bedingt
möglich, da die Gerätedatei häufig vom Kernel entfernt, oder mit dem falschen Device Identifier
(Gerätenamen) erstellt wird. Um diese Probleme zu beheben wurde ein Shellskript erstellt, das
ggf. entsprechende symbolische Links setzt bzw. die Gerätedatei neu erstellt.
4.4.2 Mobilität
Das derzeit eingesetzte Smartphone Nexus S bietet per USB angeschlossenen Peripheriegeräten
keine Stromversorgung. Deshalb muss die USB-Anschlussleitung extern mit Strom versorgt werden. Somit ist momentan wegen diesem zusätzlich nötigen Stromanschluss noch kein vollständig
mobiler Betrieb möglich.
4.4.3 Funktionsumfang
Um den Biocomfort Health Assistant als komplett eigenständiges System zu nutzen, sollte man auf
alle Daten der medizinischen Messgeräte zugreifen können. Dazu bietet der Health Manager SDK
viele verschiedene Methoden und Schnittstellen an. Da sich die derzeitige Implementierung auf die
Basisfunktionalitäten beschränkt werden einige SDK-Funktionen noch nicht verwendet. Derzeit
33
ist z.B. noch nicht möglich, die Gerätezeit direkt einzustellen oder Benutzer am Medizingerät zu
(de-)aktivieren. Alle grundlegenden Funktionen zum Abruf von Messdaten sind vorhanden.
4.4.4 Sicherheit
Die Sicherheit der Applikationsdatenbank am Smartphone vor unberechtigtem Zugriff kann derzeit
nicht vollständig garantiert werden. Dies liegt an den noch nötigen Root-Rechten zum Betrieb des
Biocomfort Health Assistant. Sobald diese nicht mehr erforderlich sind, ist die Datenbank automatisch vor direkten Zugriffen innerhalb des Android-Systems, also z.B. durch Fishing-Applikationen
geschützt. Der Datenabruf über AIDL ist für beliebige Applikationen möglich.
Eine Funktion zum Online-Export oder Außenzugriff auf Messdaten ist noch nicht vorhanden.
4.4.5 Bediencomfort und Akzeptanz
Beim Oberflächenentwurf wurden intuitive Bedienelemente mit Wischgesten oder MultitouchZooming berücksichtigt. Da noch keine Fallstudie erfolgt ist, können zum Bediencomfort und der
Akzeptanz des Biocomfort Health Assistant noch keine Angaben gemacht werden.
Kapitel 5
Zusammenfassung und Ausblick
5.1 Zusammenfassung
Die anfängliche Problemstellung war, ein mobiles Healthmanager System für die Android-Plattform
zu finden. Dieses sollte als ganzheitliches Gesundheitssystem in der Lage sein, Vitaldaten von
mobilen Drahtlossensoren aufzunehmen. Dabei sollte das System erweiterbar sein und außerdem
empfangene Daten für andere Applikationen zur Verfügung stellen.
Deshalb wurden zunächste bestehende Healthmanagersysteme analysiert. Nun sollte ein neues
System entstehen, das die genannten Anforderungen erfüllt. Als Basis für das neue System für
die Android-Platform wurde das existierende Biocomfort Health Manager System ausgewählt.
Ausgehende von diesem System wurden mit Hilfe des Health Manager SDK zwei Applikationen für Android-Smartphones erstellt. Diese beiden bilden den Biocomfort Health Assistant für
Android. Dieser ermöglicht zunächst, ständig Einsicht in die Persönlichen Gesundheitsdaten zu
behalten. Durch die Implementierung am Smartphone können außerdem Daten jederzeit und
überall aufgenommen werden, also z.B. im Job, beim Training oder im Urlaub.
Dies kann jedoch nur der erste Schritt für ein noch umfassenderes Health Management am Smartphone sein. Dazu stellt der Biocomfort Health Assistant anderen Applikationen, die Gesundheitsdaten berücksichtigen, gemessene Vitaldaten zur Weiterarbeitung zur Verfügung.
Somit ist dies hoffentlich eine Möglichkeit, das allgemeine Wohlbefinden eines jeden Menschen zu
verbessern und eine Hilfe, um schwerwiegenden Krankheiten vorzubeugen.
5.2 Ausblick
In diesem Abschnitt wird auf mögliche Erweiterungen des entwickelten Healthmanager-Systems
eingegangen. Dabei werden einerseits hardware- als auch softwareseitge Erweiterungen diskutiert.
34
Kapitel 5 Zusammenfassung und Ausblick
35
5.2.1 Hardware
Kompatibilität mit weiteren Smartphones
Der Healthmanager läuft in der derzeitigen Ausführung unter Android ICS 4.0 mit einem modifizierten Linuxkernel für das Nexus S, der einen USB-Hostmode Treiber bietet. Außerdem ist
externe Stromversorgung und ein USB-Hub nötig und somit kein mobiler Betrieb möglich.
Zwar wird seit längerem angekündigt [15], dass der USB-Hostmode standardmäßig unterstützt
wird, jedoch momentan mit Android 3.x nur unter einigen Tablets. Eine breite Unterstützung
unter 4.x lässt noch auf sich warten. Da sowohl die Stabilität, als auch die Verbreitung der
neuen Android-Version 4.x zunimmt, kann man auf eine baldige Integration hoffen. Mit der
Unterstützung für den USB-Hostmode wird auch der microUSB-Port mit Strom versorgt. Dies ist
z.B. schon beim Samsung Galaxy Nexus sowie beim Samsung Galaxy S3 der Fall.
Dadurch ist ein direkter Anschluss mit Adapter des USB-Gateways an der Android-Hardware ohne
Hub möglich. Somit wird der mobile Einsatz mit verschiedenen Android-Smartphones ermöglicht.
Erweiterung der Sensorpalette
Bei der Entscheidung für ein Health Manager spielt die Zahl der bereits vorhandenen Sensoren
eine wichtige Rolle. Durch ein größeres Angebot steigt die Attraktivität der Plattform. Deshalb
wird die Sensorfamilie derzeit erweitert.
Als Alternative zur vorhandenen Körperfettwaage kommt sowohl eine Körperfettwaage mit erweitertem Messbereich, als auch eine reine Körperwaage hinzu. Weiterhin steht bald ein Blutdruckmessgerät zur Messung am Oberarm bereit [22]. Denkbar wären z.B. auch noch Messgeräte
für weitere Vitaldaten wie Atmung, Körpertemperatur oder Herzfrequenz.
Schnittstellen
Am Markt für Medical Health Care Produkte existieren viele verschiedene Typen von Sensoren,
die verschiedene Schnittstellen zur Datenübertragung und Kommunikation benutzen. Um den
Biocomfort Health Manager als ganzheitliches Gesundheitssystem verwenden zu können, sollte
dieser möglichst viele verschiedene Schnittstellen unterstützen.
Zigbee ZigBee ist ein Funknetz-Standard und ermöglicht es Haushaltsgeräte, Sensoren, uvm.
auf Kurzstrecken (10 bis 100 Meter) zu verbinden. Da dieser ebenfalls auf IEEE 802.15.4 basiert,
müsste dabei nur um den Zigbee-Protokollstack erweitert werden.
36
ANT Der proprietäre ANT Drahtlosstandard wird durch Dynastream Innovations, einer GarminTochter, vermarktet. Ant eignet sich durch niedrige Leistungsaufnahme und hohe Effizienz gut
für medizinische Sensoren. Sensoren können entweder über einen USB-Dongle oder direkt mit
ANT-Kompatiblen Android-Geräten eingebunden werden. Viele Sensoren verschiedener Hersteller,
z.B. Garmin [23] oder FitBit [24], verwenden den ANT-Standard und schon deshalb wäre eine
Erweiterung sinnvoll.
Bluetooth Bluetooth ist gemäß dem Industriestandard IEEE 802.15.1 für die Datenübertragung
zwischen Geräten über kurze Distanz geeignet. Die meisten aktuellen Smartphones beinhalten
bereits entsprechende Schnittstellen, wodurch man nicht mehr auf externe Geräte wie ein USBGateway angewiesen ist. Bluetooth ist sehr verbreitet, unter anderem auch für drahtlose Medizinsensorik. In kürze werden auch Biocomfort Medizingeräte und das USB-Gateway optional mit
Bluetooth ausgeliefert [25].
Wireless LAN Die drahtlose Familie von lokalen Funknetzstandards IEEE-802.11 wird von nahezu allen Android-Smartphones unterstützt. Zusätzliche Hardware, wie z.B. ein USB-Dongle ist
deshalb hierbei nicht nötig. Jedoch muss die Applikation über den Wireless Local Area Network
(WLAN) Standard gesendete Daten aufnehmen können.
5.2.2 Software
Personal Fitness Trainer
Personal Fitness Trainer Applikationen wählen Übungen basierend auf den persönlichen Vitaldaten,
der Ernährung, und des Übungsfortschritts aus. Ein Beispiel dafür ist Gymskill [26, 27], einem
Personal Trainer für Android, der für Übungen das smartphoneinterne Accelerometer in Verbindung
mit einem Balance Board nutzt.
Speziell bei Vitaldaten besteht im Personal Trainer meist keine direkte Verbindung zur Hardware.
Deshalb müssen gemessene Werte dann manuell für den jeweiligen Benutzer eingegeben werden.
Durch dieses Erfordernis sinkt bei vielen Benutzern die Akzeptanz der Applikation und schränkt die
Alltagstauglichkeit ein. Die sinnvollere Alternative dazu ist der Empfang von Vitaldaten von einem
Health Manager System. Um dies zu ermöglichen, muss der Personal Fitness Trainer lediglich ein
entsprechendes Interface zum Datenempfang implementieren. Dies wäre im Falle des Biocomfort
Health Assistant ein AIDL-Interface und beschränkt sich auf wenige Dateien. Somit werden neu
empfangene Daten automatisch an den Personal Trainer weitergeleitet und schon beim nächsten
Training berücksichtigt.
37
Personal Trainer Applikationen benutzen außerdem oft Trainingsgeräte mit integrierter Sensorik,
wie z.B. Sensor-Virring [28]. Die Sensordaten der Trainingsgeräte dienen dabei meist der korrekten Ausführung von Übungen. Hierbei wäre nun denkbar, zusätzlich parallel Vitalwerte wie
Herzfrequenz oder Atmung zu messen. Dies ermöglicht, den Zustand des Benutzers während der
Übung zu überwachen und basierend darauf die Übung zu beschleunigen, zu verlangsamen oder
abzubrechen. Über gemessene Werte können zusätzlich kritische oder motivierende audiovisuelle
Anregungen, wie bereits von Kranz et al. [29] vorgeschlagen, durch die Personal Trainer Applikation gesteuert werden. Dies unterstützt die richtige Ausführung von Übungen und stellt deren
Intensität individuell auf den Benutzer ein.
Webservices
Die exklusive Speicherung der Daten auf dem Smartphone weißt nach wie vor einige Nachteile auf.
Einerseits besteht die Gefahr des Datenverlustes bei einem Gerätedefekt. Ein weiteres Problem
ist, dass bei Datenaufnahme auf verschiedenen Geräten keine Synchronisation möglich ist. Die
Weitergabe an andere beschränkt sich derzeit auf die direkte Einsicht am Smartphone. Weder eine
Überwachung von Pflegebedürftigen an entfernten Standorten, noch telemedizinische Anwendungen sind so möglich.
Alle diese Probleme können durch die Synchronisation mit einem Zentralen Speicherort gelöst werden. Diesen zentralen Speicher bildet hier ein Webserver, der bei bestehender Internetverbindung
immer erreichbar ist. Durch die geringe Datenmenge ist die Übertragung auch bei teils noch
langsamer Internetverbindung am Smartphone gut möglich. Dadurch kann auch durch telemedizinische Instanzen ein schneller Eingriff erfolgen.
Generell ist eine Anbindungen an jeden telemedizischen Webdienst möglich. Im Biocomfort Health
Manager SDK sind Anbindungen zu den Diensten Aentos and Seniokom implementiert, welche
sich deshalb für den Biocomfort Health Assistant on Android anbieten würden.
Erinnerung und Planung
Zur langsfristigen Überwachung von Patienten wird vom Hausarzt häufig die periodische Aufnahme
bestimmer Vitalwerte verordnet. Die Einhaltung dieser über mehrere Wochen kann vor allem im
Alltag schwierig sein. Die Regelmäßigkeit der Messungen sollte deshalb durch Erinnerung und
Planung unterstützt werden.
Dies kann dabei am Smartphone, oder noch besser direkt vom Health Manager aus geschehen.
Die Integration im Health Manager bietet dabei den Vorteil, dass geplante Messungen mit erfolgten Messungen abgeglichen und dem Benutzer somit Feedback darüber gegeben werden kann.
38
Außerdem ist die direkte Anzeige von Erinnerungen am Smartphone über Systembenachrichtigungen möglich. Bei der Planung besteht nun die Möglichkeit, die Häufigkeit und zeitliche Verteilung
gezielt auf die Wünsche des Benutzers, Verordnungen des Arztes oder die unterschiedlichen Sensoren einzustellen. Die Gewichtsmessung kann z.B. einmal wöchentlich, die Blutzuckermessung
morgens und Abends erfolgen. Zusätzlich wäre eine Timerfunktion für die Einnahme von Medikation denkbar. Um geplante Messungen oder Medikamente mit anderen Kalenderdaten zu kombinieren, kann diese Funktion mit bestehenden Diensten wie dem Google Calendar [30] zusammenarbeiten.
Abbildungsverzeichnis
2.1
ECG Monitoring Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Biocomfort USB-Dongle und Messgeräte . . . . . . . . . . . . . . . . . . . . . .
7
3.1
Architektur des Android-Betriebssystems . . . . . . . . . . . . . . . . . . . . . .
11
3.2
Clockworkmod Recovery
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.3
USB Hostcontroller Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.4
Übersicht Hardwarekonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.5
USB-Dongle und Medizingeräte . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.6
Übersicht der Programmfunktion . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1
Aufbau Service Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2
Allgemeine Funktion von Java Native Interface
. . . . . . . . . . . . . . . . . .
24
4.3
Einsatz von Java Native Interface . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.4
Benutzerauswahl und Benutzererstellung . . . . . . . . . . . . . . . . . . . . . .
27
4.5
Geräteübersicht, Messungsdetails und Messungsliste . . . . . . . . . . . . . . . .
28
4.6
Diagrammansicht je für Blutdruck-, Blutzucker und Waagenmessung . . . . . . .
29
4.7
MockSDK Gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
39
Literaturverzeichnis
[1] “Ärztezeitung.de,” mar 2012.
http://www.aerztezeitung.de/praxis_wirtschaft/
praxisfuehrung/article/806535/verdachtsfaelle-berufskrankheiten.html [Letzter Zugriff: 29. Mai 2012].
[2] “Welt Online,” mar 2012.
http://www.welt.de/gesundheit/article13621508/
Herzleiden-sind-die-haeufigste-Todesursache.html [Letzter Zugriff:
29. Mai
2012].
[3] Y.-H. Chu, Y.-C. Hsieh, C.-H. Wang, Y.-C. Pan, und R.-I. Chang, “Uphsm: Ubiquitous personal health surveillance and management system via wsn agent on open source smartphone,”
in e-Health Networking Applications and Services (Healthcom), 2011 13th IEEE International
Conference on, Seiten 60 –63, june 2011.
[4] P.-C. Hii und W.-Y. Chung, “A comprehensive ubiquitous healthcare solution on an android
mobile device,” Open Access, jun 2011.
[5] “Blutdruck App,” mar 2012. https://play.google.com/store/apps/details?id=com.
michaelfester.heart [Letzter Zugriff: 25. Mai 2012].
[6] “Blutdruck Logbuch App,” mar 2012. https://play.google.com/store/apps/details?
id=com.ptashek.bplog [Letzter Zugriff: 24. Mai 2012].
[7] “Withings
WiScale
App,”
mar
2012.
http://www.withings.com/de/waage/
funktionalitaten [Letzter Zugriff: 24. Mai 2012].
[8] NielsenWire, “Consumers purchasing new phones picked smartphones more often... while android was the top smartphone os,” Mar. 2012. http://blog.nielsen.com/nielsenwire/
?p=31688 [Letzter Zugriff: 9. Mai 2012].
[9] ComScore, “’Android tips the 51 percent mark in US share’,” Mar. 2012.
http://
www.engadget.com/2012/05/01/comscore-us-smartphone-share-march-2012/ [Letzter Zugriff: 9. Mai 2012].
[10] Linux Foundation, “Linux kernel source,” Mar. 2012. http://www.kernel.org/ [Letzter
Zugriff: 10. Mai 2012].
40
41
LITERATURVERZEICHNIS
[11] GNU Project, “Gnu general public license v2,” Mar. 2012. http://www.kernel.org/ [Letzter Zugriff: 10. Mai 2012].
[12] Android Open Source Project, “Android source,” Mar. 2012. http://source.android.
com/source/downloading.html [Letzter Zugriff: 10. Mai 2012].
[13] Android Lighthouse Project, “Creating native qt/c++ applications,” mar 2012. http://
sourceforge.net/p/necessitas/home/necessitas/ [Letzter Zugriff: 11. Mai 2012].
[14] “Screenshot
Clockworkmod,”
mar
2012.
http://www.giga.de/smartphones/
google-nexus/news/clockworkmod-recovery-3/ [Letzter Zugriff: 27. Mai 2012].
[15] Android Developers, “Usb accessory and host modes are directly supported in android 3.1,”
mar 2012. http://developer.android.com/guide/topics/usb/index.html [Letzter
[16] “XDA Developers Webforum,” mar 2012. http://forum.xda-developers.com/ [Letzter
[17] stzupy, “Inofficial kernel for nexus s with android 4.0 and otg-support,” mar 2012. http:
//forum.xda-developers.com/showthread.php?t=1459304 [Letzter Zugriff: 23. Mai
2012].
[18] Biocomfort, “Biocomfort health manager sourceforge project,” mar 2012.
http://
sourceforge.net/projects/hmjavasdk/files/ [Letzter Zugriff: 11. Mai 2012].
[19] Sun Microsystems, “The Java Native Interface Programmer’s Guide and Specification,” mar
2012. http://java.sun.com/docs/books/jni/html/jniTOC.html [Letzter Zugriff: 23.
Mai 2012].
[20] R. Gordon, essential JNI. Prentice Hall PTR, 2002.
[21] MrSiir, “adbwireless,” mar 2012. https://play.google.com/store/apps/details?id=
siir.es.adbWireless [Letzter Zugriff: 11. Mai 2012].
[22] Biocomfort, “Biocomfort Telemonitoring Geräte,” mar 2012. http://www.biocomfort.de/
telemonitoring_geraete.html [Letzter Zugriff: 19. Mai 2012].
[23] Garmin, mar 2012. http://www.garmin.com/de/ [Letzter Zugriff: 29. Mai 2012].
[24] FitBit, mar 2012. http://www.fitbit.com/de [Letzter Zugriff: 31. Mai 2012].
[25] Biocomfort, “Biocomfort USB Bluetooth Gateway,” mar 2012. http://www.biocomfort.
de/gateway_comfort.html [Letzter Zugriff: 19. Mai 2012].
[26] A. Möller, J. Scherr, L. Roalter, S. Diewald, N. Hammerla, T. Plötz, P. Olivier, und M. Kranz,
“Gymskill: Mobile exercise skill assessment to support personal health and fitness,” in Ninth
LITERATURVERZEICHNIS
42
International Conference on Pervasive Computing (Pervasive 2011), Video Proceedings, (San
Francisco, CA, USA), June 2011.
[27] A. Möller, L. Roalter, S. Diewald, J. Scherr, M. Kranz, N. Hammerla, P. Olivier, und T. Plötz,
“Gymskill: A personal trainer for physical exercises,” in Pervasive Computing and Communications (PerCom), 2012 IEEE International Conference on, Seiten 213 –220, march 2012.
[28] A. Schmidt, P. Holleis, und M. Kranz, “Sensor-Virrig - A Balance Cushion as Controller,”
Workshop Playing with Sensors at UbiComp 2004, Sep. 2004.
[29] M. Kranz, P. Holleis, W. Spiessl, und A. Schmidt, “The therapy top measurement and
visualization system - an example for the advancements in existing sports equipments,” International Journal of Computer Science in Sport, Band 5, Seiten 76–80, December 2006.
[30] “Google Calendar,” mar 2012. http://www.google.com/calendar [Letzter Zugriff: 27.
Mai 2012].

BIOcomfort Health Assistant for Android Plattform

Transcription

Similar documents

Referat als

Innovative Benutzungsschnittstellen und Neue

6/2014 - Macwelt

Exklusiv - Music n Stuff

Elektronik Schaltfeld 414

Benutzerhandbuch

Prodigy 7.1 HiFi Benutzerhandbuch -

TUMcampus