Bachelorarbeit. im Studiengang Technische Informatik. von. Constantin Schomburg

Transkript

1 Gottfried Wilhelm Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Software Engineering Evaluierung einer Sensor-Simulationsumgebung zum Testen von Android-Anwendungen Evaluation of a Sensor Simulation Framework for Android Application Testing Bachelorarbeit im Studiengang Technische Informatik von Constantin Schomburg Prüfer: Prof. Dr. Kurt Schneider Zweitprüfer: Prof. Dr. Joel Greenyer Betreuer: Dipl.-Inform. Stefan Gärtner Hannover, 10. September 2013

2 Zusammenfassung Mobile Geräte wie Smartphones und Tablets werden heutzutage mit einer wachsenden Anzahl von Sensoren ausgestattet, mit denen Anwendungen die Umwelt wahrnehmen und kontextspezifisch reagieren können. Im Entwicklungsprozess solcher sensorgebundener Anwendungen reichen herkömmliche Methoden und Werkzeuge zum Testen der Software meist nicht aus. Die Zielgeräte haben oft unterschiedliche Sensoren mit stark variierender Qualität, gemessene Daten können Störungen unterliegen oder sind an eine Umgebung gebunden, die sich nur schwer reproduzieren lässt. Bestehende Werkzeuge im Bereich der Sensorsimulation auf mobilen Geräten ermöglichen es bereits, von einem Quellgerät Sensordaten aufzunehmen und anschließend in der eigenen Anwendung unverändert wiederzugeben und damit die Sensoren zu simulieren. Diese sind allerdings nur begrenzt einsetzbar, da der Entwickler weiterhin Daten aus einem breiten Spektrum von Zielgeräten aufnehmen muss, um seine Anwendung zu testen. Diese Arbeit evaluiert Sensor-Simulationsumgebungen in der mobilen Software-Entwicklung. Da diese Umgebungen bei der Vielfalt mobiler Geräte nur einen eingeschränkten Nutzen haben, wird hier eine Methode präsentiert, die Sensordaten eines Quellgerätes so zu verändern, dass die Sensoren verschiedener anderer Gerätemodelle damit simuliert werden können. Des Weiteren wurden die Sensoren verschiedener Smartphones analysiert und ein Konzept zur Evaluierung der Simulation erarbeitet. Die vorgestellte Methode kann in einer Simulationsumgebung implementiert werden, um den Aufwand im Testprozess zu reduzieren. Der Nutzen eines solchen Systems im Entwicklungsprozess wird herausgestellt und die Integration in verschiedene bekannte Vorgehensmodelle untersucht. ii

3 Abstract Nowadays mobile devices such as smartphones and tablets are equipped with a growing number of sensors to perceive the environment and act accordingly. Traditional development tools often do not suffice for testing these context aware applications. The target devices regularly use different sensors which vary in quality, measurements are influenced by noise or the application uses an environment that is hard to replicate. Existing sensor simulation tools for mobile devices enable the developer to record sensory data from a source device and then play it back in their own application for simulating the sensors. However, these tools are limited by the fact that the developer still has to record data from a broad spectrum of target devices to test his applications with specific sensors. This work evaluates the use of sensor simulation frameworks in mobile application development. Since these tools only have a limited use in the variety of mobile devices, a method is presented to modify sensor values of a source device so that other devices sensors can be simulated. With this method, the developer only needs to record a single time and can use this data to simulate across a wide range of devices. In addition, this work analyzed the sensors of multiple smartphones and presents a concept to evaluate the quality of the simulation. The method can be implemented into a sensor simulation framework to reduce the effort in the testing phase. This work highlights the value of such a system in the development process and examines the integration in various established software development processes. iii

4 Inhaltsverzeichnis 1. Einführung Motivation und Problemstellung Zielsetzung Struktur der Arbeit Grundlagen Testen sensorgebundener Applikationen Die Simulationsumgebung Beschleunigungssensoren Evaluierungskonzept und Durchführung Beschreibung des Vorgehens zur Evaluierung Datenerhebung Evaluierungskonzept Referenzbewegung Sensormodellierung Normalisierung Glättung Auflösungsquantisierung der Beschleunigung Zeitliche Abstände zwischen Messwerten Evaluierung Leistungsanalyse der Simulation Auswahl eines Profilers Durchführung Auswertung Integration in den Entwicklungsprozess Black-Box-Test Zwischen Mock-Objekt und Gerät Automatisches Testen Integration in Vorgehensmodelle Wasserfall-Modell V-Modell Spiralmodell Agile Prozesse Fazit und Ausblick Fazit iv

5 Inhaltsverzeichnis 6.2. Ausblick A. Inhalt der CD 38 v

6 1. Einführung 1.1. Motivation und Problemstellung Mit dem Aufkommen von Smartphones und Tablets vor einigen Jahren haben sich die Anforderungen an Software mobiler Geräten stark verändert. Anwendungen haben nun Zugriff auf eine stetig steigende Anzahl von Sensoren, um die Umgebung wahrzunehmen. Dazu zählt der Beschleunigungssensor, der der Anwendung Informationen über die Orientierung und Bewegung im Raum liefert und zur Standardausstattung gehört, aber auch sehr speziellen Sensoren wie dem Lichtsensor oder Sensoren zum Messen von Druck, Temperatur und Luftfeuchtigkeit. Ein zweiter Unterschied zu älteren Mobiltelefonen ist auch die Verbreitung von Anwendungen über das Internet. Während früher die Anwendungen auf den Geräten von den Herstellern fest vorinstalliert und somit passend zum Gerätetyp waren, hat der Endbenutzer nun Zugriff auf eine um viele Größenordnungen höhere Anzahl von Anwendungen über sogenannte App Stores 1 im Internet. Mit der Einführung von Betriebssystemen wie Android, die auf einer großen Breite von Geräten unterschiedlicher Hersteller ausgeliefert werden, steigt auch der Anwenderkreis der eigenen Applikation um ein Vielfaches [1]. Die eigene Anwendung muss nun von vielen verschiedenen Geräten unterstützt werden, die aus unterschiedlichen Generationen, Preisklassen oder Formfaktoren stammen, und den Endnutzern dabei möglichst ähnliche Funktionalität bereitstellen. Dies wird erschwert durch verschiedene Bildschirmauflösungen, Eingabemethoden und auch im Bereich der Sensorik, wo die Bauteile sich oft stark in Qualität, Auflösung und Geschwindigkeit unterscheiden. Mit der Anzahl der Geräte, auf denen eine Anwendung läuft, erhöht sich somit auch die Komplexität in der Entwicklung. Entwickelt man für ein so großes Spektrum an verschiedenen Geräten? Es reicht nicht mehr allein, die Anwendung auf einem einzelnen Zielgerät zu testen. Vielmehr muss der Entwickler seine Anwendung mehrmals im Entwicklungsprozess an mehreren Geräten testen, die einen hohen Abdeckungsgrad über den Android-Markt bieten, um sicherzustellen, dass seine Anwendung auch jedem Nutzer uneingeschränkt zur Verfügung steht. Gerade bei Tests auf vielen Geräten steigt daher der Aufwand und die Komplexität. Möchte der Entwickler beispielsweise die Reaktion seiner Anwendung auf eine Bewegungsfolge testen, so muss er diese Bewegung mit jedem Gerät mechanisch reproduzieren, um Unterschiede zwischen den Geräten zu vermeiden. Hat ein schwaches Gerät zum Beispiel eine gewisse Trägheit beim Messen der Sensordaten, müsste dies 1 Application Store, eine digitale Vertriebsplattform von Anwendungssoftware im Internet 1

7 1. Einführung durch einen Algorithmus in der Anwendung ausgeglichen werden, um Input Lag 2 zu vermeiden Zielsetzung Zentrales Ziel dieser Arbeit ist es, eine Methode zu entwickeln, aufgenommene Sensordaten eines Gerätes so zu verändern, dass sie möglichst denen eines zweiten Gerätes ähneln und damit als Modell für dieses verwendet werden können. Dies ermöglicht es einem Anwendungsentwickler, mit nur einem einzigen aufgenommenen Datensatz das Verhalten seiner Anwendung auf mehreren Geräten testen zu können, ohne die Eingaben mehrfach zu wiederholen und die Umgebung originalgetreu zu reproduzieren. Um zu gewährleisten, dass die simulierten Daten mit denen eines echten Gerätes übereinstimmen, wird die Qualität dieser Daten anhand eines erarbeiteten Evaluierungskonzeptes überprüft und daraus das Sensormodell und die Methode verifiziert. Die Evaluierung erfordert den Vergleich mehrerer Geräte unter möglichst gleichen Umgebungsbedingungen. Daher wird eine mechanische Apparatur entwickelt, die ein Gerät reproduzierbaren Bewegungen aussetzt. Weiterhin wird untersucht, ob das verwendete Simulationssystem selbst während der Simulation der Daten auf dem Endgerät den Test zur Laufzeit beeinflussen kann. Mögliche Stärken und Limitierungen werden dabei genannt. Damit wird sichergestellt, dass die Simulationsumgebung selbst die Sensordaten beim Abspielen nicht verfälscht und die Anwendung so reagieren kann, wie sie es unter realen Sensoren täte. Mit dem so gewonnenen Einblick in Sensorsimulation unter Android wird letztendlich evaluiert, wie ein solches System den Entwicklungsprozess mobiler Anwendungen unterstützen und in die bekanntesten Vorgehensmodelle des Software Engineerings integriert werden kann Struktur der Arbeit Diese Arbeit gliedert sich in sechs Kapitel. Das zweite Kapitel beschäftigt sich mit den Grundlagen, die für das Verständnis der folgenden Konzepte hilfreich sind. Es wird ein Überblick über den bisherigen Testprozess von mobilen Anwendungen gegeben und die verwendete Simulationsumgebung erläutert. Im dritten Kapitel wird die erarbeitete Methode, um Sensordaten eines Gerätes zu modellieren, vorgestellt und ein Konzept zur Evaluierung präsentiert. Es wird auf die einzelnen Teilbereiche eingegangen und die Sensoren verschiedener Geräte werden gegenübergestellt. Die Ergebnisse der Evaluierung werden diskutiert und daraus ein Fazit gezogen. 2 Verzögerung zwischen Benutzereingabe und Reaktion auf dem Bildschirm 2

8 1. Einführung Kapitel 4 untersucht die Auswirkungen der verwendeten Simulationsumgebung auf die Zielgeräte und analysiert das Verhalten zur Laufzeit. Daraus werden mögliche Beschränkungen und Stärken des Systems abgeleitet. Das fünfte Kapitel widmet sich der Integration eines solchen Systems in den Entwicklungsprozess. Es wird ein Beispielszenario präsentiert und verschiedene Vorgehensmodelle untersucht. In Kapitel 6 werden die Ergebnisse der Arbeit zusammengefasst und es wird ein Ausblick gegeben, wie die verwendete Methode implementiert und weiterentwickelt werden kann. 3

9 2. Grundlagen 2.1. Testen sensorgebundener Applikationen Mobile Anwendungen zu entwickeln ist in vielerlei Hinsicht ähnlich zu der Softwareentwicklung von eingebetteten Geräten. Bekannte Probleme beinhalten die Integration mit der Hardware vom Gerät, die traditionellen Aspekte der Sicherheit, Performance und Verlässlichkeit [1]. Doch moderne Smartphones und Tablets stellen ein paar weitere Anforderungen, die weniger bekannt in traditioneller Software-Entwicklung sind. Mobile Anwendungen machen sehr starken Gebrauch von gemessenen Daten, die von verschiedenen Kontextanbietern kommen. Dies beinhaltet integrierte Umgebungssensoren (wie Licht-, Bewegungs- und Temperatur-Sensoren und Kamera) oder Netzwerkverbindungen (Bluetooth, GPS, WLAN, 3G-Netze) [2]. Die Qualität und der Nutzen können sich dabei je nach Umgebung und Anwendung ändern. Die eigene Anwendung muss daher in verschiedenen Situationen getestet werden, um die Bandbreite der möglichen Sensordaten, die empfangen werden können, abzudecken. Entwickelt man zum Beispiel eine Anwendung, die von der aktuellen Position abhängt, dann schließen sich weitere Fragen an. Wie verhält sich die Anwendung innerhalb von Gebäuden, wenn GPS ausfällt? Wie genau ist die Ortsbestimmung über Funknetze in Gebieten mit schlechter Abdeckung? Gerade bei ortsabhängigen Anwendungen ist ein Testen oftmals sehr aufwändig. Der Entwickler kann meist nicht einfach vor seinem Arbeitsplatz testen, sondern muss die entsprechende Testumgebung physisch aufsuchen oder Routen entlanggehen, um den Kontextwechsel seiner App zu überwachen. Außerdem können Störungen der Sensoren auftreten: Der GPS-Sensor kann je nach Signalstärke der Satelliten rapide zwischen Orten springen, ein Beschleunigungssensor ist je nach seiner Qualität unterschiedlich stark verrauscht, ein WLAN-Signal kann plötzlich von einer Störquelle behindert werden. Diese Szenarien müssen je nach Anwendung berücksichtigt werden und lassen sich schwierig unter Laborbedingungen reproduzieren. Moderne Entwicklungsumgebungen unterstützen den Entwickler schon in einer Vielzahl von Bereichen innerhalb der mobilen Anwendungsentwicklung. Viele Hersteller und Plattformen bieten ihre eigenen zugeschnittenen Werkzeuge für den Entwicklungsprozess an. Neben weit verbreiteten Funktionen wie Syntax Highlighting oder Debuggern enthalten diese oft noch weitere Werkzeuge für mobile Geräte. Das offizielle Android Studio beinhaltet zum Beispiel noch eine direkte Verbindung zum Gerät, mit dem Anwendungen sofort installiert werden und Laufzeitinformationen übertragen werden können 4

10 2. Grundlagen [3]. Zusätzlich ermöglichen es GUI-Editoren, die grafische Oberfläche auf einer Vielzahl von Geräten und Formfaktoren schon bei der Entwicklung zu sehen (siehe Abbildung 2.1). Hinzu kommen Frameworks zur Testautomatisierung wie Robotium, die automatisch Benutzeraktionen auf dem Gerät simulieren können [4]. Abbildung 2.1.: Android Studio: Simulieren der Bildschirmgrößen verschiedener Geräte Doch möchte man eine Anwendung mit Sensoren testen, stoßen diese Werkzeuge oft an ihre Grenzen. Es fehlen die nötigen Funktionen, um Sensoren zu emulieren, und der Entwickler muss wieder selbst mit dem physischen Gerät interagieren. Eine bekannte Alternative dafür ist der OpenIntents Sensor Simulator. Der Simulator verbindet sich direkt mit der Anwendung auf dem Gerät oder im Emulator und speist simulierte Sensordaten in Echtzeit ein (siehe Abbildung 2.2). Es ist ebenfalls möglich, Daten von einem Gerät aufzunehmen und unverändert wieder abzuspielen. [5] Dies deckt schon einmal eine grundlegende Funktion ab. Der Entwickler kann nun schon am Emulator während der Entwicklung Bewegungsfolgen an seine Anwendung übergeben ohne die Aktion physisch durchführen zu müssen. Eine vollständige Lösung des Sensor-Problems ist es aber nicht: Störungen des Signals oder Rauschen eines Sensors werden weiterhin nicht betrachtet und müssen in weiteren Tests abgedeckt werden. Der Entwickler muss immer noch die Umgebungsbedingungen ändern und seine Anwendung auf mehreren Geräten testen. Die Methode, die in dieser Arbeit vorgestellt wird, hat zum Ziel, diesen Aufwand zu verringern, indem die aufgenomme- 5

11 2. Grundlagen nen Daten gezielt verändert werden, um anderen Geräten entsprechen. Abbildung 2.2.: OpenIntents Sensor Simulator: Steuerung und Gerät [5] 2.2. Die Simulationsumgebung In der Lehrveranstaltung Softwareprojekt WS 2012 wurde am Fachgebiet Software Engineering eine Suite für Sensorsimulierung entwickelt, um die Entwicklung sensorgebundener Apps zu unterstützen. SensorSim besteht aus drei Komponenten: Eine Aufnahme-App dient zum Aufnehmen einer Reihe von Sensoren wie Beschleunigungssensor, WLAN-Netzen und GPS auf dem Zielgerät. Eine Upload- Funktion ermöglicht es, die aufgenommenen Daten sofort hochzuladen. Ein Web-Repository verwaltet alle hochgeladenen Datensätze in einer Datenbank und ermöglicht es, die Daten mit Rauschen zu versehen. Eine Abspiel-Library kann in die eigene Anwendung integriert werden, um Daten vom Webserver zur Simulierung von Sensoren zu verwenden. Ein Entwickler, der eine mobile Anwendung entwickeln möchte, kann mit Hilfe der Aufnahme-App entsprechende Sensordaten aufnehmen. Für eine ortsbasierte App 6

12 2. Grundlagen Abbildung 2.3.: Überblick über die Komponenten von SensorSim kann dies zum Beispiel eine Reihe von GPS-Positionen sein, während das Gerät von einem Ort zu einem anderen getragen wird. Für eine Anwendung, die den Beschleunigungssensor zur Orientierung verwendet, wie z.b. eine Wasserwaagen-App, könnten Beschleunigungsdaten aufgenommen werden. Nachdem die Aufnahme gestoppt wurde, werden die Daten ins Repository hochgeladen. Im Repository werden alle bisherigen Daten verwaltet und können nach bestimmten Kriterien eingegrenzt werden. So kann der Entwickler auf Daten aus anderen Projekten, z.b. verrauschte Daten anderer Geräte, zugreifen. Zusätzlich gibt es die Möglichkeit, die Daten mit einem einfachen additiven weißen gaußschen Rauschen (AWGN) zu versehen. Damit kann die eigene App unter verschiedenen Störeinflüssen getestet werden. Indem die Abspiel-Library in die eigene Anwendung integriert wird, können die Daten wieder abgespielt werden. Die Bibliothek verbindet sich mit dem Repository und wartet auf Daten, die auf dem Server ausgewählt wurden. Die Datensätze werden auf Gerät oder den Emulator gestreamt und sind über Klassen wie SensorManager, die den Klassen von Android nachgebildet sind, verfügbar. Der Entwickler muss seinen Code nur minimal anpassen, damit die Klassen von SensorSim statt den Android-eigenen benutzt werden (siehe Listing 2.1). Listing 2.1: Einbindung von SensorSim in eigene Applikation 1 / / Verwende Android Service 2 / / SensorManager sensormanager = ( SensorManager ) getsystemservice ( Context. SENSOR_SERVICE) ; 3 4 / / Verwende SensorSim 5 SensorSim sim = SensorSim. getinstance ( this, " mydevice " ) ; 6 Sensormanager sensormanager = ( SensorManager ) sim. getsystemservice ( Context. SENSOR_SERVICE) ; 7 8 / / R e g i s t r i e r e L i s t e n e r 9 sensormanager. r e g i s t e r L i s t e n e r ( mylistener, sensormanager. getdefaultsensor ( Sensor.TYPE_ACCELEROMETER), sensormanager. SENSOR_DELAY_NORMAL) ; 7

13 2. Grundlagen SensorSim ermöglicht eine bessere Verwaltung der Daten mehrerer Geräte und bietet einfache Möglichkeiten zum Hinzufügen von Rauschen, aber löst das zentrale Problem bei der Entwicklung sensorgebundener Apps nicht: der Entwickler muss weiterhin von vielen unterschiedlichen Geräten die notwendigen Daten erfassen, um seine App damit testen zu können. Abbildung 2.4.: SensorSim Aufnahme-App Abbildung 2.5.: SensorSim Web-Repository 8

14 2. Grundlagen 2.3. Beschleunigungssensoren Die nächsten Kapitel konzentrieren sich nur noch auf einen bestimmten Sensor mobiler Geräte, den Beschleunigungssensor (engl. Accelerometer). Die erläuterten Konzepte können in unterschiedlichem Umfang auch auf andere Sensoren angewendet werden. Der Beschleunigungssensor ist von den verfügbaren Sensoren allerdings aufgrund mehrerer Eigenschaften für die Simulation am interessantesten und wichtigsten: Er gehört zur Grundausstattung eines jeden modernen Mobilgerätes, wodurch über eine große Reihe an Geräten getestet werden kann. Das Rauschen ist im Wesentlichen sensor-inhärent und daher abhängig vom Gerätemodell im Vergleich zu umweltgestörten Sensoren wie GPS oder WLAN. Damit lassen sich gut Unterschiede zwischen Geräten feststellen und Umwelteinflüsse minimieren, was die Modellierung vereinfacht. Der Sensor liefert sowohl Orientierungs- als auch Bewegungsdaten und findet dabei in vielen Apps Verwendung, z.b. als Eingabemethode oder für Bildschirmrotation. Die Daten werden in wenigen Millisekunden kontinuierlich bereitgestellt und nicht erst auf Anfrage, womit sich die Performance des Systems gut testen lässt. Die Umweltbedingungen lassen sich einfach kontrollieren, da das Gerät lediglich standardisiert bewegt werden muss. Abbildung 2.6.: Koordinatensystem in Android [6] Auf den Beschleunigungssensor in Android wird zugegriffen, indem über den Sensor- Manager ein neuer Listener registriert wird. Um Rechenzeit und Strom zu sparen, kann dabei die Rate, mit der die Anwendung über neue Werte informiert wird, limitiert werden: SENSOR_DELAY_FASTEST: 0 ms Verzögerung, kein Limit SENSOR_DELAY_GAME: 20 ms Verzögerung SENSOR_DELAY_UI: 60 ms Verzögerung SENSOR_DELAY_NORMAL: 200 ms Verzögerung 9

15 2. Grundlagen Der Sensor informiert die Anwendung über neue Daten, indem der Listener mit der Methode onsensorchanged() aufgerufen wird und übergibt ein Objekt mit dem Zeitpunkt in ns, der Genauigkeit und den X,Y,Z-Beschleunigungswerten in ms 2 [6]. Nach [7] kann ein Modell, welches ein Accelerometer und sein Rauschen beschreibt, folgendermaßen formuliert werden: a x = x + c x + b x + w accel : (2.1) Hierbei ist a x der zurückgegebene Wert, der sich aus der tatsächlichen Beschleunigung (x), einem konstanten Offset (c x ), einem wandernden Bias (b x ) und einem weißen Sensorrauschen (w accel ) zusammensetzt. Im späteren Verlauf dieser Arbeit wird versucht, aus den erhaltenen Daten a x die tatsächliche Beschleunigung x möglichst rauschfrei zu rekonstruieren. 10

16 3. Evaluierungskonzept und Durchführung In diesem Kapitel werden die Beschleunigungssensoren verschiedener Android-Geräte miteinander verglichen und daraus eine Methode entwickelt, Sensordaten eines Gerätes so zu modifizieren, dass sie denen eines anderen Gerätes gleichen. Zur Überprüfung dieser Methode wird ein Evaluierungskonzept entwickelt, anhand dessen die Güte der modellierten Daten bestimmt werden kann. Die Methode ermöglicht es, in einer Sensor-Simulationsumgebung mehrere Geräte mit einem einzelnen Datensatz zu simulieren. Dies ist eine notwendige Funktionalität, damit eine Evaluation einer solchen Umgebung im Kontext mobiler Anwendungsentwicklung überhaupt sinnvoll ist Beschreibung des Vorgehens zur Evaluierung Die grundlegende Idee, wie man die Sensordaten eines Gerätes simuliert, ist relativ simpel. Man zeichnet mit einem anderen Gerät, welches zur Verfügung steht, die gewünschte Bewegungsfolge auf. Diese Bewegung richtet sich nach dem Ziel in der Entwicklung der eigenen Anwendung. Dies kann z.b. ein Orientierungswechsel des Gerätes vom Hoch- ins Querformat sein oder eine Schüttelbewegung. Nun entfernt man das Rauschen des Gerätes im aufgezeichneten Datensatz, z.b. durch Mittelung mehrerer Bewegungsfolgen oder Glättung mittels Tiefpassfilter. Hieraus erhält man normalisierte Daten, die möglichst nah an den tatsächlichen Beschleunigungswerten sind und keine vom Gerätesensor eingebrachten Störungen oder zeitlichen Verzögerungen enthalten. Diese bereinigte Bewegungsfolge enthält nun im Idealzustand die grundlegende Bewegung, mit der man die eigene Anwendung testen möchte, aber keine sensorabhängigen Verunreinigungen eines bestimmten Gerätes. Im nächsten Schritt wird diesen Daten nun wieder Rauschen hinzugefügt, diesmal mit den Merkmalen der Sensoren anderer Geräte (im folgenden Sensorprofil genannt), um den Einfluss der jeweiligen Sensoren zu simulieren. Am Ende erhält man aus der einzelnen aufgenommenen Bewegung n verschiedene geräteabhängige Bewegungen, die mehr oder weniger stark von Rauschen beeinflusst sind, je nach der Qualität und Bauweise des Sensors. Die Sensorprofile der einzelnen Geräte lassen sich in einer Datenerhebungsphase ermitteln, die im nächsten Abschnitt erläutert wird. 11

17 3. Evaluierungskonzept und Durchführung Datenerhebung Um die Sensoren verschiedener Geräte miteinander vergleichen zu können, müssen am Anfang erst einmal Daten gesammelt und ausgewertet werden. Die verwendeten Geräte sollten dabei ein breites Spektrum des Marktes abdecken. Für diese Arbeit wurden sechs Smartphones verschiedener Hersteller getestet, die von der ersten Android-Generation bis zu den aktuellen Martkführern reichen. Tabelle 3.1.: Übersicht über die verwendeten Geräte Hersteller Gerät Erscheinungsjahr Android-Version Firmware HTC Dream Stock LG P Stock LG P CyanogenMod Samsung Galaxy S II CyanogenMod Samsung Galaxy S Stock HTC One Stock In einer ersten Datenerfassung werden die Ausgabewerte der Beschleunigungssensoren aller Geräte in der Ruhelage über einen Zeitraum von ein paar Minuten gemessen (siehe Abbildung 3.1). Damit lassen sich sensor-inhärente Parameter wie die Samplingrate, Auflösung und die Verteilung des Rauschens bestimmen. Damit die Sensorparameter möglichst unverfälscht bestimmt werden können, müssen die Geräte in einer kontrollierten Umgebung getestet werden und externe Einflüsse auf ein Minimum reduziert werden. Um Störungen von außerhalb zu erkennen, werden die Sensordaten mehrerer Geräte parallel zum gleichen Zeitpunkt aufgenommen. Sollte ein externes Ereignis also das Gerät beschleunigen, wäre dieses in den Aufnahmen aller Geräte zu sehen. Die Geräte werden alle mit der gleichen Version der Aufnahme-App von SensorSim bespielt, welche die Beschleunigung misst, der das Gerät über einen Zeitraum ausgesetzt wird, und diese Datenreihe abspeichert. Die Messrate des Beschleunigungssensors wird im SensorManager von Android dabei mit SENSOR_DELAY_FASTEST konfiguriert, wodurch Android die Signale des Sensors so schnell wie möglich an die Anwendung sendet [6]. Die Aufnahmereihen aller Geräte werden anschließend mehrmals wiederholt, um einmalige Faktoren und Diskrepanzen wie Temperaturschwankungen oder externe Stöße in einer einzigen Reihe zu erkennen. Dies reduziert einen Einfluss der Umgebungsbedingungen, da es darum geht, nur Merkmale des Sensors selbst zu identifizieren. 12

18 3. Evaluierungskonzept und Durchführung Abbildung 3.1.: Aufnahme von Sensordaten In Abbildung 3.2 werden die gemessenen Beschleunigungsdaten aller Geräte in Ruhelage gezeigt. Schon bei einfacher Betrachtung sind die Unterschiede zwischen den Sensoren der einzelnen Geräte deutlich erkennbar. Sie unterscheiden sich stark in Stärke und Frequenz des Rauschens, Steigung und generellem Verlauf. Ebenso weicht der nahezu gerade, stufige Verlauf der beiden HTC-Geräte vom eher schwankenden Verhalten der anderen Geräte stark ab Evaluierungskonzept Nachdem im ersten Schritt die notwendigen Sensordaten gesammelt wurden, lässt sich nun in mehreren Schritten der Sensor anhand des Sensorprofils eines Zielgerätes nachbilden. Die so simulierten Beschleunigungsdaten werden nun mit den Originaldaten des Gerätes, dessen Sensorprofil verwendet wurde, verglichen. Berechnet man die Differenz der beiden Datensätze, lässt sich der mittlere Fehler der Näherung zu den Originaldaten berechnen, welcher als Gütekriterium dient. In Abbildung 3.3 sind die einzelnen Schritte des Konzeptes verdeutlicht. In einem er- 13

19 3. Evaluierungskonzept und Durchführung Abbildung 3.2.: Ausschnitt: Ruhebeschleunigung einiger Geräte sten Schritt wird von einem Referenzgerät A eine Bewegungsfolge aufgenommen. Die so erhaltenen Daten enthalten noch Rauschen und Verzögerungen, die durch die Aufnahme mit Gerät A bedingt sind. In einem Normalisierungsschritt werden diese Störelemente entfernt, um den bereinigten Datensatz zu erhalten. Anschließend wird das Rauschen eines Gerätes B nach dessen vorher ermittelten Sensorprofils hinzugerechnet, um die mittels Gerät A simulierten Daten von Gerät B zu bekommen. In einem zweiten Schritt wird mit Gerät B dieselbe Bewegungsfolge aufgenommen, welche als Referenz für unsere Simulation dient. Die Qualität der Simulation wird im dritten Schritt berechnet, indem die mittlere Abweichung der beiden Datensätze ermittelt wird. Diesen Fehler gilt es zu minimieren, da die Simulation möglichst nah am Originalgerät liegen soll. Der mittlere Fehler berechnet sich nach [9] folgendermaßen: m x = 1 n n je i j = 1 n i=1 n jx A (i ) x B (i )j (3.1) i=1 Die Simulation wird als erfolgreich gewertet, wenn der mittlere Fehler der simulierten Beschleunigungsdaten jx A (i ) x B (i )j zu Gerät B kleiner ist als der Fehler zu Gerät A. Dies bedeutet, dass unsere Simulation objektiv eher mit Daten, wie man sie von Gerät B bekommen würde, übereinstimmt als mit Daten von Gerät A. 14

20 3. Evaluierungskonzept und Durchführung Abbildung 3.3.: Evaluierungskonzept Referenzbewegung Für den Vergleich der Sensordaten zweier Geräte muss die Umgebung möglichst exakt zwischen Tests reproduzierbar sein. Im Falle des Beschleunigungssensors bedeutet dies, dass er einer immer gleichen Bewegungsfolge ausgesetzt werden muss. So lässt sich bestimmen, welche Werte des Sensors durch externe Einflüsse bestimmt werden und welche durch das Gerät selbst verursacht werden. Als Prototyp wurde mit LEGO Mindstorms eine Apparatur entworfen, die eine solche Referenzbewegung erzeugen kann. Die Anforderungen daran waren: Erzeugung einer linearen Bewegung, da diese im Vergleich zu einer Rotation unabhängig von der Position des Accelerometers immer die gleichen Daten liefert. Erzeugung einer Sinusbewegung zur leichteren Auswertung und Modellierung. externe Stromversorgung, um allmähliches Verlieren der Batteriespannung zu verhindern. das Gewicht des Gerätes muss gehalten werden können, ohne dass dadurch die Bewegung beeinträchtigt bzw. verlangsamt wird. 15

21 3. Evaluierungskonzept und Durchführung Der Motor erzeugt eine 1 Hz-Sinus-Bewegung auf der Y-Achse des Gerätes. Es stellte sich bei dem Vergleich mehrerer Geräte allerdings heraus, dass noch weitere Unterschwingungen auftraten, die sich zwischen den Testreihen änderten und durch Vibrationen des Aufbaus erzeugt wurden. Das Konzept wurde so modifiziert, dass das Referenzgerät und das zu simulierende Gerät beide übereinander auf die Apparatur gelegt werden, damit beide die gleichen Vibrationen erfahren. Dies erhöht zwar das Gewicht und macht die Apparatur damit anfälliger gegenüber Vibrationen, aber führt zu einer besseren Vergleichbarkeit der Geräte. Bevor die Daten verglichen werden können, müssen noch die Zeiten synchronisiert werden. Die Aufnahmen auf beiden Geräten sind leicht gegeneinander verschoben, da der Aufnahmeprozess manuell gestartet wird. Dies lässt sich erreichen, indem bei Variation der Verschiebung der Datensätze zueinander der mittlere Fehler minimiert wird, analog zu Schritt 3 des Konzeptes. Abbildung 3.4.: Apparatur zur Erzeugung einer Referenzbewegung 16

22 3.2. Sensormodellierung 3. Evaluierungskonzept und Durchführung Wie sich im Laufe der Arbeit gezeigt hat, muss das verwendete Sensormodell bei Android-Geräten durch ein paar zusätzliche Elemente erweitert werden. Wie aus der vorherigen Abbildung 3.2 der Ruhebeschleunigung zum Teil ersichtlich war, unterliegt nicht jedes Gerät einem reinen weißen Rauschen, wie im bisherigen Modell eines Beschleunigungssensors angenommen wurde. Stattdessen scheinen die Beschleunigungsdaten im Gerät zusätzlich modifiziert zu werden: Abbildung 3.5.: Erweitertes Sensormodell Filter: Ein lineares Filter, welches das Signal glättet. Quantisierung: Diskretisiert die gemessenen Werte in bestimmte Zahlenwerte, bestimmt durch die Sensorauflösung. Verzögerung: Zeitliche Unregelmäßigkeiten in der Abfolge der Werte, die durch den verwendeten Sensor und Android bedingt sind. Diese zusätzlichen Einflüsse ergeben sich vermutlich durch die Verwendung von kostengünstigen Accelerometern für Endkunden statt Sensoren, wie sie in der Industrie verwendet werden. Gleichzeitig können die Hersteller die Sensoren über die Firmware im Gerät auf mehrere unterschiedliche Betriebsmodi setzen, die die Bandbreite und damit die Filterqualität und das Intervall zwischen Messwerten regulieren [11][12]. Die benötigten Eigenschaften der Sensoren sind überwiegend nicht in den Datenblättern der Hersteller zu finden. Viele werden auch vom Android-Betriebssystem beeinflusst. Darüber hinaus ist oftmals nicht bekannt, welches Sensormodell in dem jeweiligen Mobilgerät verbaut ist. Daher wird in diesem Abschnitt im Detail erläutert, wie die Sensorprofile in den einzelnen Stufen ermittelt werden können und Beschleunigungsdaten mit so einem Profil wieder verrauscht werden können. Die Schritte folgen dabei der Reihenfolge, die im vorherigen Modell festgelegt wurde Normalisierung Da die gemessenen Beschleunigungsdaten eines Gerätes bereits verrauscht sind, gilt es in einem ersten Schritt, diese wieder zu normalisieren und möglichst auf die Originalbewegung zurückzuführen, wie sie ohne Einfluss durch das Gerät aussehen würde. Zuerst müssen die Zeitabstände zwischen den einzelnen Messwerten normalisiert werden. Durch geräteabhängige Verzögerungen schwanken diese um eine bestimmte 17

23 3. Evaluierungskonzept und Durchführung Rate. Die Normalisierung wird durchgeführt, indem die Werte zu äquidistanten Zeitpunkten interpoliert werden. In dieser Arbeit wird immer mit einem Zeitabstand von 10 ms gearbeitet, da dieser der Rate des schnellsten Gerätes entspricht, dem Galaxy S4. Im nächsten Schritt gilt es, die Sensordaten von geräteabhängigem Rauschen zu bereinigen. Im Frequenzspektrum der Sensordaten ist die mit der Testapparatur erzeugte Referenzbewegung bei ca. 1 Hz deutlich erkennbar (siehe Abbildung 3.6). Ebenso erkennt man weitere Ausschläge um 10 Hz herum, die auf Vibrationen der Apparatur hindeuten. Da diese durch den Testaufbau und damit die Umgebung erzeugt wurden, zählen sie ebenfalls zu unserer Referenzbewegung und müssen berücksichtigt werden. Das Rauschen des Gerätes wird als deutlich höherfrequent als eine normale Bewegung des Geräts angenommen, also lässt sich mit einem Tiefpassfilter das Rauschen herausfiltern. Die Cutoff-Frequenz des Filters richtet sich nach der durchgeführten Bewegung und lässt sich am Spektrum ablesen, da die Stärke des Rauschens deutlich geringer ausfällt als die der Referenzbewegung. Man erhält die bereinigten Daten, frei von Geräterauschen (siehe Abbildung 3.7). Abbildung 3.6.: Frequenzspektrum des Galaxy S4 bei Referenzbewegung 18

24 3. Evaluierungskonzept und Durchführung Abbildung 3.7.: Ausschnitt: Tiefpassgefilterte Sensordaten bei 13 Hz Glättung Bei vielen älteren Modellen lassen sich im Vergleich zum Galaxy S4 Anzeichen finden, die darauf hindeuten, dass das Signal geglättet wird, bevor es die Anwendung erreicht. Dies erkennt man dadurch, dass die Schwingung des Gerätes nicht den vollen Ausschlag vom S4 erreicht und einen flacheren Verlauf hat, da es auf schnelle Beschleunigungsänderungen nicht direkt reagiert. Dieses Glättungsfilter wirkt sich sehr stark auf das Signal aus und ist daher am genauesten zu modellieren. In dieser Arbeit wurde die Glättung durch ein Moving-Average- Filter angenähert [10]. Dieser mittelt die letzten n Werte innerhalb eines Zeitraumes und gibt diesen Mittelwert zurück. Um die Länge des Moving-Average-Filters zu bestimmen, wurden der Zeitraum variiert und der Verlauf des erhaltenen Signals in Bezug auf Amplitude und Steigung mit den Originaldaten verglichen. Man sieht, dass die LG P500s und das HTC Dream geglättet werden, während neuere Modelle keine Glättung aufweisen und die Daten sofort zurückgeben. Ein Beispiel für die Glättung sieht man später in Abbildung 3.9, bei dem die Sensordaten des S4 mit einem 70 ms-moving-average-filter geglättet wurden. 19

25 3. Evaluierungskonzept und Durchführung Tabelle 3.2.: Glättungsparameter Gerät Zeitraum in ms HTC Dream 70 HTC One 0 LG P500 Stock 80 LG P500 CM 80 Galaxy S II 0 Galaxy S Auflösungsquantisierung der Beschleunigung Jeder Sensor kann nur einen bestimmten Bereich von Messwerten abdecken und diese Zahlenwerte sind diskret verteilt. Die Auflösung gibt dabei die minimalen Abstände zwischen den verschiedenen Beschleunigungswerten an. Da diese zwischen verschiedenen Geräten wieder stark unterschiedlich ausfällt, sollte sie ebenfalls modelliert werden. Die Auflösung eines Gerätes kann leicht berechnet werden, indem die minimale Differenz zwischen einer Reihe von Beschleunigungswerten bestimmt wird. Über mehrere Testreihen sollte dieser Wert pro Gerät identisch sein. Die folgende Tabelle zeigt die Ergebnisse für die jeweiligen Geräte, errechnet aus 10 Testreihen in Ruhelage und unter Einfluss der Referenzbewegung: Tabelle 3.3.: Ermittelte Auflösungen der Geräte Gerät Auflösung in ms 2 Gerät Auflösung in ms 2 HTC One HTC Dream LG P500 Stock LG P500 CM Galaxy S II Galaxy S Auffallend ist, dass beide HTC-Geräte von 2008 und 2013 deutlich schlechtere Auflösungen haben als die anderen Geräte. Der Unterschied ist gut erkennbar in der folgenden Abbildung 3.8. Beim Galaxy S4 streuen sich die Beschleunigungswerte herum um den Nullpunkt und bilden eine Normalverteilung um den realen Wert, welche aufgrund des weißen Rauschens im Sensor zu erwarten wäre. Das HTC One zeigt ein anderes Bild: Aufgrund der niedrigen Auflösung des Sensors gibt es nur zwei Werte, zwischen denen der Sensor wechselt. Das weiße Rauschen wird fast vollständig verdeckt. 20

26 3. Evaluierungskonzept und Durchführung Falls das genaue Modell des Sensors bekannt ist, lässt sich die Auflösung auch im dazugehörigen Datenblatt finden. Das Datenblatt vom BMA250, welcher im HTC One Verwendung findet, gibt die Auflösung mit 3:91mg an, welche umgerechnet dem Wert von den gemessenen 0:038307ms 2 entspricht [12]. Abbildung 3.8.: Verteilung der Beschleunigungswerte in Ruhelage Die Auflösung lässt sich leicht modellieren, indem die bereinigten Daten auf die jeweilig nächsten Auflösungsstufen gerundet werden. x x r es = r ound( ) r esolution (3.2) r esolution Zeitliche Abstände zwischen Messwerten Je nach Gerät werden die Werte auch in unterschiedlichen Zeitabständen geliefert. Diese lassen sich ebenfalls leicht bestimmen, indem die Differenz zwischen benachbarten Zeitpunkten der Datenreihe gebildet wird. Auch hier zeigen sich wieder deutliche Unterschied zwischen den HTC-Modellen und den restlichen Geräten (siehe Tabelle 3.4). Während die anderen Geräte mehr oder weniger genau alle 10 ms neue Sensordaten liefern, sind die zeitlichen Abstände bei den HTC-Geräten deutlich größer und sie schwanken auch stärker. Ebenfalls verändern sie sich je nach Umgebung: wird das Gerät einer Beschleunigung ausgesetzt, liefert es öfters Daten. Bei diesen Gerät findet vermutlich ein Thresholding 1 statt, bei dem die Software erst über neue Beschleunigungswerte informiert wird, wenn eine bestimmte Schwelle überschritten wird [8]. Dies erklärt die höheren Verzögerungen in Ruhelage gegenüber der Referenzbewegung, wo die Schwelle häufiger überschritten wird. 1 Schwellwertverfahren. Ein Wert wird erst als anders vom vorherigen angenommen, wenn er um einen bestimmten Betrag von ihm abweicht. 21

27 3. Evaluierungskonzept und Durchführung Tabelle 3.4.: Mittlere zeitliche Abstände Gerät Abstand in ms bei Ruhelage Abstand in ms bei Ref.-Bewegung HTC Dream HTC One LG P500 Stock LG P500 CM Galaxy S II Galaxy S Verzögerungen bei den Zeitabständen können für Geräte ohne Thresholding simuliert werden, indem die Zeitpunkte zu festen Abständen interpoliert und mit einer Normalverteilung gemäß der berechneten Standardabweichungen verzögert werden. Bei Geräten mit Thresholding müssen in einem zusätzlichen Schritt Datenpunkte verworfen werden, wenn die Differenz zum vorherigen Wert geringer als der Schwellwert ist Evaluierung Für die Evaluierung wurde die Methode wie oben genannt durchgeführt. Das Galaxy S4 wurde als Ausgangspunkt für die zu simulierenden Daten gewählt, da es anhand der aufgenommenen Sensorprofile die höchste Auflösung, die präzisesten Zeitabstände bietet und kein interner Filtervorgang erkennbar ist, der die Daten verfälschen würde. Jedes andere Gerät wurde anschließend in mehreren separaten Testreihen zusammen mit dem Galaxy S4 auf die Testapparatur gelegt und der 1 Hz-Referenzbewegung ausgesetzt. Gleichzeitig zeichnete die Aufnahme-App von SensorSim die Sensordaten auf beiden Geräten auf. Die vom Galaxy S4 erhaltenen Daten wurden nun dem entwickelten Verfahren unterzogen. Zuerst wurde anhand des Spektrums ein Tiefpassfilter von 20 Hz gewählt (siehe Abbildung 3.6), um die normalisierte Referenzbewegung ohne Rauschen zu erhalten. Die Referenzbewegung wurde nun den einzelnen Stufen der geräteabhängigen Glättung, Auflösungsquantisierung und Zeitverzögerung unterzogen. Das erhaltene simulierte Signal wurde letztendlich mit den aufgenommenen Originaldaten des jeweiligen Gerätes verglichen und der mittlere Fehler bestimmt. Dieser Fehler ist in Tabelle 4.1 für die einzelnen Geräte aufgeführt. Einen Ausschnitt der simulierten Daten sieht man für das HTC Dream in Abbildung 3.9. Der Fehler S4 zu Original bezeichnet die Nähe der beiden Rohdaten ohne Verände- 22

28 3. Evaluierungskonzept und Durchführung Tabelle 3.5.: Qualität der mit Galaxy S4 simulierten Daten Gerät Fehler zu Original Fehler zu S4 S4 zu Original Verbesserung in ms 2 in ms 2 in ms 2 HTC Dream % HTC One % LG P500 Stock % LG P500 CM % Galaxy S II % rungen zueinander. Er dient als Kontrollwert und beschreibt, wie ähnlich die Sensordaten des Gerätes zum Galaxy S4 sind. Die beiden anderen Fehlerwerte sind die Vergleichswerte der erhaltenen Simulation zu den jeweiligen Geräten. Wenn also der Fehler zu Original geringer als der Vergleichswert S4 zu Original ist, so haben wir mit der Methode eine Verbesserung erzielt: die simulierten Daten sind ähnlicher zu den Originaldaten als zu denen des Galaxy S4. Analog dazu erwarten wir eine Vergrößerung des Fehlers zu S4, da unsere Simulation nicht mehr den Daten des S4 entspricht. Ist der Fehler zum Original letztendlich sogar kleiner als der zum S4, so kann man davon sprechen, dass die simulierten Daten eher zu dem zu simulierenden Gerät passen als zum S4 und das Ziel ist erfüllt. Man sieht, dass beim HTC Dream, dem ältesten Gerät, die Methode sehr gut funktioniert. Bei den beiden LG P500 lässt sich ebenfalls eine erkennbare Verbesserung zeigen. Auch wenn der Fehler zum Original längst nicht so niedrig ist, ist er dennoch ausreichend. Beim HTC One funktioniert die Methode nur geringfügig, sie verbessert zwar die Daten (Fehler zu Original kleiner als Vergleichswert) und entfernt sich von den aufgenommenen S4-Daten (Fehler zu S4 größer als 0), aber diese Veränderung ist nicht wesentlich (Fehler zu S4 überwiegt nicht gegenüber Fehler zu Original). Beim Galaxy S II zeigt sich, dass die Methode nicht funktioniert: Auch wenn der Fehler zum S4 größer wird, ist auch der Fehler zum Original gewachsen und nun größer als der Vergleichswert. Anhand der Rohdaten in der Datenerhebungsphase ließ sich erkennen, dass den größten Einfluss auf die Sensordaten im Wesentlichen der interne Glättungsfilter des Gerätes hat. Dies ist auch aus Abbildung 3.9 ersichtlich, wo die Schwankungen des HTC Dream deutlich schwächer und länger ausfallen als beim Galaxy S4. Da dieser Filter bei den älteren Geräten gut zu modellieren ist, sind auch die simulierten Daten entsprechend nah am Original. Bei moderneren Geräten ohne Glättungsfilter (wie dem Galaxy S II) versagt die Näherung, da die Unterschiede sowieso geringer sind und die Methode somit nur zusätzliche Störungen hinzufügt. 23

29 3. Evaluierungskonzept und Durchführung Abbildung 3.9.: Ausschnitt: Simulation des HTC Dream aus Galaxy S4 Letztendlich können aber durch die Auflösungsquantisierung und die Zeitverzögerungen wenigstens ein paar Unterschiede vom Galaxy S II zum Galaxy S4 modelliert werden. Die Methode zeigt also, dass es insbesondere bei älteren Geräten möglich ist, sie durch andere Geräte zu simulieren und liefert einen Ansatz, um dies zu erreichen. Zusätzlich können die gewonnen Sensordaten können in der Entwicklung der eigenen Anwendung hilfreich sein, um einen Filter zu entwerfen, der gerätespezifisches Rauschen entfernt. 24

30 4. Leistungsanalyse der Simulation Für eine vollständige Evaluation einer Sensor-Simulationsumgebung im Testprozess ist es wichtig, zu untersuchen, ob diese die Testergebnisse selbst beeinflusst. Wenn sich die Simulationsumgebung zur Laufzeit negativ auf die Anwendung auswirkt, beispielsweise durch zuviel CPU- oder Speicherverbrauch, spiegelt das Testergebnis nicht mehr notwendigerweise den Test auf einem realen Gerät wider. Aus diesem Grund wird die Performance einer mobilen Anwendung gemessen, die die Simulationsumgebung auf einem Gerät benutzt, und mit derselben Anwendung verglichen, wenn diese die Sensordaten vom Android-Betriebssystem erhält. Als Simulationsumgebung wird die Abspielbibliothek-Komponente von SensorSim verwendet, die in die eigene Anwendung integriert wird Auswahl eines Profilers Um Laufzeitinformationen zu messen, während eine Anwendung auf dem Gerät läuft, wurde eine Android-Anwendung gesucht, die solche Informationen aufzeichnet. Die folgenden Auswahlkriterien standen dabei im Vordergrund: Messung von System-Informationen: Gesamte Speicher- und CPU-Auslastung, Netzwerk- und Batteriestatus Messung von Anwendung-Informationen: CPU-Verbrauch, Speicherauslastung (Heap-Größe) Daten-Export in ein einfaches Format zur Auswertung Kontinuierliche Messung in niedrigem Intervall von wenigen Sekunden Ausgewählt wurde letztendlich die Profiling-Anwendung Diagnosis [13], die alle oben genannten Punkte erfüllt. Die Anwendung legt eine SQLite-Datenbank an, in der alle Messdaten einfach verfügbar und einsehbar sind Durchführung Als Beispielanwendung zum Messen der Simulation wurde die SensorSim-Aufnahme- App gewählt, da diese bereits von mehreren Sensoren Gebrauch macht und der Quellcode zur Verfügung steht. In der Anwendung werden alle Aufrufe von Android-Sensorfunktionen durch Aufrufe der SensorSim-Abspielbibliothek ersetzt. Die Verzögerung zwischen Messwerten wird im System auf SENSOR_DELAY_GAME gesetzt, welches ungefähr 25

31 4. Leistungsanalyse der Simulation Abbildung 4.1.: Profiler: Diagnosis [13] 20 ms zwischen Messwerten entspricht. Dadurch werden Sensordaten nicht mehr von den Sensoren des Gerätes aufgezeichnet, sondern von der Simulation von Sensor- Sim. Die erhaltene Anwendung wird anschließend auf jedem Mobilgerät installiert. Ebenfalls wird die Profiling-Anwendung Diagnosis installiert und der Messvorgang gestartet. In der Abspielbibliothek wird ein Datensatz ausgewählt, der die 1Hz-Referenzbewegung des jeweiligen Gerätes aus dem vorherigen Kapitel enthält und anschließend die Aufnahme gestartet. Nach ein paar Minuten werden beide Vorgänge angehalten. Anschließend wird der Vorgang mit einer unmodifizierten Variante der Aufnahme-App wiederholt, die die Sensordaten von den realen Sensoren aufzeichnet. Dies dient als Vergleichswert. Die Messungen werden für jedes Gerät mehrmals wiederholt. 26

32 4. Leistungsanalyse der Simulation 4.3. Auswertung Für jedes Gerät werden anschließend die gemessenen Laufzeitinformationen der simulierten Anwendung mit denen der normalen Anwendung verglichen. Die Werte sind in der folgenden Tabelle dargestellt: Tabelle 4.1.: Laufzeitinformationen der Simulierung Gerät CPU simuliert CPU real Speicher simuliert Speicher real HTC Dream 34.1% 28.4% MB MB HTC One 7.9% 7.0% MB MB LG P500 Stock 27.2% 23.9% MB MB LG P500 CM 26.8% 21.7% MB MB Galaxy S II 12.5% 10.9% MB MB Galaxy S 4 7.3% 6.4% MB MB Bei allen Geräten steigt die CPU-Auslastung um wenige Prozent an, aber lastet das Gerät in keinster Weise aus. Im Speicherverbrauch ist die Erhöhung sichtbarer und beträgt im Regelfall um die 7-10 MB. Durch die Einbindung der Simulationsbibliothek und ein Zwischenspeichern der zu simulierenden Daten ist ein gewisser Anstieg zu erwarten. Da die Anwendung weiterhin ohne Einschränkungen Sensordaten aufzeichnen konnte, schien dies aber nicht zu Problemen zu führen. Die CPU-Auslastung der Simulation wird im Wesentlichen durch das Intervall zwischen Messwerten des SensorManagers (regelbar in der Anwendung) bestimmt, da eine höhere Folge von Messwerten mit mehr Rechenaufwand verbunden ist. Die Speicherauslastung hängt davon ab, wie groß die zwischengespeicherten Sensordaten sind. Dies kann reduziert werden, indem der Abstand zwischen Zugriffen vermindert wird, bei denen SensorSim neue Sensordaten vom Repository holt. 27

33 5. Integration in den Entwicklungsprozess Im folgenden Kapitel wird betrachtet, wie ein Sensor-Simulationssystem den Entwicklungsprozess unterstützen und in welchen Phasen es Anwendung finden kann. Da die Simulation die Sensoren eines Gerätes ersetzen soll, lassen sich mögliche Einsatzmöglichkeiten dort finden, wo man zu einem richtigen Gerät greifen würde, um die Sensoren zu benutzen. Dies findet vor allem in zwei Phasen statt: Integrationstests: Einzelne Module der Anwendung werden kombiniert und als Gruppe getestet. Systemtests: Die gesamte, integrierte Anwendung wird getestet. Eine Simulation kann unter Umständen besser als das reale Gerät geeignet sein, auch wenn sie immer nur eine Näherung bietet. Dies kann der Fall sein, wenn das Gerät aktuell nicht zur Verfügung steht (z.b. in einem anderen Projekt gebraucht wird).... sich die Umgebung nur schwierig kontrollieren lässt (z.b. durch kontextbezogenen Ortswechsel).... die Eingabe deterministisch und reproduzierbar sein muss (z.b. beim Testen bekannter Fehler).... die Funktionsweise der Anwendung bei unterschiedlich starken Störungen sichergestellt werden soll.... die Funktionsweise der Anwendung auf unterschiedlichen Geräten sichergestellt werden soll Black-Box-Test Ein Test mit einer Sensor-Simulationsumgebung funktioniert in der Regel nach Art des Black-Box-Prinzips. Ein Black-Box-Test dient der Anforderungsüberdeckung und läuft ohne Wissen über die Funktionsweise der eigenen Anwendung ab. Die Testfälle, und damit Eingabe und erwartete Ausgabe, ergeben sich damit nur aus der Spezifikation [14]. Die möglichen Tests, bei denen eine Sensor-Simulationsumgebung unterstützen kann, hängen dabei sehr von der Art der eigenen mobilen Anwendung ab. Im folgenden ist ein mögliches Beispielszenario aufgelistet: 28

34 5. Integration in den Entwicklungsprozess Abbildung 5.1.: Black-Box-Test Szenario Tabelle 5.1.: Testszenario: Rennspiel Es wird ein Rennspiel für Android entwickelt. Der Anwender lenkt das Fahrzeug durch eine 3D-Umgebung, indem er das Mobilgerät in die gewünschte Richtung neigt. Je stärker er das Gerät neigt, desto enger fährt das Fahrzeug die Kurve. Teil der Anwendung ist ein Modul, welches Beschleunigungsdaten des Gerätes in die Lenkung des Fahrzeugs übersetzt. Test 1 Eingabe Das Smartphone wird in einem Neigungswinkel von 35 nach rechts gehalten. Ausgabe Das Fahrzeug führt eine Rechtskurve mit einem Radius von 2 m aus. Test 2 Eingabe Das Smartphone wird in 500 ms von 0 auf 35 gedreht und nach 2 s wieder zurückgedreht. Ausgabe Das Fahrzeug reagiert innerhalb weniger Millisekunden auf die Bewegung und nach 2 s hat sich seine Bewegungsrichtung um 50 geändert. Test 3 Eingabe Das Smartphone wird 30 cm linear nach rechts bewegt. Ausgabe Das Fahrzeug behält seine Bewegungsrichtung unverändert bei. Im Rennspiel-Szenario sind ein paar Testfälle definiert, wie sie für eine mobilen Anwendung aussehen könnten, die Gebrauch vom Beschleunigungssensor als Eingabe macht. Die zugrunde liegenden Anforderungen an die Anwendung können folgende sein: Präzise, gleichbleibende Lenkbewegung auf allen Mobilgeräten Schnelle Richtungsänderung im Millisekundenbereich (geringer Input Lag) auf allen Geräten Lineare Bewegungen / Positionsänderungen sollten die Lenkung nicht beeinflussen Um diese Tests durchzuführen, benötigt der Entwickler nun im Regelfall Zugriff auf mehrere physische Geräte. Die aktuelle Version der eigenen Anwendung wird auf den 29

35 5. Integration in den Entwicklungsprozess Geräten installiert. Anschließend werden die notwendigen Bewegungen als SOLL- Eingabe auf jedem Gerät einzeln durchgeführt, entweder manuell oder mit einer mechanischen Apparatur. Letztendlich wird die Ausgabe mit der SOLL-Ausgabe verglichen. Ist der Test fehlgeschlagen, werden die Tests später nach Korrektur wiederholt. Mit einer Sensor-Simulationsumgebung kann der Testaufwand reduziert werden. Der Benutzer nimmt die Referenzbewegungen aus den Testfällen mit einem einzigen Gerät auf. Dies muss nicht im Test der Anwendung selbst erfolgen. Da die SOLL-Eingabe schon nach Erstellen der Spezifikation definiert ist, reicht es auch, schon vor Implementierung der Anwendung diese Bewegungsdaten mittels Aufnahme-App von SensorSim zu erfassen. Bei Test-Durchführung wird der Datensatz zum entsprechenden Testfall in der eigenen Anwendung mittels SensorSim-Library abgespielt, entweder im Emulator (kein Gerät benötigt) oder am Gerät selbst (für reale Laufzeitbedingungen). Das Verrauschen mit den Sensorprofilen von Geräten ermöglicht es, die aufgenommenen Daten auf mehreren Geräten zu simulieren. Schlägt der Test fehl, kann dieser später mit den identischen SOLL-Eingaben wiederholt werden. Die Vorteile sind zusammengefasst: Konkrete SOLL-Eingabe schon nach Anforderungsanalyse aufnehmbar Physisches Gerät muss nicht verwendet werden, Testen auf Emulator möglich Reproduzierbare Eingabe bei mehrmaligen Testdurchführungen Mehrere Geräte können unkompliziert mit einem einzigen Datensatz abdeckt werden. Dies betrifft nicht allein Beschleunigungssensoren. Auch in anderen Anwendungsfällen mit allen anderen Sensoren von Android kann eine Simulationsumgebung ähnliche Vorteile bringen. Möchte der Entwickler beispielsweise testen, ob seine Locationbasierte Anwendung problemlos von einem Ortswechsel von draußen in ein Gebäude umgehen kann, so würde er den Weg mit einem Mobilgerät entlanggehen und dabei GPS- und WLAN-Signale mit der SensorSim-Aufnahme-App aufzeichnen. Später in einem Test können diese Daten dann wiederverwendet werden und der Ortswechsel muss nicht noch einmal für jeden Test und jedes Gerät durchgeführt werden Zwischen Mock-Objekt und Gerät Der obere Abschnitt konzentrierte sich stark auf einen Test auf Systemebene, der vollständigen Anwendung auf dem Zielgerät. Bei Modul- oder Integrationstests werden solche externen Komponenten häufig durch sogenannte Mock-Objekte ersetzt. Diese Objekte stehen als Platzhalter für echte Objekte ein, mit denen das zu testende Modul interagiert [15]. Damit lässt sich die Umgebung nachbilden und kontrollieren. Eine Sensor-Simulationsumgebung weist schon auf den ersten Blick eine Reihe von Gemeinsamkeiten mit Mock-Objekten auf. Sie bildet die Sensor-Schnittstelle des Betriebssystems nach, hat keine externen Abhängigkeiten und liefert ein determiniertes, kontrollierbares Verhalten. 30

36 5. Integration in den Entwicklungsprozess Doch je nach Art der abgespielten Daten geht sie über ein reines Mock-Objekt hinaus. In der Regel sind Mock-Objekte winzig im Funktionsumfang und liefern nur fest einprogrammierte Rückgabewerte zurück. Dies könnte im Falle von Beschleunigungssensoren ein Nullwert oder eine glatte Sinusschwingung sein. SensorSim erweitert dies, da mit realen Daten gearbeitet werden kann. Das Objekt wird zusätzlich mit Eigenschaften des realen Gerätes ausgestattet, wie Rauschen, Störungen, Auflösung oder Zeitverhalten. Damit deckt SensorSim einen großen Bereich zwischen Mock-Objekten und dem echten Gerät ab, für den es bisher keine gängigen, verfügbaren Alternativen gab (siehe Abbildung 5.2). Abbildung 5.2.: Einordnung in die verfügbaren Testmittel Je nach Anwendung und Testfall lässt sich der Grad der Simulation dabei über die aufgenommenen Daten und verfügbaren Optionen in der Simulationsumgebung bestimmen. Beispiel Filtermodul im Rennspiel: das Modul empfängt Beschleunigungsdaten vom Betriebssystem und glättet sie, um Rauschen vom jeweiligen Gerät herauszufiltern. Im Test gibt SensorSim unterschiedlich stark verrauschte Daten in das Modul (Ersatz für Android-SensorManager). Beispiel Eingabemodul im Rennspiel: das Modul bekommt eine geglättete Bewegung vom Filtermodul und lenkt das Fahrzeug dadurch in eine bestimmte Richtung. Im Test gibt SensorSim eine Referenzbewegung frei von Störungen in das Modul (Ersatz für Filtermodul). 31

37 5.3. Automatisches Testen 5. Integration in den Entwicklungsprozess Mit einer Sensor-Simulationsumgebung ist es auch möglich, in bestimmten Anwendungsfällen die Tests automatisiert nach dem Beispiel von JUnit durchzuführen. Die SensorSim-Library steht als Mock-Objekt für das Android-Betriebssystem ein und vor Testbeginn wird ein Sensor-Datensatz eingelesen, der für den Test verwendet wird. In Listing 5.1 wird ein Beispiel präsentiert, bei dem ein WLAN-Modul getestet werden soll, welches erkennt, wenn sich das Gerät in Reichweite eines WLAN-Netzes befindet. Das Modul würde normalerweise das Android-Betriebssystem zum Scannen verfügbarer WLANs benutzen, im Test wird dieses durch SensorSim ersetzt. Ein Datensatz, bei dem vom WLAN First_Router zu WLAN Second_Router gewechselt wird, wird bei Testbeginn als Umgebung eingelesen, anschließend wird der Test durchgeführt und die Rückgabewerte des zu testenden Moduls überprüft. Dies kann besonders in Test-Driven Development von Nutzen sein, z.b. wenn es darum geht, einen Filter zu entwerfen, der nur für die Anwendung relevante Sensordaten durchlässt oder gerätespezifisches Rauschen entfernt. Die eigenen Filterparameter werden angepasst und der Test automatisch neu durchgeführt. Listing 5.1: Pseudo-Code: Automatischer Test eines WLAN-Moduls 1 public void testlocationchange ( ) { 2 SensorSim sim = SensorSim. getinstance ( ) ; 3 sim. p l a y F i l e ( " dataset / sgs4_change_wifi. sim " ) ; 4 5 LocationModule mymodule = new LocationModule ( ) ; 6 assertequals ( " F i r s t _ R o u t e r ", mymodule. getwifiname ( ) ) ; 7 mymodule. waitforlocationchange ( 3 0) ; 8 assertequals ( " Second_Router ", mymodule. getwifiname ( ) ) ; 9 } 5.4. Integration in Vorgehensmodelle In diesem Abschnitt wird darauf eingegangen, an welcher Stelle eine Sensorsimulation in bekannte Vorgehensmodelle der Softwareentwicklung eingebunden werden kann Wasserfall-Modell Das Wasserfallmodell nach Royce ist ein lineares Vorgehensmodell, dass aus der Abfolge der Phasen Anforderungen, Analyse, Entwurf, Implementierung, Test und Betrieb besteht [16]. Eine Simulationsumgebung kann dabei hauptsächlich in der Test-Phase nach der Implementierung zum Einsatz kommen. Da ein finaler Test aber immer an echten Gerä- 32

38 5. Integration in den Entwicklungsprozess ten durchgeführt werden sollte, um Fehler der Simulation vor Auslieferung zu vermeiden, sollte eine Simulation vor allen Dingen in den früheren Tests stattfinden. Abbildung 5.3.: Wasserfall-Modell V-Modell Das von Boehm entwickelte V-Modell besteht im Gegensatz zum Wasserfall-Modell aus miteinander korrelierenden Phasen. Jeder konstruktiven Phase schließt sich später eine prüfende Phase auf der jeweiligen Ebene an. Die Test-Phase ist auf mehrere Teststufen unterschiedlicher Systemebenen verteilt. [16] Eine Simulationsumgebung kann auch hier in den Testphasen eingesetzt werden. Wie in den vorherigen Abschnitten erläutert, lassen sich damit im Wesentlichen die Integrations- und Systemtests abdecken. Bei Systemtests sollte wiederum final am echten Gerät getestet werden, um Fehler zu vermeiden. Ein Einsatz auf Unit-Test- Ebene ist prinzipiell möglich (siehe Abschnitt 5.3), aber nur in eingeschränktem Rahmen für einzelne Module. In den konstruktiven Phasen lassen sich bereits Datensätze als SOLL-Eingaben für die späteren Testphasen aufzeichnen. Abbildung 5.4.: V-Modell 33