Embed Size (px)
Citation preview
Fakultät für Elektrotechnik und InformationstechnikFachgebiet Verteilte Multimodale InformationsverarbeitungProf. Dr. Matthias Kranz
BIOcomfort Health Assistant for AndroidPlattform
Andreas Wallner
Studienarbeit
Verfasser: Andreas WallnerAnschrift:
Matrikelnummer:Professor: Prof. Dr. Matthias KranzBetreuer: Dipl.-Ing. Luis RoalterBeginn: 01.10.2011Abgabe: 31.03.2012
Kurzfassung
Diese Studienarbeit befasst sich mit der Untersuchung verschiedener mobiler Health Manager Sys-teme. Ein solches System ermöglicht es dem Benutzer, Vitaldaten von bevorzugt mobilen Sensorenaufzunehmen. Dabei liegt der Schwerpunkt auf den Systemen, welche möglichst mit existieren-den Smartphones funktionieren. Auf dem Markt exisitieren bereits verschiedene Sensoren, vondenen Vitaldaten digital abrufbar sind. Diese Sensoren sind jedoch nicht durchgehend kompatibelund verwenden verschiedenste Technologien und Übertragungsstandards. Als Schnittstelle zumDatenempfang am Endgerät werden dabei oft USB-Dongles eingesetzt.
Das erste Ziel dieser Arbeit liegt darin, prorietäre Hardware in Form von USB-Dongles überdie meist am Smartphone vorhandene USB-Schnittstelle (über OTG) anzubinden. Damit ist esmöglich existierende Systeme auch für Smartphones zu verwenden.
Ein mobiles Health Manager System sollte sich deshalb nicht auf einzelne Standards und Herstellerbeschränken, sondern offen, flexibel und erweiterbar sein. Außerdem sollen empfangene Vitaldateneinfach an andere berechtigte Dienste und Applikationen weitergereicht werden können. Derzeitvorhandene Systeme erfüllen die genannten Anforderungen nicht vollständig.
In dieser Arbeit wird nun der Biocomfort Health Assistant für Android vorgestellt, welcher versuchtdiese Anforderungen zu erfüllen. Da diese Anwendung zum Datenempfang immer verfügbar seinmuss, läuft diese im Hintergrund und besitzt deshalb keine grafische Benutzeroberfläche. ZurVisualisierung wurde zudem eine Beispiel-Applikation erstellt, welche die empfangenen Vital- undGerätedaten darstellen kann.
ii
Abstract
This thesis addresses the examination of various mobile health manager systems. Such a systemenables the user to gather vital data from preferred mobile sensors. Thereby the focus is on sys-tems, 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 compat-ible und use various technologies and transmission standards. Thereby oftenly USB dongles areused as interface for receiving data.
The first goal of this thesis lies in linking proprietary hardware in terms of USB dongles to themostly 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, butopen, flexible and expandable. Besides, it should be possible easily to share received vital datawith other authorized services and applications. Presently available Systems do not completelyfulfill the mentioned specifications.
This thesis introduces the Biocomfort Health Assistant for Android, which attempts to meetthose requirements. Given that the application must be available all the time it is running in thebackground and has no graphical user interface. Additionally an application to visualize receivedvital and device data was created.
iii
Inhaltsverzeichnis
Inhaltsverzeichnis iv
1 Einführung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Healthmanager 32.1 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Vorhandene Softwarelösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Garmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2 Ubiquitous Personal Health Surveillance and Management System . . . . 42.2.3 ECG Monitoring System mit mobilem Barcode-Decoder . . . . . . . . . . 52.2.4 Blutdruck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.5 Blutdruck Logbuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.6 WiThings WiScale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Biocomfort Health Manager Plattform . . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Messgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Biocomfort Health Manager Software Development Kit . . . . . . . . . . 8
3 Applikationsentwicklung unter Android 103.1 Android-Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Das Betriebssystem Android . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 Android-Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Applikationsspezifische Vorbereitungen am Gerät . . . . . . . . . . . . . . . . . 143.2.1 Rooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2.2 Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Geräte- und Applikationssetup . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.1 Gerätesetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.2 Applikationssetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Android Implementierung 204.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iv
INHALTSVERZEICHNIS v
4.2 Implementierung Biocomfort Health Assistant für Android . . . . . . . . . . . . 214.2.1 Service Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2.2 GUI Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.3 MockSDK Gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.1 Android Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.2 Biocomfort Resourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Beschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.1 Stabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.2 Mobilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.3 Funktionsumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.4 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.5 Bediencomfort und Akzeptanz . . . . . . . . . . . . . . . . . . . . . . . 33
5 Zusammenfassung und Ausblick 345.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Abbildungsverzeichnis 39
Literaturverzeichnis 40
Kapitel 1
Einführung
Die Arbeit wurde im Fachgebiet Verteilte Multimodale Informationsverarbeitung (VMI) der Tech-nischen Universität München verfasst. Sie beschäftigt sich mit der Entwicklung eines HealthManager Systems für die Android Smartphone-Plattform. Dabei werden anfangs vorhandene Im-plementierungen untersucht.In dieser Einleitung wird zunächst die Motivation der Arbeit erläutert, danach der Aufbau derArbeit angegeben.
1.1 Motivation
Die Überwachung von persönlichen Gesundheitsdaten, wie Blutdruck, Blutzucker und anderenVitalwerten im Alltag wird immer häufiger eingesetzt. Besonders aussagekräftig sind Messdaten,wenn sie regelmäßig, sowie auch langfristig aufgenommen werden. Um solche Messungen zuverwalten, kann ein Rechner mit einer entsprechender Software verwendet werden, der die Datenspeichert 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 Benutzerverfügbar, deshalb kann durch Erinnerungsfunktionen die regelmäßige Vitalwertsmessung unter-stü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 Dat-en außerdem standortunabhängig an Sachverständige verschickt werden. Das hat z.B. am Telefonden Vorteil, sofort unabhängige Meinungen unter Berücksichtigung eines Werteverlaufs zu erhal-ten oder Hilfe verständigen zu können. Auch für ältere oder pflegenbedürftige Menschen ist einederartige Datenaufnahme per Mobiltelefon eigenständig durchführbar. Bei Problemen kann dieBedienung 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 zuteilen, um Trainingseinheiten gezielt auf persönliche Sequenzen abzustimmen. Somit können z.B.bei zu hohem Blutdruck entsprechende Trainings empfohlen oder bei schlechten Blutzuckerwertenpassende Ernährungstips gegeben werden. Eine ständige Erinnerung kann das Gesundheitsbe-wusstsein im Positiven beeinflussen, Erfolge und Misserfolge eine motvierende Wirkung erzeugen.Dies kann durch den Vergleich mit alten Messdaten oder auch mobil mit anderen Benutzernerfolgen, was somit auch einen sozialen Aspekt bieten kann.
Beim mobilen Einsatz ist nun eine drahtlose Übertragung der Messdaten sinnvoll. Smartphonesbesitzen intern diverse Schnittstellen zur Drahtloskommunikation mit mobilen Sensoren. Aufge-baut wird eine Verbindung oft über WLAN, Bluetooth und Infrarot, außerdem werden teilweiseauch proprietäre Standards wie ANT/ANT+ unterstützt. Um Schnittstellen verwenden zu kön-nen, die vom Chip nicht direkt unterstützt werden, können diese per USB-Anschluss nachgerüstetwerden. Um USB-Peripheriegeräte als USB Slave Geräte verwenden zu können, muss die Firmwaredes Telefons mit USB-Anschluss den USB On The Go Modus unterstützen. Dies ermöglicht, dieApplikation am Mobiltelefon ortsunabhängig zu nutzen.
1.2 Aufbau der Arbeit
Die Arbeit beginnt mit der Analyse aktueller Health Manager Systeme. Dabei werden sowohlGeräte als auch bestehende Softwaresysteme erläutert. Außerdem wird das Biocomfort HealthManager 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 Än-derungen am System vorgenommen wurden.
In Kapitel 4 wird dann die entwickelte Implementierung vorgestellt. Dabei wird deren grundlegen-der Aufbau, wie auch Besonderheiten beschrieben. Abschließend werden in Kapitel 5 Ergebnissezusammengefasst und mögliche Erweiterungen vorgestellt.
Kapitel 2
Healthmanager
Im hektischen Alltag nimmt bei vielen Menschen die persönliche Gesundheit nur noch einenachrangige Rolle ein. Bei immer mehr Menschen diagnostiziert der Arzt Berufskrankheiten [1]und Herzkrankheiten [2]. Eine Überwachung der persönlichen Gesundheit erfolgt oft erst, wennschwerwiegende Symptome auftreten. Unter anderem viele Herz- und Zuckerkranke benutzendeshalb tragbare Sensoren, um gewünschte Werte jederzeit messen zu können. Dabei existiertjedoch eine große Zahl von Geräten von unterschiedlichen Herstellern. Gemessene Daten sind beieiner 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 In-stanz für persönliche Gesundheitsdaten. Solche Systeme ermöglichen dem Benutzer, jederzeitseine Vitalwerte zu überwachen. Dies kann damit sowohl im Krankheitsfall, als auch vorbeugenderfolgen.
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 Systemeerlä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 Sensorenverwendet werden. Diese oft sehr günstigen Geräte besitzen meist nur schlechte Darstel-lungsmöglichkeiten, begrenzten Speicherplatz und keine Sicherung gegen Geräteverlust oder De-fekt.
Deshalb ist es wünschenswert, aufgenommene Daten zu einem zentralen Datenspeicher zu trans-ferieren. Der Datentransfer kann kabelgebunden oder drahtlos erfolgen. Diese Rolle nimmt dersogenannte Health Manager ein, einer auf einem Rechner installierten Software-Platform. Alsganzheitliches System versucht der Health Manager möglichst alle gesundheitsrelevanten Vital-
3
Kapitel 2 Healthmanager 4
werte zu erfassen. Dies hat den Vorteil, dass eventuelle Parallelen zwischen verschiedene Wertenerkannt werden können. Außerdem kann auch der Messwertverlauf über kürzere oder längereZeiträume dargestellt werden. Dieser ist meist wichtiger als Einzelwerte.
Einem Datenverlust kann durch Synchronisation mit Onlinediensten vorgebeugt werden. Dieshat außerdem den Vorteil, dass Daten von überall abrufbar sind. Da so gemessene Daten leichtan andere Instanzen, also z.B. Ärzte oder Therapeuten, weitergegeben werden können, ist einederatige Datenaufnahme Grundlage für Telemedizin. Im Folgenden werden zunächst existierendeLö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 Ma-nager Applikationen. Im folgenden werden einige ausgewählte unter Android lauffähige Systemevorgestellt und deren Merkmale genannt.
2.2.1 Garmin
Die Trainingsdaten- und Healthmanagerplattform Garmin Connect ist auf Fitnesstrainingfokussiert. Die Daten werden vom jeweiligen Fitness- oder Medizinmessgerät hochgeladenund online gespeichert. Hier können per Webinterface die Daten graphisch analysiert undTrainingspläne erstellt werden. Geplant werden können auch Lauf- oder Fahrradstrecken, sowieTrainingsziele und andere Aktivitäten. Momentan existieren diverse Trainingsgeräte, sowie alsmedizinisches Messgerät eine Waage. Außer durch hochladen können Vitalwerte auch manuelleingegeben werden. Mit Garmin Fit existiert auch eine Applikation für Android, die Daten vonGarmin Connect anzeigen kann.
2.2.2 Ubiquitous Personal Health Surveillance and Management System
Das Ubiquitous Personal Health Surveillance and Management System [3] ist einHealthmanagement-System für Android-Mobilgeräte, das Gesundheitsdaten von drahtlosenSensoren empfängt. Dies erfolgt über einen ZigBee-Empfänger, der entweder über USB oderBluetooth die Daten an das Smartphone weiterleitet.
Die empfangenen Daten werden dabei verschlüsselt über die Internetverbindung des Smartphoneszu einem zentralen Datenspeicher übertragen. Um die gespeicherten Serverdaten zu teilen,kann man Berechtigungen an zugelassene Personen wie Ärzte, Verwandte, Freunde und Pflegervergeben. Außerdem werden bei Überschreitung gesundheitskritischer Grenzwerte automatischAlarmmeldungen versandt, versehen mit entsprechenden Standortdaten des Smartphones.
Kapitel 2 Healthmanager 5
Als systemkompatible Sensoren werden verschiedene gewerblich erhältliche Sensoren genannt.Das sind sowohl ein Sensor für Elektrokardiogramme, Elektromyographien und Elektroenzephalo-grafien, 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 dannam Rechner, der UPHSM Agent dient lediglich zur Datenaufnahme und Datenübergabe. Außer-dem ist eine Weiterleitung der Vitaldaten an kompatible Applikationen direkt am Smartphone sonicht vorgesehen. Das UPHSM ist somit vornehmlich an pflegebedürftige, chronisch Kranke undSenioren 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 AndroidPlattform an. Das System fokussiert sich auf die Aufnahme und Analyse elekotrokardiographischerDaten unter der Verwendung eines Wireless Sensor Networks (WSN).Der im Brustgürtel des Health Shirt enthaltene ECG-Sensor überträgt die Daten drahtlos unterVerwendung des Standard IEEE 802.15.4. Die Empfangsstation am Mobiltelefon ist als WirelessDongle 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.1zu sehen, angezeigt. Die Übertragung und Anzeige geschieht in Echtzeit, außerdem kann zwischenbloßer Darstellung der Wellenform und Datenanalyse gewählt werden.
Das System bietet weiterhin mit der Personalied Medicine Care Assistance einen personalisiertenQR-Code Scanner speziell für Medikationen an. Entsprechend an der Medikation angebrachteCodes kann man dabei über die im Mobiltelefon integrierte Kamera dekodieren und somit iden-tifizieren. Durch Verlinkung auf die entsprechende Url werden auch nichtvisuelle Inhalte wie
Kapitel 2 Healthmanager 6
Audiodateien dargestellt. Dies kann eine hilfreiche Stütze für Blinde oder visuell eingeschränkteMenschen sein.
Mit dem ECG als derzeit einzigem Sensor ist das System vornehmlich zur Vorbeugung vonHerzkrankheiten 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 Blut-druckwerten. Dabei müssen gemessene Daten manuell am Smartphone eingegeben werden.Berichte können im Tabellenformat via Email an den Hausarzt übermittelt werden. Außerdemist es mit dieser Applikation möglich die Daten statistisch auszuwerten. Zusätzlich existiert eineErinnerungsfunktion, die regelmäßige Messungen unterstützt. Die Applikation ist dabei jeweilsals Lite- und Vollversion erhältlich. Ein Funktion zur direkten Datenaufnahme von drahtlosenSensoren ist nicht vorhanden.
2.2.5 Blutdruck Logbuch
Ähnlich wie die Blutdruck-Applikation Blutdruck aus Abschnitt 2.2.4 müssen auch im Blutdruck-Logbuch [6] Daten manuell eingegeben werden. Bei einer Messung werden dabei neben Messdatenund Messzeit auch der Messort abgespeichert. Außerdem ist es auch möglich Herzfrequenz undGewicht hinzuzufügen. Die Datenexportfunktion unterstützt verschiedene Formate und kann zurDarstellung der Vitaldaten in Fremdprogrammen genutzt werden. Eine kostenpflichtige Pro Ver-sion 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 emp-fangen und darzustellen. Bei der Messung wird dabei auch das Verhältnis zwischen Fett- undMuskelmasse bestimmt. Dabei werden der Body Mass Index (BMI) berechnet und Orientierungs-bereiche angezeigt. Die Messwerte werden unter Nutzung von IEEE 802.11b/g per Wlan über-tragen. 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 direktauf dem Onlinedienst Twitter veröffentlicht werden. Neben der Android-Applikation existiert auchentsprechende Software für Mac, PC, iPhone oder iPad.
Kapitel 2 Healthmanager 7
2.3 Biocomfort Health Manager Plattform
Nach den bisher genannten Health Manager Lösungen wird nun auf die Biocomfort Health Manag-er Plattform eingegangen. Biocomfort bietet mit der Health Manager Plattform ein umfassendesSystem zur Erfassung von Gesundheitsdaten an. Dieses besteht aus einer Familie von Messgerätenzur Aufnahme und Softwareprogrammen- und Diensten zur weiteren Verarbeitung der medizinis-chen Messdaten. Zur drahtlosen Datenübertragung mit dem IEEE 802.15.4 Standard wird einWireless Gateway genutzt.
Biocomfort bietet dabei im Gegensatz zu allen anderen Lösungen offene Programmierschnittstellenan. Mit diesen Programmierschnittstellen, dem Biocomfort Health Manager SDK, können variabelBenutzerprogramme für verschiedene Plattformen erstellt werden. Dieses SDK wurde bei derEntwicklung 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 Mes-sung am Handgelenk, Blutzuckermessgerät mit mitgelieferter Einstichhilfe zur hy-gienischen Messung, sowie Diagnosewaage zur Bioelektrischen Impedanzanalyse
Zur Messung von Vitaldaten sind unter der Biocomfort Health Manager Plattform verschiedeneMobilsensoren zur Datenaufnahme verfügbar. Dies sind derzeit sowohl ein Blutdruck- undBlutzuckermessgerät, sowie eine Diagnosewaage zur Bioelektrischen Impedanzanalyse. Den Mess-geräten liegt ein einheitliches Bedienkonzept zugrunde, das die Bedienung für den Erstbenutzervereinfacht. Alle Geräte besitzen ein LCD-Display zur Darstellung von Geräte-, Mess- und Be-nutzerdaten. Messdaten können dort einzeln oder als Durchschnittswert für 7, 14, 21 oder 28 Tagedargestellt werden. Bei überhöhten Werten werden nach der Messung Warnungen am jeweiligenMessgerät ausgegeben. Zur Verwaltung von Messwerten für verschiedene Personen können bis zu8 verschiedene Benutzerprofile auf den Geräten erstellt werden. Die Messwerte werden jeweils beider Messung mit einem Zeitstempel und entsprechender Benutzernummer versehen.
Kapitel 2 Healthmanager 8
Blutdruckmessgerät
Die Blutdruckmessung mit dem tenso-comfort Blutdruckmessgerät erfolgt im oszillometrischenMessverfahren am Handgelenk. Dabei pumpt das Gerät bei der Messung automatisch Luft zuoder ab. Der intere Messwertspeicher kann mehr als 112 Messungen abspeichern. Ein einzelnerMesswert besteht dabei (neben Zeitstempel und Benutzernummer) je aus systolischem Blutdruck,diastolischem Blutdruck sowie dem gemessenen Puls. Bald ist alternativ auch ein Sensor zurBlutdruckmessung am Oberarm erhältlich.
Blutzuckermessgerät
Das gluco-comfort Blutzuckermessgerät bestimmt den quantitativen Blutzuckerwert im amper-ometrischen Messverfahren. Zur hygienischen Gewinnung eines Blutstropfens ist neben demeigentlichen Messgerät eine Stechhilfe mit austauschbaren Einstichnadeln vorhanden. Die Messungerfolgt durch Einführung von Messstreifen und dauert etwa 10 Sekunden. Der interne Messwert-speicher von gluco-comfort reicht für 122 Messungen.
Diagnosewaage
Die scaleo-comfort Diagnosewaage nimmt bei der Messung neben dem Gewicht weitere Vitalw-erte auf. In der Bioelektrischen Impedanzanalyse werden über den Wiederstandswert Körperfett,Körperwasser und Muskelmasse bestimmt. Diese sind für die Ermittlung eines aussagekräftigerenGewichtswertes nützlich, da z.B. durch Wasseraufnahme bzw. Abgabe die Körpermasse verfälschtwird. Gespeichert werden können bis zu 44 Messungen, der Messbereich bewegt sich zwischen 10und 150 kg.
2.3.2 Biocomfort Health Manager Software Development Kit
Für vergleichbare Peripheriegeräte mit Softwareanbindung, wie die drahtlosen Messgeräte vonBiocomfort, wird zur Datenaufnahme und Kommunikation lediglich ein proprietäres Softwarepaketangeboten. Derartige Softwarepakete sind oft auf wenige Plattformen und auf Peripheriegeräteder beteiligten Partner beschränkt. Dadurch ist die Integration von Hardwarekomponenten Dritternicht möglich, was eine Einschränkung auf Geräte des Herstellers bedeutet.
Als Alternative dazu werden von Biocomfort öffentliche Programmierschnittstellen in Form desHealth Manager Software Development Kit angeboten. Diese sind in den auf vielen Plattformenverbreiteten Programmiersprachen C und Java vorhanden. Das SDK bietet dabei Funktionen zurKommunikation 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
Kapitel 2 Healthmanager 9
Problemen, weitergeleitet. Darüberhinaus kann über das SDK die Konfiguration der Medizingeräteeingestellt,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 Beispielpro-gramme 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 Android-Smartphones beschrieben. Weiterhin wird auf Eingriffe ins Android-System eingegangen, diespeziell 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 mitmehreren Hardware- und Softwareanbietern, sowie Mobilfunkpartnern, die Open Handset Alliance.Diese veröffentlichte am 1. Oktober 2008 das unter der Federführung von Google entwickelteSmartphone-Betriebssystem Android. Das Android-Betriebssystem (fortan “Android” genannt)steht unter der quelloffenen Apache-Lizenz. Neben dem Betriebssystem stellt Google das AndroidSoftware Development Kit (SDK) und das Android Native Development Kit (NDK) bereit. DasSDK bietet neben einer Reihe von Entwicklungstools eine in Java implementierte Programmier-schnittstelle (Application Programming Interface - API). Zusätzlich dazu können Applikationenmit dem NDK um Nativen Code ergänzt werden. Android-Mobiltelefone werden derzeit vonSmartphone-Herstellern wie Samsung, HTC, LG, Dell, außerdem von Google selbst in Kooper-ation mit anderen Herstellern, angeboten. In den USA machen Android-Mobiltelefone derzeitknapp 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, Biblio-theken, Laufzeitumgebung, Application Framework und Anwendungen. Dieser Aufbau ist in Ab-bildung 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] freiheruntergeladen [12] und modifiziert werden. Der Kernel ist dabei für die Speicherverwaltung,Prozessverwaltung, Sicherheit, Lastverteilung und E/A-Operationen zuständig. Der Kernel stelltauß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 mitder Android-Laufzeitumgebung die Schicht oberhalb des Kernels. Diese Bibliotheken werden
Kapitel 3 Applikationsentwicklung unter Android 12
zur Beschleunigung rechenintensiver Anwendungen von höher gelegenen Schichten aufgerufen.Rechenintensive Anwendungen sind z.B. das Abspielen von Medien, Seitenrendering im Web oderbeschleunigte 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 DalvikVirtual Machine (VM). Diese registerbasierte Virtuelle Maschine ersetzt die Standard Java VM.Durch die hardwarespezifische Optimierung des Java-Bytecodes ist die Ausführung mehrerer VM-Instanzen resourcenschonender und benötigt weniger Speicher als die Java VM.
Android Application Framework
Das Android Application Framework bildet einen Satz von Systemkomponenten, die zur Anwen-dungsentwicklung genutzt werden. Diese liegen als Klassenbibliotheken in der ProgrammierspracheJava vor. Enthalten sind unter anderem Klassen für GUI, Datenaustausch, Einbindung von Re-sourcen, Systemdienste und Hardwarekomponenten.
Applikationen
Anwendungen bilden die für den Benutzer sichtbare höchste Schicht im Betriebssystem. AlsZugriffsschutz 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++-Codeergänzt werden. Mit Android Lighthouse [13] existiert auch die Möglichkeit, native Applikationenmit Qt/C++ zu erstellen.
3.1.2 Android-Applikationen
Der Android Application Framework stellt einige Grundkomponenten zur Applikationserstellungund Android bereit. Hier werden einige ausgewählte erklärt.
Activities
Eine Activity ist eine Komponente der Benutzeroberfläche. Normalerweise repräsentiert eine Ac-tivity 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 An-wendung besteht aus Activities, zwischen denen man während der Ausführung wechseln kann. Fürjede Anwendung ist zwar eine Einstiegs-Activity definiert, im Gegensatz zu Desktopanwendungen
Kapitel 3 Applikationsentwicklung unter Android 13
gibt es jedoch keine Main-Funktion. Jede Activity kann über Intents von anderen Anwendungenaufgerufen werden, sofern diese die entsprechende Berechtigung besitzt.
Services
Zur Ausführung von Aufgaben im Hintergrund kann ein Service definiert werden. RechenintensiveProzesse können hier ausgelagert werden, um das UI nicht zu blockieren. Services werden nachBeendigung der Anwendung, die ihn startete, nicht gestoppt. Es wird zwischen Started Servicesund 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 einemBound Service. Diese Client-Server Verbindung ermöglicht eine zweiseitige Kommunikation. Auchapplikationsfremde Services oder Activities können sich so mit dem Service verbinden und Datenmit ihm austauschen.
Intents
Intents sind Nachrichten, die zum Starten von Activities und Services vom System oder von An-wendungen verschickt werden. Es ist möglich, serialisierte Anwendungsdaten an diese anzuhän-gen. Intents können sowohl Komponenten der eigenen Anwendung als auch externe Komponentenstarten. Somit können anwendungsfremde Komponenten in die eigene Applikation eingebaut wer-den, ohne diese neu zu implementieren. Zum Export kann man mit Intent-Filtern dem Systemmitteilen, welche Intents durch die Applikation bearbeitet werden können.
AIDL-Interfaces
Das Android Interface Definition Language (AIDL) erlaubt es eine Programmierschnittstelle zuerstellen, auf die sich sowohl Client, als auch Server einigen, um mit IPC miteinander zu kom-munizieren. In AIDL-Dateien können Remote Procedure Calls (RPCs) vereinbart werden, die voneinem Client aus aufgerufen werden können.
Kapitel 3 Applikationsentwicklung unter Android 14
Resourcen
Resourcen werden zur deklarativen Gestaltung bestimmter Anwendungskomponenten verwendet.Android kennt verschiedene Arten von Resourcen, meist in XML-Dateien formuliert, die die Pro-grammierung und Wiederverwendbarkeit des Codes steigern sollen.Android bietet unter anderem Resourcen für Animationen, Farbdefinitionen, Rastergrafiken, Lay-outs, 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 wirdManifestdatei (AndroidManifest.xml) der Anwendung genannt.In dieser werden Activities, Services und weitere Komponenten registriert und Berechtigungendeklariert. Zusätzlich können hier die Eigenschaften der Anwendung selbst oder auch ihrer Kom-ponenten (Activity oder Services) festgelegt werden. So kann z.B. eingestellt werden, ob dieAnwendung 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 undjedem Androidgerät lauffähig, jedoch unter einigen Vorraussetzungen. Momentan ist die Applika-tion 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 Bio-comfort für die entsprechende Hardware kompiliert werden. Außerdem muss der Kernel des Gerätsdie Biocomfort-Hardware in Form des USB-Gateways unterstützen. Damit ist das Vorhandenseinentsprechender Treiber und Treibermodi erforderlich. Der größte Teil der Entwicklung erfolgteneben anfänglichen Tests im Emulator am Samsung Nexus S, das alle besagten Vorraussetzungenerfüllt.
3.2.1 Rooting
Android benutzt das Rechtemanagement des Linux-Kernels applikationsbezogen, d.h. für jedeApplikation wird bei der Installation ein neuer User erstellt. Die Applikation kann somit nur aufapplikationseigene, nicht jedoch auf Systemdaten, oder die Daten anderer Applikationen zugreifen.Die Kommunikation zwischen Applikationen erfolgt über Schnittstellen des Android ApplicationFramework. Nun existiert unter unixoiden System neben normalen Usern immer auch ein User, der
Kapitel 3 Applikationsentwicklung unter Android 15
Berechtigungen hat auf alle Dateien zuzugreifen. Bei den meisten Desktop-Linuxdistributionenist 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 erheblichesSicherheitsrisiko. Einerseits besteht dabei die Gefahr, dass das System durch Eingriffe unbenutzbarwird. Andererseits kann die Sicherheit der in Applikationen gespeicherten Benutzerdaten nichtmehr garantiert werden. Beim Rooten erlischt meist die Herstellergarantie, somit ist bei Nicht-Entwicklungsgeräten davon abzuraten.
Das Rooting ist bei der Entwicklung in vielerlei Hinsicht nützlich, als auch erforderlich. EinigeApplikationen können erst nach erfolgtem Rooting genutzt werden. Darüberhinaus kann mit Admi-nistratorrechten auch per Shell auf Applikationsdaten, wie im hier beschriebenen Anwendungsfall,z.B. der Zugriff auf SQLite-Messwertdatenbanken zugegriffen und diese zu Debugging-Zweckeninspiziert 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ündenerforderlich. Zunächst mussten Konfigurationsdateien auf der Systempartition eingespielt werden.Außerdem wurde dort auch das FTDI-Kernelmodul abgelegt, um dies beim Systemstart automa-tisch zu laden. Weiterhin war es nötig, Geräteknoten neu zu erstellen und zu verlinken. OhneRoot-Rechte ist außerdem kein Wireless Debugging möglich, was die Entwicklung sehr stark behin-dern 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 Modusumschalten kann, muss dies als Root manuell erledigt werden.
Für verschiedene Geräte existieren verschiedene Methoden zum Rooten. Eine Möglichkeit wärez.B., eine modifizierte Firmware mit Rootrechten zu flashen. Beim Nexus S ist die einfachsteMethode, ein Recoveryprogramm zu installieren, über das manuelle Systemupdates eingespieltwerden können. Als Recoverytool dient meist ClockworkMod (siehe Abbildung 3.2), über das einSuperuser-Paket installiert wird.
3.2.2 Kernel
Die gesamte Gerätekommunikation erfolgt bei Android als linuxbasiertem System über Treiber imLinuxkernel. Da der Linuxkernel eine große Masse von Hardware unterstützt, würde die Größe desKernels bei der Integration aller Treiber sehr stark anwachsen.Deshalb können Treiber über sog. Module aus dem Kernel ausgelagert werden, die erst im laufend-en 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 nichtkompiliert wird.
Kapitel 3 Applikationsentwicklung unter Android 16
Abbildung 3.2: Über Clockworkmod können manuelle Updates wie z.B. ein Superuser-Paket zumRooten 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 Verwen-dung des USB-Gateways unter Android ist somit einerseits ein Treiber für externe USB-Gerätegenerell, außerdem ein Treiber für den FTDI-Chip nötig. Da beide Treiber in ICS-Standard nichtvorhanden 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ähigerTreiber für USB-Gadgets im Host-Modus vorhanden. Deshalb wurde ein modifizierter Kernel vomUser sztupy des XDA-Developers Forum [16] benutzt. Der USB-Hostmode Treiber ist offiziellzwar derzeit noch nicht verfügbar, jedoch in den Kernelquellen für einige Tablets von Samsungunter 2.x und 3.x vorhanden. Dieser Treiber wurde nach Android 4.0 portiert und damit in denKernel 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 Kernelkonfig-uration und Kompilierung erfolgt analog zu Standard-Linux, jedoch muss die Kompilierung mitder Crosscompiler-Toolchain aus dem Android NDK, den Android-Entwicklungstools für nativenCode und für die entsprechende Gerätearchitektur erfolgen.
Kapitel 3 Applikationsentwicklung unter Android 17
Zum dynamischen Umschalten zwischen beiden Treibermodi(USB-OTG/Client) kann die Applika-tion 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 zwischenOn-the-go und Client Modus umgeschalten werden
3.3 Geräte- und Applikationssetup
Aufgrund anderer Bedingungen am Android-System auf Mobilgeräten waren einige Anpassungennötig. Das war einerseits das Setup vorhandener Hardwarekomponenten, andererseits die Hand-habung der Gerätekommunikation.
3.3.1 Gerätesetup
Zum Betrieb von USB-A-Geräten ist eine USB-A Buchse notwendig. Einige Tablets verfügenbereits über einen USB-Anschluss, Mobiltelefone werden standardmäßig ohne hergestellt. Wiedas Nexus S verfügen die meisten stattdessen über eine MicroUSB-Buchse, die in Verbindung miteinem Adapter genutzt wird.
Darüberhinaus versorgt die MicroUSB-Buchse an das Nexus S angeschlossene Geräte (wie andereUSB-Host-Geräte, also z.B. PC’s) nicht mit Strom. Dies ist im Betrieb als USB-Client auch nichtnotwendig, da das Mobilgerät vom Host versorgt wird.Diesen Zweck erfüllte am Nexus S stattdessen ein USB-Split-Kabel, wobei der zweite USB-Male Stecker an externe Stromversorgung angeschlossen wird. Außerdem ist mit dem genutzten
Kapitel 3 Applikationsentwicklung unter Android 18
Hostmode-Treiber laut Entwicklerangaben ein Hub nötig. An diesen kann nun der BiocomfortUSB-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 draht-losen Medizingeräten ( Abbildung 3.5 ). Dazu muss er Daten über das Gateway senden, empfangenund 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 Emp-fang 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 inAbbildung 3.6 dargesellt.
Kapitel 3 Applikationsentwicklung unter Android 19
Abbildung 3.5: USB-Dongle und Medizingeräte
Abbildung 3.6: Übersicht der Programmfunktion
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. Zuletztwerden Beschränkungen des Systems diskutiert.
4.1 Anforderungen
Ein Healthmanager muss bestimmte Anforderungen erfüllen. In erster Linie geht es bei einemHealthmanager um die Haltung der persönlichen Vitaldaten. Hierbei macht es keinen Unter-schied, ob die Daten am Telefon, am Rechner oder in der Cloud gespeichert werden. Für dieImplementierung mit Android sollen deshalb folgende Anforderungen erfüllt werden:
• Der Healthmanager soll Daten von den Biocomfort Medizingeräten aufnehmen und abspe-ichern. Das soll automatisch und zuverlässig geschehen.
• Es soll eine Möglichkeit zur Visualisierung vorhanden sein, diese soll jedoch von der Date-naufnahme 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önnenGerätekonfigurationen geändert oder abgerufen werden.
• Auch andere Applikationen oder Dienste können Daten vom Health Manager abrufen undweiterverwenden.
• 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) undeiner GUI-Anwendung mit grafischer Oberfläche zusammen. Dabei ist die Service Application fürdie Aufnahme von Messdaten und die Kommunikation mit der mobilen Sensorik zuständig. DieGUI-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 Medi-zingeräten, statt den tatsächlichen Sensoren, kommunizieren. Zur Steuerung dieser vorgetäuschtenSensoreinheiten wird das zusätzlich entwickelte MockSDK GUI eingesetzt.
4.2.1 Service Application
Die Service Application handhabt die Kommunikation mit den medizinischen Messgeräten. Daneue Daten ständig eintreffen, sollte der Dienst permanent verfügbar sein, um diese aufnehmenzu können. Dies können Messdaten oder Konfigurationsdaten der Medizingeräte sein. Die Datensollten im Anschluss dauerhaft abgespeichert werden, wozu bei der Implementierung SQLite ver-wendet wurde. Eine weitere Anforderung ist, dass die Service Application mit anderen abrufend-en Anwendungen kommuniziert. Der Dienst interagiert mit einer unterschiedlichen Anzahl vonApplikationen, weshalb das Interface variabel erstellt werden muss. Eine sinnvolle Lösung fürdiese Anforderung ist, bei neuen Daten Broadcast-Meldungen an alle derartigen Applikationen zuschicken, um Updates zu signalisieren. Dann können diese über ein AIDL-Interface abgerufen wer-den. 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 einge-fügt. Zur low-level Kommunikation wurden C-Bibliotheken eingesetzt. Diese können in Java unterVerwendung von Java Native Interface direkt angesprochen werden.
Datenbank Management
Zur Speicherung aller Daten auch nach Beendigung des Dienstes bzw. Ausschalten des Gerätswerden diese in einer SQlite-Datenbank abgelegt. Dies geschieht je in einer Tabelle für Benutzer-Geräte- und die verschiedenen Typen von Messdaten.
Benutzerdaten Benutzereinträge, die über die UI-Applikation oder auch andere Applikationenerstellt wurden, werden hier abgelegt. Da die Biocomfort-Medizingeräte auf derzeit 8 Einträgebeschränkt sind, wurde dies auch in der Datenbank berücksichtigt. Beim Löschen eines Benutzerswerden alle zugehörigen Messdaten aus den entsprechenden Tabellen gelöscht.
Kapitel 4 Android Implementierung 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 gespei-chert. Die Identifikation geschieht hierbei über die eindeutige Geräte-Identifikationsnummer. Beineu erhaltenen Geräteparametern, also z.B. eine aktualisierte Gerätezeit, die bereits in der Daten-bank vorhanden sind, werden diese entsprechend ersetzt.
Messdaten Da sich die Messdaten durch die Zahl der gemessenen Parameter, bzw. den Da-tentyp unterscheiden, wurden die Messdaten in verschiedenen Tabellen gespeichert. Bei neuenMessdaten wird zuvor die Datenbank auf bereits vorhandene identische Datensätze befragt, umDoppeleinträge zu vermeiden.
Mock SDK
Der MockSDK bildet sowohl das Wireless Gateway als auch die Biocomfort-Medizingeräte inSoftware nach. Er stellt die selben Schnittstellen zur Verfügung wie die Java-Implementierung desHealth Manager SDK. Außerdem werden auch auftretende Übertragungsfehler simuliert. Mit ihmkann auch ohne passende Bibliotheken und Treiber die Datenbank, Interprozesskommunikationund GUI getestet werden. Das MockSDK kann vor allem für die Erweiterung auf andere Gerätenützlich sein.
Eine vorhandene Implementierung findet sich online zum Download [18]. Diese wurde nach An-
Kapitel 4 Android Implementierung 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 abrufenwollen. Außerdem ist eine Schnittstelle zur Kommunikation mit dem MockSDK vorhanden. Datenkönnen dort nach der Öffnung einer Verbindung über ein AIDL-Interface abgerufen werden. Wennneue Daten von den Geräten eintreffen, oder Daten in der Datenbank verändert werden, werdenper Broadcast Update-Benachrichtigungen verschickt.
SDK Interface
Das SDK-Interface kommuniziert mit den Medizingeräten. Dies geschieht über JNI und dieSchnittstellen des Health Manager C SDK. Die Geräte werden hier in einer Geräteliste zwischen-gespeichert und bei Bedarf neue Einträge erstellt. Bei Empfang neuer Messdaten, Gerätekonfigu-rationen oder Fehler wird der SDK-Manager über Events benachrichtigt. Diese Komponente kannzum Testen durch das MockSDK ausgetauscht werden.
SDK Manager
Der SDK-Manager nimmt Events vom SDK-Interface an und reagiert auf diese. Intern kommu-niziert er über Listener mit dem Communication Service und bearbeitet die dort ankommendenAnfragen weiter. Dabei verwaltet er die SQLite-Datenbank, d.h. er erstellt neue Datenbankein-träge, löscht Einträge oder aktualisiert vorhandene Einträge. Außerdem prüft der SDK Managerdie Datenbank auf bereits vorhandene Einträge.
Java Native Interface
Als Kompatibilitätsschicht zwischen C und Java wurde “Java Native Interface” (JNI) (Abbildung4.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 wer-den muss. Da JNI ein zweiseitige Schnittstelle ist, unterstützt es sowohl native Bibliotheken alsauch native Anwendungen (Abbildung 4.2 ).
Java-Anwendungen rufen native Methode in der gleichen Art wie in Java implementierte Funk-tionen auf, im Unterschied dazu jedoch liegen diese Funktionen in Nativen Bibliotheken vor.Javaklassen werden dabei mit spezieller Namenskonvention auf native Funktionen abgebildet.
Kapitel 4 Android Implementierung 24
Abbildung 4.2: Funktion von Java Native Interface als Anbindung für Nativen Code in Java-Applikationen
Eine einfaches Interface zum nativen Methodeaufruf ist in Listing 4.1 dargestellt. Dabei wirdzunächst eine native Methode in C implementiert und diese dann von Java aus aufgerufen.
Listing 4.1: Aufruf von nativen Methoden über JNI∗ Nat i v e Imp l ement i e rung i n C∗/
#i n c l u d e < j n i . h>j b oo l e a n Java_com_biocomfort_jn i_JavaClass_nat iveMethod ( . . . ) {
r e t u r n t r u e ;}/∗
∗ Nat i v e Methode im Java−Code a u f r u f e n∗/
package com . b i o comfo r t . j n i ;p u b l i c c l a s s J a vaC l a s s {
p r i v a t e n a t i v e boo l ean nat iveMethod ( ) ;p r i v a t e s t a t i c vo i d main ( S t r i n g [ ] a r g s ) {boo l ean r e t v a l = nat iveMethod ( ) ;}
}
JNI unterstützt es außerdem, die Java Virtual Machine Implementation in nativen Code einzu-binden. Native Programmteile können mit der JavaVM kommunizieren, und eine Schnittstelle zumAusfü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 vordem Aufruf unter anderem die JavaVM und die aufzurufenden Java-Methoden gefunden wer-den. Beim Aufruf muss sich das native Programm den neuen Programmthread zunächst bei der
Kapitel 4 Android Implementierung 25
laufenden Instanz der JavaVM registrieren, sowie danach wieder abmelden.
Listing 4.2: Native Callbacks
/∗∗ Methode i n Java d e f i n i e r e n∗/
p u b l i c c l a s s J a vaC l a s s {p r i v a t e vo i d javaMethod ;
}
/∗∗ Java Methode aus 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>// Ze i g e r au f JavaVM , muss i n de r n a t i v e n Anwendung i n i t i a l i s i e r t werdenJavaVM ∗g_vm ;vo i d c a l l b a c k ( ) {// JNI i n t e r f a c e Po i n t e rJNIEnv ∗g_env ;// R e g i s t r i e r e n b e i de r Ak t u e l l e n I n s t a n z de r JavaVM(∗g_vm)−>AttachCur rentThread (g_vm , &g_env , NULL ) ;// Na t i v e r Methodenauf ru f(∗ g_env)−>Cal lVo idMethod ( . . . , javaMethod , arguments ) ;// D e r e g i s t r i e r e n(∗g_vm)−>DetachCurrentThread ( ) ;}
vo 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 ni n i t ( ) ;// Java Methode über Ca l l b a c k a u f r u f e n ;c a l l b a c k ( ) ;
}
Somit kann die Java-Applikation aktiv Gerätedaten mit Methodenaufrufen im Health ManagerC-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 überin Java verbotene Zeiger ausgelesen werden.
Kapitel 4 Android Implementierung 26
Mit diesem Mechanismus alleine können nur durch Polling der SDK-Zustand oder z.B. Informatio-nen ü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 nundurch SDK-Funktionen an ensprechende Java-Events gebunden werden (Abbildung 4.3, 2 ). Dadiese sogenannten “Callbacks” von der Nativen Applikationen gesteuert sind, müssen sie in einemeigenen Thread gestartet werden. Um dies zu ermöglichen, muss der neue Thread manuell bei derJava 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 sowohlnative C-Funktionen in Java, als auch umgekehrt Java-Funktionen über Callbacksin C ausgeführt werden
4.2.2 GUI Application
Die GUI-Applikation stellt die von der Service Application empfangenen Daten grafisch dar. Smart-phones werden, anders als Personal Computer, meist nur von einem Benutzer, nämlich dem Be-sitzer bedient. Dies sollte auch bei Endbenutzeranwendungen berücksichtigt werden.Deshalb werden in der Applikation nie alle Benutzerdaten gleichzeitig angezeigt, da beim Start einBenutzer gewählt werden muss. Daraufhin werden die Daten des gewählten Benutzers angezeigt.Ein zentraler Hintergrunddienst verwaltet die Daten der Applikation.
Kapitel 4 Android Implementierung 27
Hintergrunddienst
Der Hintergrunddienst ist für den Datenabruf und deren Verwaltung zuständig. Da z.T. iden-tische Daten in den verschiedenen Visualisierungen dargestellt werden, wäre ein direkter Abrufredundant. Der Dienst bildet die Schnittstelle zur Service Applikation und empfängt Update-Benachrichtigungen über Intents. Daraufhin werden die neuen Daten über ein AIDL-Interfaceabgerufen und an gerade laufende Programmkomponenten weitergegeben.
Benutzerauswahl
Die Benutzerauswahl wird anfangs aufgerufen, um den entsprechenden Benutzer zu selektieren (4.4links). Nicht mehr benötigte Benutzer können bei Bedarf gelöscht werden. Außerdem besteht dieMöglichkeit, neue Benutzer zu erstellen. Dazu müssen die Daten des neuen Benutzers eingegebenwerden (4.4 rechts).
Abbildung 4.4: Benutzerauswahl und Benutzererstellung
Viewpager
Zur Visualisierung der von der Service Applikation empfangenen Daten wird ein Viewpager einge-setzt, der eine intuitive Bedienung ermöglicht. Damit kann die Bildschirmseite per Wischgeste
Kapitel 4 Android Implementierung 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 Dia-grammansicht 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 diegemessenen Werte in Reihenfolge der Messung dargestellt. Die dargestellte Datenmenge kann beiallen 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ächeerstellt (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 Android-Gerät zwischen verschiedenen Applikationen umschalten zu müssen.Bei der Verwendung kann zunächst die IP des Zielgeräts eingegeben und dann eine Verbindungerstellt werden. Nach Verbindung ohne Fehler können nun verschiedene Events im MockSDKausgelöst werden. Per Klick kann z.B. das Anstecken bzw. Abziehen des USB-Gateways simuliertwerden. Außerdem ist ein An- und Abschalten der Medizingeräte im MockSDK möglich. Zusätz-lich 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-
Kapitel 4 Android Implementierung 29
Abbildung 4.6: Diagrammansicht je für Blutdruck-, Blutzucker und Waagenmessung
Abbildung 4.7: User Interface zur Steuerung des MockSDK
Kapitel 4 Android Implementierung 30
Interface genutzt.
4.3 Probleme
In diesem Abschnitt wird auf Schwierigkeiten eingegangen, die während der Entwicklung aufge-treten sind. Diese ergaben sich sowohl wegen der speziellen Hardwarekonfiguration, andererseitsdurch Einsatz von plattformfremden Softwarekomponenten. Weitere traten wegen nicht behobenerFehler in Android selbst auf.
4.3.1 Android Umgebung
Wireless Debugging
Kabelgebundenes Debugging ist bei Verwendung des USB-Gateways und einem USB-Slot nichtmehr möglich. Deshalb wurde zum Debugging stattdessen die drahtlose Android Debug Bridge(ADB-Wireless) verwendet [21]. Nach langwieriger drahtloser Programminstallation weißt auchder Debugger lange Reaktionszeiten und viele Abbrüche auf. Vor allem das Übertragen vongrößeren Datenmengen wird stark verlangsamt.
Geräteberechtigungen
Um auf die Gerätedatei des Gateways zugreifen zu können, müssen entsprechende Berechtigun-gen für die Applikation vorhanden sein. Da die Gerätedateien bei jeder Einbindung neu erstelltwird, muss direkt bei der Einbindung eine solche Berechtigung vergeben werden. Standardmäßigkann 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 zurEinsparung von Speicherplatz auf den udev-Dienst verzichtet. Stattdessen werden Berechtigun-gen ü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 Berech-tigungen zu setzen, musste das gepackte initramfs des Android-Gerätes modifiziert und neu aufge-spielt werden.
Kapitel 4 Android Implementierung 31
Application Framework
Neben dem regulären Application Framework können in Applikationen zusätzliche Bibliothekenzur Rückwärtskompatibilität (Support-Packages) eingebunden werden. Dabei werden einige Kom-ponenten des Application Framework reimplementiert, um die Funktionalität auf älteren Android-Versionen zu garantieren. Dabei existieren Support-Packages je für einschließlich API-Version 4und API-Version 13.Die Reimplementierung oder Ersetzung dieser Klassen kann dabei zu Doppeldeutigkeiten undInkompatibilitä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 be-hebbaren Programmabstürzen führen. Um diese zu beseitigen, wurden die Support-Packages neuerstellt. Somit werden derzeit leicht modifizierte Bibliotheken verwandt, wobei die manuellenFehlerbehebungen (Bugfixes) bei jedem Update neu eingespielt werden müssen. Die Benutzungeines Viewpagers, wie in Sektion 4.2.2 genannt, erfordert die Einbindung der Support-Packagesfü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. Diestattdessen 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 diesenahtlos im Biocomfort Health Assistant eingesetzt werden.
4.4 Beschränkungen
Der Biocomfort Health Assistant stellt ein funktionsfähiges Health Manager System dar. Jedochunterliegt die aktuelle Implementierung Beschränkungen in einigen Punkten. Diese sind einerseitsdurch den begrenzten Rahmen einer Studienarbeit, andererseits durch die Neuentwicklung auf derAndroid-Plattform bedingt. Im folgenden werden einige erläutert.
Kapitel 4 Android Implementierung 32
4.4.1 Stabilität
Der Biocomfort Health Assistant läuft im allgemeinen stabil. Probleme verursachen Abstürze desAndroid-Systems und des USB-Hostmode Treibers.
Android
Das während der Entwicklung eingesetzte Android 4.0.3 sowie der Kernel weißen noch relativviele Programmfehler (Bugs) auf. Dies zeigt sich noch recht häufig durch Einfrieren des Systemsoder ungewollte Neustarts. Da Fehler durch Bugfixes und Systemupdates relativ schnell behobenwerden, ist eine baldige Besserung zu erwarten. Schon im vor kurzem erschienene Update zu 4.0.4wurden viele Bugs entfernt.
USB-Hostmode Treiber
Der genutzte Hostmode-Treiber ist nicht besonders stabil, außerdem bei der Geräteerkennung nochrecht unzuverlässig. Einige USB-Geräte werden nicht erkannt, außerdem muss zwischen USB2.0und USB1.1-Geräten umgeschaltet werden. USB-Geräte müssen teils mehrfach angeschlossen undwieder 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 bedingtmö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, dasggf. 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ätenkeine Stromversorgung. Deshalb muss die USB-Anschlussleitung extern mit Strom versorgt wer-den. Somit ist momentan wegen diesem zusätzlich nötigen Stromanschluss noch kein vollständigmobiler Betrieb möglich.
4.4.3 Funktionsumfang
Um den Biocomfort Health Assistant als komplett eigenständiges System zu nutzen, sollte man aufalle Daten der medizinischen Messgeräte zugreifen können. Dazu bietet der Health Manager SDKviele verschiedene Methoden und Schnittstellen an. Da sich die derzeitige Implementierung auf dieBasisfunktionalitäten beschränkt werden einige SDK-Funktionen noch nicht verwendet. Derzeit
Kapitel 4 Android Implementierung 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 derzeitnicht vollständig garantiert werden. Dies liegt an den noch nötigen Root-Rechten zum Betrieb desBiocomfort Health Assistant. Sobald diese nicht mehr erforderlich sind, ist die Datenbank automa-tisch vor direkten Zugriffen innerhalb des Android-Systems, also z.B. durch Fishing-Applikationengeschü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 Multitouch-Zooming berücksichtigt. Da noch keine Fallstudie erfolgt ist, können zum Bediencomfort und derAkzeptanz 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-Plattformzu finden. Dieses sollte als ganzheitliches Gesundheitssystem in der Lage sein, Vitaldaten vonmobilen Drahtlossensoren aufzunehmen. Dabei sollte das System erweiterbar sein und außerdemempfangene Daten für andere Applikationen zur Verfügung stellen.
Deshalb wurden zunächste bestehende Healthmanagersysteme analysiert. Nun sollte ein neuesSystem entstehen, das die genannten Anforderungen erfüllt. Als Basis für das neue System fürdie Android-Platform wurde das existierende Biocomfort Health Manager System ausgewählt.Ausgehende von diesem System wurden mit Hilfe des Health Manager SDK zwei Applikatio-nen für Android-Smartphones erstellt. Diese beiden bilden den Biocomfort Health Assistant fürAndroid. Dieser ermöglicht zunächst, ständig Einsicht in die Persönlichen Gesundheitsdaten zubehalten. 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 Smart-phone sein. Dazu stellt der Biocomfort Health Assistant anderen Applikationen, die Gesundheits-daten berücksichtigen, gemessene Vitaldaten zur Weiterarbeitung zur Verfügung.
Somit ist dies hoffentlich eine Möglichkeit, das allgemeine Wohlbefinden eines jeden Menschen zuverbessern und eine Hilfe, um schwerwiegenden Krankheiten vorzubeugen.
5.2 Ausblick
In diesem Abschnitt wird auf mögliche Erweiterungen des entwickelten Healthmanager-Systemseingegangen. 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 mo-difizierten Linuxkernel für das Nexus S, der einen USB-Hostmode Treiber bietet. Außerdem istexterne 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ütztwird, jedoch momentan mit Android 3.x nur unter einigen Tablets. Eine breite Unterstützungunter 4.x lässt noch auf sich warten. Da sowohl die Stabilität, als auch die Verbreitung derneuen Android-Version 4.x zunimmt, kann man auf eine baldige Integration hoffen. Mit derUnterstützung für den USB-Hostmode wird auch der microUSB-Port mit Strom versorgt. Dies istz.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 ohneHub 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 Sensoreneine wichtige Rolle. Durch ein größeres Angebot steigt die Attraktivität der Plattform. Deshalbwird die Sensorfamilie derzeit erweitert.
Als Alternative zur vorhandenen Körperfettwaage kommt sowohl eine Körperfettwaage mit er-weitertem Messbereich, als auch eine reine Körperwaage hinzu. Weiterhin steht bald ein Blut-druckmessgerät zur Messung am Oberarm bereit [22]. Denkbar wären z.B. auch noch Messgerätefü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 denBiocomfort Health Manager als ganzheitliches Gesundheitssystem verwenden zu können, solltedieser 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.
Kapitel 5 Zusammenfassung und Ausblick 36
ANT Der proprietäre ANT Drahtlosstandard wird durch Dynastream Innovations, einer Garmin-Tochter, vermarktet. Ant eignet sich durch niedrige Leistungsaufnahme und hohe Effizienz gutfür medizinische Sensoren. Sensoren können entweder über einen USB-Dongle oder direkt mitANT-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 eineErweiterung sinnvoll.
Bluetooth Bluetooth ist gemäß dem Industriestandard IEEE 802.15.1 für die Datenübertragungzwischen Geräten über kurze Distanz geeignet. Die meisten aktuellen Smartphones beinhaltenbereits entsprechende Schnittstellen, wodurch man nicht mehr auf externe Geräte wie ein USB-Gateway angewiesen ist. Bluetooth ist sehr verbreitet, unter anderem auch für drahtlose Medi-zinsensorik. In kürze werden auch Biocomfort Medizingeräte und das USB-Gateway optional mitBluetooth ausgeliefert [25].
Wireless LAN Die drahtlose Familie von lokalen Funknetzstandards IEEE-802.11 wird von na-hezu allen Android-Smartphones unterstützt. Zusätzliche Hardware, wie z.B. ein USB-Dongle istdeshalb 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], einemPersonal Trainer für Android, der für Übungen das smartphoneinterne Accelerometer in Verbindungmit 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 dieAlltagstauglichkeit ein. Die sinnvollere Alternative dazu ist der Empfang von Vitaldaten von einemHealth Manager System. Um dies zu ermöglichen, muss der Personal Fitness Trainer lediglich einentsprechendes Interface zum Datenempfang implementieren. Dies wäre im Falle des BiocomfortHealth Assistant ein AIDL-Interface und beschränkt sich auf wenige Dateien. Somit werden neuempfangene Daten automatisch an den Personal Trainer weitergeleitet und schon beim nächstenTraining berücksichtigt.
Kapitel 5 Zusammenfassung und Ausblick 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 kor-rekten Ausführung von Übungen. Hierbei wäre nun denkbar, zusätzlich parallel Vitalwerte wieHerzfrequenz 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 oderabzubrechen. Über gemessene Werte können zusätzlich kritische oder motivierende audiovisuelleAnregungen, wie bereits von Kranz et al. [29] vorgeschlagen, durch die Personal Trainer App-likation gesteuert werden. Dies unterstützt die richtige Ausführung von Übungen und stellt derenIntensitä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 Problemist, dass bei Datenaufnahme auf verschiedenen Geräten keine Synchronisation möglich ist. DieWeitergabe an andere beschränkt sich derzeit auf die direkte Einsicht am Smartphone. Weder eineÜberwachung von Pflegebedürftigen an entfernten Standorten, noch telemedizinische Anwendun-gen sind so möglich.
Alle diese Probleme können durch die Synchronisation mit einem Zentralen Speicherort gelöst wer-den. Diesen zentralen Speicher bildet hier ein Webserver, der bei bestehender Internetverbindungimmer erreichbar ist. Durch die geringe Datenmenge ist die Übertragung auch bei teils nochlangsamer Internetverbindung am Smartphone gut möglich. Dadurch kann auch durch telemedi-zinische Instanzen ein schneller Eingriff erfolgen.
Generell ist eine Anbindungen an jeden telemedizischen Webdienst möglich. Im Biocomfort HealthManager SDK sind Anbindungen zu den Diensten Aentos and Seniokom implementiert, welchesich 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 Aufnahmebestimmer Vitalwerte verordnet. Die Einhaltung dieser über mehrere Wochen kann vor allem imAlltag schwierig sein. Die Regelmäßigkeit der Messungen sollte deshalb durch Erinnerung undPlanung 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 erfol-gten Messungen abgeglichen und dem Benutzer somit Feedback darüber gegeben werden kann.
Kapitel 5 Zusammenfassung und Ausblick 38
Außerdem ist die direkte Anzeige von Erinnerungen am Smartphone über Systembenachrichtigun-gen möglich. Bei der Planung besteht nun die Möglichkeit, die Häufigkeit und zeitliche Verteilunggezielt auf die Wünsche des Benutzers, Verordnungen des Arztes oder die unterschiedlichen Sen-soren einzustellen. Die Gewichtsmessung kann z.B. einmal wöchentlich, die Blutzuckermessungmorgens und Abends erfolgen. Zusätzlich wäre eine Timerfunktion für die Einnahme von Medika-tion denkbar. Um geplante Messungen oder Medikamente mit anderen Kalenderdaten zu kom-binieren, kann diese Funktion mit bestehenden Diensten wie dem Google Calendar [30] zusamme-narbeiten.
Abbildungsverzeichnis
2.1 ECG Monitoring Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Biocomfort USB-Dongle und Messgeräte . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Architektur des Android-Betriebssystems . . . . . . . . . . . . . . . . . . . . . . 113.2 Clockworkmod Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 USB Hostcontroller Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 Übersicht Hardwarekonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5 USB-Dongle und Medizingeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.6 Übersicht der Programmfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 Aufbau Service Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Allgemeine Funktion von Java Native Interface . . . . . . . . . . . . . . . . . . 244.3 Einsatz von Java Native Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4 Benutzerauswahl und Benutzererstellung . . . . . . . . . . . . . . . . . . . . . . 274.5 Geräteübersicht, Messungsdetails und Messungsliste . . . . . . . . . . . . . . . . 284.6 Diagrammansicht je für Blutdruck-, Blutzucker und Waagenmessung . . . . . . . 294.7 MockSDK Gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
39
Literaturverzeichnis
[1] “Ärztezeitung.de,” mar 2012. http://www.aerztezeitung.de/praxis_wirtschaft/
praxisfuehrung/article/806535/verdachtsfaelle-berufskrankheiten.html [Let-zter Zugriff: 29. Mai 2012].
[2] “Welt Online,” mar 2012. http://www.welt.de/gesundheit/article13621508/
Herzleiden-sind-die-haeufigste-Todesursache.html [Letzter Zugriff: 29. Mai2012].
[3] Y.-H. Chu, Y.-C. Hsieh, C.-H. Wang, Y.-C. Pan, und R.-I. Chang, “Uphsm: Ubiquitous per-sonal health surveillance and management system via wsn agent on open source smartphone,”in e-Health Networking Applications and Services (Healthcom), 2011 13th IEEE InternationalConference on, Seiten 60 –63, june 2011.
[4] P.-C. Hii und W.-Y. Chung, “A comprehensive ubiquitous healthcare solution on an androidmobile 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 an-droid 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/ [Let-zter Zugriff: 9. Mai 2012].
[10] Linux Foundation, “Linux kernel source,” Mar. 2012. http://www.kernel.org/ [LetzterZugriff: 10. Mai 2012].
40
LITERATURVERZEICHNIS 41
[11] GNU Project, “Gnu general public license v2,” Mar. 2012. http://www.kernel.org/ [Let-zter 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 [LetzterZugriff: 19. Mai 2012].
[16] “XDA Developers Webforum,” mar 2012. http://forum.xda-developers.com/ [LetzterZugriff: 23. Mai 2012].
[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. Mai2012].
[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,” mar2012. 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, (SanFrancisco, 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 Commu-nications (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 andvisualization system - an example for the advancements in existing sports equipments,” In-ternational 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].
