Bachelorarbeit. im Studiengang Technische Informatik. von. Constantin Schomburg

Größe: px
Ab Seite anzeigen:

Download "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

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht.

DRESDEN. Ermitteln von Sprunghöhen mit einem Windows Phone. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht. ZfP-Sonderpreis der DGZfP beim Regionalwettbewerb Jugend forscht DRESDEN Ermitteln von Sprunghöhen mit einem Windows Phone Felix Guttbier Schule: Gymnasium Brandis Jugend forscht 2014 ERMITTELN VON SPRUNGHÖHEN

Mehr

Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK

Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK und dem Zugriff auf Sensoren vertraut. Es wird

Mehr

Analyse 1: Diskussion der Beschleunigungsdaten

Analyse 1: Diskussion der Beschleunigungsdaten Flugzeugstart Zielsetzung: In diesem Experiment untersuchen wir die Bewegung eines Flugzeugs, indem wir seine Beschleunigung messen. Da es schwierig sein dürfte, dieses Experiment heutzutage ohne Probleme

Mehr

WCET-Analyseverfahren in der automobilen Softwareentwicklung

WCET-Analyseverfahren in der automobilen Softwareentwicklung WCET-Analyseverfahren in der automobilen Softwareentwicklung Martin Däumler 1 Robert Baumgartl 2 Matthias Werner 1 1 Technische Universität Chemnitz 2 HTW Dresden 28. November 2008 M. Däumler et al (TUC,

Mehr

DIE FILES DÜRFEN NUR FÜR DEN EIGENEN GEBRAUCH BENUTZT WERDEN. DAS COPYRIGHT LIEGT BEIM JEWEILIGEN AUTOR.

DIE FILES DÜRFEN NUR FÜR DEN EIGENEN GEBRAUCH BENUTZT WERDEN. DAS COPYRIGHT LIEGT BEIM JEWEILIGEN AUTOR. Weitere Files findest du auf www.semestra.ch/files DIE FILES DÜRFEN NUR FÜR DEN EIGENEN GEBRAUCH BENUTZT WERDEN. DAS COPYRIGHT LIEGT BEIM JEWEILIGEN AUTOR. Messung von c und e/m Autor: Noé Lutz Assistent:

Mehr

Einführung in die Cross-Plattform Entwicklung Das Intel XDK

Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK vertraut. Es wird Schritt für Schritt die erste eigene Hybrid-App entwickelt

Mehr

Messsystemanalyse (MSA)

Messsystemanalyse (MSA) Messsystemanalyse (MSA) Inhaltsverzeichnis Ursachen & Auswirkungen von Messabweichungen Qualifikations- und Fähigkeitsnachweise Vorteile einer Fähigkeitsuntersuchung Anforderungen an das Messsystem Genauigkeit

Mehr

Fachhochschule Bielefeld Fachbereich Elektrotechnik. Versuchsbericht für das elektronische Praktikum. Praktikum Nr. 2. Thema: Widerstände und Dioden

Fachhochschule Bielefeld Fachbereich Elektrotechnik. Versuchsbericht für das elektronische Praktikum. Praktikum Nr. 2. Thema: Widerstände und Dioden Fachhochschule Bielefeld Fachbereich Elektrotechnik Versuchsbericht für das elektronische Praktikum Praktikum Nr. 2 Name: Pascal Hahulla Matrikelnr.: 207XXX Thema: Widerstände und Dioden Versuch durchgeführt

Mehr

(1) Problemstellung. (2) Kalman Filter

(1) Problemstellung. (2) Kalman Filter Inhaltsverzeichnis (1) Problemstellung...2 (2) Kalman Filter...2 Funktionsweise... 2 Gleichungen im mehrdimensionalen Fall...3 Schätzung des Systemzustands...3 Vermuteter Schätzfehler... 3 Aktualisierung

Mehr

Artikel eindeutig mit Barcodes identifizieren und verfolgen

Artikel eindeutig mit Barcodes identifizieren und verfolgen Artikel eindeutig mit Barcodes identifizieren und verfolgen Einführung Um die Vielfalt an Anforderungen zu erfüllen haben wir drei verschiedene Varianten zur Erfassung von Barcodes implementiert. Die drei

Mehr

Optimierung des Energieverbrauchs eingebetteter Software

Optimierung des Energieverbrauchs eingebetteter Software Optimierung des Energieverbrauchs eingebetteter Software Welchen Einfluss hat eine Programmänderung auf den Energiebedarf einer Applikation? Welcher Programmteil verursacht den größten Energieverbrauch?

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Zeiterfassungsanlage Handbuch

Zeiterfassungsanlage Handbuch Zeiterfassungsanlage Handbuch Inhalt In diesem Handbuch werden Sie die Zeiterfassungsanlage kennen sowie verstehen lernen. Es wird beschrieben wie Sie die Anlage einstellen können und wie das Überwachungsprogramm

Mehr

Praktikumsbericht. Gruppe 6: Daniela Poppinga, Jan Christoph Bernack, Isaac Paha. Betreuerin: Natalia Podlaszewski 28.

Praktikumsbericht. Gruppe 6: Daniela Poppinga, Jan Christoph Bernack, Isaac Paha. Betreuerin: Natalia Podlaszewski 28. Praktikumsbericht Gruppe 6: Daniela Poppinga, Jan Christoph Bernack, Isaac Paha Betreuerin: Natalia Podlaszewski 28. Oktober 2008 1 Inhaltsverzeichnis 1 Versuche mit dem Digital-Speicher-Oszilloskop 3

Mehr

Eine Fahrstuhlfahrt. Datengewinnung (TI 83)

Eine Fahrstuhlfahrt. Datengewinnung (TI 83) Eine Fahrstuhlfahrt Zielsetzung: In diesem Experiment ist es unser Ziel die Bewegung eines Fahrstuhls zu untersuchen und seine Beschleunigung zu messen. Der Sensor ist ein Beschleunigungsmesser, der mit

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

AquaZIS. Zeitreihenkorrektur

AquaZIS. Zeitreihenkorrektur AquaZIS Zeitreihenkorrektur Aachen, Juli 2013 aqua_plan Ingenieurgesellschaft für Problemlösungen in Hydrologie und Umweltschutz mbh Amyastr. 126, 52066 Aachen Tel.: 0241 40070-0, Fax: 0241 40070-99 Geschäftsführer:

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

App-Entwicklung mit Titanium

App-Entwicklung mit Titanium Masterstudienarbeit Betreuung Prof. Dr. M. von Schwerin 1 Gliederung 1.Motivation 2.Aufgabenstellung 3.Projektbeschreibung 4.Projektstatusbericht 5.Fazit und Ausblick 2 1.Motivation Verbreitung von Smartphones

Mehr

Android Testautomatisierung mit dem Framework Robotium

Android Testautomatisierung mit dem Framework Robotium Android Testautomatisierung mit dem Framework Robotium Daniel Knott XING AG @dnlkntt http://www.adventuresinqa.com Daniel Knott Manager Quality Assurance @dnlkntt daniel.knott@xing.com Daniel Knott hat

Mehr

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Proseminar Objektorientiertes Programmieren mit.net und C# Florian Schulz Institut für Informatik Software & Systems Engineering Einführung Was hat Cross-Plattform

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Eine App, viele Plattformen

Eine App, viele Plattformen Eine App, viele Plattformen Anwendungsentwicklung für Mobile Heiko Lewandowski 23.04.2013 EINLEITUNG Festlegung App-Strategie: Welche Ziele möchte ich erreichen? Die Vielzahl der Plattformen und Geräte(hersteller)

Mehr

Kosteneffiziente Akustik-Analyse für Zulieferer im Automobilbau

Kosteneffiziente Akustik-Analyse für Zulieferer im Automobilbau Kosteneffiziente Akustik-Analyse für Zulieferer im Automobilbau Autotüren, Sitze, Nockenwellen, Kugellager, Zylinderkopfdichtungen, Heckklappen, ABS- Motoren die Liste der einzelnen Komponenten, die in

Mehr

3. Erfassung und Verarbeitung von Sensordaten

3. Erfassung und Verarbeitung von Sensordaten 3. Erfassung und Verarbeitung von Sensordaten Lernziele 3. Erfassung und Verarbeitung von Sensordaten Lernziele: Typische in mobilen Geräten enthaltene Sensorarten kennen, Daten von solchen Sensoren empfangen

Mehr

Forumslader App für Android Kurzbeschreibung

Forumslader App für Android Kurzbeschreibung Forumslader App für Android Kurzbeschreibung Für den Forumslader ab Firmware xx281112 steht ein spezielles Bluetoothmodul mit integriertem Fahrradcomputer als Zusatzkomponente zur Verfügung. Dieses sammelt,

Mehr

VARONIS DATADVANTAGE. für Exchange

VARONIS DATADVANTAGE. für Exchange VARONIS DATADVANTAGE für Exchange VARONIS DATADVANTAGE für Exchange Funktionen und Vorteile TRANSPARENZ Bidirektionale Smart Views aller Berechtigungen für Postfächer und öffentliche Ordner sowie Überwachung

Mehr

Quality Point München

Quality Point München Quality Point München Test webbasierter Applikationen - Vorgehen, Instrumente, Probleme Gestern habe ich mich wieder über eine fehlerhafte Webanwendung geärgert. Muss das sein? Test ist halt auch hier

Mehr

Kurtosis - der fehlende Knopf bei der Schwingprüfung oder Sigma Dehnung mit B&K Regelsystem 1059

Kurtosis - der fehlende Knopf bei der Schwingprüfung oder Sigma Dehnung mit B&K Regelsystem 1059 Kurtosis - der fehlende Knopf bei der Schwingprüfung oder Sigma Dehnung mit B&K Regelsystem 1059 Wer sich mit der Schwingprüfung in der Umweltsimulation befasst, verwendet dabei oft weißes, also normal-

Mehr

Softwaretechnik (WS 11/12)

Softwaretechnik (WS 11/12) Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind

Mehr

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden

Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Sperrvermerk Risikomanagement für IT-Projekte: Vergleich von Risiken und Methoden Bachelorarbeit Zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Copyright by QualityMinds. Quelle: http://www.macmania.at/wp-content/uploads/2012/09/karten-app.p

Copyright by QualityMinds. Quelle: http://www.macmania.at/wp-content/uploads/2012/09/karten-app.p 1 Quelle: http://www.macmania.at/wp-content/uploads/2012/09/karten-app.p Quelle: http://www.theeuropean.de/lars-mensel/12318-kontroverse-um-google-und-apple-kartendienste 2 Mobile Testing und Usability

Mehr

LANCOM Techpaper Routing-Performance

LANCOM Techpaper Routing-Performance Techpaper Routing-Performance Einleitung Anwendungen in der Kommunikation und Unterhaltung basieren zunehmend auf IP-Netzwerken. Um die erforderlichen Bandbreiten zuverlässig bereitstellen zu können, müssen

Mehr

LANCOM Techpaper Routing Performance

LANCOM Techpaper Routing Performance Einleitung Die Anwendungen in der Kommunikation und Unterhaltung basieren zunehmend auf IP-Netzwerken. Um die erforderlichen Bandbreiten zuverlässig bereitstellen zu können, müssen die in der Struktur

Mehr

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 16.04.2013 Software Komponenten FS13 Gruppe 03 Horw, 16.04.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Estermann Michael

Mehr

Der Bipolar-Transistor und die Emitterschaltung Gruppe B412

Der Bipolar-Transistor und die Emitterschaltung Gruppe B412 TECHNISCHE UNIVERSITÄT MÜNCHEN Der Bipolar-Transistor und die Emitterschaltung Gruppe B412 Patrick Christ und Daniel Biedermann 16.10.2009 1. INHALTSVERZEICHNIS 1. INHALTSVERZEICHNIS... 2 2. AUFGABE 1...

Mehr

Testen von graphischen Benutzeroberflächen. 24. Juni 2015

Testen von graphischen Benutzeroberflächen. 24. Juni 2015 Testen von graphischen Benutzeroberflächen 24. Juni 2015 Überblick Motivation für das automatische Testen von graphischen Benutzeroberflächen Entwicklungsprinzipien für GUIs Capture / Replay Testmethode

Mehr

Magnetische Induktion

Magnetische Induktion Magnetische Induktion 5.3.2.10 In einer langen Spule wird ein Magnetfeld mit variabler Frequenz und veränderlicher Stärke erzeugt. Dünne Spulen werden in der langen Feldspule positioniert. Die dabei in

Mehr

Sharpdesk Mobile Bedienungshandbuch

Sharpdesk Mobile Bedienungshandbuch Sharpdesk Mobile Bedienungshandbuch Für ipad SHARP CORPORATION 1. Mai 2012 1 Inhaltsverzeichnis 1 Übersicht... 3 2 Voraussetzungen... 4 3 Installation und Start... 5 4 Installation Drucker/Scanner... 6

Mehr

GEVITAS Farben-Reaktionstest

GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest Inhalt 1. Allgemeines... 1 2. Funktionsweise der Tests... 2 3. Die Ruhetaste und die Auslösetaste... 2 4. Starten der App Hauptmenü... 3 5. Auswahl

Mehr

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch

Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen. Alexander Schunk Marcel Teuber Henry Trobisch Softwaretests in Visual Studio 2010 Ultimate Vergleich mit Java-Testwerkzeugen Alexander Schunk Henry Trobisch Inhalt 1. Vergleich der Unit-Tests... 2 2. Vergleich der Codeabdeckungs-Tests... 2 3. Vergleich

Mehr

Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen

Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen Installations- und Benutzeranleitung Semesterarbeit von: Andreas Wüst Stefan Graf Juli 2005 Mobile Data Monitor Seite

Mehr

Benutzerhandbuch planlauf/vibe PRO 2015

Benutzerhandbuch planlauf/vibe PRO 2015 Benutzerhandbuch planlauf/vibe PRO 2015 Anforderungen Unterstützung von OpenGL 2.1 oder höher durch die Grafikkarte Windows 7 mit Microsoft.NET-Framework 4.0 oder höher PDF-Reader (zum Öffnen des Benutzerhandbuchs)

Mehr

MyJablotron Web Self Service

MyJablotron Web Self Service MyJablotron Web Self Service Der Web Self Service MyJablotron ist eine einzigartige Dienstleistung, die den Benutzern und auch den Montagetechnikern einen online Zugang zu den Geräten der Jablotron Holding

Mehr

Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test?

Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Auch wenn die Messungsmethoden ähnlich sind, ist das Ziel beider Systeme jedoch ein anderes. Gwenolé NEXER g.nexer@hearin gp

Mehr

Softwareentwicklung aus Sicht des Gehirns

Softwareentwicklung aus Sicht des Gehirns Softwareentwicklung aus Sicht Business Unit Manager Folie 1 Ziel Das Ziel ist die Beantwortung der folgenden Fragen: 1. Wie lösen Softwareentwickler Probleme kognitiv? 2. Was sind die Schlüsselfaktoren

Mehr

PHP Kurs Online Kurs Analysten Programmierer Web PHP

PHP Kurs Online Kurs Analysten Programmierer Web PHP PHP Kurs Online Kurs Analysten Programmierer Web PHP Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses PHP Modul 1 - Einführung und Installation PHP-Umgebung Erste Lerneinheit Introduzione

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform 02 PROFI News

Mehr

EO - Oszilloskop Blockpraktikum Frühjahr 2005

EO - Oszilloskop Blockpraktikum Frühjahr 2005 EO - Oszilloskop, Blockpraktikum Frühjahr 25 28. März 25 EO - Oszilloskop Blockpraktikum Frühjahr 25 Alexander Seizinger, Tobias Müller Assistent René Rexer Tübingen, den 28. März 25 Einführung In diesem

Mehr

Unit Testing, SUnit & You

Unit Testing, SUnit & You HUMBOLDT-UNIVERSITÄT ZU BERLIN MENSCH-TECHNIK-INTERAKTION ARBEITSGRUPPE SOFTWARETECHNIK (INSTITUT FÜR INFORMATIK) ARBEITSGRUPPE INGENEURPSYCHOLOGIE (INSTITUT FÜR PSYCHOLOGIE) Unit Testing, SUnit & You

Mehr

Grundlagen der Elektro-Proportionaltechnik

Grundlagen der Elektro-Proportionaltechnik Grundlagen der Elektro-Proportionaltechnik Totband Ventilverstärkung Hysterese Linearität Wiederholbarkeit Auflösung Sprungantwort Frequenzantwort - Bode Analyse Der Arbeitsbereich, in dem innerhalb von

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Mobile App Testing - Mit der richtigen Strategie zum Erfolg

Mobile App Testing - Mit der richtigen Strategie zum Erfolg Mobile App Testing - Mit der richtigen Strategie zum Erfolg Thomas Rieger bbv Software Services AG www.bbv.ch 03.09.2015 Q-Event 2015 Erfolgsfaktor Testing 1 Aus dem Alltag eines Mobile App Users 2 Zu

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer Markus Urban.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform

Mehr

Ein mobiler Electronic Program Guide für Android

Ein mobiler Electronic Program Guide für Android Whitepaper Telekommunikation Ein mobiler Electronic Program Guide für Android Prototyp für Android Apps 2011 SYRACOM AG 1 Einleitung Apps Anwendungen für mobile Geräte sind derzeit in aller Munde. Durch

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze) 03.06.2013 2 Innovationen

Mehr

DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung

DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung Was für ein Tempo! Das Rad dreht sich rasant schnell: Die heutigen Anforderungen an Softwareentwicklung sind hoch und werden

Mehr

10 things I wished they d told me! aktuell. innovativ. praxisbezogen.

10 things I wished they d told me! aktuell. innovativ. praxisbezogen. 10 things I wished they d told me! aktuell. innovativ. praxisbezogen. 10 things I wished they d told me! Reinhard Salomon SEQIS Geschäftsleitung SEQIS 10 things Programm 2015 19.03.2015 Mobile Testing:

Mehr

PRAKTIKUM Experimentelle Prozeßanalyse 2. VERSUCH AS-PA-2 "Methoden der Modellbildung statischer Systeme" Teil 2 (für ausgewählte Masterstudiengänge)

PRAKTIKUM Experimentelle Prozeßanalyse 2. VERSUCH AS-PA-2 Methoden der Modellbildung statischer Systeme Teil 2 (für ausgewählte Masterstudiengänge) FACHGEBIET Systemanalyse PRAKTIKUM Experimentelle Prozeßanalyse 2 VERSUCH AS-PA-2 "Methoden der Modellbildung statischer Systeme" Teil 2 (für ausgewählte Masterstudiengänge) Verantw. Hochschullehrer: Prof.

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

Entwicklungsbegleitender Test mechatronischer Systeme

Entwicklungsbegleitender Test mechatronischer Systeme Entwicklungsbegleitender Test mechatronischer Systeme Dr. Olaf Maibaum Folie 1 Übersicht Test von Regelungssoftware Testansätze MiL SiL PiL HiL Vergleich der Testansätze Testautomatisierung Testfälle Simulation

Mehr

Protokollbuch. Friedrich-Schiller-Universität Jena. Physikalisch-Astronomische Fakultät SS 2008. Messtechnikpraktikum

Protokollbuch. Friedrich-Schiller-Universität Jena. Physikalisch-Astronomische Fakultät SS 2008. Messtechnikpraktikum Friedrich-Schiller-Universität Jena Physikalisch-Astronomische Fakultät SS 2008 Protokollbuch Messtechnikpraktikum Erstellt von: Christian Vetter (89114) Helena Kämmer (92376) Christian.Vetter@Uni-Jena.de

Mehr

HP Service Virtualization. Bernd Schindelasch 19. Juni 2013

HP Service Virtualization. Bernd Schindelasch 19. Juni 2013 HP Service Virtualization Bernd Schindelasch 19. Juni 2013 Agenda EWE TEL GmbH Motivation Proof of Concept Ausblick und Zusammenfassung HP Software Performance Tour 2013: HP Service Virtualization 2 EWE

Mehr

Echtzeitanomalieerkennung für Internetdienste (Abschlussvortrag)

Echtzeitanomalieerkennung für Internetdienste (Abschlussvortrag) Lehrstuhl für Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München Echtzeitanomalieerkennung für Internetdienste (Abschlussvortrag) Markus Sieber Betreuer: Ali Fessi,

Mehr

Technische Mitteilung. Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor

Technische Mitteilung. Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor Technische Mitteilung Nutzung von Oracle für die VIP CM Suite 8 Offene Cursor Informationen zum Dokument Kurzbeschreibung Dieses Dokument gibt Hinweise zur Konfiguration des RDBMS Oracle und von VIP ContentManager

Mehr

TD-Mobile-Beispiel mit Barcodescanner

TD-Mobile-Beispiel mit Barcodescanner TD-Mobile-Beispiel mit Barcodescanner 1 Einleitung Viele Interessenten für die Entwicklungsumgebung TD-Mobile wollen mit einem mobilen Endgerät (sprich: Handy) Daten über entsprechende Barcodes erfassen

Mehr

Bedienungsanleitung DOK App

Bedienungsanleitung DOK App Bedienungsanleitung DOK App Auf den folgenden Seiten finden Sie eine Erklärung der Funktionen der Steuerungs App DOK. Sie können die App auf Ihrem Smartphone oder Tablet einrichten und benutzen. Bitte

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

1 Einleitung. 1.1 Motivation

1 Einleitung. 1.1 Motivation 1 Einleitung 1.1 Motivation Eine zunehmende Globalisierung in Verbindung mit der Verbreitung des elektronischen Handels, stets kürzer werdende Produktlebenszyklen und eine hohe Variantenvielfalt konstituieren

Mehr

Cordaware bestinformed Neuerungen in Version 4 Copyright Cordaware Informationslogistik GmbH 2007

Cordaware bestinformed Neuerungen in Version 4 Copyright Cordaware Informationslogistik GmbH 2007 Änderungen ab Basis Edition: Interne Datenbank: Durch die Erweiterung der bestinformed Datenstruktur mit einer leistungsfähigen internen Datenbank werden zahlreiche Verbesserungen erzielt. Um die wichtigsten

Mehr

Das Handbuch zu KSnapshot

Das Handbuch zu KSnapshot Richard J. Moore Robert L. McCormick Brad Hards Korrektur: Lauri Watts Entwickler: Richard J Moore Entwickler: Matthias Ettrich Übersetzung des Handbuchs: Robert Gogolok Übersetzung des Handbuchs: Kilian

Mehr

Neuerungen Analysis Services

Neuerungen Analysis Services Neuerungen Analysis Services Neuerungen Analysis Services Analysis Services ermöglicht Ihnen das Entwerfen, Erstellen und Visualisieren von Data Mining-Modellen. Diese Mining-Modelle können aus anderen

Mehr

Agile Software Verteilung

Agile Software Verteilung Agile Software Verteilung Vortrag: René Steg Steg IT-Engineering, Zürich (Schweiz) Gründe für Agile Software-Verteilung Wenn Sie Hunderte von Servern mit vielen Anwendungen betreiben Verteilte Anwendungen

Mehr

Beilage 1 Zertifikat WAVEEX / W-LAN. A. Morphographische Vermessung der W-LAN-Emission (Verbindung Router-MacBook) ohne und mit WAVEEX

Beilage 1 Zertifikat WAVEEX / W-LAN. A. Morphographische Vermessung der W-LAN-Emission (Verbindung Router-MacBook) ohne und mit WAVEEX A. Morphographische Vermessung der W-LAN-Emission (Verbindung Router-MacBook) ohne und mit WAVEEX Grafik A1: Basismessung Folie 1 Diese Grafik stellt das Ergebnis der Messung dar, bei der die neutrale

Mehr

Ein Geräusch: " Plopp"

Ein Geräusch:  Plopp Ein Geräusch: " Plopp" Zielsetzung: Das Ziel dieses Experiments ist es die Druckveränderungen zu untersuchen, die auftreten, wenn ein Zylinderkolben aus einer kleinen Spritze gezogen wird und die Eigenschaften

Mehr

Schwingungsmessgerät. Place, Connect & Explore

Schwingungsmessgerät. Place, Connect & Explore Schwingungsmessgerät Place, Connect & Explore MENHIR Schwingungsmessgerät MENHIR (Modular ENHanced Intelligent Recorder) misst Schwingungen und Erschütterungen auf effiziente und sichere Art. Im Bereich

Mehr

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Absolut, relativ oder einfach mehr Geld? Analyse der Netto-Differenzen 2014

Absolut, relativ oder einfach mehr Geld? Analyse der Netto-Differenzen 2014 Voraussetzungen Absolut, relativ oder einfach mehr Geld? Analyse der -en 2014 Tarifbeschäftigte und beamtete Lehrerinnen und Lehrer erhalten bei gleicher Arbeitszeit, gleichen Aufgaben und gleichen Belastungen

Mehr

Testen von graphischen Benutzeroberflächen. 26. Juni 2013

Testen von graphischen Benutzeroberflächen. 26. Juni 2013 Testen von graphischen Benutzeroberflächen 26. Juni 2013 Überblick Testarten Methoden-, Klassen-, Komponenten-, Systemtests Motivation für automatisches Testen von graphischen Benutzeroberflächen Entwicklungsprinzipien

Mehr

Abschlussarbeiten 2010 in der Medizininformatik

Abschlussarbeiten 2010 in der Medizininformatik Abschlussarbeiten 2010 in der Medizininformatik Ansprechpartner: Prof. Dr. Eberhard Beck eberhard.beck@fh-brandenburg.de FACHHOCHSCHULE BRANDENBURG FACHBEREICH INFORMATIK UND MEDIEN Konzeption und prototypische

Mehr

Untersuchung der Auswahl der Hauptfreiheitsgrade zum Import eines Modells von ANSYS nach SIMPACK

Untersuchung der Auswahl der Hauptfreiheitsgrade zum Import eines Modells von ANSYS nach SIMPACK IMW - Institutsmitteilung Nr. 35 (2010) 103 Untersuchung der Auswahl der Hauptfreiheitsgrade zum Import eines Modells von ANSYS nach SIMPACK M. Leng; Z. Liang Die Auswahl der Hauptfreiheitsgrade spielt

Mehr

Entwicklungsumgebungen. Packer, Vagrant, Puppet. Alexander Pacnik Mannheim, 10.11.2014

Entwicklungsumgebungen. Packer, Vagrant, Puppet. Alexander Pacnik Mannheim, 10.11.2014 Entwicklungsumgebungen Packer, Vagrant, Puppet Alexander Pacnik Mannheim, 10.11.2014 inovex... über inovex und den Referenten 2 Entwicklungsumgebungen... Übersicht Einführung Packer Konfiguration Packer

Mehr

Lizenzierung von System Center 2012

Lizenzierung von System Center 2012 Lizenzierung von System Center 2012 Mit den Microsoft System Center-Produkten lassen sich Endgeräte wie Server, Clients und mobile Geräte mit unterschiedlichen Betriebssystemen verwalten. Verwalten im

Mehr

Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015

Migrationsstrategien. Dr. Thorsten Arendt Marburg, 22. Januar 2015 Migrationsstrategien Dr. Thorsten Arendt Marburg, 22. Januar 2015 Re-Engineering Patterns [Demeyer et al.] 2 Software-Evolution WS 2014/2015 Überblick Probleme Wenn man ein bestehendes System re-engineered

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

e-serve UP&SM Consult

e-serve UP&SM Consult , Stöckackerstrasse 30, CH-4142 Münchenstein Ph:++41 (0) 61 413 15 00, Fax:++41 (0) 61 413 15 01 http://www.e-serve.ch, crm@e-serve.ch e-serve UP&SM Consult UP&SM: UNIFIED PROCESS & SOFTWARE MANAGEMENT

Mehr

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa Berner Fachhochschule Hochschule für Technik und Informatik HTI Performance und Bandbreitenmanagement Tests Version 10.01.2005 Diplomarbeit I00 (2004) MuSeGa Mobile User Secure Gateway Experte: Andreas

Mehr

Hochschule Mittweida. UML-Dokumenation. Franziska Frenzel [Wählen Sie das Datum aus]

Hochschule Mittweida. UML-Dokumenation. Franziska Frenzel [Wählen Sie das Datum aus] Hochschule Mittweida UML-Dokumenation Franziska Frenzel [Wählen Sie das Datum aus] Inhalt UML-Dokumenation Inhalt... 1 /PF 000/ App ausführen inkl. Tracking und UUID erstellen... 2 /PF 001/ Modus wechseln...

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

auf, so erhält man folgendes Schaubild: Temperaturabhängigkeit eines Halbleiterwiderstands

auf, so erhält man folgendes Schaubild: Temperaturabhängigkeit eines Halbleiterwiderstands Auswertung zum Versuch Widerstandskennlinien und ihre Temperaturabhängigkeit Kirstin Hübner (1348630) Armin Burgmeier (1347488) Gruppe 15 2. Juni 2008 1 Temperaturabhängigkeit eines Halbleiterwiderstands

Mehr

Computergestützte Videoanalyse physikalischer Vorgänge

Computergestützte Videoanalyse physikalischer Vorgänge Computergestützte Videoanalyse physikalischer Vorgänge Erprobung des Systems AVA Wissenschaftliche Arbeit zur Erlangung der ersten Staatsprüfung für das Lehramt am Gymnasium Universität Leipzig Fakultät

Mehr

Dynamische Geometrie

Dynamische Geometrie Dynamische Geometrie 1) Die Mittelsenkrechten, die Seitenhalbierenden, die Höhen und die Winkelhalbierenden eines beliebigen Dreiecks schneiden sich jeweils in einem Punkt. a) Untersuchen Sie die Lage

Mehr

Mobile Enterprise Application Platforms

Mobile Enterprise Application Platforms Mobile Enterprise Application Platforms 17. April 2013 Fachbereich Wirtschaft und Gesundheit Prof. Dr. Volker Wiemann volker.wiemann@fh bielefeld.de +49 (0) 521/106 389 Problem 0. Ausgangslage Blackberry

Mehr

http://www.jimdo.com Mit Jimdo eine Homepage erstellen Kapitel 16 Seite 1 Die eigene Homepage mit Jimdo http://benutzername.jimdo.com Der Benutzername

http://www.jimdo.com Mit Jimdo eine Homepage erstellen Kapitel 16 Seite 1 Die eigene Homepage mit Jimdo http://benutzername.jimdo.com Der Benutzername Kapitel 16 Seite 1 Die eigene Homepage mit Jimdo Mit Jimdo ist das Erstellen einer eigenen Homepage ganz besonders einfach. Auch ohne Vorkenntnisse gelingt es in kurzer Zeit, mit einer grafisch sehr ansprechenden

Mehr

4 1 0.2 2.1 0 1 rtsch e s G ia tth a M Herzlich Willkommen

4 1 0.2 2.1 0 1 rtsch e s G ia tth a M Herzlich Willkommen Herzlich Willkommen 1 «Neue Technologien» Welche Möglichkeiten gib es ausser dem 0815 Variound GPS? 2 Ablauf Grundsätzlich Hardware Software Stromversorgung Externe Sensoren Quellenverzeichniss Fragen

Mehr