Systemunterstützung für kontextbezogene Anwendungen

Zusammenfassung der Arbeit

System Support For Context-Aware Computing

Habilitationsschrift zur Erlangung der Venia Legendi in Informatik Angenommen von der Fakultät Informatik, Elektrotechnik und Informationstechnik Universität Stuttgart

vorgelegt von Dr. phil. nat. Christian Robert Becker aus Hanau

Institut für Parallele und Verteilte Systeme Abteilung Verteilte Systeme Universität Stuttgart

November 2004

Einleitung Die fortschreitende technologische Entwicklung im Bereich der Sensortechnologie, der Miniaturisierung von eingebetteten Systemen und deren Integration mit Sensorik und Kommunikationsfähigkeit erlauben das Erfassen von Zuständen der physischen Welt und deren Kommunikation. Der Einbezug solcher Informationen in Softwaresysteme führt zu kontextbezogenen Systemen, die ihre Ausführung auf Basis von Kontextinformationen adaptieren können. Beispiele solcher Anwendungen sind: * Navigationswendungen: auf Basis von dynamischen Informationen, wie Verkehrsinformationen, können bereits heutige Navigationssysteme dynamische Anpassung von Routen vornehmen. Weitere Parameter, durch die Navigationsanwendungen ihr Verhalten in Bezug auf den Anwender verändern können, sind Präferenzen – beispielsweise für die Auswahl eines Restaurants – die Aktivität eines Anwenders, um maßgeschneiderte Benutzerschnittstellen für Fußgänger, Benutzer öffentlicher Verkehrsmittel oder Autofahrer anzubieten. Darüber hinaus können spezialisierte Navigationssysteme, wie Touristenführer oder die Unterstützung sehbehinderter Menschen, von aktuellen Informationen der physischen Welt profitieren. * Instrumentierte Räume: diese Klasse von kontextbezogenen Anwendungen bietet durch die Integration von eingebetteten Systemen und entsprechender Sensorik Unterstützung für maßgeschneiderte Anwendungen. Ein Produktionsplanungssystem in einer Fabrik kann beispielsweise die Position und den Wartungszustand von Werkzeugen erfassen und somit sicherstellen, dass immer die benötigten Werkzeuge für den Produktionsplanungsprozess vorgehalten werden. Weitere Beispiele in dieser Klasse finden sich im Bereich so genannter „Smart Environments“, in der Räume auf bestimmte Anwendungsklassen ausgerichtet werden. Beispiele sind die Unterstützung von Besprechungen und Lehrveranstaltungen bei denen Anwendungen auf installierte Geräte, wie Projektoren, Besprechungstische mit Anzeige, und dynamisch in solche Umgebungen eingebrachte Geräte, wie mobile Engeräte von Anwendern, beispielsweise Notebooks, verteilt werden. Dabei werden die Dienste und Informationen, die sich aus der dynamischen Konstellation der installierten und eingebrachten Geräte ergeben, für die Ausführung von Anwendungen einbezogen. * Annotationen: im Gegensatz zu den vorangegangenen Beispielen, bei denen Anwendungen auf die Änderungen der physischen Welt, beispielsweise durch Verkehrsinformationen oder die Änderung in der Ausführungsumgebung, reagieren, kann auch Information mit Objekten der physischen Welt verknüpft werden (d.h. diese Objekte werden annotiert) und Anwender können so mit Informationen bedient werden. Beispiele sind hier ortsbezogene Dienste, bei denen Gebäude oder andere Orte mit zusätzlichen Informationen verknüpft werden, die Anwender abrufen können. Aus den oben genannten Beispielen ist ersichtlich, dass sich diese Anwendungen von herkömmlichen Anwendungen dadurch unterscheiden, dass sie ihre Ausführung in Abhängigkeit der physischen Welt verändern. Dies drückt sich in den folgenden beiden Definitionen aus:

Definition Kontext Kontext ist die Information, die zur Charakterisierung der Situation einer Entität herangezogen werden kann. Entitäten sind Personen, Orte oder Objekte, welche für das Verhalten von Anwendungen als relevant erachtet werden. Dabei wird eine Entität selbst als Teil ihres Kontexts betrachtet.

Definition kontextbezogene Anwendungen Eine Anwendung ist kontextbezogen, wenn ihr Verhalten durch Kontextinformationen beeinflusst wird.

Dabei können vier Klassen von kontextbezogenen Anwendungen unterschieden werden: * Kontextbezogene Selektion: die Auswahl von Diensten oder Informationen geschieht in Abhängigkeit des Kontexts, beispielsweise die Selektion des nächsten Druckers bezogen auf einen Anwender. * Kontextbezogene Präsentation: die Darstellung einer Anwendung ändert sich abhängig vom Kontext, beispielsweise kann bei einer lauten Umgebung eine Audioausgabe auf eine graphische Benutzeroberfläche umschalten. * Kontextbezogene Aktion: in Abhängigkeit von Kontextinformationen, wie dem Betreten eines Raums durch einen Benutzer, wird eine Aktion, etwa das Einschalten des Lichts, ausgelöst. * Annotation von Kontext: diese Klasse von Anwendungen erlaubt die Verknüpfung von Informationen mit Kontext, wie Orten oder Gebäuden, und den späteren Zugriff auf diese Informationen über den Kontext. Klassifikation der Systemunterstützung für kontextbezogene Systeme Die Klassifikation von Systemunterstützung kontextbezogener Systeme soll anhand von zwei Dimensionen geschehen. Die erste Dimension kennzeichnet das zugrunde liegende Systemmodell. Dabei sind die möglichen Ausprägungen Infrastruktur oder ad hoc Systemmodelle. Anwendungen in Infrastrukturbasierten Systemmodellen sind dadurch gekennzeichnet, dass sie Zugriff auf Dienste und Informationen in der Infrastruktur haben bzw. Vorkehrungen, wie das Vorabladen von Daten, existieren, um Verbindungsabbrüche zur Infrastruktur abzufedern. Im Gegensatz dazu sind ad hoc Systemmodelle dadurch gekennzeichnet, dass sie durch die spontane Vernetzung mobiler Endgeräte durch drahtlose Kommunikation gebildet werden. Häufige Partitionierungen des Netzwerkes und damit einhergehende wechselnde Sichten auf die Informationen und Dienste, die einer Anwendung zur Verfügung stehen, sind Eigenschaften dieses Systemmodells. Die zweite Dimension betrachtet die Unterstützung von Anwendungsadaptation. Dabei kann hier unter Adaptation durch das System und Adaption durch die Anwendung unterschieden werden.

Abbildung 1: Anpassung durch das System

Bei Adaption durch das System wird eine Anwendung in Form von nicht-adaptiven Blöcken spezifiziert und das System konfiguriert die Anwendung bei einem Kontextwechsel entsprechend um (Abbildung 1). Im Gegensatz dazu, trifft bei Adaption durch die Anwendung das Systems keine Entscheidung bezüglich der Anwendungsadaption. Anwendungen greifen auf den Kontext typischerweise über einen Dienst zu, der ein Kontextmodell verwaltet, und treffen ihre Adaptationsentscheidungen (Abbildung 2) ohne Systemunterstützung, was mit einem entsprechenden Mehraufwand bei der Konzeption und Programmierung der Anwendungen verbunden ist.

Abbildung 2: Anpassung durch die Anwendung Zusammenfassung der Beiträge Die Beiträge der vorliegenden Arbeit sollen im Folgenden den Klassen der Systemunterstützung kontextbezogener System zugeordnet und diskutiert werden. Die Einordnung geschieht hier entlang der Dimension der Systemunterstützung für die Anwendungsadaptation. Adaption durch die Anwendung In dieser Klasse von Systemunterstützung finden sich Dienste, die Kontextinformationen verwalten und Anwendungen durch geeignete Schnittstellen verfügbar machen. Die Ortsbezogenheit von Kontextinformationen macht eine Organisation von Kontextinformationen in Bezug auf ihre räumliche Struktur notwendig. Kapitel 3 der vorliegenden Arbeit diskutiert zunächst Eigenschaften von Koordinaten, wie sie von Positionierungssystemen unterstützt werden. Aufgrund einer Analyse von kontextbezogenen Anwendungen werden Anfragen nach Position, dem nächsten Nachbar und Objekten in einem Gebiet motiviert. Der Hauptbeitrag dieses Kapitels liegt in der Klassifikation möglicher Lokationsmodelle für symbolische Koordinaten und eine Bewertung dieser Modelle in Hinblick auf ihre Eignung für die o.g. Anfragen sowie des damit einhergehenden Modellierungsaufwands. Symbolische Koordinaten zeichnen sich dadurch aus, dass sie – im Gegensatz zu geometrischen Koordinaten - keine räumlichen Bezüge zwischen einzelnen Koordinaten, wie eine Distanz, besitzen. Lokationsmodelle bilden räumliche Beziehungen zwischen symbolische Koordinaten ab und erlauben somit die Bearbeitung von räumlichen Anfragen. Der Beitrag dieses Kapitels kommt sowohl infrastrukturbasierten wie auch ad hoc Systemen zu Gute. Kapitel 4 und 5 widmen sich der Kontextverwaltung in ad hoc Systemen. In Kapitel 4 wird die Usenet-on-the-Fly Anwendung als ein Beispiel für eine kontextbezogene Anwendung in ad hoc Systemen vorgestellt. Diese Anwendung erlaubt es Benutzern, ähnlich wie die Usenet-Anwendung im Internet, bestimmte Informationskanäle zu abonnieren, Nachrichten zu lesen und zu schreiben. Die Verteilung der Nachrichten zwischen den mobilen Endgeräten in dem ad hoc Netzwerk geschieht über ein dreiphasiges Protokoll, in dem zunächst nur Informationen über eine Kennung von einem Knoten seinen Nachbarknoten angeboten werden. Nach einer Nachfrage, werden diese Daten dann übermittelt. Dies erlaubt die Verteilung von Informationen in einem ad hoc Netzwerk, das sich durch häufige Topologieänderungen auszeichnet. Eine Analyse des Protokolls durch Simulationen zeigt die Tragfähigkeit des Ansatzes. Kapitel 5 beschreibt eine Modifikation dieses Protokolls, um den Nachrichtenaustausch in ad hoc Netzwerken mit häufigerer Netzwerk-partitionierung zu unterstützen. Die Zustellung von Informationen über Partitionsgrenzen hinweg bedeutet, dass Knoten diese Informationen lokal vorhalten und wiederkehrend anbieten. Bei einer größeren Menge an Informationen bedeutet dies aber, dass die Größe der Anbieternachrichten steigt. Um diesem Problem zu begegnen wurde eine Dreiteilung der Anbieternachrichten in Klassen eingeführt. Die erste Klasse enthält Nachrichten bis zu einem gewissen Alter, das durch einen Schwellwert bestimmt ist. Diese Nachrichten werden immer angeboten, da diese als aktuell und somit für andere Knoten interessant erachtet werden. Der verbleibende Platz in der Anbieternachricht wird für das Anbieten älterer Nachrichten verwendet. Die zweite Klasse beinhaltet ältere Nachrichten, die aber von Knoten häufiger nachgefragt werden und somit eine hohe Popularität besitzen. In der letzten Klasse werden – nach unterschiedlichen Strategien, wie Round-Robin oder Zufall - ältere Nachrichten angeboten, um sicherzustellen, dass auch diese Partitionsgrenzen überwinden können. Wird eine Nachricht der letzten Klasse nachgefragt, steigt deren Popularität und diese wechselt in die zweite Klasse über. Die Leistungsfähigkeit des Protokolls wurde wiederum durch Simulationsergebnisse gezeigt. Die Unterstützung durch Kontextinformationen für Anwendungen, damit diese ihre Adaptionsentscheidung treffen können, setzt voraus, dass Kontextinformationen in einem Dienst geeignet verwaltet und zugreifbar gemacht werden. Die unterschiedlichen Ansätze solche Dienste zu realisieren und die Kontextinformationen zu strukturieren bedeuten allerdings, dass Anwendungen hinsichtlich der verwendeten Kontextinformationen auf kompatible Dienstanbieter beschränkt werden. Daher ist es wünschenswert, dass Zusammenschlüsse von unterschiedlichen Kontextanbietern in eine einheitliche Struktur geschaffen werden, die Anwendungen einen einheitlichen Zugriff und eine einheitliche Modellierung bieten. In Kapitel 6 wird über die Erfahrungen einer Integration zweier Kontextmodelle, die als infrastrukturbasierte Dienste realisiert sind, berichtet. Ausgehend von zwei Kontextdienste, der Nexus-Plattform der Universität Stuttgart, und einem Kontextdienst für das „Aware Home“ Projekt am Georgia Institute for Technology werden die konzeptionellen Schritte für die Integration und die resultierende Implementierung beschrieben. Der Aware Home Spatial Server (AHSS) des Aware Home Projekts wurde aufgrund einer Analyse der Bedürfnisse von Anwendungen in diesem Projekt hin entworfen. Bedingt durch die organisatorische Struktur des Projekts wurde die Festlegung einer einheitlichen Semantik der im AHSS verwalteten Kontextinformationen verworfen. Die Abstimmung der Entwickler erfolgt im Wesentlichen durch engen, persönlichen Kontakt. Die Struktur der Kontextinformationen wurde auf Basis eines baumbasierten Lokationsmodells vorgenommen, das für die Unterstützung von Nachbarschaftsanfragen weitere Beziehungen zwischen Lokationen erlaubt. Die Speicherung erfolgte in einer Datenbank mit Erweiterung für räumliche Zugriffe und Anwendungen wurde eine Schnittstelle über CORBA und das zugrunde liegende Internet Inter ORB Protokoll (IIOP) angeboten. Im Gegensatz dazu hat das Nexus-Projekt eine offene Plattform als Ziel, bei dem Kontextanbieter ihre Informationen frei integrieren können. Eine Föderation bietet Klienten eine einheitliche Sicht auf die in der Plattform verwalteten Kontextdienste. Die Integration beliebiger Kontextdienste erfolgt auf Basis einer einheitlichen Modellierung von Kontextinformation durch ein erweiterbares Klassenschema, das die Spezialisierung von einer großen Anzahl von Basisklassen erlaubt. Eine XML-basierte Anfragesprache dient zur Integration der Kontextdienste in die Föderation wie auch zur Anfragebearbeitung von Klientenanfragen. Die Integration des AHSS in die Nexus-Plattform erforderte die Einbettung der Kontextinformationen in das von der Nexus-Plattform vorgegebene Klassenschema und die Umsetzung der Nexus-Anfragesprache auf die Anfragebearbeitung des AHSS. Die Erfahrungen, die aus dieser Einbettung gewonnen wurden, sind positiv. Während Anwendungen im Aware Home weiterhin die Kontextinformationen über den AHSS nutzen können, sind diese über die Einbettungen für die Nexus-Anwendungen verfügbar. Die Einbettung in das Nexus-Klassenschema hat keine Änderung dieses Schemas erfordert, was als Bestätigung der gewählten Klassenstruktur zu werten ist. Weiterhin ist durch die Einbettungen es nun auch Nexus-Anwendungen möglich auf die im AHSS gespeicherten Kontextinformationen zuzugreifen. Die systematische Untersuchung der Integration von Kontextinformationen und der Einbettung von Kontextdiensten, wie dem AHSS, in die Nexus-Plattform hat eine über diese beiden Projekte hinausgehende Bedeutung, da sie eine Untersuchung der Aufgaben und Probleme der Dienst- und Informationsintegration im Bereich der kontextbezogenen System darstellt und somit dem gesamten Bereich zu Gute kommt. Adaption durch das System Bislang wurde die Klasse von Systemunterstützung für kontextbezogenen Anwendungen betrachtet, die auf Basis von Kontextinformationen ihr Verhalten adaptieren. Kapitel 7 bis 10 der vorliegenden Arbeit widmen sich der Klasse der vom Systemunterstützung für vom System adaptierten kontextbezogenen Anwendungen. Der Schwerpunkt liegt hierbei auf der Unterstützung von Anwendungen basierend auf ad hoc Netzen. Solche Systeme finden sich im Bereich des Peer-to-Peer Pervasive Computing, bei dem Anwendungen auf Funktionalität, die in dem ad hoc Netz verfügbar ist, zurückgreifen können. Die Relevanz der Informationen und Dienste in einem ad hoc Netz wird durch die Nähe bestimmt, was letztlich dazu führt, dass nur Dienste und Information mit wenigen Zwischenknoten Entfernung in Betracht gezogen werden. Durch die Charakteristika des zugrunde liegenden ad hoc Netzes fluktuieren die einer Anwendung zur Verfügung stehenden Dienste und Informationen. Um dieser Dynamik zu begegnen ist die Unterstützung von Anwendungsprogrammierern durch geeignete Systemsoftware notwendig.

Abbildung 3: Systemunterstützung in Peer-to-Peer Pervasive Computing

In Kapitel 7 werden die Anforderungen an Systemunterstützung in dem Gebiet des Peer-to-Peer Pervasive Computing abgeleitet. Im wesentlichen zerfallen die Anforderungen in einen anwendungsunabhängigen Bereich, der für die Etablierung eines spontan vernetzten Funktionsverbunds in dem ad hoc Netzwerk zuständig ist, und einem anwendungsabhängigen Bereich, der die Unterstützung der Adaption von Anwendungen durch das System beinhaltet. Abbildung 3 zeigt die in Kapitel 8 und 9 beschriebene Systemunterstützung dieser beiden Bereiche. Die Verteilungsinfrastruktur „BASE“, die in Kapitel 8 beschrieben wird, erlaubt die automatische Etablierung spontaner Funktionsverbünde durch geeignete Dienstfindungsmechanismen und die flexible Nutzung von Transport- und Interoperabilitätsprotokollen. BASE beruht auf einem Mikrokern-Entwurf und kann so selbst auf ressourcenarmen Geräten zur Ausführung gebracht werden. Die Nutzung von Ressourcen auf größeren Geräten wird durch die Erweiterbarkeit des Mikrokerns sichergestellt. Im Gegensatz zu bereits existierenden Verteilungsinfrastrukturen erlaubt BASE die Trennung der Kommunikationsmodelle von Anwendung und Interoperabilitätsschicht. Dies erlaubt BASE, die Interoperabilitätsprotokolle während der Interaktion mit entfernten Diensten zu wechseln und somit für die Anwendung transparent die Kommunikation zu adaptieren. Ein Beispiel, wo dieses zum Einsatz kommt ist ein Verbindungsabbruch beim Aussenden eines Dienstauftrages über eine Infrarotschnittstelle. Steht allerdings noch eine Verbindung, beispielsweise über eine Funkverbindung zur Verfügung, wird diese von BASE für die Zustellung des Ergebnisses benutzt. BASE stellt keine Anforderungen an die Struktur von Anwendungen und bietet nur eine einfache Signalisierungsschnittstelle an, bei denen Anwendungen die Verfügbarkeit und Unverfügbarkeit von Ressourcen signalisiert bekommen. Das in Kapitel 9 vorgestellte Komponentensystem PCOM basiert auf einem kontraktbasierten Anwendungsmodell. Kontrakte dienen zu vollständigen Beschreibung der Abhängigkeiten von Komponenten an andere Komponenten aber auch an die zugrunde liegende Ausführungsumgebung, beispielsweise Speicher oder CPU Bedarf. Anwendungen werden als Bäume beschrieben, deren Knoten Komponenten sind, die den Baum durch ihre Abhängigkeiten aufspannen. Aufgrund dieser Informationen kann das Laufzeitsystem eine Anwendung starten (was einem Sonderfall der Adaption gleichkommt) oder adaptieren, sollten Komponenten vorliegen, die einen Kontrakt besser erfüllen, oder aber genutzte Komponenten unverfügbar werden. Das Laufzeitsystem von PCOM basiert auf BASE und kann somit andere Laufzeitsysteme in dem spontanen Funktionsverbund auffinden und die lokal verfügbaren Komponenten austauschen. Komponenten in PCOM müssen nicht adaptiv in Bezug auf Kontextinformationen sein. PCOM fällt in die Klasse der Systemunterstützung für vom System adaptierten Anwendungen. Kapitel 10 berichtet von den Erfahrungen, die bei der Portierung von BASE auf ein eingebettetes System und die Nutzung von BASE als Basis von PCOM entstanden sind.