• Keine Ergebnisse gefunden

3. Kontextverarbeitung und Adaption 51

3.3. Kontextadaption

Eingabewerten Muster zu erkennen und hieraus beispielsweise Klassen-zugehörigkeiten abzuleiten. Das so entstandene Modell kann die erlern-ten Muster dann auf neue, zuvor unbekannte Eingabewerte anwenden.

Regelsysteme Regelsysteme bilden die einfachste Art des Schließens ab, in-dem sie sich auf If-then-else-Konstrukte beschränken. Nach [LD10] stel-len sie zudem die populärste Gruppe von Verfahren dar. Regelbasierte Systeme werden dabei oft im Zusammenhang mit ontologischem Schlie-ßen verwendet.

Fuzzylogik Fuzzylogik oder unscharfe Logik erlaubt näherungsweise Aussa-gen und dient der Modellierung von Unsicherheit, um Zustände um-gangssprachlich zu beschreiben, und ähnelt dem probabilistischen Schlie-ßen. Die Konfidenz drückt in diesem Fall den Grad der Zugehörigkeit zu einer Gruppe aus. Fuzzylogik wird seit längerer Zeit in Kombination mit anderen Verfahren verwendet, um Unsicherheit zu modellieren und so am Beispiel der Temperatur die Zustände „kalt“, „relativ warm“ und

„sehr warm“ anstatt einer konkreten Temperaturangabe in Grad Celsius abzubilden.

Ontologisches Schließen Ontologiebasierte Systeme basieren auf der Be-schreibung von Zusammenhängen in einer Wissensbasis, wie sie im Zu-sammenhang mit der ontologiebasierten Modellierung erwähnt wurden.

Ontologisches Schließen bietet sich entsprechend vor allem in Zusam-menhang mit ontologischer Modellierung von Kontextinformationen an.

Probabilistisches Reasoning Bei diesen Verfahren werden Schlüsse und Ent-scheidungen auf Basis von Wahrscheinlichkeiten getroffen, die den ein-zelnen Fakten zugehörig sind. Ein prominentes Beispiel sind versteckte Markov-Ketten, bei denen das Ereignis, auf das es zu schließen gilt, un-bekannt ist und nur mithilfe von Beobachtungen und anhand von Wahr-scheinlichkeiten Schlüsse abgeleitet werden. Sie kommen insbesondere bei der Aktivitätserkennung (activity recognition) zum Einsatz [SBI+15].

Distribution Die Distribution von Kontextdaten stellt den letzten Schritt in-nerhalb des Verarbeitungsprozesses von Kontextdaten dar. Die Kontextbereit-stellung wird in diesem Schritt oft von Konsumenten oder Empfänger der Kon-textdaten aus initiiert. Entsprechend stellt er das Gegenstück zur Kontextak-quisition dar (vergleiche Abschnitt 3.2.1) und bietet dieselben Kommunikati-onsstile an (pull und push).

we-3.3. Kontextadaption 67

niger auf die Wahrnehmung und stärker auf den Anpassungsprozess und das Ziel kontextadaptiven Verhaltens bezieht:

„Adaptation in ubiquitous computing is understood as the reactive pro-cess triggered by a specific event or a set of events in the context, with an ultimate goal to improve the QoS [Quality of Service] perceived by the end-user.“ [KPP10]

Kontextadaption oder kontextadaptives Verhalten beschreibt nach [KPP10]

den Prozess und die Fähigkeit eines Systems, sich an seinen Kontext anzupas-sen, mit dem Ziel die Dienstqualität für den Endanwender zu erhöhen. Zur Realisierung einer einfachen Kontextadaption wie der Anpassung der Bild-schirmhelligkeit an die Lichtverhältnisse der Umgebung reicht es entspre-chend eine Teilmenge der im Prozess der Kontextverarbeitung beschriebenen Schritte zu durchlaufen. Es existieren jedoch auch weitaus komplexere Adap-tionsszenarien, die weitergehende Konzepte erfordern:

Eine der wesentlichen Basistechnologien zur Realisierung solch eines kom-plexen adaptiven Verhaltens ist laut [KPP10] dasAutonomic Computing. Die-ser im Jahre 2003 von der Firma IBM erstmalig verwendete Begriff beschreibt ein Paradigma, das sich nach[KC03] aus vier Prinzipien zusammensetzt, die auch als Self-CHOP oder abweichend als Self-Management-Eigenschaften be-zeichnet werden und wie folgt beschrieben werden:

Selbstkonfiguration (self configuration): Die Fähigkeit eines Systems, sich eigenständig zu konfigurieren. Wird beispielsweise eine neue Kom-ponente in ein Gesamtsystem eingebracht, so registriert sich diese zu-sammen mit ihren Fähigkeiten, sodass andere Teile des Gesamtsystems diese Komponente benutzen oder ihr eigenes Verhalten auf das Vorhan-densein dieser neuen Komponente abstimmen.

Selbstverbesserung (self-optimization): Die Fähigkeit eines Systems, sich selbst zu optimieren. Selbstverbessernde Systeme versuchen proaktiv ih-re Funktionsweise als Gesamtsystem zu optimieih-ren, um beispielsweise die Performance des Gesamtsystems zu erhöhen.

Selbstheilung (self-healing): Die Fähigkeit eines Systems, Fehler zu er-kennen, die Ursache zu diagnostizieren und entsprechende kompensie-rende Maßnahmen zur Fehlerbehandlung zu ergreifen. In diesem Zu-sammenhang kann ein selbstheilendes System Fehler in der Hardware oder Software mithilfe einer Diagnose-Komponente erkennen und ent-sprechende kompensierende Strategien auslösen, beispielsweise das Ein-spielen eines Updates, welches den Fehler behebt.

Selbstschutz (self-protection): Die Fähigkeit eines Systems, sich vor An-griffen zu schützen und sich selbst proaktiv gegen zukünftige Angriffe durch Anpassung vorzubereiten.

Die vorgenannten Fähigkeiten erlauben so eine Form der Selbstorganisation, die sich nicht nur auf ein Teilsystem, sondern auf das Gesamtsystem bezieht

[KC03]. Diese Selbstorganisation läuft nach [KC03] in Form eines Regelkreises ab, der die Schritte des Monitorings, der Analyse, der Planung und der Aus-führung (execute) einer Anpassung mithilfe einer Wissensbasis realisiert und der entsprechend als MAPE-K-Schleife (loop) bezeichnet wird. In [KPP10] wird dieser Regelkreis auf die Problemstellung des kontextabhängigen Adaptions-bedarfes mobiler Geräte übertragen und als Regelkreis der Adaption im Ubi-quitous Computing beschrieben, der in Abbildung 3.4 veranschaulicht wird.

Context sensing and processing

Pass adaptation decisions to

Adaptation Mechanisms

Adaptation Reasoning Adaptation

Acting

light noise ...

Abbildung 3.4.:Regelkreis der Adaption nach [KPP10]

Eine Adaption besteht laut Kakousis et al. in diesem Regelkreis aus drei wesentlichen Schritten:

Der Wahrnehmung und Verarbeitung von Kontextdaten, wie sie bereits in den vorhergehenden Abschnitten dieses Kapitels beschrieben wurde.

In dieser Phase beobachtet ein System seinen Kontext und verarbeitet diese Daten hin zu höherwertigen Informationen.

Der Erkennung eines Adaptionsbedarfes: In dieser Phase entscheidet ein selbstadaptives System auf Basis der Kontextinformationen über einen Anpassungsbedarf, der häufig in Form von Aktionen (action based) oder Adaptionszielen (goal based) beschrieben wird [VB14,HSMK09] und eine Adaptionsentscheidung zum Ergebnis hat.

Die Durchführung der Adaption: In dieser Phase nutzt ein selbstadapti-ves System einen Adaptionsmechanismus, um die zuvor getroffene Adap-tionsentscheidung umzusetzen.

Entsprechend sollen in den folgenden Abschnitten die Erkennung eines Ad-aptionsbedarfes und die Durchführung der Adaption näher beschrieben wer-den. Hierzu werden die Gründe beschrieben, warum sich ein System an sei-nen Kontext anpasst und welche verschiedesei-nen Formen der Adaption hierfür üblicherweise Anwendung finden. Abschließend wird ein kurzer Überblick zu adaptiven Architekturen gegeben.

3.3. Kontextadaption 69

3.3.1. Adaptionsgründe

Die Gründe dafür, dass sich ein System oder eine Anwendung adaptiv verhält, um sich an seine Umgebung und seinen Nutzungskontext anzupassen, sind vielfältig. Dementsprechend existieren verschiedene Verfahren zur Erkennung eines Adaptionsgrundes und der Planung eines daraus resultierenden Adapti-onsbedarfes. In [KPP10] werden hierzu die folgenden vier Kategorien unter-schieden:

Aktionsbasierte Anpassung (action-based adaptation) Die aktionsbasierte oder regelbasierte Anpassung stellt nach [KPP10] die prominenteste Ka-tegorie von Verfahren dar, wenn es um die Definition von Verhaltensmu-stern innerhalb kontextadaptiver Systeme geht. Hier werden Anpassun-gen eines Systems durch Zustände (states) undAktionen (actions) defi-niert. Ein System in einem ZustandSund die Erfüllung einer Bedingung plöst eine Aktion aus, die das System in einen neuen ZustandS‘ über-führt. Die Realisierung dieses Verhaltens lässt sich nach [KD07] durch eine Menge von Regeln in der FormIF(Condition) – Then(Action) definie-ren, die bestimmen, wie sich das System in einem bestimmten Zustand und damit in einer bestimmten, durch seinen Kontext definierten Situa-tion verhält.

Regelbasierte Systeme stellen damit prinzipiell ein intuitives und ein-faches Instrument zur Realisierung von kontextadaptivem Verhalten dar [KPP10]. Zusätzlich ist ihre Auswertung oft auch auf ressourcenbe-schränkten mobilen Geräten möglich, da lediglich die Erfüllung der die Aktion auslösenden Bedingung p geprüft werden muss. Die Einfachheit dieses Instruments schränkt jedoch in gleichem Maße ihre Nutzbarkeit innerhalb mobiler Umgebungen ein. Einerseits, da sich der beobachtete Kontext oft ändert, und andererseits, da es für den Entwickler oft schwie-rig ist alle möglichen Kontextzustände vorherzusehen und entsprechende Regeln zu entwickeln, die diesen Zustand abdecken und eine gewünschte Adaption ermöglichen [WC13].

Zielbasierte Anpassung (goal-based adaptation) Eine weitere Kategorie von Verfahren zur Abbildung von Adaptionsbedarfen bildet die Gruppe der zielbasierten Anpassungen. Anstatt regelbasiert einzelne Kontextzu-stände zu beschreiben, die eine Adaption auslösen, wird in dieser Kate-gorie von Adaptionsverfahren ein gewünschter Ziel-Zustand des Systems beschrieben. Dieser Ansatz verlagert die Komplexität der Zielformulie-rung vom Entwickler in das System, welches hierfür entsprechende Fä-higkeiten zum Planen und logischen Schließen vorhalten muss. Konflik-täre und konkurrierende Ziele erschweren alerdings die Nutzung dieses Ansatzes, weswegen von Kephart und Das in [KD07] Nutzenfunktionen als der logische Evolutionsschritt zur zielbasierten Anpassung gesehen werden.

Nutzenfunktionen (utility functions) Als Erweiterung der zielbasierten Anpas-sung verwenden Nutzenfunktionen Messgrößen zur Bewertung einer Zielerreichung. In diesem Zusammenhang unterstellen sie Kosten der je-weiligen Alternative, um zur Laufzeit zwischen alternativen Adaptions-strategien die Strategie mit dem maximalen Nutzen ermitteln zu können.

So können im Gegensatz zur zielbasierten Anpassung unterschiedliche Ziele gleichzeitig vefolgt werden.

Nutzenfunktionen eignen sich dabei insbesondere im Umfeld des Ubiqui-tous Computings, da sie für jeden Kontextzustand eine effiziente Bewer-tung des Nutzens einer jeweiligen Adaptionsstrategie vornehmen können [GBE+09].

Wissensbasierte Anpassung (adaptation reasoning by experience) Neben den bisher vorgestellten drei Kategorien von Verfahren, die allesamt auf (durch den Entwickler) vordefinierten Verhaltensmustern basieren, existiert eine weitere Kategorie, die keinerlei Form der Beschreibung von Adaptionsgründen oder Adaptionszielen bedarf.

Bei der wissensbasierten Anpassung werden die zur Laufzeit gesammel-ten Kontextinformationen verwendet, um einen Anpassungsbedarf und eine passende Aktion zur Erfüllung des Anpassungsbedarfs zu ermitteln.

Der Vorteil dieses Ansatzes liegt laut [KPP10] darin, dass das adapti-ve Verhalten der Anwendung nicht wie bei den anderen Verfahren zur Entwurfszeit der Anwendung festgelegt wird, sondern sich individuell auf den Kontext des jeweiligen Gerätes oder seiner Nutzer bezieht. Solch ein wissensbasiertes System lernt die Qualität seiner bisherigen Adapti-onsentscheidungen und leitet daraus neue AdaptiAdapti-onsentscheidungen ab, die den Nutzen einer mobilen Anwendung für den Anwender maximieren soll. Die Realisierung solcher Systeme erfolgt oft mithilfe von Verfahren des fallbasierten Schließens (case-based reasoning) oder als verstärken-des Lernen (reinforcement learning realisiert), einer Form verstärken-des maschi-nellen Lernens. Die richtige Art Verstärkung kann beispielsweise aus vergangenen, erfolgreichen Adaptionsentscheidungen abgeleitet werden.

Hierzu gilt es allerdings den Erfolg einer solchen Adaptionsentscheidung anhand der Erfüllung oder Nichterfüllung bestimmter Kriterien zu defi-nieren. Beide Verfahren basieren auf der Annahme, dass ähnlichen Pro-blemen durch ähnliche Lösungen begegnet werden kann. Hierzu nutzt ein entsprechendes System bestehendes Wissen über Kontextzustände und vergangene Adaptionsentscheidungen, um hieraus die passende Ad-aptionsentscheidung für einen neuen Kontextzustand abzuleiten.

Obwohl diese Verfahren mitunter suboptimale Adaptionsentscheidung lie-fern und stets eine ausreichend große Historie vergangener Kontextzustände und Adaptionsentscheidungen benötigen, haben sie einen entscheidenden Vor-teil. Der Entwickler einer mobilen Anwendungen kann kaum alle zukünftigen Kontextzustände, denen seine Anwendung ausgesetzt sein wird, vorhersehen

3.3. Kontextadaption 71

[WC13]. Eine wissensbasierte Anpassung kann ihn allerdings von dieser Auf-gabe befreien, sofern sie in der Lage ist die Zusammenhänge zwischen dem Kontextzustand und dem Ergebnis einer vergangenen Adaptionsentscheidung zu erkennen und dieses Wissen erfolgreich auf aktuelle und zukünftige Kon-textzustände überträgt.

3.3.2. Adaptionsformen

Adaption kann auf eine Reihe von verschiedenen Arten, aber auch auf ver-schiedenen Ebenen begriffen und durchgeführt werden, entsprechend werden die in diesem Zusammenhang relevantesten Formen der Adaption im Folgen-den vorgestellt.

In diesem Zusammenhang kann Adaption zunächst danach unterschieden werden, ob sie statisch oder dynamisch stattfindet. Statische Adaption be-schreibt die Anpassung einer Anwendung zur Entwurfszeit [MSKC04]. Das adaptive Verhalten einer solchen Anwendung ist entsprechend auf Anpas-sungen der Softwarearchitektur beschränkt und wird auch als Entwurfszeit-Adaptivität bezeichnet [Gei08]. Dynamische Adaption hingegen verlagert die Anpassung des Verhaltens einer Anwendung in die Laufzeit derselbigen. Sie bietet entsprechend weitaus bessere Möglichkeiten, auf den häufig wechseln-den Kontext mobiler Geräte angemessen reagieren zu können. Diese auch als Laufzeitadaptivität bezeichnete Fähigkeit [Gei08] lässt sich nach [KPP10] wei-tergehend in Reaktivität und Produktivität unterteilen. Reaktivität bezeichnet in diesem Zusammenhang die Fähigkeit eines Systems, sich im Anschluss an eine Veränderung des Kontextzustandes anzupassen. Obwohl sich ein Groß-teil existierender kontextbewusster Systeme bereits dynamisch an seinen Nut-zungskontext anpassen kann, so beschränkt sich die Anpassung jedoch häu-fig noch auf einzelne Kontextattribute, fast ausschließlich reaktiv zu arbeiten [May04,Sig08].

Nur sehr wenige kontextadaptive Anwendungen oder Systeme bieten ent-sprechend eine proaktive Anpassung an ihren (zukünftigen) Nutzungskontext, welche allerdings von Mayrhofer als entscheidendes und wesentliches Krite-rium für den erfolgreichen Einsatz dieser Lösungen angesehen wird [May04].

Beispielsweise liefern in einem Auto die Vorhersage von Aquaplaning und die proaktive Reduktion der Geschwindigkeit einen deutlich höheren Mehrwert für den Nutzer als das reaktive Verhalten eines elektronischen Stabilitätspro-gramms, welches versucht, den bereits außer Kontrolle geratenen Wagen zu stabilisieren.

Neben der vorgenannten zeitlichen Dimension der Anpassung können die dynamischen Adaptionsformen kontextadaptiver Systeme zusätzlich dahinge-hend unterschieden werden, mithilfe welcher softwaretechnischer Prinzipien die Adaption realisiert wird. Hierbei wird zwischen der parametrischen und der kompositionellen Adaption unterschieden.

Parametrische Adaption Parametrische Adaption beschreibt die Anpassung des Kontrollflusses einer Anwendung oder eines Systems. Ein bekanntes Bei-spiel ist die Implementierung der Flusskontrolle innerhalb des Transmission Control Protocol (TCP), in welchen die Größe des Übertragungsfensters an die Last- und Fehlersituation im Netzwerk angepasst wird. In diesem Fall beein-flusst der Zustand der Umgebung, beispielsweise die aktuelle Last im Netz-werk, die internen Parameter einer Anwendung oder eines Systems, in diesem Fall die Größe des Übertragungsfensters.

Parametrische Adaption verändert dabei nicht die Struktur einer Anwen-dung oder eines Systems, sondern verändert lediglich einzelne Stellgrößen, die in Abhängigkeit von externen Zuständen gesetzt werden. Die Adaptionsmög-lichkeiten werden hierbei vom Entwickler zur Entwurfszeit festgelegt [Gei08].

Die fehlende Fähigkeit zur Anpassung der Struktur wird als die wesentliche Einschränkung in Bezug auf den Grad der Adaptionsfähigkeit dieser Adapti-onsform angesehen [MSKC04].

Kompositionelle Adaption Im Gegensatz zur parametrischen Adaption er-laubt es die kompositionelle Adaption durch das Austauschen, Hinzufügen und Entfernen von Teilen der Geschäftslogik einer Anwendung zur Laufzeit, um das Verhalten im Hinblick auf den aktuellen Nutzungs- und Ausführungs-kontext einer Anwendung hin zu optimieren. Hierdurch kann neues Verhal-ten hinzugefügt oder bestehendes VerhalVerhal-ten angepasst werden, wodurch ein weitaus höherer Grad Adaptionsfähigkeit erreicht wird [MSKC04]. Beispiels-weise kann bei einer Anwendung auf einem mobilen Gerät mithilfe der kompo-sitionellen Adaption eine für die Kommunikation verantwortliche Komponen-te zur Laufzeit ausgetauscht werden, sobald sich die zur Verfügung sKomponen-tehenden Netzwerkverbindungen ändern.

Diese hohe Flexibilität erfordert nach [MSKC04] drei wesentliche Basistech-nologien, die im Folgenden jeweils kurz beschrieben werden sollen: einen kom-ponentenbasierten Entwurf (component based design), die Trennung von Ge-schäftslogik und Adaptionslogik (separation of concerns) und die Fähigkeit zur Introspektion (computational reflection).

Komponentenbasierter Entwurf Die kompositionelle Adaption stellt eine Rei-he von Anforderungen an die Softwarearchitektur, die Laufzeitumgebung und den Entwurf einer adaptiven Anwendung [Gei08]. Die grundlegen-de Fähigkeit zur Adaption wird wie zuvor beschrieben erreicht, ingrundlegen-dem einzelne Komponenten zur Laufzeit ausgetauscht werden oder zwischen ihnen umgeschaltet wird und hierdurch das Verhalten einer Anwendung beeinflusst wird, ein Ansatz der ursprünglich von Kramer und Magee in [KM85] vorgeschlagen wurde.

Dies erfordert es einerseits, dass die Funktionalität einer adaptiven Anwendung durch den Entwickler in entsprechende Komponenten

auf-2Je nachdem ob die eigesetzte Ausführungsumgebung dies unterstützt, sind eine oder beide Va-rianten denkbar.