Prozessgestützte Entwicklung von Ubicomp Applikationen

Inhaltsverzeichnis

1. Einleitung
1.1. Ziele der Arbeit
1.2. Gliederung der Arbeit

2. Analyse
2.1. Ubiquitous Computing Applikationen
2.2. Applikationsentwicklung
2.3. Auswahl von Algorithmen zur Kontextklassifikation
2.4. Anforderungen an das zu erstellende System

3. Entwurf
3.1. Entwurf eines Prozesses
3.2. Entwicklungsmodell
3.3. Schritt 1: Sammeln von Daten
3.4. Schritt 2: Annotation
3.5. Schritt 3: Datenverarbeitung
3.6. Schritt 4: Auslieferung des Systems
3.7. Evaluation

4. Implementierung
4.1. Anwendungsumgebung
4.2. Datenbank-Logger
4.3. Werkzeug zur Annotation
4.4. Klassifikator für die Kontexterkennung
4.5. CReSB im Überblick

5. Evaluation
5.1. Methodik
5.2. Szenario 1: Dokumentenhandling
5.3. Szenario 2: Whiteboard Aktivitäten
5.4. Szenario 3: Raumüberwachung
5.5. Szenario 4: Bewegungserkennung
5.6. Analyse möglicher Fehlerquellen
5.7. Fazit

6. Zusammenfassung und Ausblick

Literaturverzeichnis

Anhang A. Dokumentation
A.1. Voraussetzungen
A.2. Einrichtung des CReSB
A.3. Datenbank-Logger / ParticleAnalyzer
A.4. Annotations-Tool
A.5. Equip-Komponenten

1. Einleitung

Anwendungen im Bereich Ubiquitous Computing verwenden regelmäßig Kontexte, um da­raus zusätzliche Informationen zu schließen. Kontexte dienen hier dazu, möglichst viel Wissen über die Umgebung, in der eine Anwendung läuft, in diese mit einzubeziehen. Ge­nauso, wie Menschen im Gespräch zu einem Thema alleine schon durch die Nennung des Themengebietes, über welches geredet wird, eine gewisse Menge an impliziertem Wissen zu diesem Thema haben, wird auch bei Anwendungen im Bereich Ubiquitous Computing versucht, die Gesamtsituation, in der sich die Anwendung abspielt, zu erkennen und das sich daraus ergebende Wissen, das in aller Regel deutlich über die Daten hinaus geht, die aus den Sensoren gewonnen werden können, mit in die Anwendung einzubeziehen.

Ein Anwendungskontext muss dazu aus den vorliegenden Daten, die von den beteiligten Sensorknoten zur Verfügung gestellt werden, geschlossen werden. Eine solche Umlegung von Sensordaten auf Kontexte ist jedoch mit verschiedenen Schwierigkeiten verbunden. So muß beachtet werden, dass mehrere Sensorwerte den identischen Kontext repräsentieren können, dass Sensoren für die Zuordnung des Kontextes nicht relevante Daten liefern oder auch, dass eine Kombination von Sensorwerten nicht eindeutig einem Kontext zugeordnet werden können. Weiterhin ist in Anwendungen, bei denen Bewegungs- oder Sprachinfor­mationen von Personen verarbeitet werden, zu beachten, dass verschiedene Personen unter­schiedliche Sprach- und Bewegungsmuster haben. Gleiche Daten, die bei verschiedenen Personen erfasst wurden, können daher unter Umständen unterschiedliche Bedeutungen re­präsentieren.

Für die Installation entsprechender kontextbasierter Anwendungen im Bereich Ubiquitous Computing ist es daher nötig, die Sensordaten derart zu verarbeiten und zu interpretieren, dass der Anwendung selbst Informationen über den Kontext geliefert werden können. Die entsprechende Verarbeitung muß dabei auf den jeweiligen Einsatzfall individuell angepasst werden. Wünschenswert wäre hierzu ein einheitliches Verfahren, mit dessen Hilfe ein Ent­wickler für verschiedenste Anwendungen in kurzer Zeit eine individuell auf den Anwen­dungsfall angepasste Verarbeitung der Sensordaten zu Kontextinformationen einrichten kann.

1.1. Ziele der Arbeit

Ziel dieser Diplomarbeit ist es, eine Vereinheitlichung des Entwicklungsprozesses für kon­text-sensitive Ubicomp Applikationen zu erreichen und als direkte Folge dessen die Ge­schwindigkeit für die Entwicklung neuer Ubicomp Applikationen deutlich zu steigern. Denn aktuell existiert noch kein einheitliches Verfahren, um Kontextinformationen für eine Ubicomp Anwendung aus den aktuell vorliegenden Sensordaten, die von den für die An­wendung installierten Sensorknoten geliefert werden, zu schließen. Bao et al. bezeichnen in ihrer Ausarbeitung zum Thema „Activity Recognition from User-Annotated Acceleration Data“ [08] die Erkennung von Kontexten, in denen sich eine Anwendung gerade befindet, gar als eines der Schlüsselprobleme des Ubiquitous Computings.

Bei den am TecO eingerichteten Anwendungen musste daher in der Vergangenheit jeweils die komplette Verarbeitung der Sensordaten von Grund auf implementiert werden, was ei­nen entsprechenden Arbeitsaufwand mit sich gezogen hat, der bei jeder Anwendung wieder angefallen ist. Mit Hilfe der Ergebnisse dieser Diplomarbeit soll dieser Arbeitsaufwand bei zukünftigen Projekten reduziert werden.

Im Rahmen dieser Diplomarbeit soll daher ein einheitlicher Prozess entwickelt werden, mit dessen Hilfe es in Zukunft bei verschiedenen Projekten möglich sein soll, die Verarbeitung der Sensordaten zu Kontexten auf die gleiche Art und Weise einzurichten. Alle für diesen neu zu gestaltenden Prozess notwendigen Anwendungen sind im Rahmen der Diplomarbeit zu implementieren. Der Prozess und die einzelnen Anwendungen sollen dabei so gestaltet werden, dass sie später in möglichst verschiedenen Anwendungen zum Einsatz kommen können.

1.2. Gliederung der Arbeit

Vor der eigentlichen Implementierung wird zuerst eine ausführliche Analyse durchgeführt, um die Anforderungen von Ubiquitous Computing Applikationen im Allgemeinen festzu­stellen. Der neu zu entwickelnde Prozess für die Kontexterkennung soll danach in einem Entwurf so gestaltet werden, dass die im Rahmen der Analyse aufgedeckten Anforde­rungen vollständig erfüllt werden. Darüber hinaus ist schon im Entwurf darauf zu achten, den neuen Prozess so zu gestalten, dass er die gewünschte Flexibilität in Hinblick auf den Einsatz in verschiedenen Anwendungen erfüllen kann.

Nachdem der neue Prozess vollständig Entworfen ist, wird er im Rahmen der Implementie­rung praktisch umgesetzt. Für Teile des Prozesses, in denen am TecO bestehende Anwen­dungen wiederverwendet werden können, sind diese Anwendungen bevorzugt einzusetzen oder gegebenenfalls anzupassen, so dass einerseits unnötige Doppelentwicklungen vermie­den werden und andererseits die Anwender mit vertrauten Werkzeugen weiterarbeiten kön­nen.

Im Anschluß an die Implementierung ist der neu entwickelte Prozess zu testen. Bei der Auswahl der Testszenarien wird darauf geachtet, dass diese möglichst verschiedenartig ge­staltet sind. Es soll somit sichergestellt werden, dass es möglich ist, eine fundierte Aussage darüber zu treffen, ob das Ziel erreicht worden ist, den Prozess so zu gestalten, dass er in in verschiedensten Anwendungsfällen eingesetzt werden kann.

2. Analyse

Zu Beginn der Arbeit soll eine Analyse durchgeführt werden, welche Bestandteilen zentral für Ubiquitous Computing Anwendungen sind, welche davon bereits verfügbar sind und an welcher Stelle sich bei der vorhandenen Software Lücken ergeben, wenn man eine Ubiqui­tous Computing Anwendung möglichst automatisch erstellen will.

2.1. Ubiquitous Computing Applikationen

Ubiquitous Computing steht für die allgegenwärtige Verarbeitung von Informationen durch (Kleinst-)Computer. Geprägt wurde der Begriff des Ubiquitous Computings vor allem durch Mark Weiser, dessen Publikation „The Computer for the 21st Century“ als die Basis der kompletten Ubicomp Forschung gilt. Die Grundidee des Ubiquitous Computings ist die Verschmelzung der Umwelt mit den Zusatzinformationen, die ein Computer zu dieser lie­fern kann. Dadurch „besteht die Möglichkeit, mit überschaubarem Aufwand Informationen zu gewinnen, die im jeweiligen Umfeld zusätzliche Nutzenpotentiale generieren können.“ [01] Ein besonderes Anliegen der Ubiquitous Computing Forschung ist die Vermeidung von Medienbrüchen „als zentrales Argument zur Steigerung der Effizienz in Netzwerken“ [01].

Ein zentraler Bestandteil von Ubiquitous Computing Anwendungen sind daher Sensoren, welche Daten aus der realen Welt direkt aufnehmen können. Aus den durch die Sensoren gewonnenen Rohdaten können dann innerhalb der Applikationen höherwertige Informati­onen wie beispielsweise Anwendungskontexte gefolgert werden. Eine derartige Folgerung hochwertigerer Informationen setzt jedoch das vorherige Einbringen von Expertenwissen voraus, durch welches den Rohdaten eine Bedeutung gegeben werden kann, ähnlich wie ein Mensch Zahlen in verschiedenen Einheiten nur durch seinen Erfahrungsschatz eine Be­deutung zumessen kann. Zum Beispiel ist es ohne eine Umrechnung in eine aus der Heimat bekannte Währungseinheit am ersten Urlaubstag nicht möglich zu entscheiden, ob Preise in einer unbekannten Währung billig, fair oder überteuert sind. Sobald jedoch eine derartige Umrechnung (auch wenn es nur eine grobe Überschlagsrechnung im Kopf ist) durchgeführt wurde, lassen sich die Preise beurteilen. Nach dem selben Prinzip lassen sich nur dann hö­herwertige Informationen aus Sensor-Rohdaten schließen, wenn die Sensordaten in Bezug zu früheren Messungen gesetzt werden können, zu denen eine Interpretation durch einge­brachtes Expertenwissen vorliegt.

Ubicomp Applikationen laufen typischerweise verteilt auf in die Umgebung eingebettete Computersysteme mit nur geringen Ressourcen, und nicht wie klassische PC-Applikati­onen werden auf einem zentralen Rechner. Sowohl die Datenaufnahme, die Verarbeitung der Daten als auch die Ausgabe der Ergebnisse findet dabei direkt in der Umgebung statt, zu der die Berechnungen durchgeführt werden müssen. Marc Weiser hat diesen Gegensatz zwischen diesen beiden Konzepten in einer Grafik (siehe Abbildung 2.1) zum Ausdruck gebracht. In der virtuellen Realität wird die gesamte Funktionalität auf einen zentralen Rechner zusammengebracht, dieser Rechner entspricht somit einem Multifunktionsgerät, was Weiser mit Pfeilen auf den in der Mitte der Zeichnung liegenden PC deutlich macht. Im Ubiquitous Computing dagegen werden die einzelnen Funktionen in jene auf die Um­welt verteilten Objekte eingebettet, welche für die entsprechenden Aktivitäten benötigt werden. Letzteres macht Weiser wiederum mit Pfeilen deutlich, die vom zentral gelegenen Rechner weg hin zur Umwelt gehen.

Für den im Rahmen dieser Diplomarbeit zu entwickelnden Prozess lassen sich aus den ge­nerellen Anforderungen des Ubiquitous Computings zusammengefasst folgende Anforde­rungen ableiten: Der Prozess muss zu Applikationen führen, die Sensordaten sowie zusätz­lich eingebrachtes Experten­wissen aufnehmen können. Ferner soll die Anwendung verteilt in der Umgebung laufen können, aus der die Daten, welche verarbeitet werden sollen, stammen. Ein besonderes Au­genmerk soll dabei auf Kontextinformationen gelegt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Abgrenzung von virtueller Realität und Ubiquitous Computing nach Marc Weiser
[Quelle: http://www.ubiq.com/hypertext/weiser/VRvsUbi.gif]

Kontextinformationen sind zentraler Bestandteil von Ubiquitous Computing Anwen­dungen. Durch die direkte Einbeziehung von den Informationen über die Umwelt, in der eine Anwendung läuft, ist es möglich, den Benutzer von Eingaben zu entlasten, da die An­wendung notwendige Informationen selbstständig aus dem Kontext, in dem sie läuft, schließen kann. Kontext-bewusste Anwendungen passen sich „an den Ort, an dem sie aus­geführt werden, Personen im Umkreis oder verfügbare Geräte automatisch an“ [04]. Dey et al. bezeichnen Kontext als wichtige Informationsquelle für interaktive Computeranwen­dungen [05].

Schon in den Anfängen der Forschung zum Thema Ubiquitous Computing wurde der Kon­texterkennung eine entscheidende Rolle eingeräumt. In ihrer Ausarbeitung „Context-Aware Computing Applications“ [04] beschreiben Schilit et al. Versuche, wie sie mit dem Parc­Tab, einem der ersten speziell für Ubiquitous Computing Anwendungen geschaffenen Ge­räte, mit Hilfe von dessen eingebauter Sensorik eine raumbezogene Ortsbestimmung durchführen können. Die sich aus dieser Ortsinformation ergebenden Informationen sind eine Form von Anwendungs-Kontext. Jedoch stellt die Erkennung von Kontexten, in denen sich eine Anwendung gerade befindet, eines der Schlüsselprobleme des Ubiquitous Com­putings dar [08].

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: Einordnung der Kontextinformationen zwischen Sensordaten und Anwendung

Für eine Ubiquitous Computing Anwendung lässt sich die Einordnung des Kontextes gut in einem Schichtenmodell darsellen (Abbildung 2.2). Auf unterster Ebene liegen die Roh­daten, die aus den für die Anwendung eingerichteten Sensoren stammen. Darüber liegt die Kontext Schicht, die auf die Rohdaten zugreift und aus diesen Kontextinformationen gene­riert, welche von der wiederum darüber liegenden Anwendungsschicht verwendet werden. Eine derartige Trennung der Verarbeitung der reinen Sensordaten von der Anwendung ist sehr sinnvoll, da sich nun der Applikationsentwickler nicht mehr um die Interpretation der Sensordaten kümmern muss, sondern direkt auf die aufbereiteten Kontextinformationen zugreifen kann [05]. In den folgenden Abschnitten werden die Anforderungen und Mög­lichkeiten, die sich innerhalb der Anwendungs- und Kontextschicht stelle, näher betrachtet.

Mit dem System Sentient Processes der Universität Stuttgart steht ein System zur Verfü­gung, welches in der Lage ist, auf der Basis von erkannten Kontexten Aktionen auszufüh­ren [10]. In Sentient Processes werden dazu Kontextsituationen modelliert. Für jeden mo­dellierten Kontext lassen sich dann Aktionen angeben, die ausgeführt werden, sobald der entspre­chende Kontext erkannt wurde. Entscheidend für die korrekte Ausführung eines an­gedachten Prozesses ist es dabei natürlich, dass die Kontexte entsprechend korrekt erkannt werden.

2.2. Applikationsentwicklung

An dieser Stelle sollen die verschiedenen Möglichkeiten, die sich in Bezug auf die Appli­kationsentwicklung bieten, miteinander verglichen werden und auf die besonderen Anfor­derungen der Applikationsentwicklung im Bereich Ubiquitäre Systeme eingegangen wer­den.

2.2.1. Programmierung durch Anwender

Khai Truong, Elaine Huang und Gregory Abowd verfolgen in ihrem 2004 veröffentlichten Paper „A Magnetic Poetry Interface for End-User Programming of Capture Applications for the Home“ [02] den Ansatz, dass Endbenutzer eines Ubiquitous Computing Systems selbst in die Lage versetzt werden sollten, das System, welches sie benutzen wollen, zu Programmieren. Hierzu wurde mit CAMP (Capture and Access Magnetic Poetry) ein Sy­stem entwickelt, dass sich ganz klar von Ansätzen, bei denen Entwickler die Einrichtung eines Ubiquitous Computing Systems übernehmen müssen, distanziert.

Auch von bereits existierenden Projekten zum Thema Anwenderprogrammierung di­stanzierten sich Truong und seine Mitarbeiter deutlich. Der Grund hierfür ist in der Tatsa­chen zu finden, dass existierende Arbeiten zum Thema zwar für Endanwender gedacht sind, den Aufbau der Applikationen jedoch sehr ähnlich zu Ansätzen halten, die eigentlich für die Programmierung durch Experten gedacht sind. In diesen Projekten steht nicht das vom Be­nutzer verfolgte Ziel im Vordergrund, sondern es wurde eher versucht, die Pro­grammierung einzelner Geräte für den Benutzer zu vereinfachen. Die Gruppe um Truong hat es sich jedoch vorgenommen, das vom Anwender verfolgte Ziel in den Vordergrund zu stellen, was gemäß ihrer Untersuchungen für einen ungeübten Anwender deutlich intuitiver ist als die reine Programmierung von Geräten oder auch Aufgaben.

Nach einer Studie, in welcher der Frage nachgegangen wurde, wie Anwender Ubiquitous Computing Applikationen, die sie bei sich zu Hause als hilfreich empfinden würden, intui­tiv beschreiben würden, kam man zu zwei zentralen Beobachtungen. Zum einen gingen die Teilnehmer der Studie nicht auf die Geräte ein, die für Ihre Anwendung benötigt werden, sondern beschrieben nur, was sie tun möchten. Die zweite Beobachtung war, dass sich die Benutzer keine besonderen Gedanken über die Art der Daten gemacht haben, die sie für ihre Anwendung von den Geräten aufzeichnen lassen wollten. Die Art der Daten, welche die Benutzer für Ihre Applikationen aufnehmen wollen, wurde stets impliziert und nicht explizit erwähnt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3: Ein Beispiel für ein System für die Programmierung durch Anwender:
Capture and Access Magnetic Poetry (CAMP) Quelle: [02]

Ausgehend von dieser Untersuchung sowie einer Untersuchung darüber, wie eine Ubiqui­tous Computing Anwendung aus Anwendersicht aussehen sollte, wurde von Truong et al. das Capture and Access Magnetic Poetry (CAMP) System entwickelt. Innerhalb des CAMP Systems ist es dem Anwender möglich, mit einem begrenzten, domain-spezifischen Wortschatz die von ihm gewünschte Anwendung in seiner ihm bekannten natürlichen Sprache zusammenzusetzen. Dieses Konzept hat den großen Vorteil, dass die Anwender praktisch nicht in das System eingelernt werden müssen, da ihnen die Sprache bereits be­kannt ist.

Aus einem vorgegebenen Wortschatz können die Anwender bei CAMP innerhalb einer grafischen Benutzeroberfläche Sätze zusammen klicken, welche die von ihnen erwünschte Anwendung beschreiben. Das System generiert aus diesen Sätzen dann alle benötigten In­formationen für die Ansteuerung der benötigten Geräte. Abbildung 2.3 zeigt die Benutzero­berfläche des CAMP-Systems.

Das CAMP System von Truong et al. arbeitet komplett auf der Anwendungsebene der drei in Abb. 2.2 skizzierten Schichten. Der Anwender, der mit CAMP Ubiquitous Computing Applikationen erstellt, muss sich nicht um die Erkennung von Kontexten oder gar die Ver­arbeitung von Rohdaten kümmern. Die dazu notwendigen Routinen müssen bereits zuvor von den Entwicklern des CAMP Systems zur Verfügung gestellt werden.

2.2.2. Programmierung durch Experten

Bei der Entwicklung von Ubiquitous Computing Anwendungen durch Experten muss im Gegensatz zur Programmierung durch den Anwender keine Rücksicht darauf gelegt wer­den, dass die Anwendung möglichst intuitiv zusammengestellt werden kann. Ganz im Ge­genteil kann davon ausgegangen werden, dass ein als Experte bezeichneter Programmierer mit allen Details und den benutzten Geräten bestens vertraut ist und auf niedriger Ebene di­rekt auf die zur Verfügung gestellten Daten und Routinen einzelner Geräte zugreifen kann. Genauso ist ein Entwickler in der Lage, alle benötigten Routinen für die Verarbeitung der Daten selbst zu erstellen.

Optimalerweise werden von Entwicklern entworfene Anwendungen so gestaltet, dass sich Teile davon für spätere Anwendungen wieder verwenden lassen. Dieses Ziel wird in der Praxis jedoch selten erreicht, beispielsweise da in der Endphase eines Projektes nicht ge­nug Zeit bleibt, die Anwendung auf ihre Wiederverwertbarkeit hin auszulegen oder weil weite Teile der Anwendung zu spezifisch für ihren eigentlichen Einsatzzweck entwickelt wurden, als dass man sie später für andere Applikationen wieder anwenden könnte. Ein Grund hierfür ist, dass die Algorithmen für die Auswertung sehr speziell für den jeweiligen Anwendungsfall implementiert werden können. Dies hat zwar den Vorteil, in diesem einen Anwendungsfall sehr detailliert auf die speziellen Anforderungen eingehen zu können und die Lösung für diesen Fall entsprechend komplex implementieren zu können. Gleich­zeitig führt diese Spezialisierung jedoch auch dazu, dass sich die Ergebnisse nicht oder nur sehr eingeschränkt auf andere Anwendungsfälle übertragen lassen.

Für die Programmierung durch Entwickler gibt es verschiedene Ansätze in Bezug auf die Konzeption des Systems. Besonders verbreitet sind hierbei die Low-Level Programmierung sowie die Verwendung einer Middleware. Bei der Low-Level Programmierung hat der Pro­grammierer einen direkten Zugriff auf die Sensorik der zum Einsatz kommenden Sensor­knoten. Dies ermöglichst ein sehr effizientes Programmieren mit kurzen Reaktionszeiten und kleinen zu übertragenden Datenmengen, erfordert jedoch gleichzeitig ein sehr tiefes Verständnis von den zum Einsatz kommenden Komponenten.

Dem gegenüber steht der Middleware-Ansatz. Hierbei werden Funktionen nicht durchge­hend vom Auswertungsprogramm bis zur Sensorik implementiert, sondern es werden ver­schiedene Abstraktionsschichten eingeführt. Ein Zugriff auf einen Sensor erfolgt dann nicht mehr direkt auf diesen, sondern auf die entsprechende Schnittstelle in der Abstrakti­onsschicht. Diese hat einerseits den Vorteil, dass für Zugriffe auf Sensoren nicht mehr das Expertenwissen über die genaue Ansteuerung eines Sensors nötig ist, es reicht, wenn man einmalig die Ansteuerung der Sensor-Abstraktionsebene verstanden hat. Andererseits führt es jedoch zu einem Overhead an zu übertragenden Daten, der größer ist als beim direkten Zugriff auf den Sensor, da die Daten der Sensoren für die einheitliche Schnittstelle aufbe­reitet werden müssen.

Die Nachteile der Anwendungsentwicklung durch Programmierer sind vor allem in der mangelnden Standardisierung zu finden. Es gibt für Bereiche wie die Datenaufnahme oder die Verarbeitung der Daten kein allgemeingültiges Verfahren sondern eine Vielzahl an ver­schiedenen Wegen, die alle zum gleichen Ziel führen können. Eine Applikation wird daher oftmals von Grund auf spezifisch auf den jeweiligen Anwendungsfall zugeschnitten ent­worfen. Auch wenn dies zwar einerseits ermöglicht, für jeden Anwendungsfall eine mög­lichst optimal passende Anwendung schreiben zu können, so wird diese Flexibilität jedoch gleichzeitig mit einem jedes Mal auf das Neue anfallenden hohen Arbeitsaufwand bezahlt.

Einen Ansatz zur Standardisierung der Entwicklung von Anwendungen stellt das Context Toolkit von Dey et al. dar [05]. Im Context Toolkit wird eine mehrstufige Architektur ein­geführt, um zwischen den Sensoren und der Anwendung zu vermitteln. Zuerst werden die Sensordaten auf sogenannte Widgets abstrahiert. Ähnlich wie bei einer Middleware ermög­licht es diese Abstraktion, dass für die weitere Verarbeitung kein Detailwissen über das Datenformat der Sensordaten nötig ist. Die Anwendung kann nun entweder direkt auf einen derartigen Widget zugreifen, oder aber auf einen Context Server, der die Daten von mehre­ren Widgets aggregiert.

2.2.3. Methoden der Anwendungsentwicklung in Ubicomp Umgebungen

Sowohl die prozessbasierte Applikationsentwicklung als auch die komponentenbasierte Applikationsentwicklung sind im Bereich der Ubiquitären Systeme weit verbreitet und sol­len daher auch für die im Rahmen dieser Diplomarbeit anstehende Entwicklung beachtet werden.

Eine komponentenbasierte Anwendung vereint hierbei gleich zwei entscheidende Vorteile. Neben der Tatsache, dass eine komponentenbasierte Anwendung sehr gut in Einklang zu bringen ist mit der dezentralen Herangehensweise, die Grundlage jeder Anwendung im Be­reich Ubiquitous Computing ist, bieten sich auch enorme Vorteile im Hinblick auf die Weiterentwicklung der Anwendung. Eine komponentenbasierte Anwendung vereint durch die Tatsache, dass die Anwendung mit geringem Aufwand umkonfiguriert werden kann, um neuen Anforderungen zu entsprechen oder um die Anwendung zu verbessern, ein hohes Maß an Adaptierbarkeit auf neue Anforderungen mit der Möglichkeit, die Anwendung evo­lutionär Weiterzuentwickeln [11].

Ein Beispiel für ein derartiges komponentenbasiertes System, welches sich auch für die Be­nutzung durch Anwender eignet, ist das von Chris Greenhalgh an der University of Not­tingham entwickelte Equator System. In Equator ist es dem Anwender möglich, aus einer Vielzahl von vorgefertigten Komponenenten eine eigene Anwendung zu erstellen und zu konfigurieren. Gleichzeitig ist Equator auch für Entwickler geeignet, da es über eine defi­nierte Schnittstelle die Möglichkeit bietet, sowohl in Java als auch in C++ neue Kompo­nenten zu erstellen.

Im Rahmen der prozessbasierten Applikationsentwicklung soll die Möglichkeit ausgenutzt werden, bestehende Teilfunktionen weiter zu nutzen. Urbanski et al. zeigen hierzu in [12] das Beispiel einer Service-Hotline auf, bei der der Gesamtprozess der Reparatur eines Ge­räts nach einem Kundenanruf und der anschließenden Abrechnung durch die Servicegesell­schaft neu aufgestellt wird, dabei jedoch auf verschiedene bereits existierende Möglich­keiten zurückgegriffen wird. Dieses Zurückgreifen auf bestehende Bausteine und der For­mung eines neuen Gesamtprozesses aus diesen Bausteinen kann bei der Erstellung des neu­en Prozesses viel Arbeit ersparen. Von Urbanski et al. Wurde daher das System Sentient Processes entwickelt, das für die Erstellung von neuen längfristigen Tätigkeiten auf Bau­steine in Form von bereits implementierten kurzfristigen Tätigkeiten zurückgreift.

2.2.4. Zusammenfassung

Aus den vorangegangenen Betrachtungen über verschiedene Programmiertechniken und den jeweils zur Verfügung stehenden Werkzeugen lässt sich die in Tabelle 2.1 dargestellte Übersicht zusammenfassen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Übersicht über verschiedene Anwendungsumgebungen und ihre Ausrichtung

Die Übersicht verdeutlicht, dass vor Beginn der Implementierung klar gemacht werden muß, wie eine Anwendung am Ende aussehen soll. Ausgehend von dieser Entscheidung kann dann das passenden Toolkit für die Entwicklung der Anwendung verwendet werden.

2.3. Auswahl von Algorithmen zur Kontextklassifikation

Nachdem im vorangegangenen Abschnitt die Programmierung auf der Anwendungsschicht betrachtet wurde, soll nun die nächste in Abbildung 2.2 eingezeichnete Schicht betrachtet werden. Für die Auswertung von Sensordaten zu Kontextinformationen stehen eine Viel­zahl von verschiedenen Verfahren zur Verfügung, die sich in die Klassen der regelbasierten Systeme, den Wahrscheinlichkeitsansätzen sowie neuronale Netze einteilen lassen.

Ein Beispiel für ein regelbasiertes System ist das von Terada et al. in [16] vorgestellte Prin­zip Event Condition Action (ECA). Eine Regel in ECA setzt sich aus drei Teilen zusam­men: Zuerst wird ein Ereignis festgelegt, welches eine Regel auslösen soll. Dazu gibt es für jede Regel Bedingungen, die die beim Auslösen der für die Regel spezifizierten Aktion eingehalten werden müssen. Eine solche Aktion kann dabei nicht nur das Auslösen eines externen Programmes sein sondern auch eine weitere ECA-Regel. Jung et al. haben in [13] eine XML-basierte Sprache zur Beschreibung derartiger ECA Regeln vorgestellt, welches ubiquitäre Systeme verstärkt in eine ereignisbasierte Richtung führen soll. Es sind hierbei jedoch keine Möglichkeiten für das automatische Einlernen eines solchen ECA-Systems vorgesehen, die entsprechenden Regeln müssen vorher vom Entwickler statisch einpro­grammiert werden.

Fuzzy-Logiken ordnen Ereignisse Klassen zu, wobei die Zuordnung unscharf geschieht. Ein Ereignis kann dabei nicht nur fest zu einer Klasse zugeordnet werden, sondern auch nur teilweise zu dieser Klasse zugeordnet werden.

Künstlichen neuronale Netze finden große Verwendung im Bereich der Forschung zur künstlichen Intelligenz. Eine stärke von künstlichen Neuronalen Netzen ist die Fähigkeit, auch dann gute Erkennungsraten zu liefern, wenn nur wenig Expertenwissen zu einer Situation vorliegt. So haben auch Laerhoven et al. in [14] ein auf einem künstlichen neuro­nalen Netzwerk basierendes System erstellt, das sich möglichst autonom einlernen sollte. Darin wurden die Daten aus verschiedenen Sensoren kombiniert um einen Kontext für das Gesamtsystem aller Sensoren feststellen. Zum Einsatz kam dieses neuronale Netzwerk bei der Erkennung von Aktivitäten, die eine Person aktuell ausführt. Unterschieden wurde hier­bei zwischen sitzen, stehen, gehen und rennen.

Im Bereich der auf der Berechnung von Wahrscheinlichkeiten basierenden Algorithmen sind vor allem Bayes-Netzwerke stark verbreitet. Bayes-Klassifikatoren berechnen anhand bekannter a-Priori Wahrscheinlichkeiten die bedingte Wahrscheinlichkeit, dass ein Ereig­nis A auftritt unter der Bedingung, dass Ereignis B aufgetreten ist. Denkbar sind hier auch Kombinationen aus mehreren Verfahren. Park et al. haben in [15] ein Verfahren vorge­stellt, bei dem eine Klassifikation von Ereignissen mit einer Kombination aus Bayes- und Fuzzy-Klassifikation durchgeführt wurde.

Tabelle 2.2 zeigt eine Übersicht über verschiedene in den einzelnen Verfahrensklassen zur Verfügung stehenden Algorithmen. Um die Leistungsfähigkeit der einzelnen Algorithmen für eine spezielle Anwendung vergleichen zu können, existieren bereits entsprechende Werkzeuge. Exemplarisch angeführt sei hierzu an dieser Stelle das an der Lancaster University entwickelte CommonSense Toolkit.

Das im Rahmen des CommonSense Projektes entstandene Toolkit von Kristof Van Laerho­ven [06] ist vor allem zur Live-Auswertung von Sensordaten ausgelegt. Es bietet neben Komponenten für den Zugriff auf Sensoren, der Abstraktion sowie der Visualisierung von Sensordaten die Möglichkeit, verschiedene Algorithmen wie k-nächster Nachbar oder mul­tivariate Gauß-Klassifikatoren auf ihre Eignung für ein Szenario zu evaluieren vgl. [07]. Dazu bietet das CommonSense Toolkit Funktionen für die Annotierung von Daten.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Gegenüberstellung zweier möglicher Annotationstechniken

Mit dem CommonSense Toolkit steht somit ein Werkzeug zur Verfügung, Daten zu anno­tieren und verschiedene Algorithmen zu evaluieren. Da das Toolkit jedoch auf den Live-Betrieb ausgelegt ist, sind keine Möglichkeiten vorgesehen, die anfallenden Sensordaten sowie die Annotierungen auch für den späteren Gebraucht zu speichern. Zur Evaluation verschiedener Algorithmen unter den exakt gleichen Bedingungen, also mit den exakt glei­chen Sensordaten, erfordert das CommonSense Toolkit jedoch eine vom Benutzer zu schaffende Möglichkeit zur Speicherung eben dieser Daten. Die Annotation der Daten wäre in diesem Fall vom User zu wiederholen.

2.4. Anforderungen an das zu erstellende System

Die bisherige Bestandsanalyse zeigt, dass es für die Weiterverarbeitung von Kontextinfor­mationen eine Vielzahl von bestehenden Systemen gibt, sowohl für die Anforderungen, die Anwender an die Entwicklung von Applikationen stellen, als auch für die tiefgreifenderen Anforderungen, die von Entwicklern gestellt werden.

Ebenso existieren Werkzeuge, die den bequemen Zugriff auf Sensordaten ermöglichen. Je­doch fehlt ein wiederverwertbares System, mit dem sich aus vorliegenden Rohdaten auf höherwertige Kontextinformationen schließen lässt, welche dann wiederum über bestehen­de Möglichkeiten weiter verarbeitet und verbreitet werden.

Im Rahmen dieser Diplomarbeit soll daher ein System entwickelt werden, das es ermögli­cht, mit möglichst geringem Aufwand in verschiedensten Anwendungen von den vorlie­genden Rohdaten auf hochwertigere Kontextinformationen zu schließen. Da bei bestehen­den Ubiquitous Computing Applikationen regelmäßig ähnliche Schritte durchgeführt wur­den, um ein derartiges automatisches Schließen von Kontexten zu erzielen (zuerst die Auf­nahme von ersten Sensordaten, danach das Hinzufügen von Expertenwissen zu den aufge­nommenen Daten und am Ende die Reproduktion des Expertenwissens auf neue Sensorda­ten), wird davon ausgegangen, dass sich für diesen Vorgang ein automatisiertes Verfahren einrichten lässt, welches sich dann für eine Vielzahl von Ubiquitous Computing Anwen­dungen einsetzen lässt.

Um einen Vergleich verschiedener Algorithmen unter gleichen Bedingungen zu ermögli­chen, soll das neu zu schaffende System nicht nur Auswertungen von aktuell anfallenden Daten vornehmen können, sondern den Benutzer auch dabei unterstützen, anfallende Daten aufzuzeichnen und später beliebig oft wieder abzuspielen, um verschiedene Klassifikatoren unter exakt gleichen Bedingungen zu testen und zu vergleichen.

Neben der reinen Aufnahme der Sensordaten muss außerdem eine Möglichkeit geschaffen werden, Expertenwissen über den aktuellen Zustand des zu beobachtenden Szenarios zu speichern. Mit der Anforderung der Möglichkeit zur Speicherung der Annotationsdaten soll sich das System vom CommonSense Toolkit abheben, welches die Annotation nur für den Live-Betrieb vorsieht. Dies ist zwingend erforderlich, zum einen um das Auswertungssy­stem anhand der Rohdaten und dieses Expertenwissens einlernen zu können, zum anderen um das System auf die Qualität der Erkennung hin untersuchen zu können. Da Systeme, bei denen die Benutzer selbst in der Lage sind, die Annotation ihrer Daten zu übernehmen, po­tenziell deutliche bessere Ergebnisse liefern können als solche, bei denen Aufsichtsper­sonen die Annotation durchführen müssen [08], soll das neue Annotationssystem so be­schaffen sein, dass es dem Benutzer ohne besonderen Aufwand selbst ermöglicht, die An­notation seiner aktuellen Aktivitäten durchzuführen. Da die Erkennungsraten in der spä­teren Praxisanwendung besser sind, wenn das System schon im Alltag eingelernt wurde, und nicht unter Laborbedingungen [08], soll das System außerdem so beschaffen sein, dass eine Annotation im Alltag möglich ist.

Zusammengefasst soll das neu zu erstellende System einen einheitlichen Entwicklungspro­zess für das Schließen von Kontexten in Ubiquitous Computing Applikationen bieten, es soll dazu Sensordaten aufzeichnen und später wieder abspielen können, eine Eingabemög­lichkeit für Expertenwissen bieten, welches für spätere Wiederholungen der Daten wieder­holbar abgespeichert werden soll und verschiedenartige Ubiquitous Computing Anwen­dungen einsetzbar sein.

3. Entwurf

Nachdem im vorangegangenen Kapitel eine Analyse durchgeführt wurde, in welcher der Bedarf an einem System festgestellt wurde, welches genutzt werden kann, um aus vorlie­genden Sensordaten automatisch einen Anwendungskontext zu schließen, soll ein derar­tiges System nun entworfen werden.

3.1. Entwurf eines Prozesses

Im vorangegangenen Kapitel wurde die Anforderung aufgestellt, dass sich das neu zu ent­wickelnde System für eine Vielzahl von Anwendungsfällen einsetzen lassen soll. Dies setzt einen entsprechenden Abstraktionsgrad im Entwurf des Prozesses voraus. Für das kontex­terkennende System wird daher die in Abbildung 3.1 skizzierte eine Schrittfolge festgelegt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3.1: Entwurf des Prozesses

Im ersten Schritt, dem Sammeln von Daten, muss eine gewisse Anzahl von Daten einge­sammelt werden, anhand derer später der Klassifikator, der für die eigentliche Erkennung der Kontexte zuständig sein wird, eingelernt werden kann. Im zweiten Schritt werden die eingesammelten Sensordaten mit Expertenwissen annotiert.

Auf Basis der anfangs eingesammelten Daten sowie der Annotationen wird im folgenden Schritt der Klassifikator für die Kontexterkennung eingelernt und auf seine Leistungsfähig­keit überprüft. Sobald das System zufriedenstellende Erkennungsraten liefert, kann das Sy­stem ausgebracht und benutzt werden. Auch dann soll es jedoch noch möglich sein, einen Schritt zurück zu gehen und das System mit zusätzlichen Daten weiter zu trainieren, um die Erkennungsrate zu verbessern.

3.2. Entwicklungsmodell

Der Prozess soll so ausgelegt sein, dass sich die Einlernphase mit den gleichen, im Spei­cher gehaltenen Daten, beliebig oft wiederholen lässt, um den Klassifikator zwischenzeit­lich auszutauschen oder zu modifizieren und die mit den unterschiedlichen Klassifikatoren erzielten Ergebnisse zu vergleichen bzw. durch mehrmaliges verändern und verfeinern des Klassifikators nach und nach bessere Ergebnisse zu erreichen.

Der Prozess soll sich daher an dem in der Softwaretechnik verbreiteten Wasserfall-Modell (vgl. [17]) orientieren. Konkret soll der Prozess es ermöglichen, zwischen der Analyse der vorliegenden Situation und der Nutzung des Systems beliebig oft auf eine vorhergehende Prozessstufe zurück zu gehen. Diese Rücksprünge sollen vor allem dazu dienen, den Klas­sifikator durch mehrmaliges verändern und einlernen stetig zu verbessern, bis die ge­wünschte Qualität in der Erkennung erreicht wird.

[...]