Home

Technische Universität Dresden

1. 50 Architektur aici whe Oe am oe ae Qo a He a 55 Beispiel eines Entscheidungsbaums 76 Gerateontologie are eee ae te ae 81 Ger tef higkeiten Device 81 Ausschnitt aus der Task Ontologie 87 98 Abbildungsverzeichnis 99 Danksagung Hiermit m chte ich mich bei denen bedanken die mir geholfen haben bis hierher zu kom men In guten Zeiten und in schlechten Zeiten 100 Danksagung
2. BA GOR ak Pde Ee We ar Soke Wee ee 3 9 Dienste dds See PE RR ale Bie te a ee ae Se Pe 3 6 Zusammenfassung ack d as pens poke al Be ee din Gale Hence ees Konzeption 4 1 Regeln und Policen 2 2 22 ee eee ee eee AVA ROGEN 2 242 et et REDE ES 41 2 Regeln er 28 Ge er a a 4 1 3 Tasks eeng ateme Wat ale ee eh ae Re ASQ Architektur a ne ae ee ee 42 1 Home Controller 1 8 2 23 ae ee 12 18 18 24 25 27 27 27 28 28 28 29 31 32 35 37 38 41 42 44 45 46 47 4 2 2 Residential Gateway 60 4 2 3 Knowledge Base 60 4 2 4 Device Cooperation Manager 61 4 2 5 Multimodaler Benutzerschnittstellen Manager 62 4 2 6 User Modeling amp User 63 4 927 Policy Interface aioe veld eee Bee ace 64 4 2 8 Policy 64 4 2 9 Policy to Rule Translator 64 4 2 10 Begelschicht u Ysera Se ee a 64 42101 Rule Engine 64 4 2 10 2 Regel Monitor rn peada hak 5 64 4 2 10 3 Regel Konfliktmanager 4 2 10 4 Regel Entdecker 42105 ReasOner wu I er Oe e
3. 1 Ein Ger t stellt eine Schnittstelle zur Anwendung dar beziehungsweise zu den Daten und ist nicht eine Ansammlung von Software 2 Eine Anwendung ist f r den Nutzer das Mittel um eine Aufgabe auszuf hren nicht eine Software die verf gbare Ressourcen verbraucht und dem Selbstzweck dient 3 Die Computing Environment erweitert die Umgebung des Nutzers durch zus tzliche Informationen und soll nicht ein virtueller Raum f r das Speichern und Ausf hren von Software sein Die unbewusste Interaktion mit der Technik zur Konzentration auf die wesentlichen Auf gaben erfordert dass sich die zur Verf gung stehende Technik und die Ger te unauff llig in die Umgebung des Nutzers integrieren und miteinander kooperieren Der Nutzer soll die Anwesenheit eines solchen Systems prim r durch dessen Unterst tzungsleistung wahrneh men Es wird untersucht ob sich das Leben des Nutzers wirklich vereinfacht oder durch die Bedienung unn tige Anforderungen gestellt werden In dieser Arbeit wird der Schwer punkt insbesondere auf die Lebensqualit t und die Wohnsituation lterer Menschen gelegt Sie soll sich durch den Einsatz elektronischer Hilfen signifikant verbessern und ihnen einen Teil ihrer Unabh ngigkeit bewahren Die Motivation f r Smarthomes Smarthomes sind intelligente Wohnumgebungen in denen versucht wird die Ideen des Ubiquitous Computing umzusetzen Durch den Einsatz allgegenw rtiger Technik wird den Menschen das Leben erleichtert
4. POLLERES Axel Hrsg HARMELEN Frank van Hrsg GENESERETH Michael R Hrsg MEDIATE2005 Bd 168 CEUR WS org 2005 online http CEUR WS org Vol 168 MEDIATE2005 paper6 pdf S 81 95 FENSEL Dieter Hrsg LAUSEN Holger Hrsg POLLERES Axel Hrsg BRUIJN Jos D Hrsg STOLLBERG Michael Hrsg ROMAN Dumitru Hrsg DOMINGUE John Hrsg Enabling Semantic Web Services The Web Service Modeling Ontology Heidelberg Springer Verlag 2006 ISBN 3540345191 FRIEDMAN HILL Ernest Java Expert System Shell Jess the Rule Engine for the Java Platform GRUBER Thomas R A translation approach to portable ontology specifications In Knowledge Acquisition 5 1993 Nr 2 S 199 220 ISSN 1042 8143 94 Literaturverzeichnis 11 12 13 14 15 16 17 18 19 20 21 22 23 24 Gu T PuNG H K ZHANG D Q Toward an OSGi based infrastructure for context aware applications In Pervasive Computing IEEE 2004 S 66 74 ISSN 1536 1268 HAMMERSCHALL Ulrike Verteilte Systeme und Anwendungen Architekturkonzepte Standards und Middleware Technologien Pearson Studium 2005 HAND Von D J MANNILA Heikki SMYTH Padhraic Principles of Data Mining The MIT Press August 2001 ISBN 026208290X HORROCKS Ian PATEL SCHNEIDER Peter BOLEY Harold TABET Said GROSOF Benjamin DEAN Mike SWRL A Semantic Web Rule Lan
5. Beide Prototypen wurden von einer Gruppe von Informatik studenten evaluiert und dabei wurde ermittelt dass die Nutzerkontrolle ber das System verhalten zunimmt wenn eigene Regeln definiert werden und so das Systemverhalten zur Laufzeit ver ndert wird Der erste Prototype bei dem die Regeln von Grund auf in der Regelsprache definiert werden ist in der Praxis zu kompliziert Hingegen k nnen beim zweiten Prototypen dieselben Regeln mit erheblich niedrigerem Zeitaufwand weniger Feh lern und weniger Hilfestellung erstellt werden In Anbetracht der Tatsache dass es sich bei den Probanden in diesem Test um Informatikstudenten gehandelt hat die normalerwei se detaillierte Vorkenntnisse im Umgang mit technischen Ger ten besitzen und dennoch Probleme beim Erstellen der Regeln hatten zeigt wie wichtig der Aspekt des Regelerstel lens f r den Einsatz in einem Smarthome f r ltere Menschen ist Der Rule Builder muss eine sehr einfache und intuitive Benutzerschnittstelle haben die es Menschen mit wenigen technischen Vorkenntnissen erm glicht die Smarthome Anwendung an ihre Bed rfnisse anzupassen 4 2 10 9 Regel Inspektor Mit dem Rule Inspektor kann der Nutzer bereits ausgef hrte Regeln inspizieren Der Nutzer kann Regeln nicht nur lesen sondern auch modifizieren l schen aktivieren oder deakti 4 2 ARCHITEKTUR 67 vieren So kann der Nutzer Regeln personalisieren und seinen Bed rfnissen anpassen und bestimmen wie sich das Sy
6. Besonders ltere Menschen und Menschen mit Behin derungen haben die gr ten Vorteile von Smarthomes mit kontextbewusster Technik und Anwendungen F r sie bedeutet der Einsatz dieser Technologien mehr Unabh ngigkeit 21 6 1 EINLEITUNG 1 2 Problemstellung In einem Smart Home werden existierende Ger te dynamisch in ein Gesamtsystem inte griert in dem sie miteinander kooperieren um besonders lteren Menschen ein unabh ngi geres und angenehmeres Leben zu erm glichen Diese Integration erfolgt nahtlos also ohne dass der Nutzer diese Ger te konfigurieren oder Einstellungen ndern muss Die Ger te melden sich dynamisch an und stehen dann mit allen Funktionalit ten zur Verf gung Die zu entwickelnde Middleware soll kontextabh ngig sein den Nutzer seine Umgebung und seine vorhandenen Ger te ber cksichtigen Die Ger te kooperieren selbstst ndig So kann sich der Nutzer auf die Erledigung seiner Aufgaben und Ziele konzentrieren also auf das Was will ich machen und muss nicht dar ber nachdenken Wie muss ich die Ger te bedienen um ein Ziel zu erreichen Es gibt Hardware Standards wie UPnP die das Anschlie en und die Kommunikation zwi schen UPnP Ger ten spezifizieren Dazu m ssen alle Ger te diesen Standard implemen tieren Die m gliche Kommunikation zwischen den verschiedenen Ger teklassen wird im Vorhinein festgelegt Es ist somit kein dynamisches und intelligentes Verhalten adhoc m g lich Die m gli
7. Gibt es dabei Einschr nkungen Und welche Context Awareness Welcher Kontext muss vom System erkannt werden e Welche Schnittstellen m ssen die Ger te implementieren e Technologien SOA OSGi Wird eine SOA verwendet und warum Welche Ereignisse werden erfasst e Einschr nkungen 3 2 1 Interplay Interplay ist eine Forschungsarbeit mit dem Titel A Middleware for Seamless Device In tegration and Task Orchestration in a Networked Home 18 Motivation dieser Arbeit ist die f r den Nutzer zunehmende Komplexit t bei der Bedienung von vernetzten Unterhal tungsger ten im Haushalt Diese Ger te werden immer m chtiger und der Nutzer muss sich die komplexen Funktionalit ten merken selbst um einfachste Tasks auszuf hren F r den Nutzer bedeutet dies zunehmend mehr Unbehagen und Frustration mit steigender Anzahl von Ger ten Inhalten und Daten F r die L sung dieses Problems wurde eine Middleware entwickelt die heterogene Un terhaltungsger te integriert Sitzungen verwaltet und dem Nutzer einfach erlaubt seine gew nschte Aktivit t Tasks im Haus auszuw hlen und auszuf hren Aus den Ger te funktionalit ten dem Ort Inhalten und Nutzerpr ferenzen im Haus kann Interplay dem Nutzer die m glichen Tasks zeigen die er ausf hren kann Die Nutzerabsicht user in tention wird aus einfachem Kontext geschlussfolgert und daraufhin k nnen dem Nutzer Vorschl ge unterbreitet werden Zielsetzung ist es die Absicht des Nutzers
8. In CoBrA wird OWL verwendet um damit Ontologien zu definieren f r die Modellierung von Kontext die Erstellung gemeinsamer Vokabulare f r den Wissensaustausch f r das Reasoning ber die Beziehung zwischen Kontextdaten und das Dom nenmodell und die Abbildung benutzerdefinierter Zugriffsregeln zur Sicherung der Privatsph re des Nutzers Der Context Broker sammelt Kontextdaten von verschiedenen heterogenen Quellen und integriert diese in ein einheitliches Modell welches dann mit verbundenen Ger ten geteilt werden kann Der CoBrA Ansatz unterst tzt ressourcenschwache Endger te die nur limi tierte F higkeiten zum Sammeln und Reasoning von Kontextdaten besitzen und bertr gt diese Aufgaben an einen zentralen ressourcenstarken Broker der das Aufsp ren von Kon text Reasoning und das Aufl sen von inkonsistentem Kontextwissen bernimmt Durch die zentrale Datenverwaltung ist es einfach m glich Schutz f r die Privatsph re und den Datenschutz zu implementieren SOUPA ist eine Menge von Ontologien die den typischen Kontext in der Intelligent Mee ting Room Domain modellieren soll Es wurden dabei typische Konzepte und Beziehungen zur Beschreibung von physischen Ortsangaben Zeit Menschen Software Agenten Mo bilen Ger ten und Meetingevents definiert siehe Abbildung 3 1 Auf diesen Konzepten kann Reasoning durchgef hrt werden Dabei kann unterschieden werden nach Reasoning ber Ortsontologien Ger teontologien und Zeitontologien So
9. auf dem der Bewohner in formiert werden kann Der Bewohner muss erreichbar sein Abschlussbedingungen Der Bewohner wurde ber das Ereignis informiert und es wurde eine Auswahl an Aktionen angezeigt aus denen der Bwohner eine ausgew hlt und ausgef hrt hat Qualit tsanforderungen Dem Bewohner wird die Information ber das Freignis inner halb von 1 Sekunde angezeigt 2 3 Anforderungsanalyse W hrend der Anforderungsanalyse wurden aus den dargestellten Szenarien und mit Hilfe der daraus entwickelten Anwendungsf lle Anforderungen ermittelt Das sind erstens Anfor derungen die ein Nutzer an ein intelligentes System hat Zweitens sind es Anforderungen die an die beteiligten Ger te gestellt werden Eine Unterteilung nach Muss und Kann Kriterien wird im Abschluss dieses Abschnitts vorgenommen 2 3 1 Funktionale Anforderungen Aus der Anforderungsanalyse haben sich diese funktionalen Anforderungen an das zu ent wickelnde System ergeben I Integration heterogener Ger te PC Haushaltselektronik 2 3 ANFORDERUNGSANALYSE 19 IV vy VI VII Unterhaltungselektronik eingebettete Ger te mobile Ger te Heterogene Ger te sollen sich dynamisch anmelden und abmelden k nnen Service Discovery und Integration Die Ger tekategorien umfassen PCs Unterhaltungs elektronikger te Haushaltsger te und Mobile Ger te Sollten in der Zukunft neue Ger teklassen hinzukommen dann sollen diese Ger te a
10. basierten Mechanismus zum Finden der Dienste Aus der Device Registry ermittelt die Komponente die verf gbaren Dienste und w hlt aus diesen den passenden Dienst aus Die Komponente liefert auf die Anfrage den den gefundenen Dienst als Resultat zur ck Im n chsten Schritt wird zu dem Dienst das Ger t gefunden welches diesen Dienst anbietet Diese Komponente dient dazu passende Dienste nach semantischen Kriterien und in Ab h ngigkeit des Kontextes zu finden Beispiel Wenn ein Dienst f r die Videoausgabe gesucht wird dann wird gesucht nach dem Kriterium Videoausgabe mit den Parametern Bildschirmaufl sung Anzahl der Farben und Bildwiederholrate Bei positiver Suchanfrage wird ein passender Videoausgabe Dienst zur ckgeliefert 4 2 15 Privatssph ren Manager Der Privacy Manager regelt die Aspekte der Privatssph re die in einer Smarthome Um gebung sehr wichtig sind Nutzer wollen entscheiden wer Zugriff auf ihre Daten hat und m chten nicht dass jeder Gast in ihrem Haus Einstellungen ver ndern kann Besonders relevant ist dies weil dieses System den Nutzerkontext berwacht und so jederzeit bekannt ist wo sich der Nutzer aufh lt und was er macht Die Privatsph re ist das h chste Gut des Einzelnen und es muss gew hrleistet sein dass sie nicht f r Aspekte der Bequemlichkeit blossgestellt wird 4 2 16 Netzwerkabstraktionsschicht Die Netzwerkabstraktionsschicht abstrahiert die unterschiedlichen Netzwerktechnologogien und
11. bei erstmaliger Initialisierung des Systems Fragen zu seinem Verhalten und seinen Pr ferenzen gestellt Eine andere Variante zur Erfassung von Nutzerdaten f r die Bildung eines Profils ist eine Lernphase in der der Nutzer beobachtet wird Basie rend auf dem gelernten Nutzerprofil wird dem Nutzer das hnlichste sterotypische Modell vorgeschlagen Damit wird der Aufwand zur Erstellung von Profilen f r den Nutzer redu ziert da das System selbst ndig lernt und der Nutzer nur vorgefertigten Profilen an seine Bed rfnisse anpassen muss Der Nutzer muss jederzeit auf die Nutzermodellierung vollen Zugriff haben und den Prozess der Modellierung abschalten k nnen 16 64 4 KONZEPTION 4 2 7 Policy Interface Die Komponente Policy Interface erm glicht es dem Nutzer ber die Benutzerschnittstelle Policen in das System einzugeben Der Nutzer hat das gleiche Interface unabh ngig vom Hersteller des Ger tes Die Policies werden unabh ngig von Regeln spezifiziert 4 2 8 Policy Manager Der Policy Manager verwaltet die Policen also Richtlinien Regeln auf hohem Niveau mit denen das low level Systemverhalten kontrolliert und angepasst wird High Level Re geln betreffen Aspekte der Privacy und Pr ferenzen Eine Beschreibung von Policen ist in Unterabschnitt 4 1 1 zu finden 4 2 9 Policy to Rule Translator Diese Komponente bersetzt Policies aus der obersten Schicht der dreischichtigen Koope rationsarchitektur siehe Abbildung 4 1
12. nnen Das System muss aufw rts als auch abw rtskompatibel sein um Inkompatibilit ten zwischen verschiedenen Versionen zu reduzieren 9 Das System soll sich leicht installieren lassen 10 Wartbarkeit und Wartungsfreundlichkeit 2 4 Zusammenfassung Dieses Kapitel hat einen kurzen Einblick in die Anwendungsdom ne gegeben in deren Umfeld diese Diplomarbeit angesiedelt ist Es wurden am Anfang Szenarien vorgestellt die den Einsatz dieses Systems in einem intelligenten Haus vom Gesichtspunkt eines Nut zers aus verdeutlichen sollten Aus den Szenarien wurden Anwendungsf lle ermittelt die die gew nschte Funktionalit t des Systems beschreiben Mit Hilfe der Anwendungsf lle wurden dann Funktionale und Nichtfunktionale Anforderungen ermittelt Diese Anforde rungen k nnen nur eine Teilmenge der Anforderungen sein die an ein System gestellt werden welches die Intelligenz in einem Smarthome realisieren soll Die Nichtfunktionalen Anforderungen sollen ebenfalls nur einen Eindruck vermitteln f r die Vielzahl an verschie denen Aspekte die in einem solchen System bis zur Markteinf hrung ber cksichtigt werden m ssten Aspekte wie Usability Sicherheit und Zuverl ssigkeit sind die gr ten Herausfor derungen die gel st werden m ssen bevor ein reales System von den Nutzern akzeptiert und schlussendlich eingesetzt wird In den folgenden Kapiteln dieser Diplomarbeit werden zun chst verwandte Arbeiten und Technologien in diesem Bereich
13. r welchen Nutzer ein auftretendes Ereignis interessant sein k nnte Hat die Dame Janet die Waschmaschine eingeschaltet dann m chte sie in der Regel dar ber informiert werden dass diese fertig ist Diese Sta tusinformation ist f r die dreij hrige Enkelin die gerade ein Bild malt und meistens auch f r andere Nutzer irrelevant Aus diesem Grund ist es wichtig einen Ereignistypen festzu legen Aus diesem muss sich ableiten lassen wie die konkrete Benachrichtigung auszusehen hat Das bedeutet welche Personen k nnten sich f r das Freignis interessieren und wer muss auf jeden Fall benachrichtigt werden und wie Ereignisse vom Typen Interaktionsereignis ben tigen eine Interaktion des Nutzers Es muss folglich ein Ger t gefunden werden auf dem dieses Ereignis angezeigt werden kann und mit dem der Nutzer interagieren kann Dabei muss noch die Adaptation an das geeignetste Ger t vorgenommen werden diese Aufgabe wird von dem Multimodaler Benutzerschnittstellen Manager bernommen 70 4 KONZEPTION Ohne Verwendung eines Kontextdienstes k nnten einfach alle Ger te eines Nutzers unter seinem Namen identifziert werden und der Nutzer wird nur von Freignissen benachrichtigt die auf diesen beteiligten Ger ten ausgel st werden Ereignisbehandlung Ger te die sich anmelden k nnen sich f r Ereignistypen registrieren Vergleich EventLi ster dass entspricht dem herk mmlichen Ereignismechanismus Bei dem hier gew hlten Ansatz melden
14. tekonfiguration integriert und wieder ausgegliedert werden 3 2 4 Dienstorientierte kontextbewusste Middleware SOCAM Service Oriented Context Aware Middleware siehe 11 wurde mit dem Ziel entwickelt Rapid Prototyping von kontextabh ngigen Anwendungen zu erm glichen SO CAM konvertiert verschiedene physische R ume in denen Kontext erfasst werden kann in einen semantischen Raum in dem kontextbewusste Anwendungen den Kontext teilen und darauf zugreifen k nnen Architektur Context aware application Context aware application D D a a a gt Data flow Control and signaling flow Abbildung 3 4 berblick ber die SOCAM Architektur 11 Die Middleware besteht aus den folgenden Komponenten e Der Context provider abstrahiert n tzlichen Kontext von heterogenen Kontextquel len interne und externe und wandelt diese in OWL Darstellung um so dass an dere Dienstekomponenten diese teilen und wiederverwenden k nnen Eine externer Context Provider kann ein Wetterinformationsdienst sein der Wetterdaten eines be stimmten Ortes liefert Ein interner Context Provider sammelt Kontext von verteilten Sensoren wie RFID Ortssensoren in einem Smarthome Daraus k nnen Ereignisse der Art Person liegt auf dem Bett oder Person ist hingefallen erzeugt werden Nutzer und Dienste k nnen entweder Kontext direkt abfragen oder Informationen ber Kontex tereignisse abonnieren Der Context
15. ten ausgef hrt werden und Ausf hren einer Aktion Dem Nutzer sollen m gliche Aktionen dargestellt werden abh ngig davon wo er sich aufh lt und mit welchen Ger ten er in Kommunikation steht Diese k nnen in seiner momentanen Situation auf den verf gbaren Ger ten ausgef hrt werden Zu einem Freignis welches eine Reaktion erfordert soll dem Nutzer eine Auswahl aller m glichen Aktionen angezeigt werden um auf das dargestellte Ereignis reagieren zu k nnen Das System muss dazu ein Ger t ermitteln welches die M glichkeit zur Interaktion bietet so dass der Nutzer Aktionen ausw hlen und ausf hren kann e Bei einer Fehlermeldung werden dem Nutzer Aktionen angezeigt so dass er unter Anleitung des Systems den Fehler beheben kann e Der Nutzer soll einen Anruf auf einem beliebigen Ger t annehmen k nnen e Anzeige von Ereignissen die Interaktion erfordern Ereignis anzeigen oder zum Beispiel den H ndler informieren Beispiel Wenn jemand an der T r klingelt soll der Nutzer dar ber auf einem Ge r t informiert werden Auf einem Ger t sollen die m glichen Aktionen f r dieses Ereignis angezeigt werden Auf dem Ger t wird der Name der klingelnden Person angezeigt und die Aktionen T r ffnen Mit der Person sprechen oder Ableh nen Der Nutzer w hlt die Aktion T r ffnen und die T r wird vom System ge ffnet Kontrollieren von Funktionen eines anderen Ger tes von einem geeigneten Ger t aus Fer
16. 79 5 1 2 Abbilden von OWL Konzepten auf Dienste 82 5 1 3 Kooperation von Ger ten 82 5 1 4 Integration von existierenden Ger ten 83 5 1 5 Integration neuer Ger te 2 2 KL Emmen 83 5 1 6 Dienste s ira onsa are ner Ba 83 9 2 Regelschicht 2 2 03 2 2 eth ack ae anne Meo 85 Bids a ee 86 5 4 Ger te als OSGi Bundles a 2 2 a oo nn nn 88 5 4 1 Ereignisbehandlung 5 4 2 Kontextbenachrichtigung 6 Bewertung der Arbeit 7 Zusammenfassung Literaturverzeichnis Abbildungsverzeichnis 89 91 93 97 1 Einleitung 1 1 Motivation Ubiquitous Computing Ubicomp steht f r die Allgegenw rtigkeit von Rechnern In der idealen Ubiquitous Computing Umgebung ist der Nutzer von intelligenter Technik umge ben ohne diese bewusst wahrzunehmen Die einzelnen Ger te kooperieren miteinander gehen auf vorhandenen Kontext ein und vereinfachen so den Alltag des Nutzers Es be deutet einen Innovationssprung von der Zeit in der der Nutzer dem Computer und den Ger ten Befehle geben und diese bedienen musste bis hin zu einer Zeit in der Computer und andere Ger te Aufgaben selbst ndig erkennen und ausf hren ohne den Benutzer in seinen Aktivit ten zu unterbrechen In der Publikation Challenges An Application Model for Pervasive Computing 2 werden folgende Grunds tze aufgestellt
17. Die Implementierung der Middleware erfolgt in der OSGi Implementierung von Prosyst Damit werden die Komponenten Bundles editiert verwaltet die Nutzerver waltung durchgef hrt und die Sicherheit kontrolliert 3 2 5 DAFNE DAFNE Distributed Web based Management Framework for Ambient Reconfigurable Ser vices in the Intelligent Environment 25 ist eine Framework L sung f r intelligente Um gebungen und hat das Ziel heterogene Netzwerke und Ger te zu verwalten Virtualisation of the ambient network infrastructure will enable the integration interaction and interoperation of different devices from different vendors and diverse networking technologies Bisher fehlten Frameworks welche die gro e Anzahl und Heterogenit t von Ger ten Tech nologien und Ambient Intelligent Subsystemen vereinen um das Potenzial dieser Techno logien auszusch pfen und die Anforderungen einer intelligenten Umgebung zu befriedigen Dabei soll solch ein System so unauff llig wie m glich die automatisierte Interaktion mit und zwischen Ger ten erm glichen DAFNE ein wirklich integriertes intelligentes System in der die Infrastruktur so unauff llig wie m glich ist und die Interaktion mit und zwischen Ger ten autonom erfolgt Dazu bernimmt DAFNE die Verwaltung von Anwendungen und Diensten und richtet sich dabei nicht nur an den Bereich des Smarthomes sondern auch an den Firmen und ffentlichen Sektor Mit dieser dienste orientieren Architektur l sst sich
18. Kommt ein neues Ger t hinzu wird die Policy gleich ber cksichtigt e Fernsehen aufnehmen wenn ich von Kontakten die in meinem Adressbuch stehen angerufen werde e Sch tzen der Privatsph re e Vor um 8 Uhr morgens nehme alle Telefonate auf den AB auf e Wecke mich zu einer festgelegten Uhrzeit zum Beispiel um 8 Uhr e Nutzer legt fest dass er bei Statusmeldung nicht benachrichtigt werden m chte e Ger testeuerung und Statusabfrage e Statusmeldungen von Ger ten nur demjenigen zeigen der Ger t bedient hat e Sobald jemand schauen will ob zum Beispiel Waschmaschine frei ist werden diese Statusmeldungen ben tigt e Nur Eigent mer einer Todo Liste darf diese modifizieren Rechteverwaltung f r Zugriff auf den HomeController also die zentrale Steuerung Rechteverwaltung f r Zugriff auf Konfigurationen Wer darf neue Regel anlegen El tern Kind Administrator Ist von der Rolle abh ngig Altersbeschr nkung der In halte e Wie lange sollen die Sitzungsdaten gespeichert werden wenn berhaupt e Licht ausschalten wenn der Nutzer schl ft e Heizung herunterfahren wenn der Nutzer in den Urlaub f hrt 4 1 REGELN UND POLICEN 53 Policen die Umweltbewusstsein umsetzen Heizung und Licht nur dort wo sich Nut zer aufh lt e Schutz des Nutzers durch Sicherung der Wohnumgebung e Benachrichtigungsreihenfolge e Nutzer definiert welche Ausgaben auf welchen Ger ten angezeigt werden Definition v
19. Ma f r die Anzahl der Abh ngigkeiten innerhalb eines Subsystems Ziel ist es die Abh ngigkeiten zwischen verschiedenen Subsy stemen zu minimieren Die Koh sion innerhalb eines Subsystems soll maximiert werden Somit werden die verschiedenen Komponenten mit ihren Funktionalit ten weitestgehend voneinander entkoppelt und k nnen unabh ngig entwickelt und getestet werden 3 6 ZUSAMMENFASSUNG 47 Ein Service Provider bietet einen Dienst an und ein Service Consumer nutzt einen Dienst Dazu stellt er eine Anfrage Service Request und erh lt als Antwort eine Service Respon se Hier eine bersicht ber die Vorg nge von Dienstanbieter und Dienstkonsument und deren Interaktion e Ver ffentlichen publish eines Dienstes und Registierung register e Finden eines Dienstes find e Binden eines Dienstes bind e Ausf hren des Dienstes execute Die hierarchische Zerlegung des Systems ergibt einen geordneten Satz von Schichten Das System wird in Partitionen zerlegt und jede Partition ist f r eine Klasse von Diensten zust ndig Beispielsweise wird das Softwaresystem in einem Auto in die folgenden Dien ste zerlegt Reisedienst Pr ferenzdienst Fahrzeugdienst 3 Mit Orchestrierung wird die Anordnung von Diensten in eine festgelegte Ausf hrungsabfolge bezeichnet 3 6 Zusammenfassung Aus der Analyse der verwandten Arbeiten hat sich f r mich ergeben dass OSGi als Dienste plattform sehr verbreitet ist und in bestehenden Sm
20. Provider nutzt ein Service Template oder einen OWL Ausdruck um zu spezifizieren welchen Kontext es liefert 3 2 VERWANDTE ANSATZE 39 e Context interpreter bietet logische Schlussfolgerungsdienste ftir die Verarbeitung von Kontextinformationen an und ist somit ein Context Provider fiir High level Kontext Er besteht aus einem Context reasoner zum Ableiten der Kontextdaten und einer Kontextwissensbasis Implementiert wird der Context Interpreter mit dem Jena2 Se mantic Web Toolkit e Context database speichert Kontextontologien und vergangenen Kontext fiir eine spezifische Subdom ne Jede Dom ne hat eine logische Kontextdatenbank Die Kon textdatenbank enth lt T Box Informationen ber die Subdom ne und A Box Infor mationen ber die Instanzen der Kontextontologie Kontextbewusste Anwendungen nutzen verschiedene Level des Kontextes und passen ihr Verhalten an den Kontext an e Service Locating Service SLS bietet einen Mechanismus der es dem Context inter preter und dem Context provider erm glicht ihre Dienste anzubieten und Nutzern und Anwendungen diese Dienste zu finden Fine Anwendung die an einem Kontext wert interessiert ist schickt eine Anfrage z B John socam befindetSichIn x an diesen Dienst und erh lt als Antwort eine Referenz zu dem Context Provider der diese Information enth lt Abbildung 3 4 zeigt einen berblick ber die SOCAM Architektur Alle SOCAM Kom ponenten sind als unabh ngige Komponenten r
21. Service orientierten Archi tektur SOA Es wird eine Intelligente Umgebung vorgeschlagen die den Kontext und das Verhalten der Hausbewohner ber cksichtigt um kontextabh ngige Dienste anzubie ten Der Schwerpunkt dieser Arbeit wird auf auf das OWL basierte Kontextmodell und auf die Schlussfolgerungschicht Inference Layer gelegt die mit der SWRL Regelsprache umgesetzt wird Die Architektur zur Kontexterfassung besteht aus folgenden vier Schichten 1 Wahrnehmungsschicht mit Sensoren zur Kontexterfassung 3 2 VERWANDTE ANSATZE 43 2 Kontextschicht stellt eine high level semantische Sicht auf die ermittelten Daten be reit 3 Schlussfolgerungsschicht berechnet die Kontextdaten 4 Contextual Services Schicht bezieht sich auf Kontextdaten um Aktionen zu bestim men Kontextmodell und logisches SchlieBen Das Kontextmodell repr sentiert den Kontext zu einem bestimmten Zeitpunkt t und Ziel ist es den Kontext darzustellen der auf Sensordaten basiert Aus Gr nden der Interopera bilit t mit anderen Ans tzen wird eine OWL Ontologie zur Modellierung der Smart Home Dom ne verwendet Diese enth lt die physische Repr sentation des Smart Homes T ren W nde Fenster und eine Repr sentation der Objekte die in einem Haus vorkommen wie M bel und elektrische Haushaltsger te Ebenso wird der Bewohner im Kontextmodell re pr sentiert durch Modellierung seiner Charakteristiken wie Nutzerpr ferenzen Ort Iden tifikation
22. Zugriff auf Objektkontrolle Verschiedene Dienste von unterschiedlichen An bietern k nnen auf einer einzigen Gateway Plattform gehostet werden Desweiteren unter st tzt OSGi eine Vielzahl von Heimvernetzungstechnologien Die OSGi Spezifikation legt den Schwerpunkt auf die Bereitstellung von verschiedensten Diensten durch ein Gateway in Heim B ro oder Fahrzeugumgebung OSGi als herstellerunabh ngige generische OSGi Softwareplattform dient der Vernetzung einer Vielzahl von m glichen Ger ten Inzwischen wird OSGi in einigen Smarthome L sungen und f r Middleware L sungen verwendet Das OSGi Framework ist eine Service Orientierte Architektur mit folgenden Eigenschaften e geringe Kopplung e Komponenten finden sich dynamisch f r Zusammenarbeit e Komponenten k nnen dynamisch an Ger te im Operationsfeld ausgeliefert werden e Komponenten die auf einer Vielzahl von Ger ten von sehr klein bis sehr gro laufen k nnen Das OSGi Framework ist in folgende Schichten unterteilt e LO Execution Environment e LI Modules e 12 Life Cycle Management f gt Bundles hinzu die dynamisch installiert gestartet gestoppt upgedatet und deinstalliert werden k nnen e L3 Service Registry bietet Kooperationsmodell f r Bundles welches Dynamik be r cksichtigt Es ist ein umfassendes Modell um Objekte zwischen Bundles zu teilen nttp www osgi org Eine Auswahl ist zu finden unter http osgi org markets smarthome asp 46 3 VER
23. an welches dem Nutzer am n chsten ist In einem eingebetteten System werden aufgrund der Datenmenge in der Ontologie mo mentan noch f nf Sekunden Zeit f r das Schlussfolgern ben tigt Zusammenfassung Dieser SOA Ansatz hat seinen Schwerpunkt auf dem Kontextmodell und dem kiinstli chen Intelligenz Teil der auf einer OWL Ontologie und darauf schlie enden SWRL Regeln basiert Das Szenario konzentriert sich in den Beispielen auf Sensoren und Aktoren wie gesteuerte Lampen und Heizungen Dabei stellt sich die Frage worin der Mehrwert einer solchen L sung beseht und warum nicht einfach Bewegungsmelder und andere Sensoren genutzt werden Die SWRL Regeln definieren Aktionen die von Aktoren ausgef hrt werden Das System muss anhand von Daten in der Ontologie schlussfolgern welches die beste Aktion ist die ausgef hrt werden soll Momentan ist die ben tigte Zeit f r das logische Schlie en aufgrund der Leistung von eingebetteten System noch zu lang und dadurch k nnte sich der weite Einsatz von Ontologien verz gern 3 3 Heimvernetzungstechnologien Es gibt verschiedene Technologien zur Heimvernetzung und diese arbeiten in ihren Berei chen gut Sie haben sehr n tzliche Funktionen zur Beschreibung von Ger ten und ihren Diensten Es mangelt allerdings bei allen an der Beschreibung wie Ger te kooperieren k n nen Von den gefundenen L sungen setzt nur UPnP Regeln f r die korrekte Kooperation zwischen Kontext und Objekten ein aber di
24. den zentralen Zugriff auf die Konfiguration von Ger ten Policen Regeln erm glicht Die Benutzerschnittstelle ist in drei verschiedene Sichten unterteilt die die den Zugriff auf Einstellungen und Funktionen regulieren Es gibt eine Sicht f r den Nutzer eine f r den Administrator und eine f r 4 2 ARCHITEKTUR 57 den Anwendungsentwickler Je nach Wiinschen des Anwenders k nnen sich die Sichten berschneiden In den folgenden Paragraphen werden die Sichten beschrieben und inwieweit sie sich voneinander unterscheiden Nutzersicht Die Nutzersicht ist die Sicht ber die der Nutzer mit dem Home Controller interagiert Dar ber erfolgt die Kontrolle und Konfiguration von Ger ten Der Nutzer definiert damit Policies welche die Kooperation und Integration von Ger ten festlegen Daf r wird auf die Komponente Policy Interface zugegriffen welche die Eingabe des Nutzers verarbeitet und mit Hilfe des Policy To Rule Transformers in Regeln transformiert beziehungsweise direkt in der Knowledgebase abspeichert Der Nutzer meldet sich beim Home Controller an und kann sich den Status der vorhan denen Ger te in seiner Wohnumgebung anschauen Dazu gibt es eine Statusampel die mit den Farben gr n gelb und rot den Gesamtzustand des Systems visualiert Wenn die Statussampel gr n anzeigt dann ist der Status aller Ger te in der Wohnumgebung in Ordnung Bei gelb gibt es Warnungen die beachtet werden sollten Bei rot ist ein Fehler aufgetreten d
25. die Benutzerschnittstelle integrieren lassen insbesondere bisher unbekannte Ger tefunk tionalit ten Diese Arbeit soll ber die reine Vernetzung von Ger ten in vordefinierten Szenarien und Abl ufen hinausgehen Es m ssen spezielle Regeln f r Standardsituationen und Szenarien in der Wohnumgebung vordefiniert werden Die Middleware soll Entscheidungen f r den Nutzer bernehmen oder dem Nutzer Handlungsoptionen in leicht verst ndlicher Weise anbieten 1 4 STRUKTUR DER ARBEIT 7 1 4 Struktur der Arbeit Um genau zu verstehen wie die Anforderungen an eine solche Middleware sein sollen wird in Kapitel 2 die Anwendungsdom ne genauer analysiert Es werden typische Anwendungs f lle dargestellt in denen die Kooperation von Ger ten dem Nutzer hilft und sein Leben erleichtert Aus diesen spezifischen Szenarien werden Anwendungsf lle ermittelt aus denen sich die Anforderungen bestimmen lassen In Kapitel 3 werden existierende Technologien und verwandte Arbeiten gesichtet Diese liefern die Ideen f r die Konzeption in Kapitel 4 Die Beschreibung des Prototyps zur Konzeption folgt in Kapitel 5 Die Verifikation meines Ansatzes in Kapitel 6 bewertet die Vorgehensweise Die Zusammenfassung in Kapitel 7 schlie t diese Diplomarbeit mit einer Bewertung und einem Ausblick ab 1 EINLEITUNG 2 Identifikation der Anwendungsdomane Das Ziel dieser Arbeit ist es Konzepte des Ubiquitous Computing und der Context Awareness zu untersuche
26. die Integra tion von vielf ltigen Systemen m glich Damit werden die Anforderungen I Integration heterogener Ger te II Zwischen Ger ten soll eine nahtlose Kooperation ohne vorheri ge Konfiguration m glich sein III Ger te m ssen eine semantische Selbstbeschreibung haben und IV Finden von Ger ten mit Suche nach deren F higkeiten erf llt Die nichtfunktionalen Anforderungen wie Usability Sicherheitsanforderungen Leistung und Effizienz wurden in dieser Arbeit nicht konkret behandelt Denn diese erfordern ein ausgiebiges Testen durch eine ausgew hlte Nutzergruppe und die Integration der Middle ware in eine Smarthome Umgebung Die Tests k nnen nur unter realen Bedingungen am Besten in einem richtigen Smarthome durchgef hrt werden Auf Grundlage dieser theore tischen berlegungen wurde ein erster Prototyp entwickelt der sich durch seine Anwend erfreundlichkeit auszeichnet Hilfestellung in typischen Situationen Werden die in der Aufgabenstellung genannten typischen Situationen von lteren Menschen erfasst und kann den Menschen in diesen Situationen geholfen werden Darstellung von Funktionalit t auf leicht verst ndliche Weise und Anbieten von verf gba 90 6 BEWERTUNG DER ARBEIT ren Aufgabe Es steht nicht das einzelne Ger t im Vordergrund sondern das Zusammenspiel der unterschiedlichen kooperierenden Ger te ist entscheidend Das intelligente System er mittelt automatisch anhand der Situation des Nutzers u
27. die Interoperabili t Verwaltung von Ressourcen und Rekonfiguration erm glichen Das System konzentriert sich haupts chlich auf die Anwendungsf lle Gesundheitspflege lterer Menschen und Menschen mit Behinderungen und Sicherheit in Intelligenten Umgebungen F r die Umsetzung der virtuellen ambienten Netzwerk Infrastruktur wird eine Kombi nation aus OSGi und UPnP verwendet Dienste und Anwendungen werden auf diesem Framework als OSGi Bundles deployed Das erlaubt die dynamische Registrierung Ak tivierung und Deaktivierung und das Auffinden von Diensten als auch die Interaktion zwischen Diensten von verschiedenen Anbietern UPnP wird f r die Kommunikation mit anderen Modulen der Intelligent Environment genutzt dass hei t der Context Awareness Komponente und der Ambient Network Infrastructure Die einzelnen Anwendungen werden 42 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN als virtueller UPnP Dienst deployed Das Framework hat Mechanismen fiir die dynamische Integration von Komponenten damit sich installierte Komponenten finden und zusammen arbeiten k nnen um einen Task zu erledigen Die Entwicklung und das Deployment von Diensten soll so dynamisch wie m glich sein neue Dienste sollen wie bei Plug and Play hinzukommen und es soll eine dynamische Rekonfiguration des Systems erfolgen Anforderungen an intelligenten Umgebungen die das DAFNE Framework erf llt und die auch f r die vorliegende Arbeit relevant sind 1 Virtuali
28. ea ae 122 Problemstellung a seh ar naar ee 1 3 L sungsansatz eg urn a an ein eh 1 4 Struktur der Arbeit 2 2 u 888 a ana er ae Identifikation der Anwendungsdom ne 2 1 Szenari n bse PES AS ae ee ne er a 2 2 Anwendunssfalle ea 32 PRESS Deere 23 Anforderunssanalyse ee ee 2 3 1 Funktionale Anforderungen 2 3 2 Nichtfunktionale Anforderungen 2 4 Zusammenfassung Verwandte Arbeiten und existierende Technologien 3 1 Ontologien und Tell OWE a N Be nn A 3 1 2 Semantic Web Rule Language 3 13 Context Awareness 3 1 4 Gu s Ontology based Context Model for Intelligent Environments 3 1 5 Chen s Standard Ontology for Ubiquitous and Pervasive Applicati ons SOUPA ee ok pe el ee ee as 3 2 Verwandte Ans tze asus es ash lan ee 3 21 Interplay Die act ee en ae 3 2 2 AMIGO y er a Ba hI u ee 3 2 3 Nahtlose Integration von Ausgabeger ten 3 2 4 Dienstorientierte kontextbewusste Middleware 3 2 9 SD ARNE is ox eek WO a ae RO eee a Oe 3 2 6 Schlussfolgern auf Kontext im Smarthome Ein SWRL Ansatz 3 3 Heimvernetzungstechnologien
29. eine Ger testeuerung vorhanden ist Das System berwacht bei Vorhandensein entspre chender Ger te den Gesundheitszustand des Nutzers und l st einen Alarm aus wenn vorgegebene Parameter berschritten werden Anzeige von Informationen Auf einem geeigneten Ger t welches sich in der N he des Nutzers befindet sollen beliebige Informationen wie Warnung Fehler Status Notfall Termin und Ereig nisse anderer Ger te anzeigt werden Das System muss ermitteln wo sich der Nutzer aufh lt und vom welchem Ger t er das Ereignis wahrnimmt Dann muss das Sy stem die Darstellung der Information an dieses Ger t anpassen Die Informationen sollen in einer f r ltere Menschen verst ndlichen Weise dargestellt werden Jedes Ereignis soll ausf hrlich mit einer Beschreibung dargestellt werden Dazu geh rt die Information von welchem Ger t aus das Ereignis ausgel st worden ist e Das System muss die Priorit t einer Nachricht kennen Konflikte in der Be handlung von Ereignissen d rfen nicht auftreten Wenn zur gleichen Zeit eine Warnsituation und ein Notfall auftreten dann muss der Notfall zuerst ange zeigt werden da diese Nachricht eine h here Priorit t hat e Bei einem Notfall muss der Nutzer oder eine andere Person die Hilfe einleiten kann auf jeden Fall informiert werden Dem Nutzer muss eine Handlungsvor schlag dargestellt oder ausgegeben werden e F r die vollst ndige Darstellung einer Warnung muss dem Nutzer mitgeteilt
30. einen Handlungsvorschlag und aus dieser Entscheidung werden Policen f r die Kooperation von Ger ten generiert F r die spezifischeres Anpassung der Policies an abweichendes Verhalten werden diese in separate Profilen unterteilt Diese Profile sind kontexabh ngig und stehen in Zusammen hang mit der Situation des Nutzers anwesende Personen Gesundheitszustand des Nutzers wie Krankheit geplante l ngere Abwesenheit Urlaub der Tageszeit Angenommen der Nutzer erh lt spontanen Besuch von seiner Familie dann will er die normale Ausf hrung der Regeln unterbrechen Der Nutzer ruft dazu den Home Controller auf und wechselt von der Standardausf hrung der Regeln auf das Profil jemand ist zu Besuch Wenn das installierte System in der Wohnumgebung Kontext ermitteln kann um solche Situation selbst ndig festzustellen dann kann der Wechsel zwischen den Profilen automatisiert erfolgen Der Nutzer hat aber dabei immer die M glichkeit das aktuelle 58 4 KONZEPTION Profil schnell zu wechseln und die regul re Ausf hrung zu unterbrechen Der Nutzer kann sich alle existierenden Profile und Policen im Home Controller anzeigen lassen Er hat die M glichkeit folgende Aktivit ten f r Tasks und Policen durchzuf hren e Neue Profile und Policen definieren e Bestehende Profile modifizieren e L schen eines Profils e Unterbrechen der Ausf hrung e Anhalten und Fortsetzen der Ausf hrung Wie Ger te miteinander kooperieren d rfen h ngt
31. erfolgen kann welche Datentypen werden unterst tzt und welche Regeln und Policies werden von einem Ger t unterst tzt 4 3 3 Nutzerontologie Die Nutzerontologie enth lt Wissen ber Nutzerpr ferenzen ber den Aufenthaltsort des Nutzers und seine Aktivit t In dieser Ontologien werden auch Beziehungen zwischen verschiedenen Nutzern abgebildet Daraus lassen sich R ckschl sse f r eine bestimmte Bedienung des Systems ziehen Einem Nutzerkonzept ist eine Aktivit t zugeordnet und eine Situation in der sich der Nutzer befindet Dieses Nutzerkonzept wird mit aktuellen Kontextdaten gef llt Dem Nut zerkonzept sind weiterhin zugeordnet welches Ger te oder welche Ger te vom Nutzer verwendet werden Aus der Aktivit t und der Nutzung eines Ger tes l t sich auf die Si tuation des Nutzers schliessen Die Aktivit t muss ber cksichtigt werden wenn der Nutzer mit einem Ger t interagiert beziehungsweise Ger te kooperieren damit der Nutzer einen Task ausf hren kann Enth lt die Beschreibung der Ger te mit deren Funktionalit ten wie Eingabe und Ausgabemodalit ten 4 3 4 Taskontologie In der Taskontologie werden die Konzepte von Tasks beschrieben F r jeden Task ist de finiert welche Ger tefunktionalit t zur Ausf hrung ben tigt wird Das hei t in dem Task steht welche Dienste dieser verwendet und mit welchen Parametern Die zur Laufzeit ver f gbaren Tasks ergeben sich aus der Ger tekonfiguration und die Anwendung gr
32. ihren elektronischen Kalender eingetragen und damit ist das Problem vorerst f r sie gel st automatische Terminvereinbarung Szenario 2 Szenario Janet sitzt vor dem Fernseher und das Telefon klingelt 2 1 SZENARIEN 11 Akteur Instanzen e Janet Bewohnerin e Anrufer e Telefon Fernseher Ger te im Haushalt Ereignissfluss 1 Janet schaut sich gerade eine interessante Reisereportage im Fernsehen an als das Telefon klingelt 2 Auf dem Fernseher erscheint ein Fenster mit dem Namen des Anrufers und der Frage ob Janet das Telefonat annehmen und die Sendung aufzeichnen m chte ber ein einfaches Men Dr cke Gr ne Taste f r Annehmen Dr cke Rote Taste f r Besetzt kann die Auswahl getroffen werden 3 Janet m chte den Anruf annehmen Von diesem Zeitpunkt an wird das aktuelle Programm angehalten und auf einem beliebig verf gbaren Videoaufnahmeger t z B dem angeschlossenen Festplattenrekorder aufgezeichnet 4 Das Telefonat wird ber die Fernseherlautsprecher und ein Raummikrofon gef hrt Janet die nicht mehr gut h rt und auch Probleme hat die kleinen Tasten auf dem Telefon zu bedienen kann so ganz bequem von der Couch ihre Telefonate f hren Ein weiterer Vorteil ist dass sie ihr Telefon nicht mehr suchen muss und dass die Anrufer nicht mehr den meistens sehr lauten Fernseher im Hintergrund h ren 5 Nach dem Telefonat wird ihr auf dem Fernseher ein Auswahlmen angezeigt auf dem angeboten wird die Reis
33. in der Smarthome Umgebung l uft dieses System Die Ger te stellen dem System ihre Funktionalit t als Dienste zur Verf gung Ein Ger t meldet f r jede abgrenz bare Funktionalit t einen Dienst an Das bedeutet dass zum Beispiel ein Videorekorder einen Dienst Video abspielen und einen weiteren Dienst Video aufnehmen anmeldet Die Middleware l uft auf einer Virtuellen Maschine und kann somit auf allen Ger ten installiert werden die diese Virtuelle Maschine unterst tzen 4 2 1 Home Controller Der Home Controller ist das zentrale Ger t mit dem der Nutzer interagiert Aufihm werden die Komponenten installiert die f r die zentrale Verwaltung und Kontrolle der beteiligten Ger te und deren Funktionalit ten in der Anwendungsdom ne zust ndig sind Fr wird nur einmal auf einem zentralen Ger t in der Anwendungsdom ne installiert und ausgef hrt da so die Verwaltung der verteilten Ger te und Funktionalit ten am Einfachsten erscheint Mit dem Home Controller erh lt der Nutzer Zugriff und die Kontrolle auf alle angeschlossenen Heimautomatisierungsger te Der Zugriff auf diese zentralen Funktionen ist von jedem Standort Computer oder ande ren geeigneten Ger t dieser Anwendungsdom ne m glich also auch per Webschnittstelle durch ein beliebiges an das Internet angeschlossene Endger t wie Mobiltelefone PDA Webconsolen Der Home Controller bernimmt die Aufgaben eines Routers und bietet diverse Kom munikationsschnittstellen zu Heim
34. in niedrigschichtigere Regeln 4 2 10 Regelschicht Diese Schicht enth lt die eigentliche Logik dieses Systems In einem Repository werden alle Regeln gespeichert die vordefiniert sind und die vom Nutzer zus tzlich definiert werden Auf Basis von diesen Regeln wird die Kooperation und Integration der beteiligten Ger te festgelegt Die Regelschicht erh lt die aktuellen Kontextdaten aus der Kontextschicht und feuert bei Kontext nderungen die entsprechenden Regeln die daraufhin ausgef hrt werden In Unterabschnitt 4 1 2 wird beschrieben wie solche Regeln aufgebaut sind 4 2 10 1 Rule Engine Die Rule Engine greift auf die in der Knowledge Base vorhandenen Regeln und die dazu geh rigen Kontextdaten und Ereignisse zu und wertet die Regeln damit aus 4 2 10 2 Regel Monitor Der Rule Monitor wird von der Kontextschicht ber Kontextereignisse informiert Er ber pr ft alle Regeln auf einen passenden Event Teil welcher der aktuellen Situation entspricht Es k nnen mehrere Regeln gefunden werden deren Event Teile bereinstimmen und da durch k nnen Konflikte auftreten wenn diese gleichzeitig gefunden werden oder wenn Dienste die im Actions Teil ausgef hrt werden sollen exklusiv sind also z B dieselben Ressourcen beanspruchen Diese Konfliktregeln werden an eine andere Komponente den Regel Konfliktmanager weitergeleitet und von diesem aufgel st bevor die entsprechenden Dienste aufgerufen werden 4 2 ARCHITEKTUR 65 4 2 1
35. l sst sich beispielsweise aus gemessenen Sensordaten die ermittelt haben dass sich eine Person in einem bestimmten Raum befindet und dem Wissen dass dieser Raum Teil eines bestimmten Geb ude ist 3 2 VERWANDTE ANSATZE 31 schlussfolgern dass sich die Person in dem Geb ude befindet Solche Aussagen k nnen relevant sein wenn Regeln f r den Oberbegriff Geb ude definiert werden und diese auch f r alle R ume Subkonzepte in diesem Geb ude gelten sollen Um die Realisierbarkeit des CoBrA Ansatzes im Easy Meeting System Anwendung die Intelligent Meeting Room Domain umsetzt zu demonstrieren wurde der zentrale Context broker als Agent implementiert der auf der JADE Plattform Java Bibliothek f r FIPA Agenten l uft und diesem Standard f r Agenten entspricht F r den Zugriff und die Bear beitung der OWL Ontologien verwendet der Broker das Jena Semantic Web Toolkit 17 F r das logische Schlie en Reasoning wird Jess Java basierte Rule Engine 9 verwendet Der Vorteil von Jess gegen ber anderen verf gbaren Rule Engines ist die Interoperabili t t mit existierenden Semantic Web Bibliotheken und Werkzeugen die ebenfalls in Java geschrieben wurden SOUPA ist ein Ansatz mit dem Ziel eine umfassende Ontologie f r die Dom ne des Ubi quitous Computing zu bieten Damit haben Anwendungen in diesem Bereich Zugriff auf eine gemeinsame Ontologie und k nnen kooperieren 3 2 Verwandte Ans tze Mit den folgenden Anforderung
36. m glichen Kooperationen in der Taskontologie ab 5 1 KLASSIFIKATION VON GERATEN UND EREIGNISSEN 83 Damit kann der Home Controller Tasks automatisch finden wenn dies in einer bestimmten Situation erforderlich ist 5 1 4 Integration von existierenden Geraten Bevor Ger te kooperieren k nnen m ssen sie zuerst in die Middleware integriert werden Die Anforderung I siehe Abschnitt 2 3 schreibt vor dass die Integration heterogener Ge r te nahtlos erfolgen soll In der Konzeption siehe Abschnitt 4 3 wurde festgelegt dass Ger te in einer Ger teontologie beschrieben werden was die Integration und das Hinzuf gen neuer Ger te erm glicht Im Prototypen wird ein Ger t in die Middleware integriert durch Starten des entspre chenden Dienstes im Home Controller Die Device Registry bernimmt die Registrierung des Dienstes und die Device Classification f hrt die Instanziierung der entsprechenden OWL Konzepte durch 5 1 5 Integration neuer Ger te Die Integration neuer Ger te erfolgt hnlich der existierender Ger te Allerdings gibt es f r neue Ger te noch keine OWL Repr sentation Anhand der semantischen Dienstebeschrei bung und mit Hilfe der Device Classification wird ein neues OWL Konzept in die Ontologie integriert und dann wird das neue Ger t als dessen Instanz hinzugef gt Bei Konflikten muss der Administrator benachrichtigt werden Als neue Ger te werden hier ein Laptop ein Handy und ein Radio hinzugef gt Die
37. shall not be aware of this interaction but concentrate fully on his tasks Consequently dynamic device integration and cooperation is essential We achieve this by proposing a middleware and a three tier cooperation architecture defining policies rules and tasks Devices and services are described abstractly with ontologies OWL The cooperation between devices is defined by rules A protype based on OSGi presents the feasibility of the here introduced approach Kurzfassung Ubiquitous Computing steht f r die Allgegenw rtigkeit von Rechnern welche die Aufgabe haben die Menschen zu unterst tzen Dazu ist es erforderlich dass die r umlich verteilte intelligente Technik miteinander kooperiert Diese Vorg nge sollen sich der Aufmerksam keit des Menschen entziehen damit er sich auf seine wesentlichen Aufgaben konzentrieren kann Voraussetzung daf r ist die dynamische Integration und Kooperation von Ger ten In dieser Arbeit wird eine Middleware entwickelt die dies erm glichen soll Es wird eine drei schichtige Kooperationsarchitektur eingef hrt Sie definiert die Policen auf der obersten Regeln auf der mittleren und Tasks auf der untersten Schicht Ger te und Dienste wer den mit Ontologien OWL abstrakt beschrieben und anhand von Regeln die Kooperation zwischen Ger ten festgelegt Eine prototypische Umsetzung in OSGi zeigt die Machbarkeit des vorgestellten Ansatzes Inhaltsverzeichnis Einleitung bl Motivation a ee een
38. sich die Ger te an und dann legt der HomeController fest f r welche Er eignisse dieses registriert wird Der EventListener muss somit nicht zu Beginn festlegen f r welches Ereignis er sich interessiert sondern das kann dynamisch zur Laufzeit bestimmt werden Die Abonnierung bernimmt der Controller als Stellvertreter und dieser kennt m gliche Ger te die ein Ereignis verarbeiten k nnen 4 2 13 Context Service Der Kontextdienst Context Service hat die Aufgabe Kontextdaten zu erfassen zu verar beiten und diese an andere Komponenten welche sich f r Kontextdaten interessieren zu liefern Dieser kann relevanten Kontext von den verschiedensten Kontextquellen ermitteln und zusammenfassen Aus low level Kontext leitet der Kontextdienst h herwertigen Kon text wie Situationen Aktivit ten ab Diese werden auf Anwendungsschicht der Anwendung zur Verf gung gestellt Beim Kontextdienst werden alle Ger te mit ihrem Kontext registriert Er wird ber alle nderungen die den Kontext betreffen informiert Sie erlaubt es Anwendungen die an Kontextdaten interessiert sind sich f r Kontext nderungen anzumelden Die Anwendungen werden dann ber alle relevanten nderungen bez glich eines bestimmten Kontextattri butes oder einem h heren Kontextwert informiert Der Kontextdienst wird von verschiedenen Komponenten genutzt die Kontext ben tigen Die Rule Engine ist mit dem Kontextdienst verbunden um auf die Kontextdaten zuzu greifen di
39. stellt der Anwendung eine einheitliche Netzwerkschicht zur Verf gung Ger te die sich mit der Middleware verbinden wollen k nnen dies ber eine unterst tzte Netzwerkschnitt stelle tun Auf die verschiedenen Heimvernetzungsstandards wie UPnP HAVI Bluetooth Wlan oder andere Technologien zur Verbindung der Ger te auf Netzwerkschicht soll in dieser Arbeit nicht weiter eingegangen werden Es wird angenommen dass die Ger te auf Netzwerkschicht miteinander verbunden sind und die hier beschriebene Middleware ver 74 4 KONZEPTION bindet die beteiligten Ger te in der Anwendungsschicht des ISO OSI Schichten Modells 4 2 17 Plattform Das System lauft auf allen verbreiteten heterogenen Hardware Plattformen wie PCs Ein gebetteten Systemen Mobilen Ger ten Unterhaltungselektronik Ger ten Die Middleware l uft auf einer Virtuellen Maschine und ist so unabh ngig von einem bestimmten Betriebs system 4 3 Ontologien In diesem Abschnitt wird die Verwendung von Ontologien in der entworfenen Architektur beschrieben In den Ontologien werden die Konzepte des Smarthomes beschrieben dass heisst es wird der Kontext modelliert der zur Ausf hrung der Smarthome Anwendung be n tigt wird Dazu geh rt die Beschreibung der bergeordneten Dom nen Ontologie Diese enh lt die spezifischen Sub Ontologien zur Beschreibung von Ger ten den Nutzern und von Tasks Ein Ger t meldet sich beim Home Controller an und bermittelt Beschreibungsdate
40. und Men punkte ausgew hlt werden k nnen 6 Janet w hlt auf der Mikrowelle die Aktion Wohnungst r ffnen aus 7 Die Wohnungst r wird ge ffnet und der Nachbar betritt die Wohnung Die Szenarien beschreiben drei verschiedene Anwendungsbereiche Das erste Szenario steht stellvertretend f r die Anwendungsf lle in denen ein Ger t einen fehlerhaften Zustand hat Auf einem Ger t tritt ein Fehler auf und das Ger t l st daraufhin ein Freignis aus Diese Ereignisse k nnen entweder direkt auf dem Ger t angezeigt oder werden auf einem Ger t dargestellt werden welches sich der Wahrnehmung eines Nutzers beziehungsweise dem den das Freignis betrifft befindet Der Nutzer soll auf das Ereignis reagieren Dazu muss das Ereignis auf einem Ger t dargestellt werden auf dem der Nutzer auch f r ein anderes Ger t Interaktionen ausf hren kann z B TV So kann der Nutzer mit seinen Interaktio nen wahlweise von verschiedenen Ger ten aus auf ein entferntes Ereignis reagieren Das zweite Szenario beschreibt eine Situation in der ein Ereignis auftritt und vom System Regeln ausgef hrt werden um dem Nutzer m gliche Aktionen vorzuschlagen und diese automatisch auszuf hren wenn das den Pr ferenzen des Nutzers entspricht Das dritte Szenario beschreibt den Anwendungsbereich der Fernbedienungsfunktion Ger te werden aus der Ferne bedient Dazu werden auf einem Ger t die Steuerungsfunktionen dargestellt welche ben tigt werden um ein an
41. und zur Ausf hrung an das entfernte Ger t bermittelt werden Untersucht werden muss inwieweit und wie das bei existierenden L sungen funk tioniert Parameter und R ckgabewerte eines Dienstes werden mit in die Ger teontologie aufgenommen Diese Komponente wird von den anderen Komponenten als kontextabh ngiger Dienst ge nutzt 4 2 6 User Modeling amp User Profiling In dieser Komponente wird der Nutzer und seine Pr ferenzen modelliert In einem Nutzer modell werden die Daten zu einem Nutzer abgespeichert Diese wird in der Knowledge Base verwaltet Damit das System den Nutzer bestm glich unterst tzen kann muss das System Kenntnisse ber Eigenschaften Pr ferenzen und Gewohnheiten des Nutzers haben Dazu geh rt es unter Anderem die Interaktionsmodalit ten Eingabe und Ausgabemodalit ten mit denen der Nutzer mit einem System interagieren kann des Nutzers zu ber cksichtigen Diese h ngen vom jeweiligen Nutzer ab und k nnen im Vergleich zu einem angenommenen sterotypischen Normalnutzer eingeschr nkt sein So hat ein Nutzer der nicht sehen kann keine M glichkeit visuelle Inhalte wahrzunehmen und kann nicht mit grafischen Eingabe ger ten interagieren Es gibt vorgefertigte Modelle von stereotypischen Nutzern aus denen das Modell ausge sucht wird welches dem Nutzer am hnlichsten ist Des Weiteren gibt es vordefinierte Benutzerrollen wie Bewohner Familie Freund Nachbar Pflegepersonal usw Dazu wer den dem Nutzer
42. von folgenden Parametern ab e Wer ist der Eigent mer und wer ist der Nutzer des Ger tes e Wer darf das Ger t benutzen und wann in welchem Kontext e Wo befindet sich das Ger t e Was ist die Funktion des Ger tes e Welche Funktionen d rfen verwendet werden e Welche Inhalte stellt es dar e Wird ein Ger t gerade verwendet Kann es dann trotzdem f r eine andere Aufgabe genutzt werden Der Nutzer hat in dieser Sicht Bausteine aus denen er die Policen zusammensetzen kann Es werden ihm die einzelnen Ger te visualisiert deren Standort angezeigt mit welchen anderen Ger ten diese kooperieren k nnen In dem System sollen die Ger te so intelligent sein dass sie sich weitestgehend dem Be wusstsein des Nutzers entziehen Dazu muss das System ermitteln k nnen welche Ent scheidungen es dem Nutzer abnehmen kann und welche Entscheidungen der Nutzer aus schlie lich alleine treffen muss Ziel ist es die Balance zwischen Abstraktion der Ger te und ihren Funktionalit ten und der Kontrolle durch den Nutzer zu finden Die Integration eines neuen Ger tes vollzieht sich folgenderma en Der Nutzer m chte ein neues Ger t integrieren Dem Nutzer wird auf dem Home Controller angezeigt dass ein neues Ger t erkannt wurde Es werden die Funktionalit ten des Ger tes angezeigt und wie dieses mit dem bestehenden Ger ten kooperieren wird Nachdem ein Ger t zur Dom ne hinzugef gt wird kann es ab diesem Zeitpunkt vom System verwendet
43. vorgestellt Dann folgen die Kapitel zur Konzeption Vor stellung des Prototyps Verifikation der Konzeption und eine abschlie ende Zusammenfas sung 26 2 IDENTIFIKATION DER ANWENDUNGSDOMANE 27 3 Verwandte Arbeiten und existierende Technologien Diese Kapitel beschreibt existierende Technologien und verwandte Arbeiten die an dieser Stelle vorgestellt werden Im folgenden Abschnitt werden Begriffe Ontologien und Regeln eingefiihrt Im zweiten Teil wird auf verwandte Forschungsarbeiten im Bereich des Ubiqui tous Computing Smarthomes und kontextbewussten Infrastrukturen eingegangen 3 1 Ontologien und Regeln 3 1 1 OWL Die Web Ontology Language OWL 19 wird fiir die Beschreibung von Ontologien verwen det Eine Ontologie dient der Beschreibung von Begriffen und Relationen zwischen diesen Ein haufig zitiertes Zitat von Tom Gruber aus dem Jahr 1993 An ontology is a formal explicit description of concepts and relations in a do main of discourse including properties of each concept and constraints expres sed as axioms 10 Eine Ontologie ist eine formale und explizite Beschreibung von Konzepten und Beziehungen in einer Anwendungsdom ne und beinhaltet Attribute jeden Kon zeptes und Einschr nkungen die als Axiome dargestellt werden 10 Ontologien werden nach dem Level der Allgemeinheit Generality klassifiziert in Top Level Ontologien in Dom nen und Task Ontologien und in Anwendungsontologien Die Haupt
44. wird der Aufwand f r die Erstellung der Ontologien reduziert Eine intelligente Umgebung muss relevante Informationen ber die Vorg nge im Innern sammeln was als Kontext bezeichnet wird um kontextbewu tes Verhalten zu zeigen Be sonders relevant ist es die Kontextdaten des Nutzers zu erfassen Dazu geh ren der Auf enthaltsort des Nutzers seine Aktivit t und die Anwesenheit anderer Menschen Um zu ermitteln mit welchen Ger ten ein Nutzer interagieren kann muss die Position der Ger te bekannt sein und Kontextdaten ber deren Status wer das Ger t momentan bedient wer sich in der N he befindet und weitere sind von Nutzen Reasoning Die Reasoning Komponente schlussfolgert ber Kontext und leitet h herwertigen Kontext aus niederwertigen Kontextdaten ab Storage Die Storage Komponente k mmert sich darum die Kontextdaten in einer geeigneten Form abzuspeichern Es gibt eine Assoziation zur Knowledge Base und dort werden alle Kon textdaten als Individuen in den Ontologien abgespeichert Discovery Die Discovery Komponente ist daf r verantwortlich Kontext zu finden EventListener Der EventListener h rt auf Kontext nderungen und Ereignis nderungen und aktualisiert die modellierten Kontextdaten 4 2 14 Device Registry amp Classification Die Komponente Device Registration amp Classification verwaltet alle im System angemel deten Ger te und klassifiziert sie entsprechend der Ger tefunktionalit ten in die Ger
45. zu ermitteln und dann automatisch die geeigne ten Tasks anzubieten beziehungsweise auszuf hren Daf r soll eine Middleware geschaffen werden die es dem Nutzer erm glicht seine Intention auszudr cken die Ger tefunktio nalit ten zu verstehen und aus den Ger tefunktionalit ten und Ger tef higkeiten Orten Inhalten und Nutzerpr ferenzen dem Nutzer m gliche Tasks anzubieten Die L sung soll auf existierender Unterhaltungsger ten und der kommenden Jahre laufen Aus dem Anwendungsgebiet vernetzter Unterhaltungselektronik in einem Haus wurden folgende Aspekte extrahiert 1 Taskorchestrierung um einen Task auszuf hren m ssen mehrere Ger te kontrol liert und konfiguriert werden 2 Task Sitzung welche Ger te Einstellungen sind oder waren zusammen an einem Task beteiligt Dieser gemeinsame Zustand wird als Session bezeichnet 3 Ger tekollaboration Verwendung von verschiedenen m glicherweise inkompati blen Ger ten um einen Task auszuf hren Diese Ger te m ssen nahtlos im Haus zusammenarbeiten 4 Auswahl von Inhalten Suchen und Finden der Inhalte die ber das gesamte Haus Ger te und Verzeichnisse verteilt sind 3 2 VERWANDTE ANSATZE 33 Ermittlung der Nutzerabsicht Beispielsweise schaltet der Nutzer den Fernseher ein und legt eine DVD ein daraus wird dann geschlussfolgert dass er sich die DVD anschauen m chte Die Auswahl der m glichen Tasks wird von der Middleware Software auf einer einfachen pseudo
46. 0 3 Regel Konfliktmanager Wenn Konflikte zwischen verschiedenen ausl senden Regeln auftreten dann m ssen diese aufgel st werden So kann es sein dass im Aktionsteil einer Regel ein Ger t verwenden soll welches dann aber die Ausf hrung der anderen Regeln blockiert oder nur einen exklusiven Zugriff hat Soll beispielsweise ein Videorekorder von einer Videoquelle aufzeichnen dann kann das nur von einer Quelle zur gleichen Zeit erfolgen Das sind ger tenahe Regeln die von dem jeweiligen Ger t an das System bermittelt werden m ssen und die sich aus der Spezifikation des Dienstes ergeben Dazu haben die einzelnen Regeln eine Priorit t die ausgewertet wird Diese ist abh ngig von der Aktion die durch diese Regel ausgel st werden soll Des Weiteren h ngt die Prio rit t einer Regel von der Rolle des Nutzers ab f r den die Regel gefeuert wurde Aus der Rolle des Nutzers ergibt sich in welcher Reihenfolge Regeln ausgef hrt werden 4 2 10 4 Regel Entdecker Diese Komponente findet Muster im Nutzerverhalten mithilfe der frequent pattern dis covery 13 Wenn der Nutzer mehrfach dieselbe Aktion in einer bestimmten Situation ausf hrt dann wird das vom System erkannt und es generiert neue Regeln Regeln wer den entweder vom System gelernt oder direkt vom Nutzer oder Administrator eingeben Aus Nutzerentscheidungen und dem Nutzerverhalten werden Pr ferenzen abgeleitet die bei zuk nftigen Entscheidungen ber cksichtigt werden Dazu wi
47. Base Beispiele f r SWRL Regeln mit Vorbedingungen und einer Konsequenz Elternteil x y A Bruder y z Onkel x z Anruf x A Person y A hatAktivitat y schautTV A Videorekorder z gt hatStatus z aktiv Eine Beispielregel zur Demonstration eines Freignis das Interaktion ben tigt Haushalts ger t Wei e Ware und Status Fehler Interaktionsereignis gt ZeigeEreignisAufInterak tionsGeratAn Regelauswertung mit einer Rule Engine Die Rule Engine hat nun Zugriff auf das Ereignis und den aktuellen Kontext der die Situation der Anwendungsdom ne beschreibt Durch dieses Ereignis und den entspre chenden Kontext wird die Regel ausgel st die definiert dass bei einer Unterbrechung Anruf Ereignis steht in Ereignis Ontologie unter Unterbrechung und aktueller Aktivit t des Nutzers schaut TV das aktuelle Fernsehprogramm auf einem Videoaufnahme Ger t aufgezeichnet werden soll Wenn diese Regel ausgel st wird dann m ssen die ben tigten Parameter f r den auszuf hrenden Task VideoAufnahmeVonFernseher ermittelt werden Dazu werden vom Fernseher der aktuelle Fernsehsender ausgelesen Dieser Fernsehsender wird vom Videoaufnahme Ger t aufgezeichnet bis der Nutzer ohne Unterbrechung weiter schauen kann und m chte Die Komponente Rule Engine wird als Dienst in OSGi implementiert und beim Home Controller registriert Sie greift auf den Dienst Knowledge Base zu um Konzepte zu holen die f r das logische Schlu folgern be
48. Bewohner Kommuniziert mit fernzusteuerndem Ger t en 1 Der Bewohner ruft das Auswahlmen zur Fernsteuerung eines Ger tes auf 2 System zeigt vorhandene Ger te an 3 Der Bewohner w hlt ein Ger t aus der Liste aus 4 Das System ruft die Kontrollfunktionen des Ger tes ab 5 Das Ger t schickt seine Kontrollfunktionen an das Sy stem 6 Das System leitet die Kontrollfunktionen an das Ger t weiter das die Aufmerksamkeit des Bewohners hat 7 Dieses Ger t zeigt die Kontrollfunktionen an 8 Der Bewohner w hlt eine Kontrollfunktion aus und stellt Parameter ein 9 Das System bermittelt diese Kontrollfunktionen und die Parameter an das Ger t 10 Das Ger t f hrt die Kontrollfunktionen aus 11 Das System zeigt dem Nutzer eine R ckmeldung ber die ausgef hrte Aktion an Anfangsbedingungen Es muss ein Ger t vorhanden sein welches ferngesteuert werden kann Abschlussbedingungen Der Bewohner hat eine Best tigung ber die Ausf hrung einer Funktion erhalten Qualit tsanforderungen Der Bewohner erh lt die gew nschte Best tigung innerhalb von 5 Sekunden 16 IDENTIFIKATION DER ANWENDUNGSDOMANE Anwendungsfall 3 Anwendungsfallname Pr sentation von Informationen Akteure Bewohner Anrufer Ger t 1 Der Anrufer ruft den Bewohner auf einem Ger t an 2 Das Ger t meldet das Ereignis an das System 3 Das System sucht ein Ger t das die Aufmerksamkeit des Bewohners hat und welches dieses Ereignis a
49. Feuchtigkeit CO2 Ortssensoren Nutzeraktivit teninformationsprovider Der Informationsaustausch zwischen Kontextquellen und kontextabh ngigen Diensten erfolgt in AMIGO ber Webservice Technologien Beispiel der Regel Maria m chte benachrichtigt werden wenn ihre Kinder mit Freunden nach Hause kommen Upon EnterTrue Pablo isAtHome OR EnterTrue Roberto isAtHome When Pablo isAtHome AND Pablo withFriends OR Roberto isAtHome AND Roberto withFriends Do Notify Maria kids are home with friends 3 2 VERWANDTE ANSATZE 37 3 2 3 Nahtlose Integration von Ausgabegeraten In dem Projekt 5 wird eine Infrastruktur vorgestellt mit der multimediale Ausgabeger te nahtlos in eine intelligente Umgebung integriert werden und die Ausgabe optimiert wird hinsichtlich der Ger tef higkeiten und der momentanen Aufgabe des Nutzers Die Koor dination der Ausgabeger te erfolgt basierend auf deren Selbstbeschreibung Als Anwen dungsbeispiel dient ein intelligentes Wohnzimmerszenario zur Validierung der Ergebnisse Anforderungen an eine solche Infrastruktur sind die dynamische Verbindungsf higkeit von Ger ten adaptive Benutzerschnittstellen und Darstellungen und die Darstellung von Aus gaben auf mehreren Ger ten zur gleichen Zeit Die Infrastruktur basiert auf einer Schichtenarchitektur mit der physischen Verbindungs schicht als Basis Darauf setzt die abstrakte Verbindungsschicht auf die sich um das dy namische Auffinden von Ger te
50. Nach Kokar in 15 ist es unm glich eine generische Ontologie f r alle m glichen Anwendungsf lle zu modellieren Es sollte eine eigene Ontologie mit anderen verf gbaren Ontologie erweitert und vereinigt werden ontology alignment 7 Mit Ontologien erh lt man eine formale Darstellung des Kontextes und somit k nnen Methoden zum logischen Schlie en auf den Kontextdaten angewendet werden 27 Laut der Autoren ist das Neue an ihrem Ansatz dass sie die Semantic Web Rule Language SWRL f r das Schlie en auf Kontextdaten verwenden SWRL verfolgt als Ziel die Kom bination von OWL und einer Schlussfolgerungssprache basierend auf RuleML Mit SWRL kann eine verbreitete Sprache f r das Kontextmodell OWL und das logische Schlie en SWRL verwendet werden Sie denken dass logisches Schlie en auf Kontextdaten noch nicht sehr entwickelt ist aber sehr wichtig ist um damit besser an den Nutzer adaptierte Dienste anzubieten Kontextabh ngige Inferenzregeln Mit der M glichkeit des logischen Schlie ens kann eine K nstliche Intelligenz Schicht in die Systemarchitektur eingef gt werden und high level Kontext aus low level Kontext ab geleitet werden Es gibt zwei Arten von Regeln e Backchain rules Beschr nkungen direkt auf er OWL Ontologie Diese Regeln werden direkt in den OWL Dateien beschrieben Forwardchain rules Mit Ausdr cken der Art wird auf Axiomen geschlussfol gert Beispiele f r Forwardchain Regeln Lich
51. RDF Beschreibungen werden mit der Rule Engine JESS Java Expert System Shell 9 verarbeitet Zur Unterst tzung von UPnP Ger ten gibt es Plugins Das Fernsehger t ist die Kontrollstelle f r das Auffin den und die Kontrolle der UPnP Ger te Jedes Ger t verwaltet seine Ger te und Task Beschreibungen w hrend der Auffindungsphase werden URLs dieser Beschreibungsdateien an das Fernsehger t bermittelt 3 2 2 AMIGO Das AMIGO Projekt 16 mit dem vollen Namen Ambient Intelligence for the networked home environment ist ein Projekt der Europ ischen Union und f nfzehn der f hrenden Europ ischen Industriepartner Mehr Informationen dazu gibt es unter Start war im September 2004 und die Dauer des Projektes betr gt 42 Monate Amigo soll das volle Potenzial von Heimnetzwerken aussch pfen um so das Leben der Bewohner zu verbessern und soll dann in Richtung Ambient Intelligence gehen In diesem Ansatz soll eine Middleware L sung entwickelt werden die die bisher getrennten Dom nen Mobile Ger te PCs Heimautomatisierung Unterhaltungselektronik vereinigen Bisher nttp www hitech projects com euprojects amigo project_information htm 36 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN wurde das Potenzial der Heimvernetzungstechnologie noch nicht entfaltet da es kein kon sistentes Framework fiir Heimsysteme gibt Hauptprobleme sind bisher e Die Usability des Systems Gerate Infrastruktur und Dienste e Der Mang
52. TECHNISCHE UNIVERSITAT DRESDEN FAKULTAT INFORMATIK INSTITUT FUR SYSTEMARCHITEKTUR PROFESSUR RECHNERNETZE PROF DR RER NAT HABIL DR H C ALEXANDER SCHILL Diplomarbeit zur Erlangung des akademischen Grades Diplom Medieninformatiker Eine Middleware fiir die nahtlose Integration und Kooperation von Geraten Roman Wilkowski Geboren am 8 Oktober 1979 in Berlin Betreuer Herr Dr Ing Waltenegus Dargie Dresden 21 Januar 2008 Aufgabenstellung Ziel Im Umfeld des Ubiquitous Computing sind Gegenst nde so intelligent dass sie sich der Aufmerksamkeit des Benutzers entziehen und den Menschen bei seinen Tatigkeiten unbe merkt unterst tzen Der Benutzer interagiert m helos und ohne sich dessen bewusst zu sein mit einer Vielzahl an unterschiedlichen Ger ten mobil eingebettet station r und kann so seine Aufmerksamkeit auf die wesentlichen Aufgaben richten Ubiquitous Computing setzt die dynamische Integration und Kooperation von Ger ten voraus Durch die dynamische und nahtlose Integration von Ger ten und Ressourcen wird der Um gang mit der Technik intuitiver und in Zusammenarbeit mit Kontextbewusstsein Context Awareness kann so insbesondere lteren Menschen ein unabh ngigeres Leben erm glicht werden Das Ziel dieser Diplomarbeit ist es ausgew hlte Konzepte des Ubiquitous Computing und der Context Awareness zu untersuchen Dabei soll deren Umsetzung besonders lteren Menschen in ihrer Wohnumgebung und der
53. TextRenderer sein Prot g ist ein freier Open Souce Ontologie Editor und ein Wissensbasiertes Framework der vom St anford Center for Biomedical Informatics Research an der Stanford University School of Medicine entwickelt wurde Fiir mehr Informationen siehe http protege stanford edu 5 1 KLASSIFIKATION VON GERATEN UND EREIGNISSEN 81 7 Motion Temperature shwasher uont Refridgerator washingMachine SensorsActuators interactionDevice _ wnhiteGoods OutputDevice OAvailableDeviceForShowingEvent ev eae ainmentElectronics ah InputDevice Br 4 er SonyEricssonCellphone 8 commnicatonEkctonts luetoothEnabledCellphone DVDPlayer NokiacellPhone aii Stereo SecurityCameras dHeating Abbildung 5 1 Ger teontologie TextRecorder AudioRecorder VideoRenderer vVideoRecorder AudioRenderer DeviceCapabilities Renderer Bu TextRenderer SpeechRecorder AudioProvider ontentProvider SpeechRenderer vVideoProvider SpeechProvider OT xtProvider Abbildung 5 2 Ger tef higkeiten Device Capabilities 82 5 IMPLEMENTIERUNG Somit muss es keine Regel fiir den Videorekorder und den Fernseher geben sondern nur fiir die bestimmten Konzepte also den Dienst Dieser Dienst kann von unterschiedlichen Ger ten implementiert werden Ein VideoR
54. WANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN Ereignisse werden beim Erscheinen und Verschwinden von Bundles ausgel st Dienste werden durch Java Interface spezifiert Bundles implementieren dieses Interface und registrieren den Dienst bei der Service Registry Clients dieses Dienstes finden die sen in der Registry oder reagieren darauf wenn er erscheint oder verschwindet Das ist vergleichbar zur Service Orientieren Architektur bei Web Services Diese kommunizieren allerdings auf der Transportschicht und sind dadurch viel langsamer als OSGi Services die direkte Methodenaufrufe verwenden Die Basis Software Komponenten sind Service Bundles Ein Bundle besteht aus dem Service Interface einer Implementierungsklasse und einer Activator Klasse Das Service Interface legt fest welchen Dienst diese Komponente bereitstellt und die Implementierungsklasse enth lt die Implementierungsdetails Die Activator Klasse wird vom Framework genutzt zum Starten und Stoppen des Service Bundles und zum Registrieren und Deregistrieren von Services Das OSGi Framework ist die Laufzeitumgebung f r die Komponenten Es regelt den Lebenszyklus der Bundles l st Abh ngigkeiten zwischen Bundles auf hat eine Registry zur Verwaltung der Dienste und bietet eine Kommunikationsplattform f r die Kommunikation zwischen den Bundles Besonderes Merkmal ist die dynamische Umgebung dass hei t OSGi Komponenten k n nen zur Laufzeit heruntergeladen installiert aktualisier
55. arthome L sungen verwendet wird On tologien eignen sich am Besten um die Konzepte einer Anwendungsdom ne zu beschreiben und soll in diesem Ansatz verwendet werden Besonders das Forschungsprojekt AMIGO hat viele interessante Punkte die mit meinem Ansatz bereinstimmen Das Konzept welches ich aus den hier gewonnenen Kenntnissen entwickelt habe wird im Kapitel 4 vorgestellt 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN 49 4 Konzeption F r die Anforderungen die w hrend der Anforderungsanalyse ermittelt wurden siehe Ka pitel 2 soll eine L sung entwickelt werden In diesem Entwurf soll nicht auf Aspekte ein gegangen werden die von Middleware L sungen auf niedrigerem Level abgedeckt werden wie Interoperabilit t zwischen verschiedenen Ger ten und Anwendungen und Protokol len Service Discovery Sicherheit und Skalierbarkeit Diese Arbeit legt den Schwerpunkt auf Softwaredienste in h heren Schichten die auf basierenden Infrastrukturen aufbauen und den Nutzern Funktionalit ten zur Verf gung stellen 16 Es wird die Vorgehensweise beschrieben die zu dem hier dargestellten Konzept gef hrt hat Dabei werden verschiedene L sungsans tze aufgef hrt und begr ndet wie sich die konkrete Entwurfsentscheidung durchgesetzt hat Die Konzeption wird aus einer relativ abstrakten Sicht beschrieben auf die Implementierungsdetails wird in Kapitel 5 eingegangen Daf r m ssen die Funktionalit ten abstrahiert werden und ei
56. charakteristiken von Ontologien sind e Teilen des allgemeinen Verst ndnisses einer Informationsstruktur zwischen Menschen und Softwareagenten e Erm glichen die Wiederverwendung von Dom nenwissen e Erm glichen Annahmen von expliziten Dom nen e Trennung des Dom nenwissens von dem operationellen Wissen Durch die Nutzung von Ontologien ergeben sich die folgenden Vorteile Intelligenteres Ver halten Flexibilit t Wiederverwendbarkeit und semantische Interoperabilit t Mit Onto logien ist auch die Beschreibung von Webservices m glich Agenten entdecken diese auto matisch und greifen darauf zu Es k nnen damit die Schnittstellen die Parameter und die Funktionalit t beschrieben werden 28 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN 3 1 2 Semantic Web Rule Language SWRL Die Semantic Web Rule Language SWLR 14 ist ein Vorschlag fiir eine Regelsprache zur Beschreibung des Semantic Web welche die Untersprachen von OWL OWL DL und OWL Lite kombiniert mit denen der Rule Markup Sprache RuleML Die Regeln entsprechen der Form Vorbedingung antecedent Konsequenz consequent Wenn alle Vorbedingungen erf llt sind dann ergibt sich daraus die Konsequenz Eine Bei spielregel in menschenlesbarer Syntax lautet wie folgt hatEltern x y A hatBruder y z hatOnkel x z 3 1 3 Context Awareness Eine der am h ufigsten zitierten Definitionen f r Kontext stammt von Anind K Dey Context is any information tha
57. chen Szenarien m ssen im Vorfeld definiert werden In dieser Arbeit soll eine Middleware entwickelt werden die verschiedenste Ger te inte griert Dazu wird auf die folgenden Fragestellungen eingegangen Wie k nnen heterogene Ger te miteinander kooperieren Welche Regeln und Policen sind daf r n tig 1 3 L sungsansatz Damit sich heterogene Ger te verschiedener Herstellern verst ndigen k nnen wird eine abstrakte Sprache zur Beschreibung der Ger te ihrer Funktionalit ten und Dienste ben tigt Daf r eignet sich die Web Ontology Language OWL Mit diesem ontologie basierten Ansatz k nnen die Ger te Regeln und Policen formal und maschinenlesbar spezifiziert wer den Die einzelnen Ger te die im Haushalt vorkommen werden abstrakt in einer Ontologie beschrieben und als Dienste umgesetzt Die Ger te sind vollst ndig in die Middleware integriert nachdem sie sich mit einer Selbstbeschreibung ihrer F higkeiten und Dienste angemeldet haben Zur Umsetzung dient eine serviceorientierte Architektur SOA Das System ben tigt Kenntnisse ber die Pr ferenzen und die aktuelle Situation des Nutzers Hierf r ist die Erfassung des Kontextes und das logische Schlussfolgern auf dem Kontext entscheidend Diese Aufgabe wird von einem Kontextdienst bernommen Ein interessanter Aspekt der ber die Aufgabenstellung dieser Arbeit hinausgeht ist unter anderem die Fragestellung wie sich die Funktionalit ten der vernetzten Ger te dynamisch in
58. d die W nsche des Nut zers ber cksichtigen Dem Nutzer werden nur die Tasks angeboten die zu dem aktuellen Zeitpunkt m glich sind Dies ist notwendig da das System dem Nutzer das Leben er leichtern soll Dieser Automatismus kann den Nutzer irritieren Zu einem Zeitpunkt wird eine Sendung aufgezeichnet wenn jemand anruft Beim n chsten Mal nimmt der Videore korder gerade eine andere Sendung auf und der Tasks VideoaAufnehmen wird nicht mehr angeboten Im Folgenden wird beschrieben wie die m glichen Tasks ermittelt werden Ein Task ist die rechte Seite einer Regel der Form Bedingung gt Task Jedem Task ist ein Subjekt has Subject Subject Content und eine Ressource requiresResource Device zugeordnet Das Subjekt ist der Inhalt der dargestellt werden soll oder von dem eine Aufgabe ausgeht Die Ressource ist ein Ger t welches ben tigt wird um den Task auszuf hren Anhand des folgenden Beispiels werden die Bestandteile eines Task gezeigt Der Hausbe wohner sitzt vor dem Fernseher und schaut sich eine interessante Sendung an Jemand ruft an Falls Videoaufnahmeger t aktiv ist wird das aktuelle TV Programm von diesem Ger t aufgezeichnet Task TVProgrammAufVideoRekorderAufnehmen Bedingung Anruf und Person sieht fern und Videorekorder aktiv Anruf Telefon klingelt Kontextdienst erh lt den Wert Telefon wird angerufen PersonSiehtFern Person und Aktivit t sitzt vor TV und TV aktiv AufnahmeVideoQuelle aufne
59. den Termin erinnert Au erdem ist abzusehen dass ein solches System nicht in jeder Situation die korrekte Ent scheidung treffen kann vgl 29 Das wirft wiederum die Frage auf ob der Nutzer irritiert wird wenn er nicht mehr jede Entscheidung nachvollziehen kann Ein weiterer Aspekt der nicht betrachtet wurde ist der der Privatssph re In diesem Bereich ist noch viel Forschungsarbeit erforderlich damit solche L sungen in der Praxis eingesetzt und von der Nutzergruppe akzeptiert werden Momentan gibt es mehrere gro e EU Projekte die sich mit Smarthomes auseinandersetzen Es kann davon ausgegangen werden dass die Mehrheit der Bev lkerung in den n chsten Jahren von der Unterst tzung der ubiquit ren Technik profitieren wird wenn diese finan zierbar geworden ist Als Ausblick bleibt die Umsetzung der Aufgabe Policies vollautomatisch zu lernen in Regeln zu transformieren und auch vollkommen unbekannte Ger te und Ressourcen auto matisch in das System zu integrieren damit sie miteinander kooperieren k nnen Dabei ist zu gew hrleisten dass der Nutzer jederzeit alle Prozesse im Innern des Systems nachvoll ziehen und das Systemverhalten beliebig abschalten oder dynamisch ndern kann 98 Literaturverzeichnis 1 2 3 4 5 6 7 8 9 10 ABOWD Gregory D DEY Anind K BROWN Peter J DAVIES Nigel SMITH Mark STEGGLES Pete Towards a Better Understanding of Context and Co
60. deres Ger t zu bedienen Beispiel ffnen der Wohnungst r ber ein Men auf der Mikrowelle 2 2 Anwendungsf lle Aus den Szenarien wurden Anwendungsf lle identifiziert welche n her betrachtet und von der zu entwickelnden Middleware L sung umgesetzt werden sollen Die Abbildung 2 1 zeigt die Kommunikationsbeziehungen zwischen den Akteuren Nutzer und System und den Anwendungsf llen die erfasst werden sollen In diesem Diagramm werden abstrakte Anwendungsf lle dargestellt die als Oberklassen der konkreten Anwendungsf lle dienen So m ssen nicht alle Anwendungsf lle die in einem Smarthome auftreten k nnen erl utert werden Auf der linken Seite ist der Akteur Nutzer dargestellt der mit den verschiedenen An 2 2 ANWENDUNGSFALLE 13 System participate N initiate initiate EN ren System nn participate Nutzer u participate initiate Abbildung 2 1 Kommunikationsbeziehungen zwischen Anwendungsfalldiagrammen wendungsf llen interagiert Auch das System ist als Akteur dargestellt der an den An wendungsf llen partizipiert und f r deren Umsetzung weitere Anwendungsf lle initialisiert und ausgef hrt werden Wird ein Ereignis im System ausgel st dann wird der Anwendungsfall Anzeige von In formationen gestartet Dem Nutzer werden die Informationen auf einem beliebigen Ger t dargestellt Der Anwendungsfall Anzeigen von Aktionen ist als Erweiterung von Anzeige vo
61. die der Nutzer versteht und leicht zu definieren sind oder ausw hlbar sind in Regeln die vom System verstanden werden Ebenfalls m ssen Ger te die mit einer Ontologiesprache beschrieben werden f r den Nutzer in eine verst ndliche Form gebracht werden Der Nutzer muss die Funktionalit t eines bestimmten Ger tes leicht ablesen k nnen Dem Nutzer soll verdeutlicht werden welche Ger te sind vorhanden und welche Aufgaben ergeben sich daraus Die gesamte Situation des Nutzers mit seinem Kontext wird dem Nutzer verst ndlich dargestellt so dass er Regeln daf r definieren kann 4 2 10 8 Regelersteller Mit einem Regelersteller Rule Builder erzeugt ein Nutzer Regeln Regelsprachen sind nicht einfach zu verstehen und aus diesem Grund muss es f r den Nutzer eine einfache Be nutzeroberfl che geben mit der Regeln erstellt werden k nnen In 30 werden zwei Proto typen eines Rule Builder beschrieben Der erste Prototyp bietet eine graphische Repr sen tation des JESS Regelkonzeptes Der zweite Prototype basiert auf einem Beispiel basierten Ansatz der Puzzle hnliche Teile verwendet Der Nutzer kopiert einfach existierende Re geln die vom Entwickler vordefiniert wurden oder teilweise vom RuleDiscoverer empfohlen wurden und passt diese an Jeder Nutzer hat ein sehr unterschiedliches Verhaltensmuster und daher wird vom Nutzer erwartet dass er das Systemverhalten durch Hinzuf gen oder Entfernen von Bedingungen und Aktionen modifiziert
62. die einzige Komponente mit dem Zugriff auf externe Netzwerke Die einzelnen Ger te die als Dienste angemeldet sind stellen eine Anfrage an den HomeCon troller wenn sie Zugriff auf Web Services ben tigen und der HomeController koordiniert diese Anfragen und leitet sie an das Residential Gateway weiter Ein Ger t enth lt in sei nen Ger tedaten eine semantische Beschreibung des Ger teherstellers Bei Anfragen und Problemen wird die Hersteller URL aufgerufen und eine Problembehandlungsstragie herun tergeladen Falls keine Probleml sung durch den Nutzer erfolgen kann und der Nutzer eine Terminkalenderanwendung besitzt dann kann diese Termine mit einem externen Dienst leister ausmachen Beliebige Termine Arzttermine Reisetermine etc k nnen vereinbart werden wenn die Anbieter die entsprechenden Schnittstellen unterst tzen und diese se mantisch beschrieben haben Desweiteren k nnen ber das Gateway aktuelle Reise und Wetterdaten abgerufen werden Die Kommunikation mit den externen Diensten erfolgt ber Semantische Web Services 8 Der Zugriff auf den HomeController per Webinterface wird ber das Residential Gateway realisiert Der Nutzer muss in seinen Policen genau festlegen welche Dienste externe Web Services aufrufen und Daten nach au en schicken d rfen Die einzelnen Anwendungen m ssen konfigurierbar sein damit anwendungsspezifische Policen einstellbar sind Der Nutzer ist im Fehlerfall eines Ger tes daran interessiert dass ei
63. dung zwischen der Mikrowelle und der T rwechselsprechanlage auf 7 Auf der Mikrowelle werden m gliche Aktionen angezeigt die in dieser Situation ausgef hrt werden k nnen 8 Die Bewohnerin m chte den Nachbarn einlassen und w hlt die Aktion Offne Wohnungst r aus siehe Anwen dungsfall Steuere Ger t fern 9 Das System ffnet die Wohnungst r und der Nachbar kann die Wohnung betreten 10 Das Anzeigefenster auf der Mikrowelle wird geschlossen Anfangsbedingungen Es muss ein Ger t vorhanden sein auf dem der Bewohner in formiert werden kann Der Bewohner muss erreichbar sein Abschlussbedingungen Der Nutzer wurde ber das Ereignis informiert und es wurde Qualit tsanforderungen eine Auswahl an Aktionen angezeigt Dem Nutzer wird die Information ber das Ereignis innerhalb von 1 Sekunde angezeigt 18 2 IDENTIFIKATION DER ANWENDUNGSDOMANE Anwendungsfall 5 Anwendungsfallname L se Aktion aus Akteure Bewohner Ger t Ereignisfluss 1 Ereignis tritt auf 2 Das System zeigt auf einem Ger t m gliche Aktionen an Anzeigen von m glichen Aktionen 3 Der Bewohner w hlt eine Aktion aus Ausw hlen einer Ak tion 4 Der Bewohner startet die Ausf hrung der Aktion Ausf h ren einer Aktion 5 Das System f hrt die Aktion aus 6 Das System informiert den Bewohner ber die korrekte Ausf hrung der Aktion oder ber Ausf hrung mit Fehler Anfangsbedingungen Es muss ein Ger t vorhanden sein
64. e 4 2 10 6 Regelbasis au ee EL eee 4 2 10 7 Regel bersetzer 66 4 2 10 8 66 4 2 10 9 Regel Inspektor 66 4 2 10 10 Regel Debugger 67 4 2 11 67 4 219 Ereignis Manager a Era Aal 68 A 213 COMTEX Service ne a NR 70 4 2 14 Device Registry amp Classification 71 4 2 14 1 Device Registry iocs a dan idi ara 71 4 2 14 2 Device 1 72 4 2 14 3 Semantic Service 73 4 2 15 Privatssph ren Manager 73 4 2 16 Netzwerkabstraktionsschicht 73 4 2 17 Plattform 2 22 34 em 74 4 3 ee eee ee 74 4 3 1 Dom nen Ontologie 74 4 3 2 75 4 3 3 Nutzerontologie 22 CC ron rennen 75 43 4 Taskontol gie oa 2 0 2 Fr ana dam Dee 75 44 Entscheidungsb ume 75 4 5 Zusammenfassung 77 Implementierung 79 5 1 Klassifikation von Ger ten und Ereignissen 79 5 1 1 Repr sentation der Konzepte in einer Dom nenontologie
65. e Entscheidungen die aus vielen Einzel entscheidungen bestehen zu modellieren 78 4 KONZEPTION 79 5 Implementierung Dieses Kapitel stellt den Prototypen vor der w hrend dieser Diplomarbeit entwickelt wur de Der Prototyp soll die Machbarkeit einzelner Konzepte demonstrieren Desweiteren hilft der Prototyp dabei sich ber ben tigte Funktionalit ten des Systems bewusst zu werden Es ist ein vertikaler Prototyp ein vertikaler Schnitt durch das System der alle Funktio nalit ten von der obersten Schicht bis zur untersten Schicht ber cksichtigt Der Prototyp setzt das Szenario Anzeige einer Fehlermeldung auf einem beliebigen Ger t welches die Aufmerksamkeit von Janet hat aus dem Abschnitt 2 1 um Die daran betei listen Komponenten und Ger te werden als OSGi Bundles umgesetzt Das sind der Home Controller ein Videorekorder ein Fernseher und ein Telefon Jedes dieser Ger te wird auf seine Wesentlichen hier ben tigten Funktionalit ten reduziert F r jedes Ger t wurde eine grafische Benutzerschnittstelle programmiert welches die Interaktion mit dem Ger t er m glicht Das Telefon zeigt den Namen eines Anrufers an und es gibt einen Button zum Anrufen Der Fernseher zeigt den aktuell eingestellten Sendernamen an und die eingestellte Lautst rke Der Nutzer kann einen anderen Sender einschalten und die Lautst rke ver n dern Der Videorekorder zeigt den Sendernamen an der eingestellt ist Zus tzlich zeigt er den aktu
66. e Regeln die vom Nutzer auf hohem Level parametrisiert werden um damit das Systemverhalten auf den tieferen Schichten zu definieren Sie sind relativ starr und k nnen nur das Systemverhalten der unteren Regelschichten anpassen und kontrollie ren wenn dieses von den Ger ten angeboten wird Der Nutzer definiert so was erlaubt ist und wie und was nicht Policy is an emerging technique for controlling and adjusting the low level sy stem behaviors by specifying high level rules 24 Police ist eine aufkommende Technik f r die Kontrolle und Anpassung von low level Systemverhalten durch das Spezifizieren von high level Regeln 24 4 1 REGELN UND POLICEN 51 Es wird unterschieden zwischen ger tebezogenen Policen und nutzerbezogenen Policen Ger tebezogene Policen haben auf die Ger tefunktionalit t bezogen eine h here Wertig keit als die nutzerbezogenen Policen dass hei t der Nutzer kann keine Werte einstellen die vom System oder von einem Ger t nicht unterst tzt werden Anders ausgedr ckt der Nutzer legt das bergreifende Systemverhalten fest dabei st tzt sich das System aber auf die ger tebezogenen Policies Nutzer parametrisieren somit die Bedienung die zur Verf gung steht Beispielsweise legt der Nutzer fest bei bei welcher Temperatur sich ein Ger t einschaltet oder um welche Uhrzeit er geweckt werden m chte Allerdings kann der Nut zer die Zentralheizung nicht auf 500 Grad Celcius schalten sondern nur innerhalb d
67. e ben tigt werden Wenn die Rule Engine Anbindung an die RuleEngine zur bermittlung s mtlicher ben tigter Kontextdaten Anwendungen registrieren Regeln die spezifizieren bei welchen nderungen des Kontextes sie benachrichtigt werden sollen Modelling Von den erfassten Kontextdaten werden Instanzen zu den Konzepten im Kontextmodell erzeugt Das ontologiebasierte Kontextmodell enth lt eine Beschreibung der Dom ne und eine Beschreibung der Ger tefunktionalit ten Eine Ontologie wird verwendet weil diese eine bessere Interoperabilit t zwischen verschiedenen Anwendungen bietet Desweiteren hat eine Ontologie eine h here Aussagef higkeit als andere Ans tze zur Kontextbeschrei bung siehe Unterabschnitt 3 1 1 Es wird dem Vorschlag von 4 11 gefolgt und ein mehr schichtiger Ansatz gew hlt mit einer oberen Ontologie und mehreren dom nenspezifischen Ontologien Die dom nenspezifische Ontologien beschreiben in dieser Arbeit die Wohnum gebung den Nutzer die Funktionalit t der Ger te und Tasks siehe Abschnitt 4 3 F r das hier zu verwendene Kontextmodell werden bereits existierende Ontologien wie derverwendet und erweitert Hier wird die CONtext Ontology CONON und die Home 4 2 ARCHITEKTUR 71 Domain ontology wiederverwendet Diese Ontologien beschreiben alle Aspekte der Woh numgebungsdom ne Es werden bereits existierende Ontologien die die Smarthome Dom ne beschreiben aus dem AMIGO Projekt wiederverwendet Damit
68. ealisiert die ber heterogene Netzwerke verteilt werden k nnen und miteinander interagieren k nnen Die Komponenten sind in Java implementiert und ben tigen nur eine Java Virtual Machine in der sie laufen Die Kommunikation zwischen den verteilten Komponenten erfolgt ber Java RMI SOCAM wird in die OSGi Diensteplattform integriert um damit ein zuverl ssiges sicheres System zu bauen dass kontextabh ngige Dienste in einem Smarthome anbietet Jede Komponente wird als separates Bundle realisiert Kontextmodellierung Da es schwierig ist Kontextwissen zentral zu verwalten und zu verarbeiten in einer Pervasi ve Computing Environment wird hier ein hierarchischer Ansatz verwendet Dabei werden die Kontextontologien in eine allgemeine High level Ontology und domain spezifische On tologien unterteilt Die High Level Ontologie definiert die generellen Informationen ber die physische Welt einer Pervasive Computing environment dass sind Basiskonzepte von Person Location Computational Entity und Activity wie auf Abbildung 3 5 zu sehen ist Die Details dieser Basiskonzepte und deren Eigenschaften in jeder Subdom ne Heim B ro oder Fahrzeug werden in dom nenspezifischen Ontologien definiert Dadurch wird die Menge an Kontextwissen erheblich reduziert und die Kontextverarbeitung vereinfacht Der gr te Vorteil des hierarchischen Ansatzes ist dass er Reasoning erlaubt OWL wird verwendet weil es ausdrucksf higer ist als zum Beispiel RDF K
69. edlichsten Ger te und Anwendungen angepasst werden Das Ziel ist eine optimierte Benutzerschnittstelle die dynamisch an die Nutzerpr ferenzen das jeweilige Endger t dessen Darstellung und Performance angepasst wird Diese Komponente soll festlegen wie die Funktionalit t von verschiedenen Ger ten am Besten auf einem Ger t integriert und dargestellt wird Nachdem das System ein Ge r t f r die Interaktion mit dem Nutzer ausgew hlt hat welches die Aufmerksamkeit des Nutzers hat erfolgt die Adaption der abstrakten Benutzerschnittstelle an das ausgew hlte Ger t Diese Komponente arbeitet mit der Nutzermodellierungskomponente und der Context Ser vice Komponente zusammen da bei der Adaption von Modalit ten immer die Nutzerei genschaften und Nutzerpr ferenzen ber cksichtigt werden Die Benutzerschnittstelle passt sich an den Kontext des Nutzers an dass hei t an seinen Ort das Interaktionsger t oder seine Behinderungen 6 Diese Komponente nutzt Kontex tinformationen um die Abpassung an den Nutzer vorzunehmen In Abh ngigkeit von der T tigkeit des Nutzers und seiner Situation wird die Ausgabemodalit t und die Eingabemo dalit t angepasst Die Eingabe des Nutzer kann per Tastatur Maus Stift Spracheingabe oder irgendeine andere Eingabeschnittstelle erfolgen Die Nutzung diverser Eingabemetho den wird durch die aktuelle Aktivit t des Nutzers eingeschr nkt Ein Nutzer der gerade kocht kann nicht oder nur schwer per Tastat
70. eift darauf zu um dem Nutzer m gliche Tasks anzubieten 4 4 Entscheidungsb ume Entscheidungsb ume Decision trees werden verwendet um komplexe Entscheidungsab folgen zu modellieren In Abbildung 4 3 ist ein Entscheidungsbaum f r das Ereignis dass die Waschmachine nicht abpumpt abgebildet 76 4 KONZEPTION Yes interagiere mit Gerat Label Yes WM pumpt nicht ab No Label Kann Ereignis auf diesem Ger t anzeigen Ger t in der Nahe vorhanden Informiere Handler Problem ist schwierig Zeige Ereignis an x Gerat in der Nahe vorhanden Kann Ereignis auf diesem Ger t anzeigen Perfekt dann Wasser abstellen Yes Informiere Yes Jemand da der helfen kann Problem kann von Bewohner selber gel st werden Yes No Bewohner hat verstanden Yes Erkl re dem Bewohner was zu tun ist Bewohner braucht Hilfe Abbildung 4 3 Beispiel eines Entscheidungsbaums 4 5 ZUSAMMENFASSUNG 77 4 5 Zusammenfassung Dieses Kapitel hat die Konzeption der Architektur vorgestellt Die prototypische Umset zung dieser Architektur mit den ben tigten Komponenten wird in Kapitel 5 beschrieben Es wurde desweiteren vorgestellt wie die Middleware Regeln und Policen einsetzt um da mit die Koooperation und Integration von Ger ten zu erm glichen Entscheidungsb ume werden kurz gezeigt als Methode um kompliziert
71. el an gen gend attraktiven Diensten Dem Nutzer fehlt der Vorteil durch die Nutzung e Die Kosten sind hoch da diese Technologien noch eine geringe Marktverbreitung haben Anforderungen an das System sind e F r die Usability muss die Benutzerschnittstelle einfach vertraut robust sein und den Datenschutz und Sicherheit einhalten e Interoperabilit t durch Middleware Standards die funktionale Interoperabilit t auf der Anwendungsebene liefern Momentan gibt es noch keine Middleware f r alle vier Dom nen e Notwendig f r eine leichte Installation Automatisches Entdecken von Ger ten und Diensten Dienste m ssen zusammengef gt werden k nnen Upgrade F higkeit Selbst administrierung e Offene Middleware die heterogene Dienste integriert und zusammenf gt Dazu wird die Beschreibung der Dienste genutzt und die Erkennung und Komposition erfolgt bis auf ein Semantisches Level e AMIGO Dienste m ssen einen Vorteil ber nicht vernetzte Dienste haben Es wird Kontext ber andere Ger te im System und den Nutzer gesammelt und daraus wer den neue kontextabh ngige Dienste entwickelt Intelligent User Services Der Prototyp legt den Fokus auf die Anwendungsdom nen H usliche Pflege Homecare Sicherheit Home information und Unterhaltung Kontextmodellierung und Reasoning Zur Modellierung des Kontextes wird RDF verwendet Nutzermodellierung und Profiling Kontextquellen sind Haushaltsger te Komfortsensoren Temperatur
72. ellen Status an Das kann der Status Aufzeichnen beziehungsweise Bereit sein Der Home Controller siehe Unterabschnitt 4 2 1 bernimmt die zentrale Kontrolle aller Ger te Dazu zeigt er alle Ger te an die im Haus vorhanden sind und deren aktuellen Status Tritt ein Ereignis auf und wird dadurch ein Task erzeugt dann wird das ebenfalls auf dem Home Controller angezeigt Dazu werden die dazugeh rigen Regeln und der Kon text angezeigt so dass nachvollzogen werden kann wann und warum eine Regel ausgel st wird Die Umsetzung jeder Komponente als OSGi Bundle bedeutet dass jedes Ger t einen oder mehrere Dienste bereitstellt So hat beispielsweise der Videorekorder die beiden Dienste VideoAbspielDienst und VideoAufnahmeDienst Um seine Dienste bereitzustellen kann es sein dass ein Ger t auf andere Dienste zugreifen muss Dies wird in OSGi als Abh n gigkeiten engl Dependencies bezeichnet Dadurch wird definiert dass ein Dienst nur ausf hrbar ist wenn er auf bestimmte Dienste zugreifen kann 5 1 Klassifikation von Ger ten und Ereignissen 5 1 1 Repr sentation der Konzepte in einer Dom nenontologie F r die semantische Beschreibung der Ger te und ihrer Funktionalit t wurden diese in einer Ontologie beschrieben siehe Abbildung 5 1 Dazu wurde eine Ontologie f r typische Ger te die auch eine lterer Nutzer verwendet entwickelt Diese umfasst die Konzep te f r typische Ger te aus den Kategorien Kommunikationsger te Unterhal
73. en zu interpretieren und der jeweiligen Anwendung zur Verf gung zu stellen F r die Anwendung soll die Herkunft der Kontextdaten dabei weitestgehend transparent sein 3 1 4 Gu s Ontology based Context Model for Intelligent Environments Gu et al haben ein formales ontologiebasiertes Kontextmodell entwickelt und verwenden f r die Darstellung die Web Ontology Language OWL Ziel ihrer Arbeit ist die semanti sche Kontextrepr sentation f r die semantische Interoperabilit t das Reasoning ber Kon text und den Austausch von Wissen Knowledge Sharing Sie ber cksichtigen die Klassi 3 1 ONTOLOGIEN UND REGELN 29 fizierung von Kontext Abh ngigkeiten zwischen Kontext und die Qualit t von Kontext Den Anwendungsbereich ihres Kontextmodells sehen sie in der Smarthome Environment also in der Anwendungsumgebung intelligenter H user Die Ontologie soll dabei die gro e Vielzahl heterogener Kontextdaten erfassen k nnen So ist ihr Ansatz eine allgemeine Anwendungsdom ne upper ontology zu definieren die um spezifische Subdom nen Domain specific ontologies erweitert werden kann Vorteil dieser Herangehensweise ist das dynamische Nachladen von zus tzlichen konkreten Dom nen und eine damit einhergehende Entlastung der mobilen Endger te die nicht zu jeder Zeit eine komplette Ontologie im Speicher halten m ssen Gr ere Ontologien entstehen so durch die Integration von Dom nen spezifischen Ontologien Die Upper Ontology be s
74. en Instanzen von einer VideoQuelle Videorekorder und einem VideoRenderer TV ben tigt und diese m ssen den Zustand aktiv haben Wenn mehrere Instanzen eines Konzeptes vorhanden sind muss die Middleware ermitteln welches Ger t das Beste f r diese Situation ist In dem gew hlten Beispiel gibt es mehre re Videorekorder und auf welcher wird f r eine Videoaufnahme verwendet Die Auswahl erfolgt anhand von Qualit tseigenschaften zeitlicher Verf gbarkeit und Priorit ten und wird von der Komponente Semantic Service Discovery siehe Unterunterabschnitt 4 2 14 3 durchgef hrt T BOX Konzepte gt A BOX Instanzen In Beschreibungslogiken werden Konzepte mit T BOX Terminological axioms bezeichnet Die konkrete Situation also die Instanzen die den Zustand der modellierten Welt repr sentieren werden mit A BOX bezeichnet T Box Jeder Angestellte ist eine Person Wird benutzt f r die Klassifizierung A Box Bob ist ein Angestellter F r die Instanz Bob kann berpr ft werden von welchem Konzept sie ist instance checking Darstellung von den Konzepten T Box und den Individuen der A Box in einem Beispiel Task VideoAbspielen ben tigt VideoQuelle und VideoRenderer VideoQuelle Videorekorder liefert Videosignal VideoRenderer TV der Video anzeigen kann 88 5 IMPLEMENTIERUNG 5 4 Gerate als OSGi Bundles Die Device Registry ist die zentrale Stelle in der Ger te registriert werden Ein aktives Ger t meldet s
75. en allt glichen Leben entscheidende Hilfestel lung leisten k nnen Die Arbeit soll typische Situationen lterer Menschen wie Notf lle Vergesslichkeit und Verzweiflung im Umgang mit fehlerhaften Betriebszust nden von Ge r ten und Anwendungen veranschaulichen Bearbeitungsschwerpunkte 1 Auseinandersetzung mit verwandten wissenschaftlichen Arbeiten Smart Space Kon textbewusste Infrastrukturen Ontologien 2 Identifikation von Anwendungsbereichen in der Wohnumgebung 3 Entwurf einer konzeptionellen Architektur 4 Untersuchung des Einsatzes von Ontologien OWL zur Modellierung von Smart Environments 5 Regeln und Policen f r die nahtlose Kooperation und Integration von Ger ten 6 Erstellung eines Prototyps Selbststandigkeitserklarung Hiermit erkl re ich dass ich die von mir am heutigen Tag dem Priifungsausschuss der Fakult t Informatik eingereichte Diplomarbeit zum Thema Eine Middleware f r die nahtlose Integration und Kooperation von Ger ten vollkommen selbstst ndig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe Dresden den 21 Januar 2008 Roman Wilkowski Abstract In the ideal Ubiquitous Computing environment devices and resources are intelligent enough to conceal themselves from the attention of the user with the goal to support him Therefore it is required that those intelligent devices cooperate with each other The user
76. en in der Wissensbasis informiert Ab diesem Zeitpunkt steht das Ger t f r Regeln zur Verf gung und wenn eine Regel ausgel st wird dann wird mit dem Ger t ein Task ausgef hrt 4 2 14 2 Device Classification Die Komponente Device Classification ist f r die Modellierung von Ger ten zust ndig An hand der semantischen Beschreibungen der Dienste eines Ger tes erfolgt die Abbildung in die verschiedenen Kategorien der Ger teontologie automatisch Ein Ger t welches meh rere Dienste anbietet wird in mehreren Kategorien eingeordnet Ger te werden modelliert und in Ger teklassen eingeordnet Der erste Schritt ist dabei die Ger teschnittstellen abzuleiten Daraus wird eine Hierarchie von Schnittstellen ermittelt und Funktionalit ten in abstrakte Oberklassen ausgelagert Der n chste Schritt ist es eine allgemeine Ger teklassifikation in einer Ontologie darzustellen Ger te werden unterschie den in allgemeine Kategorien wie Unterhaltungsger te Haushaltsger te und Steuerungsge r te Die Ger tefunktionalit t wird abstrakt beschrieben da sich die verschiedenen Ger te sehr voneinander unterscheiden Durch die Beschreibung der Ger te in einer Ontologie l sst sich dieses System programmiersprachen und plattformunabh ngig umsetzen Damit die Ger te den Konzepten in den Regeln und Tasks entsprechen erfolgt eine Abbil dung zwischen der Beschreibung eines Ger tes und diesen Konzepten Wenn das Ger t dem System schon bekannt i
77. en werden die verwandten Arbeiten verglichen und ana lysiert Dabei wird ermittelt welche Anforderungen erf llt beziehungsweise nicht erf llt werden Aus diesen Ergebnissen folgt die Motivation f r diese Arbeit und es soll heraus gestellt werden wo die L cken sind und warum der hier zu entwickelnde Ansatz ben tigt wird Anforderungen Anwendungsdom ne Richtet sich der Ansatz wirklich an ltere Menschen Werden die besonderen Anforderungen von dieser Zielgruppe unterst tzt Werden die hier beschriebenen Anwendungsf lle von den verwandten Arbeiten unterst tzt Zielstel lung lteren Menschen unabh ngiges Leben zu erm glichen e Einsatz von Ontologien zur Modellierung des Smarthomes Smart environment der Ger te und den Tasks Automatisch Tasks erkennen und ausf hren die der Absicht des Nutzers entsprechen e Wie erfolgt die nahtlose Kooperation von Ger ten Werden dazu Regeln eingesetzt Wie e K nnen verschiedene heterogene Ger te dynamisch kooperieren um gemeinsamen einen Task auszuf hren Nahtlose und dynamische Integration heterogener Ger te Anmelden Abmelden Be reitstellen von Funktionalit t und Diensten auch unbekannter Ger te e Welche Ressourcen k nnen von dem dargestellten System integriert werden Gibt es irgendwelche Einschr nkungen Hardwareanforderungen an die Ger te auf denen System laufen soll und die Midd 32 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN leware
78. enderer kann auch ein Laptop sein oder ein VideoBeamer Nat rlich werden f r die genaue Spezifikation eines Dienstes Parameter verwendet So reicht es nicht nur zu wissen dass ein VideoRenderer im System vorhanden ist F r die Darstellung eines Videos sollte der VideoRenderer eine definierte Displaygr e beziehungsweise Videogr e bieten Die Ger te verwenden unterschiedliche Attribute um das gleiche Konzept auszudr cken So hat ein Videobeamer nicht das Attribut Displaygr e sondern die Gr e der Videoausgabe wird in Projektionsfl che gemessen Zwischen diesen Attributen muss es eine semantische Abbildung geben die diese Attribute gleichsetzt 5 1 2 Abbilden von OWL Konzepten auf Dienste Wie erfolgt die Abbildung von OWL Konzepten auf Dienste Die Dienste werden seman tisch beschrieben und es gibt eine Abbildung von einer Dienstbeschreibung in der Ontologie auf die vorhandenen Dienste in der Service Registry F r die Abbildung wird das Jena Se mantic Web Framwork verwendet Damit lassen sich in Java Ontologien beschreiben Aus den Java Klassen k nnen auf direktem Weg OWL Konzepte erstellt werden 5 1 3 Kooperation von Ger ten Die Kooperation zwischen Ger ten ist generisch und unabh ngig von einer bestimmten Anwendungsdom ne Die Vorbereitung einer m glichen Kooperation erfolgt durch die In tegration eines Ger tes in die Middleware In der Regel hat die Kooperation einen Ursprung und ein Ziel Der Ursprung oder die Ur
79. enge basierend auf einer Forward Chaining Rule Engine Kontextabhangige Dienste F r jede Anwendung gibt es eine Kontextkonfigurationsdatei Anwendungsentwickler defi nieren Regeln und bestimmen die Methoden die aufgerufen werden wenn die Bedingung wahr wird Als Beispiele f r kontextabh ngiges Verhalten werden genannt Gesundheits f rsorge Erinnerungshilfe und um Energie zu sparen Die Regeln werden in einer Datei gespeichert und in den Kontextreasoner eingelesen W hrend der Laufzeit k nnen Regeln modifiziert und aktualisiert werden 3 2 VERWANDTE ANSATZE 41 Anwendungsgebiet Entwickeln einen Smarthome Prototypen basierend auf der kontextabh ngigen Infrastruk tur Zus tzlich wird noch eine Esszimmeranwendung entwickelt Diese spielt Musik ab und passt das Licht an wenn Familienmitglieder zusammen im Esszimmer essen Die High level Ontologie und Heim Dom nen Ontologie enth lt auch Nutzerkontext wie den Geburtstag eines Familienmitglieds Ortskontext wird durch Location Provider berwacht Der Con text Interpreter leitet die Raumaktivit ten ab Abendbrot Zusammenfassung Nutzen Ontologie basiertes Kontextmodell in OWL f r semantische Kontextdarstellung Reasoning und Wissensaustausch Basierend auf dem Kontextmodell wird eine Service Orientierte Kontextabh ngige Middleware SOCAM vorgeschlagen Reasoning erlaubt es High Level Kontext aus Low Level Kontext und impliziten Kontext von explizitem Kon text abzuleiten
80. englischen Benutzer schnittstelle pr sentiert und der Nutzer muss sich nicht mehr berlegen wie ein Task ausgef hrt wird how to do a task oder wo sich ein bestimmter Inhalt befindet sondern nur what to do um einen Task auszuf hren Beschreibung eines Tasks Zwei technische Schl sselkonzepte werden in Interplay entwickelt die Pseudos tze und Tasksitzungen In einem Pseudosatz besteht ein Task aus Verb Subjekt und einem Target Device Subjekt kann ein Inhaltstyp oder ein bestimmter Inhalt sein Pseudos tze haben folgende Eigenschaften 1 einfache und intuitive Methode um die Absicht des Nutzers zu beschreiben 2 k nnen von Nutzer ohne Handbuch verstanden werden 3 gen gend detailliert um in Ger tediensteaufrufe transformiert zu werden f r die Tas kausf hrung Eine einfache Men struktur gen gt um dem Nutzer eine Auswahl an m glichen Tasks anzubieten die seiner Intention am Besten entspricht Ein solcher Task den der Nutzer ausw hlen kann ist beispielsweise Play Movie LivingRoom DTV Die Tasks werden auf der Benutzerschnittstelle in einem leicht verst ndlichen Pseudo English pr sentiert siehe Abbildung 3 2 Composer ESA Contents Movie BoomBox Music HomeTheater Photo LivingRoomDTV Network Printer Abbildung 3 2 The Task Composition Screen Das zweite Konzept Task Sessions siehe Abbildung 3 3 bezeichnet dass ein Task in einer Session ausgef hrt werden kann Eine Session be
81. er STEINMETZ Joa chim DARGIE Waltenegus EMODE ein Ansatz zur werkzeuguntersttitzten Model lierung multimodaler adaptiver Benutzerschnittstellen In KOSCHKE Rainer Hrsg HERZOG Otthein Hrsg R DIGER Karl Heinz Hrsg Marc Hrsg Informatik 2007 Band 1 Bremen Germany September 2007 Lecture Notes in Informatics WUSTMANN Patrick Ein Kontextbasiertes Modell f r den situationsabh ngigen Ein satz von Ein und Ausgabemodalit ten in adaptiven Benutzerschnittstellen Technische Universitat Dresden Diplomarbeit December 2006 ZHANG Tao BRUEGGE Bernd Empowering the User to Build Smart Home Appli cations In Toward a Human friendly Assistive Environment 2004 96 Literaturverzeichnis 97 Abbildungsverzeichnis 2 1 3 1 3 2 3 3 3 4 3 9 3 6 4 1 4 2 4 3 5 1 5 2 5 3 Kommunikationsbeziehungen zwischen Anwendungsfalldiagrammen 13 SOUPA Ontology 2004 06 4 30 The Task Composition 33 The Session Screeny osea nl Mh ar cha kr Moser 34 berblick ber die SOCAM Architektur 1 38 CONtext ONtology CONON 1 40 Beispiele einer Teilregelmenge basierend auf einer Forward Chaining Rule ogy 32 od A ae cn ed a ied es oy etl a Ge dk AE Ey 40 Dreischichtige
82. er te automatisch f r den Nutzer konfiguriert Das System hilft dem Nutzer bei der berwachung und Kontrolle von Ger ten im Haushalt Der Nutzer soll Regeln f r bestimmte Situationen erstellen k nnen 2 3 ANFORDERUNGSANALYSE 28 XVI XVII Das System soll den an Tatigkeiten und Termine Der Nutzer kann Termine auf Aufgaben in das System eingeben und das System kann automatisch Aufgaben ermitteln aus einem geplanten Sollzustand und dem aktuellen Zustand Der Nutzer soll an Geburtstage Treffen mit Freunden und der Familie an die Tabletteneinnahme erinnert werden Das System soll Termine mit einer Terminplanungsanwendung abgleichen k nnen Der Nutzer soll einen Sollzu stand f r jedes Ger t eingeben k nnen Beispiel Das System kennt den Mindestinhalt des K hlschrankes und erstellt au tomatisch eine Einkaufsliste f r fehlende Produkte oder bestellt die Produkte bei einem Interneth ndler je nach Nutzerwunsch Der Nutzer und sein Verhalten in den jeweiligen Situationen wird beobachtet und die Regeln werden angepasst Weiterf hrung der Bedienung auf einem anderen Ger t Task Continuation Der Nutzer soll die Anzeige vom einem Ger t auf ein anderes Ger t weiterleiten k nnen Weiterleitung Das Auswahlmen wandert von Ger t zu Ger t Auf dem anderen Ger t wird der gleiche Inhalt dargestellt Dazu geh rt eine Auswahl eines Ger tes Parameter die scho
83. er behandelt werden muss Der Nutzer kann sich den Fehler anzeigen lassen und erh lt L sungsvorschl ge wie der Fehler behoben werden kann F r jedes Ger t hat der Ger tehersteller definiert was der Normalzustand ist ein Zustand bei dem eine War nung ausgel st werden soll und was ein Fehlerzustand ist Der Nutzer kann sich zu jedem Ger t anzeigen lassen wie der Zustand definiert ist Desweiteren hat er hat die M glich keit innerhalb von herstellerseitig definierten Grenzen f r ein Ger t den Normalzustand Warnungszustand und Fehlerzustand zu definieren Der Nutzer hat unterschiedliche M glichkeiten um die Kooperation zwischen Ger ten zu regeln Mit Policies definiert der Nutzer das Verhalten des Systems in Bezug auf das Koope rationsverhalten und die Integration von Ger ten auf hohem Niveau Die Benutzerschnitt stelle bietet die Funktionalit t zum Hinzuf gen eines neuen Ger tes Beim Hinzuf gen werden die Konfigurationsm glichkeiten eines Ger tes mit den Anderen in dieser Um gebung angezeigt Der Nutzer w hlt aus der angezeigten Liste mit potentiellen Ger ten f r die Kooperation die gew nschten Ger te aus Damit wird die Kooperation der Ger te auf der h chsten Ebene definiert Eine andere M glichkeit ist es dem dem Nutzer in ei ner gegebenen Situation alternative Handlungsvorschl ge zur Erreichung eines bestimten Ziels anzubieten welches die Kooperation von Ger ten einbezieht Der Nutzer entschei det sich f r
84. er von der Zentralheizung vorgegebenen Grenzen Der Ger tehersteller ist daf r verantwortlich die Grenzen f r die einstellbaren Parameter des Ger tes zu definieren Nutzerbezogene Policies werden ber das Policy Interface in den HomeController eingegeben und in der Knowledge Base abgespeichert Ger tebezogene Policen werden von den Ger teherstellern vordefiniert und bei der Anmeldung eines Ger tes an den HomeController in die Knowledge Base integriert Beispiele f r ger tenahe Policen e Jedes Ger t hat Public und Private Methoden Funktionalit t e Regelung des Systemverhaltens bei unvorhergesehene Systemzust nden Es gibt einen minimalen Systemkern der immer l uft e Verhalten bei einem Systemabsturz oder schwerwiegenden Fehler Es gibt einen Neu start oder es gibt eine Startsequenz in der die Systeme hochgefahren fahren e Definierte Reaktion bei Abbruch e Ordnung der Regeln Systemkritische Regeln haben eine h here Priorit t als weniger kritische Regeln e Abarbeitung und Ablauf der Regeln wird durch deren Pritor t bestimmt e Nutzerereignis wie Nutzer ist tot gt Wie erfolgt die Abarbeitung der offenen Auf gaben FIFO LIFO Abbruch e Was tun bei St rfall Ausnahme e Unerlaubter Zugriff e Welche Ger te sind zul ssig f r Kooperation Integration Alle Ger te die angemel det wurden F r welche Zeitdauer e Welche sind berhaupt verwaltbar Bringt das Ger t seine Regeln mit die von den Police
85. ereportage fortzusetzen 6 Janet dr ckt die OK Taste Die Wiedergabe der Reportage wird ab diesem Zeitpunkt fortgesetzt Szenario 3 Szenario Janet befindet sich in der K che und ein Nachbar klingelt an der Wohnungst r Akteur Instanzen e Janet Bewohnerin e Nachbar e Telefon T rwechselsprechanlage mit integrierter T r berwachungskamera Mikro welle Ger te im Haushalt Ereignissfluss 1 Janet befindet sich gerade in der K che als ein Nachbar an der Wohnungst r klingelt Die T rwechselsprechanlage ist mit einer Videokamera ausgestattet 2 Das System ermittelt den Aufenthaltsort von Janet und sucht nach einem Ger t welches zur Anzeige dieses Ereignisses geeignet ist In der K che befindet sich ein 12 2 IDENTIFIKATION DER ANWENDUNGSDOMANE Telefon Das System l sst das Telefon klingeln da dieses so eingestellt ist dass es klingeln soll wenn jemand an der T r klingelt 3 Aufdem Telefondisplay wird der Text T rwechselsprechanlage angezeigt Janet nimmt den H rer ab und spricht mit dem Nachbarn vor der T r 4 Sie dreht sich dann zu ihrer Mikrowelle um die einen eingebauten Bildschirm Vi deoausgabeger t hat und sieht dort das eingeblendete Videobild von der T r ber wachungskamera 5 Auf dem Display der Mikrowelle wird ein Men angezeigt mit m glichen Aktionen die in der aktuellen Situation von Janet ausgef hrt werden k nnen Die Mikrowelle hat Tasten mit denen Einstellungen vorgenommen
86. ese Regeln sind zu statisch So ist es schwierig umzusetzen dass Ger te dynamisch kooperieren um neue Dienste zu schaffen wenn diese nicht vorher programmiert wurden Nachteilig ist auch dass Ger te nut gefunden werden k nnen wenn es eine bekannte Beschreibung gibt 3 4 OSGI 45 UPnP Jini and HAVi have focused on connecting devices electronically in a va riety of different forms that only provide simply device interactions and controls through the use of standardized APIs 18 eignet sich sehr gut f r die Zusammenarbeit von Audio Video Ger ten da es Videost reaming und die automatische Ger tesuche unterst tzt Es kann allerdings keine Befehle an einfache Ger te wie Lampen oder Waschmaschinen schicken 3 4 OSGi OSGi steht f r Open Service Gateway Initiative und ist eine offene Architektur offene Diensteplattform die es erm glicht eine gro e Anzahl an WAN Diensten in einem LAN Smarthomes Automobile einzusetzen Es ist ein leichtgewichtiges Framework zum Aus liefern und Ausf hren von diensteorientierten Anwendungen und bietet Verwaltungsfunk tionalit ten wie das Installation Aktivierung Aktualisierung und Entfernen von Diensten Die Vorteile von OSGi sind Es ist eine Java basierte L sung die nur eine Java Virtual Ma chine voraus setzt und ist somit plattformunabh ngig Hardware Betriebssystem OSGi bietet verschiedene Level an Systemsicherheit von dem Signieren von heruntergeladenen Dienste bis
87. f llt sind feuern die entsprechenden Regeln Am Ende die ser Regelkette gibt es eine Regel die eine Aktion erzeugt Aus einer Aktion wird ein Task abgeleitet Dieser Task wird direkt vom Device Cooperation Manager auf einen Dienst abgebildet der von einem Ger t oder mehreren Ger ten ausgef hrt wird Der Device Co operation Manager k mmert sich somit um die Abbildung von Tasks auf phyische Ger te und ruft deren Dienste mit den entsprechenden Parametern auf Zwischen den unterschiedlichen Diensten kann es zu Abh ngigkeiten kommen die Probleme 62 4 KONZEPTION in der Ausf hrung verursachen k nnen Der Device Cooperation Manager erkennt diese Abh ngigkeiten und bringt die Ausf hrung der Tasks in die richtige Reihenfolge Dazu ermittelt er welche Ger te f r die Ausf hrung des Tasks also f r eine Kooperation zur Verf gung stehen Die ben tigten Daten erh lt er aus der Knowledge Base und aus der Device Registry Treten nderungen in diesen Quellen auf wird er mit Ereignissen dar ber informiert M ssen mehrere Dienste kombiniert werden um einen Task auszuf hren dann bernimmt der Device Cooperation Manager die Service Komposition und Orchestrierung 4 2 5 Multimodaler Benutzerschnittstellen Manager Diese Komponente ist f r die Anpassung von Eingaben und Ausgaben an die geeigne teste Ein und Ausgabemodalit t verantwortlich Die Benutzerschnittstelle wird abstrakt definiert und kann so dynamisch an die unterschi
88. f ein spezifisches Ereignis bestimmt Ausgabeort und art Ereignisse klassifiziert nach Ereignistyp und Priorit t 1 Status 2 Warnung 3 Fehler 4 Notfall Diese Klassifizierung stellt Oberklassen dar und kann weiter differenziert werden in ver schiedene Notf lle L sst sich f r jedes Ereignis eine Standardverhalten in einer Situation festlegen Der Ger tehersteller ordnet jedes Freignis dass auf dem Ger t auftreten kann in die hier entwickelte allgemeine Ereignistypkategorie ein Aus der Kategorie ergibt sich das Standardverhalten Reaktion welches bei Auftreten des Ereignisses angewendet werden soll So soll beispielsweise bei einem Ereignis der Kategorie Notfall die Feuerwehr alarmiert werden Es soll eine weitere Ontologie geben die das Wissen enth lt wer benachrichtigt werden soll bei welchem Ereignistypen Ereignis und Aktion werden durch die Middleware voneinander entkoppelt Es gibt keine direkte Verkn pfung zwischen Freignis und Tasks und den Regeln Im System gibt es vordefinierte Tasks f r bekannte Ereignistypen Die Ereignisquelle bezeichnet den Ursprung eines Ereignisses Sozusagen den Ort an dem das Ereignis ausgel st wurde Wenn der Kontextdienst zu dieser Ereignisquelle befragt wird k nnen weitere interessante Kontextinformationen abgerufen werden So kann der Standort des Ger te ermittelt werden wer mit dem Ger te interagiert hat Aus der Inter aktionsgeschichte des Ger tes kann ermittelt werden f
89. guage Combining OWL and RuleML World Wide Web Consortium 2004 W3C Member Submission KOKAR Mieczyslaw M Ontology Based Situation Awareness and High Level Fu sion Methods and Tools Workshop on Information Fusion Fusion06 Florence Italy july 2006 MAGERKURTH C ETTER JANSE M KELA J Kocsis O RAMPARANY F An intelligent user service architecture for networked home environments In Intelligent Environments 2006 IE 06 2nd IET International Conference on 1 5 6 July 2006 S 361 370 ISSN 0537 9989 MCBRIDE B Jena a semantic Web toolkit In Internet Computing IEEE 6 2002 S 55 59 ISSN 1089 7801 MESSER A KUNJITHAPATHAM A SHESHAGIRI SONG H KUMAR NGUYEN Kyoung H InterPlay a middleware for seamless device integration and task orchestration in a networked home In Pervasive Computing and Communi cations 2006 PerCom 2006 Fourth Annual IEEE International Conference on 2006 S 10 pp PATEL SCHNEIDER Peter HAYES Patrick HORROCKS Ian PATEL SCHNEIDER Peter Hrsg HAYES Patrick Hrsg HORROCKS Ian Hrsg OWL Web Ontology Language Semantics and Abstract Syntax World Wide Web Consortium 2004 Forschungsbericht RICQUEBOURG Vincent DURAND David MENGA David MARHIC Bruno DELA HOCHE Laurent LOGE Christophe JOLLY DESODT Anne Marie Context Inferring in the Smart Home An SWRL Approach In Advanced I
90. h f r die Freignisse interessiert die w hrend des Waschprogramms auftreten 24 2 IDENTIFIKATION DER ANWENDUNGSDOMANE 2 3 2 Nichtfunktionale Anforderungen Mit den Nichtfunktionalen Anforderungen werden die Anforderungen an das System be schrieben die nicht direkt die Systemfunktionalit t betreffen 1 Das System muss es dem Nutzer erm glichen dass sein Fokus bei der Bedienung der Ger te ist Was m chte ich tun und nicht Wie muss ich es tun Der Nutzer soll seine Aufmerksamkeit auf seine wesentlichen Aufgaben richten k nnen Das System soll Regeln so ausf hren dass der Nutzer keine Verz gerung bemerkt Das hei t die Verz gerung darf nicht l nger sein als die Ausf hrung einer bestimmten Aktion normalerweise in dieser Anwendungsdom ne betr gt Zeitnahe und garantierte Anzeige von Ereignissen Leistung und Effizienz Antwortzeiten Ressourcenbedarf Sicherheitsanforderungen werden nicht betrachtet da zu umfangreich Untersucht werden m ssten Aspekte wie Vertraulichkeit Datenintegrit t Verf gbarkeit Zuverl ssigkeit Robustheit Fehleranf lligkeit Schutz vor Fehlbedienung Systemver halten muss immer deterministisch sein Usability bzw Anforderungen an die Benutzerschnittstelle e Es soll die Absicht des Nutzers aus dem Kontext ermittelt werden und es sollen nur die Tasks angezeigt werden welche ausgef hrt werden k nnen e Der Nutzer soll nachvollziehen k nnen welche Regeln das Sys
91. hmen Video von Quelle Video ben tigt VideoQuelle VideoAufnahmeGer t Sobald die Sendung aufgezeichnet wurde steht ein neuer Task VideoAbspielen zur Verf gung Nach dem Telefonat wird dem Hausbewohner auf dem Fernseher die M glichkeit angeboten die aufgezeichnete Sendung abzuspielen Dieser Punkt l sst sich noch weiter differenzieren Der Task kann auch unabh ngig von dem Anruf entstehen Wenn Videoin halte zur Verf gung stehen dann wird dem Nutzer angeboten sich das Video anzuschauen 5 3 TASK 87 TaskRenderVideoContent TaskRenderAudioContent TaskShowEmergency TaskShowStatus ena TaskCaptureAudioContent askRenderConten TaskShowError F TaskCapturerContent TaskC askCaptureVideoContent _ TaskShowEvent nn Task _ Fi f xX TaskOpenDoor TaskShowWarningMessage 7 N v a Action vr N TaskPrintContent TaskAnswerPhone et TB TaskShowText Fa x B A ETaseiarcon a a Abbildung 5 3 Ausschnitt aus der Task Ontologie Dieser Aspekt ist noch abh ngig von den Nutzerpr ferenzen f r eine solche Situation und anderen Parameter wie der Tageszeit Ein Task enth lt die Aktionen also die Logik die in einer bestimmten Situation ausgef hrt werden soll Task Aktionen F r die Erstellung eines Tasks m ssen dessen Bedingungen erf llt werden In diesen Bei spielen werd
92. ibt es mehrere Dienste mit gleicher Funktionalit t dann muss anhand von zu definieren den Kriterien ausgesucht werden welcher von den verf gbaren Diensten verwendet wird In diesem Prototyp gibt es nur einen verf gbaren VideoAufnahmeDienst Dieser wird ge startet und nimmt die aktuelle Sendung auf Wenn keine Fehlermeldung eintrifft geht der Home Controller davon aus dass der Dienst erfolgreich ausgef hrt wird Der VideoAuf nahmeDienst nimmt auf und der Videorekorder auf dem dieser Dienst l uft meldet seinen neuen Status dass er gerade Inhalt aufzeichnet an den Home Controller Sobald Inhalt aufgenommen wurde wird der VideoWiedergabeDienst auf dem Videorekorder aktiv und kann von Regeln ber cksichtigt werden Wenn ein Task ausgef hrt wird dann wird das auf einem Ger t angezeigt wenn es das unterst tzt Dem Nutzer wird auf dem Fernseher angezeigt dass dieser Task ausgef hrt wurde und das Fernsehprogramm aufgezeichnet wird Wenn das Telefonat beendet ist sen det das Telefon ein Event an den Home Controller und daraufhin wird dem Nutzer auf dem Fernseher der Task VideoVonAufnahmeAbspielen angezeigt Der Task entsteht dadurch dass die Konzepte in der Ontologie instanziiert werden Der Reasoner schlussfolgert darauf und leitet diese ab In dem Moment ab dem der Videorekorder die Sendung aufnimmt steht Inhalt zum Abspielen zur Verf gung Der Videorekorder hat sich beim Home Controller angemeldet und den VideoWiedergabeDienst registr
93. ich bei dem Home Controller an und wird in der Device Registry registriert In OSGi ist das die ServiceRegistry Diese verwaltet alle Zust nde eines Dienstes Ein Bundle kann den Zustand aktiv inaktiv haben Es kann installiert aktualisiert update und deinstalliert werden Ein Ger t wird duch seine Dienstebeschreibung in der Manifest Datei spezifiziert In dieser wird genau definiert welche Funktion der Dienst hat und welche anderen Bundles von ihm ben tigt werden Das Bundle kann erst gestartet werden wenn alle ben tigten Bundles verf gbar sind Beim Aktualisieren eines Bundles wird gepr ft ob es Abh ngigkeiten zu anderen Bundles gibt und diese m ssen dann erst beendet werden 5 4 1 Ereignisbehandlung Ger te registrieren sich beim Home Controller f r Ereignisse die f r sie relevant sind Wenn das Ereignis auftritt informiert der Home Controller alle Ger te die als Listener registriert sind Der Home Controller registriert f r alle Ger teereignisse Service Listener im Framework Er ist somit der zentrale Ereignisvermittler zwischen den verschiedenen Ger ten Die Rule Engine ist f r alle Ereignisse als Listener eingetragen und wird vom Home Controller ber alle Ereignisse informiert Die Ereignisbehandlung erfolgt in der Methode des jeweiligen Listeners Ein Anrufer ruft an und das Telefon informiert den Home Controller ber dieses Freignis Der Home Controller leitet das Ereignis an die Rule Engine weiter Bei diesem Ereig
94. ie Middleware integriert werden Er definiert die Schnittstellen des Ger tes und legt dadurch fest mit welchen anderen Ger t es kooperieren kann Der Nutzer und Ger teentwickler erwarten von der Middleware dass die Anwendung ein fach arbeitet und abw rtskompatibel ist Es gibt viele verschiedene Standards offene defakto proprit re welche ber cksichtigt werden m ssen um das Hauptziel die Inter operabilit t zu gew hrleisten Ger tehersteller Der Ger tehersteller entwickelt das Ger t so dass die Middleware darauf l uft Die Funk tionalit t des Ger tes wird semantisch beschrieben damit das Ger t dynamisch integriert 60 4 KONZEPTION werden kann Anhand der semantischen Beschreibungen erfolgt die Integration des Gerates in die Ontologien Wie Ger te miteinander kooperieren wird vom Ger tehersteller vordefi niert So legt dieser fest das ein Videorekorder ein bestimmtes Videoformat abspielen und aufnehmen kann F r dem Videorekorder bedeutet das er mit allen Videoanzeigeger ten kooperieren kann Der Ger tehersteller erh lt eine Testplattform um so das Zusammenspiel verschiedener Ger te zu testen 4 2 2 Residential Gateway Die logische Komponente Residential Gateway ist f r die Anbindung des Systems an exter ne Netzwerke zum Beispiel um Web Services aufzurufen zust ndig F r die Anbindung an externe Diensteanbieter muss diese Netzwerkschnittstelle geschaffen werden Das Resi dential Gateway ist
95. ie allein zu Hause wohnt Sie hat gerade ihren 70igsten Geburtstag gefeiert und von ihrer Familie moderne Haushaltsger te Kommunikationsge r te und Unterhaltungselektronik geschenkt bekommen oder sich selber angeschafft die ihr helfen sollen ihren Alltag zu vereinfachen Im allt glichen Umgang mit diesen Ger ten k nnen sich unterschiedliche Szenarien ergeben in denen Janet Ger te bedient und verschiedene Ger te kooperieren um Janet zu helfen und ihr den Alltag zu erleichtern Szenario 1 Szenario Anzeige einer Fehlermeldung auf einem beliebigen Ger t welches die Aufmerk samkeit von Janet hat 10 2 IDENTIFIKATION DER ANWENDUNGSDOMANE Akteur Instanzen e Janet Bewohnerin e Gerdatehersteller e Waschmaschine Geschirrsp ler Fernseher Ger te im Haushalt Ereignissfluss 1 Janet bedient gerade die Waschmaschine im Keller Auf dem Display der Waschma schine wird eine kurze Fehlermeldung angezeigt dass die Geschirrsp lmaschine in der K che l uft aber kein Wasser auspumpt und das aktuelle Reinigungsprogramm ge stoppt wurde Es wird angezeigt dass dieser Fehler eine Reaktion von ihr erfordert Normalerweise w rde Janet jetzt im Benutzerhandbuch nachlesen wie ein solcher Fehler behoben werden kann Sie wei dass ihr das System die ben tigte Hilfestel lung anbietet Aber ohne Brille kann Janet das kleine Display der Waschmaschine nicht gut erkennen und sie m chte sich auch lieber bequem hinsetzen w hrend sie
96. iert Status nderungen eines Ger tes werden dem Home Controller als Events mitgeteilt Aus dem Status eines Ger tes ermittelt der Home Controller m gliche Tasks Bei dem Videorekorder der Zugriff auf Inhalte hat ist das der Task VideoAbspielen Der Videorekorder f hrt den Dienst nur aus und hat keine Informationen dar ber wer die Aufnahme gestartet hat Da der Home Controller den Vi deoAufnahmeDienst beauftragt hat das Fernsehprogramm f r einen Nutzer aufzunehmen hat der Home Controller Informationen dar ber welchem Nutzer diese zugeordnet ist und bietet dann diesem Nutzer den Task zum Videoabspielen an In einem Befehlsspeicher wer den gestartete Dienste mit den Benutzerinformationen abgespeichert Damit der Task auf dem Fernseher angezeigt werden kann muss der ZeigelnteraktionDienst des Fernsehers mit dem Parameter Task aufgerufen werden Dieser Dienst dient der Interaktion mit einem Ger t Es wird eine Auswahlliste mit m glichen Tasks auf dem Fernseher dargestellt und daraus wird eine Auswahl getroffen Der Fernseher dient nur zur Anzeige und Auswahl des Tasks und muss die Semantik nicht verstehen Das Resultat der Auswahl wird zur ck an den Home Controller geschickt und dieser f hrt den entsprechenden Task aus In diesem Szenario hat sich der Nutzer dazu entschieden das Fernsehprogramm an der Stelle fort zusetzen also muss das Video vom Videorekorder abgespielt werden Dem Videorekorder wird der Befehl zum Abspielen des Videos gese
97. inhaltet den Ausf hrungszustand verteilt ber alle beteiligten Ger te spielt gerade pausiert Aus den Pseudos tzen die eine Auf gabe auf hohem Niveau beschreiben werden Ger teaufrufe erstellt Somit ist dynamisches 34 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN Hinzuf gen und Entfernen von Ger ten in der Session m glich und keine komplizierte Logik in der Task Composition Procedure n tig Nowplay Pause Stop Option Abbildung 3 3 The Session Screen Anwendungsfall Die h ufigsten Anwendungen aus dem Unterhaltungsbereich werden unterst tzt Dazu ge h ren Audio und Video Unterhaltung unter Nutzung von beliebigen Medienrenderern und Transcoding Ger ten Dann werden noch multimediale Anwendungen unterst tzt wie das Drucken von Bildern wobei es keine Rolle spielt wo sich der Inhalt und das jeweilige Ausgabeger t befindet Eine weitere Anwendung ist die Synchronisierung von Inhalten zwischen verschiedenen Speicherger ten Context Awareness und Ontologien Auf Nutzerkontext wird nicht eingegangen Beachtet wird nur das Hinzukommen eines neu en Ger tes und dessen Funktionalit t und Inhalte Die Task und die Ger tebeschreibung wird in RDF und OWL umgesetzt Task Beschreibung F r die Task Komposition werden funktionale Anforderungen Requirements mit ver f gbaren Funktionalit ten der Ger te verglichen F r die Beschreibung der Eingabe und Ausgabetypen von Ger ten werden Input Output MIME type S
98. karten Renderer der aus Koordinaten eine Landkarte generiert Der Zustand dieser Komponenten wird definiert durch Parameter wie die Sichtbarkeit Bild schirmkoordinaten und die Fenstergr e Bei dynamischen Ausgabekomponenten wird der aktuelle Zustand registriert wie spielt gerade pausiert gestoppt Nachteil dieses Ansatzes ist es dass nicht ausreichend Informationen zur Unterscheidung von Diensten vorhanden sind es fehlt die semantische Beschreibung der Dienste Aus diesem Modell wird abgeleitet dass falls kein grafisches Eingabeger t vorhanden ist dann kann der Nutzer keinen Button auf dem Display dr cken Anforderungen an die Planung der Pr sentation umfassen den aktuellen Zustand der Ger tekonfiguration die geforderte Ausgabe und den aktuelle Stand der Ausgabe Treten nde rungen in der Ger tekonfiguration auf dann m ssen neue Ausgabetasks generiert werden Der Kern des Pr sentationsproblems sind kausale Abh ngigkeiten r umliche und zeitliche Beschr nkungen Es gilt einen Plan mit detaillierten Anweisungen zu erstellen f r die fi nale Darstellung F r die L sung des Pr sentationsproblems wird K nstliche Intelligenz 38 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN genutzt Dieser Ansatz unterst tzt die spontane Verbindung zwischen heterogenen Ger ten die durch verschiedenste Netzwerke miteinander verbunden sein k nnen Durch die Selbstbe schreibung der Ger te k nnen diese dynamisch in die Ger
99. ll Ger te finden k nnen durch die Suche nach semantischen Beschrei bungen der Ger teeigenschaften und Ger tefunktionalit ten Das System muss ein geeignetes Ger t f r die Interaktion mit dem Nutzer ermitteln k nnen Es soll ein Repository f r Ger te geben Darin werden alle Ger te verwaltet die sich in der Hausdom ne befinden und dem Nutzer geh ren Fremde Ger te m ssen freigeschalten werden bevor diese sich an melden k nnen Das System soll kontextbewusst sein und sich zu jeder Zeit an den Kontext des 20 2 IDENTIFIKATION DER ANWENDUNGSDOMANE Nutzers Aufenthaltsort Aktivit t und seine Nutzerpraferenzen anpassen Das System muss den Kontext der f r das kontextabh ngige Systemverhalten ben tigt wird ermitteln und darauf zu jedem Zeitpunkt Zugriff haben Kontext nderun gen m ssen registriert werden Das System soll die aktuelle Situation des Nutzers erfassen und erkennen Context awareness Fremde Nutzer die in das Haus kom men sollen vorher gefragt werden ob sie an dem System teilnehmen m chten Das System soll aus dem Nutzerverhalten in Situationen lernen und sich anpassen k n nen Der Nutzer kann seine Pr ferenzen einstellen dass hei t wie sich das System in einer bestimmten Situation verhalten soll Das System muss die Hausdom ne semantisch verstehen So muss das System dem Bewohner bei schlechtem Wetter empfehlen die Fenster zu schlie en oder diese automatisch schlie en wenn
100. lte des Typs Video von VideoProvidern aufnehmen kann Neue Konzepte f r den Videorekorder sind Ger t VideoCapturer VideoProvider Inhalt Video Task aufnehmen Der Administrator definiert Sicherheitsregeln f r den Einsatz von Ger ten Auf Sicherheits aspekte soll in dieser Diplomarbeit nicht n her eingegangen werden aber es soll dennoch erw hnt werden dass fremde Ger te ein potentielles Risiko darstellen wenn nicht genau definiert ist welchen Code sie ausf hren d rfen und von welchem Besitzer sie stammen Besonders in Anbetracht der aktuellen Meldungen die von immer mehr Viren uns Sicher heitsschwachstellen in Betriebssystem berichten muss in diesem sensiblen Bereich alles daf r getan werden dass Angriffe absolut unm glich sind Der Administrator f hrt Software Updates durch wenn diese nicht automatisch durch gef hrt werden k nnen Dazu geh rt auch die Aktualisierung von Ontologien um neue Konzepte und Regeln die von anderen Anbietern stammen Der Administrator konfigu riert die Rollen f r die Nutzer in der Umgebung ein Anwendungsentwicklersicht Anwendungsentwickler bezeichnet hier die Zust ndigkeit f r die Programmierung der Midd leware und der Ger te auf denen die Middleware l uft Der Anwendungsentwickler ent wickelt die Middlewaresoftware und stellt sicher dass die Software einwandfrei auf den Ger ten intalliert wird und lauff hig ist Werden neue Hardware Schnittstellen entwickelt dann m ssen diese in d
101. m ssen sich vom Nutzer erstellen lassen Die Regeln sollen so beschaffen sein dass der Nutzer aus vorgefertigten Komponenten die Regeln zusammensetzen kann Diese Komponenten m ssen leicht verst ndlich sein Wenn Regeln f r Ger te beschrieben werden dann sollen dem Nutzer das Ger t und die Ger tefunktionen in einer Auswahl dargestellt werden Die Situation in der sich der Nutzer befindet muss erfasst werden k nnen Das System soll es erm glichen dass ein Ger t einen Fehlerbericht an den H ndler sendet Das System soll als Antwort einen L sungsvorschlag erhalten Wenn der Nutzer das Problem nicht beheben kann soll das System mit dem H ndler automatisch einen Termin mit dem Ger tehersteller vereinbaren k nnen Dem Nutzer sollen nur Aufgaben angezeigt werden die seiner Intention und seinem Kontext entsprechen Es muss ermittelt werden k nnen was die Intention des Nutzers ist Dazu muss analysiert werden wie sich der Nutzer in bisherigen Situationen entschieden hat und diese Entscheidung in einer hnlichen Situation zuerst vorgeschlagen werden Bei der Kooperation von Ger ten gibt es unterschiedlich wahrscheinliche Aufgaben die der Nutzer ausf hren m chte Diese sollen nach der Wahrscheinlichkeit sortiert angezeigt werden Das System soll anhand von Regeln automatisch Entscheidungen treffen k nnen Dazu muss das System Regeln verwalten und ausf hren k nnen Dem Nutzer wer den Aufgaben abgenommen wenn das System G
102. m Nutzer einen intuitiveren Umgang mit seiner techni schen Umgebung und schafft ihm ben tigte Freir ume Die dazu in dieser Arbeit entworfene L sung wird nachstehend bewertet Umsetzung der aufgestellten Anforderungen Die in der Anforderungsanalyse siehe Kapitel 2 aufgestellten funktionalen Anforderun gen konnten gr tenteils umgesetzt werden Folgende Anforderungen die ber die reine Middleware L sung hinausgehen wurden noch nicht umgesetzt Das sind die Anforderun gen XI Das System muss die geeignete Modalit t zur Ausgabe und Eingabe von Informa tionen ausw hlen XIII Das System soll es erm glichen dass ein Ger t einen Fehlerbe richt an den H ndler sendet XTV Dem Nutzer sollen nur Aufgaben angezeigt werden die seiner Intention und seinem Kontext entsprechen XVI Das System soll den Nutzer an T tigkeiten und Termine erinnern k nnen XVII Weiterf hrung der Bedienung auf einem anderen Ger t Task Continuation und XIX Protokollierung aller Nutzerinterak tionen mit den Ger ten Damit diese Anforderungen umgesetzt werden k nnen bedarf es weiterer Komponenten in der Systemarchitektur Es gibt f r die verschiedenen Ger teklassen eine semantische Repr sentation in der Ger teontologie und es wurden verschiedene Ger te im Prototypen als Dienst implementiert Durch die Nutzung von Ontologien zur semantischen Beschreibung der Dom ne und der Kontextdaten wird eine abstrakte Beschreibung gewe hlt und dadurch ist
103. modelliert welche Person das Ger t bewu t wahrnimmt e isLocatedIn ein Ger t hat einen Standort an dem es sich befindet ownedBy gibt an welcher Person das Ger t geh rt Die Ger tekategorien siehe oben werden als Unterkonzepte von Ger t dargestellt Somit wird die gewohnte Kategorisierung aus der Realwelt entsprechend durch die Ontologie beschrieben Bisher wurde Ger tefunktionalit t in anderen Ans tzen per Interfaces definiert In die sem Ansatz wird die Funktionalit t auf einem abstrakten Niveau mit OWL definiert Es muss dann eine Abbildung von OWL auf die Ger te definiert werden Durch die Objekt Eigenschaft wird definiert welche F higkeiten ein Ger t hat In Abbildung 5 2 ist die On tologie dargestellt welche die F higkeiten Konzepte definiert Ein Fernseher hat die Capabilites VideoRenderer AudioRenderer und TextRenderer Der Videorekorder ist mit den Capabilities VideoProvider und VideoCapturer verbunden Die Konzepte bezeichnen die Funktionalit t des Ger tes Diese Funktionalit ten k nnen von verschiedenen Ger ten angeboten werden Ein Radio ist wie der Fernseher auch die Capa bilities AudioRenderer Die F higkeit AudioRenderer ist ein Unterkonzept von Renderer Daraus ergibt sich eine Hierarchie von F higkeiten Wenn ein Ger t f r die Kooperation einen Renderer ben tigt egal welchen dann kann aus den verf gbaren Renderern einer aus gesucht werden Das k nnte ein AudioRenderer ein VideoRender oder ein
104. n Die Komponente Police Interface speichert Policen direkt in der Knowledge Base ab oder diese werden vom Police to Rule Transformer in Regeln transformiert und diese werden abgespeichert Die Rule Engine ben tigt Zugriff zum Ausf hren der Regeln Die Device Registry speichert die registrierten Ger te in der KB ab und der Classifier ben tigt Wissen aus der KB um die Ger te korrekt zu klassifizieren 4 2 4 Device Cooperation Manager Der Device Cooperation Manager ist f r die Verwaltung der tats chlichen Kooperation der Ger te verantwortlich Er wird von der Rule Engine ber ausgel ste Regeln informiert verarbeitet diese Informationen und steuert Ger te durch Aufrufen der entsprechenden Dienste auf den Ger ten Ein Ger t bietet einen Dienst an und dieser soll anhand eines Regelwerkes dynamisch aufgerufen werden Wie ist der Weg von einem Ereignis welches auftritt bis zum Punkt dass ein Dienst aufgerufen wird Zuerst tritt ein Ereignis auf dieses wird verarbeitet und zu einer Aktion dann entsteht daraus ein Task und dieser wird auf einen Dienst abge bildet In der Rule Engine werden Regeln ausgel st wenn bestimmte Bedingungen von Regeln erf llt sind Durch eine Regel die ausl st entsteht ein Ergebnis welches wiederum Eingabe Bedingung f r die n chste Regel sein kann So wird eine Regelkette ausgef hrt Zuerst wird ein geeignetes Ger t gefunden dann muss der Status passen und der Kontext Wenn all diese Bedingungen er
105. n tigt werden F r die Rule Engine Implementierung wird JESS Java Expert System Shell verwendet JESS ist eine Java basierte Rule Engine 86 5 IMPLEMENTIERUNG die OWL Ontologien verarbeitet Weil JESS wie auch OSGi Java basiert ist wird aus diesem Grund JESS fiir die Implementierung verwendet Die Regeln sind in der SWRL beschrieben und werden in der Knowledge Base abgespei chert Die SWRL Jess Bridge erm glicht die Interaktion zwischen der Knowledge Base welche die SWRL Regeln und die OWL Ontologien enthalt und der Rule Engine die diese Daten verarbeitet Die Regeln sind immer in der Rule Engine geladen Der Arbeitsspeicher dieser Rule Engine enthalt die Fakten Sogenannte Shadow facts sind verbunden mit Java Objekten und sie erlauben es auf Java Objekten zu schlussfolgern die sich au erhalb des Arbeitsspeichers befinden Ein Fakt besteht aus einem Template vgl Java Klasse mit einem Namen einer Menge von Slots Das sind einfache Java Klassen die nur Getter und Setter Methoden enthalten und entspricht der Java Beans Konvention Die Regeln arbeiten auf diesen Plain Old Java Objects POJOs 5 3 Task Der hier gew hlte Ansatz ist Task orientiert Mit Tasks siehe Abbildung 5 3 werden m g liche Aufgaben bezeichnet die der Nutzer eines Smarthomes ausf hren kann Diese ergeben sich aus dem aktuellen Kontext der die Ger tekonfiguration deren Status die Situation in der Wohnumgebung m glicherweise auch au erhalb davon un
106. n zu seinen Funktionalit ten an das Repository Die Ontologie wird dann mit folgenden Daten initialisiert e Standort des Ger tes in der Anwendungsdom ne hier Wohnung oder im Haus Dieser Kontext wird ben tigt f r die Kooperation e Nutzer die mit dem Ger t interagieren e Daten die den Nutzer beschreiben e Ereignisse die vom Ger t ausgel st werden k nnen e Geratespezifische Policen welche festlegen wer das Ger t bedienen darf und welche Funktionalit t des Ger tes aufgerufen werden d rfen W hrend der Laufzeit werden vom Ger t aktuelle Statusdaten bertragen wie der aktuelle Zustand Ereignisse und die Daten in der Ontologie werden damit aktualisiert 4 3 1 Dom nen Ontologie Die Dom nen Ontologie repr sentiert hier den Anwendungskontext der Smarthome Dom ne und enth lt alle Konzepte die in der Hausumgebung auftreten k nnen Die Dom nen Ontologie wird erweitert um eine Ger te Ontologie zur Beschreibung der Ger te Konzepte um die Nutzer Ontologie welche die Nutzerkonzepte beschreibt und die Task Ontologie Die Ontologie ist um beliebige neue Konzepte erweiterbar durch Hinzuf gen der neuen Subdom nen 4 4 ENTSCHEIDUNGSBAUME 75 4 3 2 Gerateontologie Die Ger teontologie beschreibt die Konzepte der Ger te die sich in dieser Dom ne befin den Es werden die Schnittstellen des Ger tes im Detail beschrieben Das sind Beschrei bungen der Funktionalit ten mit welchen Ger ten eine Kooperation
107. n Informationen modelliert Aktionen sind Informationen auf die der Nutzer reagieren kann Damit Informationen dargestellt werden k nnen muss das System die Modalit t ausw hlen mit der die Informationen dargestellt werden Es muss nach einem passenden Ger t suchen und den Kontext ermitteln Das System initialisiert dazu die entsprechenden Anwendungsf lle Der Nutzer f hrt den Anwendungsfall Ausw hlen einer Aktion aus Das System partizipiert an diesem Anwendungsfall indem es die beiden Anwendungsf lle Wer te Regeln aus und Integriere Ger t initialisiert Das System ermittelt anhand von Regeln und der integrierten Ger te im System welche Aktionen dargestellt und welche Aktionen vom Nutzer ausgew hlt werden Der Anwendungsfall Konfiguriere System kennzeichnet die Situationen in denen der Nutzer nderungen am System vornimmt Dazu geh rt das Erstellen Modifizieren und L schen von Regeln und Policen Den Anwendungsfall Ger t anmelden initialisiert der Nutzer wenn er ein neues Ger t anmelden m chte Der Nutzer registriert Ger te und meldet diese durch Auswahl dieser Funktion in einer Auswahlmaske an Alternativ meldet das System Ger te automatisch an wenn sich diese in der N he oder im Besitz des Nutzers befinden wenn dieser das Haus betritt Es wurden verschiedene Akteure in diesen Anwendungsf llen identifiziert Ein Akteur kann ein Nutzer Mensch aber auch ein anderes System sein das dieses System nutzt Der Ak teur befindet
108. n eingeben wurden werden bergeben Dazu muss das Ger t seinen aktuellen Zustand an das System bermitteln k nnen Das System findet das neue Ger t welches der Nutzer bedienen m chte und stellt dort den Zustand des vorherigen Ger tes her Transferieren des Dienstes von einem Ger t zu einem Anderen soll erm glicht werden Dienstemigration Der Nutzer bzw das System m ssen jederzeit einen Alarm absetzen und Hilfe anfordern k nnen Mit einem Knopfdruck muss Alarm ausgel st werden k nnen Das System soll Alarmsituationen selbst ndig erkennen und f r den Nutzer Hilfe anfordern Die ser Fall trifft unter anderem zu wenn eine Fehleranzeige erfolgt ist aber der Nutzer nicht reagiert Die Wahrscheinlichkeit eines Fehlalarms muss unter zwei Prozent sein L se Notfall aus mit HealthMonitoringService Der Gesundheitszustand des Nutzers soll die gesamte Zeit berwacht werden Wenn die berwachung f r mehr als 20 Sekunden ausf llt dann muss sofort ein Alarm ausgel st werden Das Alarmsystem muss konfigurierbar sein Der Nutzer kann einstellen wer alarmiert werden soll Protokollierung aller Nutzerinteraktionen mit den Ger ten Es muss erfasst werden welche Eingabe der Nutzer gemacht hat und wie sich das Systemverhalten dadurch ver ndert hat Es soll protokolliert werden wer mit einem Ger t interagiert hat Beispiel Janet hat die Waschmaschine angestellt und ein Waschprogramm gest artet Daher wird angenommen dass sie sic
109. n k mmert um die Organisation von Peers eines Channels in Gruppen und um die direkte Interaktion zwischen Peers Die oberste Schicht ist die Ko ordinierungsschicht f r die Selbstorganisation der Ger te Es gibt keine zentrale Kontrolle und kein Wissen ber andere Peers so dass die Pr senz anderer Peers nicht geplant werden kann Die Middleware ist physisch verteilt Dadurch gibt es keinen Single Point of failure Jedes Ger t hat eine Instanz zur Middleware oder Verbindung zu einer entfernten Instanz via Proxy Es wird ein Modell ben tigt f r die Selbstbeschreibung der Ger te Ein und Ausgabeger te geh ren entweder die Kategorie Grafisch oder Akustik Zur Identifikation der Ger te wird eine eindeutige ID verwendet F r Ger te wie z B einen PC mit Eingabe und Ausgabe Komponenten werden beide Komponenten unter derselben ID registriert F r eine Eingabekomponente gibt es einen zust ndigen Eingabedienst siehe Bernsen s Taxonomy Dieser liefert Informationen ber den aktuellen Zustand des Eingabeger ts F r eine Ausgabekomponente liefern Ausgabedienste Informationen dar ber welche Inhalte unterst tzt werden Das sind zum Beispiel ASCII Texte die in Sprachausgabe ausgegeben werden k nnen oder JPEG Dateien die grafisch ausgegeben werden Bei der Grafikausgabe wird die aktuelle Aufl sung ber cksichtigt Ein weiterer Komponententyp kann Inhalte nur generieren oder verarbeiten aber nicht darstellen Das ist zum Beispiel ein Land
110. n kontrolliert werden e Kontrolle der Daten die zwischen den Ger ten ausgetauscht werden e Kontrolle der Zugriffe auf Netzwerke 52 4 KONZEPTION Beispiele fur nutzerbezogene Policen W hrend Kooperation Zugriffsbeschr nkung auf relevante Funktionalit t es soll kein Auslesen von pers nlichen Daten erfolgen e Ich will nicht dass ich ber den Fernseher telefoniere und dieser alle meine Telefon nummern kopiert oder meine SMS e Beispiel Handy mit pers nlichem Telefonbuch wird mit Fernseher und Telefonanlage oder Navigationsger t integriert Private Adressen sollen nicht sichtbar sein e Fremde Ger te die nicht in den Haushalt geh ren sollen erst nach Nachfrage bei dem Nutzer und seiner Erlaubnis integriert werden e Fremde Personen die das Haus betreten sollen sich und ihre Ger te authentifizieren e Nutzer sagt Ruhe ich will nicht gest rt werden Wie k nnen die Ger te das gemeinsam umsetzen was muss jedes einzelne daf r tun Der Nutzer kann das am HomeControl ler einstellen dass er jetzt nicht gest rt werden m chte F r nicht st ren gibt es eine Police die festlegt dass Ger te keine akustischen Meldungen ausgeben Ereignisse sollen dem Nutzer nur mitgeteilt werden wenn sie wichtig sind Der Anrufbeant worter soll Anrufe aufzeichnen und die T rklingel wird abgestellt F r jede einzelne Ger teklasse ist festgelegt wie sich ein Ger t dieser Klasse verhalten soll um die Po licy zu erf llen
111. n und ob die Umsetzung dieser Konzepte alteren Menschen in ihrem allt glichen Leben entscheidende Hilfestellung leisten und ihnen so ein unabh n gigeres Leben erm glichen kann Der Alltag insbesondere lterer Menschen spielt sich gr tenteils in ihrer Wohnumgebung ab Es sollen daher Anwendungsbereiche in der Woh numgebung identifiziert werden in denen die zu entwickelnde Middleware L sung diesen Menschen Hilfestellung leisten kann Um die Anforderungen an eine solche Middleware zu ermitteln werden nachfolgend Szenarien dargestellt die ausf hrlich die notwendigen und interessanten Aspekte dieses Anwendungsbereichs betrachten Daraus werden die Anforde rungen Requirements ermittelt die generell an ein solches System gestellt werden k nnen Die Konzeption der zu entwickelnden Middleware basiert auf diesen Anforderungen und wird in Kapitel 4 eingehend beschrieben Typische Situationen lterer Menschen die alleine leben sind Notf lle Vergesslichkeit e Hilflosigkeit im Umgang mit fehlerhaften Ger ten und Anwendungen e Schwierigkeiten bei der Umsetzung der existierenden Technik e Nicht ausreichende extrinsische Anreize durch Arbeitsalltag Nachbarschaft Familie politische Aktivit ten usw 2 1 Szenarien F r die Analyse der Anforderungen werden nachfolgende Szenarien zu Grunde gelegt in de nen die unterschiedlichen Anwendungsbereiche herausgestellt werden Hauptperson dieser Szenarien ist die ltere Frau Janet d
112. nbedienung Ger te die sich im Haus befinden sollen sich ber ein beliebiges interaktionsf hi ges Ger t fernbedienen lassen Auf diesem Ger t soll ein Auswahlmen zur Auswahl eines Ger tes dargestellt werden Von dem ausgew hlten Ger t sollen alle Funktio nen die aus der Ferne aufgerufen werden k nnen dargestellt werden Aus diesen Funktionen w hlt sich der Nutzer eine Funktion oder mehrere Funktionen aus die er ausf hren m chte Beispiel Der Nutzer schaltet die Waschmaschine vom Fernseher aus 22 2 IDENTIFIKATION DER ANWENDUNGSDOMANE XI XII XIII XIV Das System muss die geeignete Modalitat zur Ausgabe und Eingabe von Informationen auswahlen Die Eingaben und Ausgaben in das System sollen unabh ngig von der Modalit t er folgen Das System w hlt f r die Anzeige von Informationen die geeignete Modalit t aus Das ist abh ngig von der Situation den verf gbaren Ger ten und den Nutzer pr ferenzen Folgende Eingabemodalit ten sollen unterst tzt werden Per Tastatur Maus Stift Sprache Gesten Mimik Folgende Ausgabemodalit ten sollen unter st tzt werden visuell akustisch Gestik Braille Nutzer soll das System konfigurieren k nnen Der Nutzer soll zu jedem Zeitpunkt das System konfigurieren k nnen Das System muss es dem Nutzer erm glichen anwendungsspezifische Regeln und Policen zu definieren und auszuf hren Dazu muss es Regeln verwalten und speichern k nnen Regeln
113. nd der Ger tekonfiguration welche Aufgaben mit den Ger ten m glich sind Daraufhin werden ihm nur diese Aufgaben an gezeigt aus denen er dann die gew nscht ausw hlen und ausf hren kann Somit ist die Interaktion mit Ger ten schon sehr vereinfacht Der Nutzer muss nicht mehr berlegen welche Ger te er alle einstellen und wie konfigurieren muss Dar ber hinaus kann der Nut zer so auch Aufgaben mit Ger ten ausf hren die ihm vorher nicht bewusst waren Viele Ger te verstecken eine Vielzahl von Funktionalit t hinter unz hligen Men s die ohne aus giebiges Studium der Handb cher oder Hilfen nicht erreicht werden k nnen Besonders ltere Menschen sind sehr vorsichtig im Umgang mit Technik und m chten nichts falsch machen Inwieweit unterst tzt das System ltere Menschen in deren typischen Situationen Notf lle werden erkannt durch Sensoren die in den Haushalt integriert werden Diese berwachen den Gesundheitszustand des Nutzers und alarmieren Rettungskr fte wenn ein kritischer Zustand erreicht ist In diesem System werden Regeln definiert mit denen sich beliebige Situationen definieren und kontrollieren lassen Mit diesen Regeln und der Auswertung von Kontextdaten wird auf Notf lle reagiert Vergesslichkeit Das System bietet dem Nutzer in jeder Situation die m glichen Funktiona lit t an und ber cksichtigt seine Da viele Vorg nge automatisiert werden muss der Nut zer sich nicht mehr an alles erinnern Das birgt andere
114. ndet mit der Ausgabe auf den Fernseher In der Beschreibung eines Dienstes wird festgelegt wie viele Instanzen dieses Dienstes zur gleichen Zeit ausgef hrt werden k nnen So kann der VideoAufnahmeDienst nur von einer Videoquelle zur gleichen Zeit aufzeichnen 5 2 REGELSCHICHT 85 5 2 Regelschicht Regeln werden mit der Semantic Web Rule Language SWRL definiert SWRL kombinierte OWL Konstrukte und Teile der RuleML Sprache Regeln sind dazu da zu definieren wie ein Task gebildet wird Sie arbeiten auf Konzepten aus den Ontologien Eine Regel kann nur ausgel st werden feuern wenn jede ihrer Bedingungen erf llt ist Zu jedem Konzept dass in der Regel vorkommt muss es mindestens eine Instanz geben um die Regeln zu erf llen Ein Konzept f r einen Dienst wird instanziiert wenn dieser Dienst aktiv ist Bei der sequentiellen Abarbeitung von Regeln sollten keine Konflikte zwischen den einzel nen Regeln auftreten Falls das nicht der Fall ist dann m ssen ab diesem Zeitpunkt die be n tigten Dienste reserviert werden damit keine andere Regel die ben tigten Dienste Res sourcen verwendet Auftreten von Race Conditions Vorgang des Einlesen und der Verarbeitung der Regeln 1 Laden der SWRL Regeln aus der SWRL Rule Base und OWL Knowledge Base in die Rule Engine diese entspricht Java Rule Engine API JSR94 2 Ausf hren dieser Regeln auf der Knowlege Base Pr fung der Resultate 3 Speichern der Resultate in der OWL Knowledge
115. ne L sung zur Behebung des Fehlers schnell gefunden wird Dazu muss mit dem Hersteller kommuniziert werden und ein Reparaturtermin vereinbart werden Aus Datenschutzgr nden sollte jedoch bei diesem Vorgang der Hersteller nicht ber alle freien Termine des Nutzers informiert werden Da mit die bestm gliche Sicherheit und ein hohes Ma an Privatsph re gew hrleistet werden kann werden Regeln anwendungsbezogen definiert beziehungsweise f r einen konkreten Anwendungsfall der von unterschiedlichen Anwendungen implementiert werden kann 4 2 3 Knowledge Base Die Knowledge Base KB ist der zentrale Aufbewahrungsort f r Ereignisse Ontologien und Regeln Folgende Fakten sind in der Knowledge Base gespeichert e S mtliche Ereignisse die auftreten k nnen werden in die Dom nenontologie ber nommen 4 2 ARCHITEKTUR 61 e Die Ontologien beschreiben die Anwendungsdom ne e Regeln fiir die Auswertung durch die Rule Engine e Policies e Ger te Haushaltsger te Unterhaltungsger te Steuerungsger te Heizung Licht Sensoren e Nutzerdaten und deren Pr ferenzen Definierte Situationen in der Wohnumgebung e Tasks und Aktionen Ein Administrator gibt in die Knowledge Base neue Ontologien ein erweitert bestehende Ontologien um neue Konzepte und modifiert Regeln Auf die Knowledge Base wird von unterschiedlichen Komponenten zugegriffen die auf diese Fakten zugreifen um diese abzurufen beziehungsweise neue Fakten hinzuf ge
116. ne Umwandlung in verschie dene Eingabe und Ausgabemodalit ten m glich sein Anhand der aktuellen Situation des Nutzers und seiner Umgebung soll ermittelt werden welche Aktionen der Nutzer ausf hren m chte Die Integration von Ger ten vollzieht sich auf verschiedenen Schichten e In der Benutzerschnittstelle erfolgt eine Komposition der verf gbaren Funktionen die von verschiedenen Ger ten eingebunden werden e Die Funktionalit ten der einzelnen Ger te werden abstrahiert und f r die Koopera tion miteinander verkn pft e Die Situation des Nutzers wird erkannt und ihm werden m gliche ausf hrbare Ak tionen angezeigt Diese ergeben sich aus der Funktionalit t der verf gbaren Ger te 4 1 Regeln und Policen f r die nahtlose Integration und Kooperation Es wird eine dreischichtige Kooperationsarchitektur siehe Abbildung 4 1 vorgeschlagen Diese besteht aus den Policen engl Policies auf der obersten Ebene den Regeln engl Rules auf der mittleren Ebene und Tasks auf der untersten Ebene Der Nutzer sieht und konfiguriert nur die Policen auf der obersten Ebene so dass s mtliche Einstellungen auf einer hohen Abstraktionsebene vorgenommen werden Das System bernimmt die ber setzung der Policen in Regeln und Tasks Die Tasks definieren wie einzelne Dienste zusam mengesetzt werden Regeln definieren wie Tasks ausgef hrt werden Die Policen auf der h chsten Stufe werden vom Nutzer parametrisiert und konfigurieren die An
117. nformation Networking and Applications Workshops 2007 AINAW 07 21st International Conference on Bd 2 2007 S 290 295 SANDERS Jane GT Research Horizons Winter 2000 SATOH Ichiro Mobile Agents for Ambient Intelligence In MMAS 2004 5 187 201 SINDEREN M J van HALTEREN van WEGDAM M MEEUWISSEN EERTINK E H Supporting context aware mobile applications an infrastructure approach In Communications Magazine IEEE 44 2006 Nr 9 S 96 104 ISSN 0163 6804 SLOMAN E Security and management policy specification In Network IEEE 16 Literaturverzeichnis 95 25 26 27 28 29 30 Mar Apr 2002 Nr 2 S 10 19 ISSN 0890 8044 STAVROULAKI DEMESTICHAS ADAMOPOULOU DEMESTICHAS Distributed Web based Management Framework for Ambient Reconfigurable Services in the Intelligent Environment In Mobile Networks and Applications 11 2006 Dezember S 889 900 STELLER Luke KRISHNASWAMY Shonali NEWMARCH Jan Discovering Relevant Services in Pervasive Environments Using Semantics and Context In MOST FAOUI Soraya K Hrsg MAAMAR Zakaria Hrsg GIAGLIS George M Hrsg IWUC INSTICC Press 2006 ISBN 978 972 8865 51 1 5 3 12 WANG Xiao ZHANG Daqing Gu Tao Hung K Ontology Based Context Modeling and Reasoning using OWL In PerCom Workshops 2004 S 18 22 WINKLER Matthias HEINRICH Matthias BEHRING Alexand
118. nis soll der Nutzer informiert werden um auf das Ereignis zu reagieren Der Home Controller be fragt den Kontextdienst nach dem aktuellen Aufenthaltsort des Nutzers wenn der aktuelle nicht bekannt ist Als Antwort erh lt den Aufenthaltsort des Nutzers Der befindet sich gerade vor dem Fernseher Der Fernseher ist geeignet um das Ereignis anzuzeigen Also wird der Nutzer auf dem Fernseher ber das Ereignis informiert Die Ereignisbehandlung wird im Prototypen mit dem OSGi Event Admin Service realisiert Dieser verteilt Ereignisse an Listener In OSGi werden Ereignisse so definiert das sie einen Typen und eine Nachricht enthalten Darauf setzt das hier entwickelte Ereignismodell auf 5 4 2 Kontextbenachrichtigung Jede Kontext nderung die auftritt l st ein Ereignis aus wor ber die Abonnenten die sen Kontexts informiert werden Die Einbindung von Kontext kann ber den BIB3R Kontextdienst erfolgen In diesem Prototypen werden allerdings keine Kontextdaten erfasst Sie werden durch Nutzereingaben also ndern von Attributen in der GUI simuliert Die Rule Engine abonniert alle Kontextereignisse und l st Regeln aus wenn die Bedingungen der Regeln an die Kontextdaten gekn pft sind In diesem Kapitel wurden der Prototyp und die bei der Implementierung betrachteten Aspekte vorgestellt 89 6 Bewertung der Arbeit Die nahtlose Integration und Kooperation von Ger ten als eine Voraussetzung f r das Ubi quitous Computing erm glicht de
119. ntext Awareness In HUC 99 Proceedings of the 1st international symposium on Handheld and Ubiquitous Computing London UK Springer Verlag 1999 ISBN 3 540 66550 1 5 304 307 BANAVAR Guruduth BECK James GLUZBERG Eugene MUNSON Jonathan SUSSMAN Jeremy ZUKOWSKI Deborra Challenges an application model for perva sive computing Boston Massachusetts United States ACM Press 2000 266 274 S ISBN 1 58113 197 6 BR GGE Bernd DUTOIT Allan H Objektorientierte Softwaretechnik mit UML Entwurfsmustern und Java Pearson Studium 2004 CHEN Harry PERICH Filip FININ Tim JOSHI Anupam SOUPA Standard Ontology for Ubiquitous and Pervasive Applications In International Conference on Mobile and Ubiquitous Systems Networking and Services Boston MA August 2004 DING Y ELTING SCHOLZ U Seamless integration of output devices in in telligent environments Infrastructure strategies and implemeentation In Intelligent Environments 2006 06 2nd International Conference on Bd 1 2006 ISBN 0537 9989 5 21 30 ESLER Mike HIGHTOWER Jeffrey ANDERSON Tom BORRIELLO Gaetano Next Century Challenges Data Centric Networking for Invisible Computing The Portolano Project at the University of Washington In Mobile Computing and Networking 1999 S 256 262 EUZENAT Jerome Alignment Infrastructure for Ontology Mediation and other Appli cations In HEPP Martin Hrsg
120. nzeigen kann 4 Das Ger t zeigt dem Bewohner das Ereignis und die Ak tionen um darauf zu reagieren in einem Auswahlmen an 5 Der Bewohner w hlt eine Aktion aus dem Auswahlmen aus 6 Das Ger t schickt die ausgew hlte Aktion an das System 7 Das System f hrt diese Aktion aus 8 Der Bewohner f hrt ein Telefonat Anfangsbedingungen Es muss ein Ger t vorhanden sein welches angerufen werden kann Der Bewohner muss erreichbar sein Abschlussbedingungen Der Bewohner wurde ber das Ereignis informiert und es wurde Qualit tsanforderungen eine Auswahl an Aktionen angezeigt Dem Bewohner wird die Information ber das Ereignis inner halb von 1 Sekunde angezeigt 2 2 ANWENDUNGSFALLE 17 Anwendungsfall 4 Anwendungsfallname Nachbar klingelt an Wohnungstiir Akteure Bewohner Nachbar Gerat 1 Nachbar klingelt an der Wohnungst r Die Wechselsprech anlage l st ein Ereignis aus und sendet dieses an das Sy stem Wenn es klingelt soll der Bewohner dar ber infor miert werden 2 Das System ermittelt den Standort des Bewohners und berpr ft ob sich dort Ger te befinden die das Ereignis ausgeben k nnen 3 Die Bewohnerin befindet sich in der N he der Mikrowelle 4 Das System schickt das Ereignis an die Mikrowelle Auf der Mikrowelle ffnet sich ein Anzeigefenster 5 Die Bewohnerin w hlt aus dass sie mit der Person vor der T r sprechen m chte 6 Die Middleware baut eine Gespr chsverbin
121. on erf llt sein muss Die Aktion wird ausgef hrt wenn der Bedingungsteil der Regel erf llt ist 4 1 3 Tasks Die Tasks befinden sich in dieser Hierarchie auf unterster Ebene und ein Task definiert eine atomare Aufgabe die ausgef hrt werden kann Atomare Tasks sind ganz einfache Tasks die die Funktionalit t von genau einem Dienst repr sentieren Komplexe Tasks sind aus mehreren atomaren Tasks zusammengesetzt Ein Beispiel f r einen atomaren Task ist der Task Schalte Licht An Ein komplexer Task ist der Task Nehme Video Auf der die Dienste des ContentProviders und den Dienst CaptureDevice beinhaltet In der Ontologie beschreibt das Konzept eines Tasks eine Kooperationsaufgabe zwischen Ger ten Tasks ergeben sich aus den verf gbaren Diensten die zusammengesetzt werden um die Kooperation zwischen den Ger ten zu realisieren Ein Task ist eine Zusammensetzung von mehreren Diensten und definiert die Funktionalit ten die sich aus der Ger tekonfiguration und der aktuellen Situation des Nutzers ergibt Die Darstellung der Tasks erfolgt durch Beschreibung dieser Konzepte in der Task Ontologie Durch Klassifizieren auf den Konzepten der Ontologie mit einem Reasoner werden die m g lichen Tasks die sich aus den Ger tefunktionalit ten ergeben automatisch gefunden Die Erzeugung eines Tasks wie ein Task mit Parametern initialisiert wird und die Ausf hrung eines Tasks wird in Unterabschnitt 4 2 4 beschrieben 4 2 Architektur An diese
122. on Policen durch den Nutzer Dem Nutzer werden Policen auf der Benutzerschnittstelle des Home Controllers angezeigt Dazu werden zu jeder Police die verf gbaren Parameter und die dazugeh rigen Wertebe reiche dargestellt Der Nutzer w hlt aus diesen die gew nschten Parameter und Werte aus Die Policen werden in einem einheitlichen Format dargestellt sind also unabh ngig von einer Herstellerdefinition Eine andere Variante ist es dem Nutzer nach einem Ereignis welches eine Bearbeitung erfordert m gliche Reaktionen anzubieten und der Nutzer w hlt eine Variante aus Dar ber hinaus kann der Nutzer festlegen wie sich das System in Zukunft in dieser Situation verhalten soll Der Nutzer legt mit einer Police das Systemverhalten als Reaktion auf ein Ereignis fest Die Police wird mit der Komponente Police zu Regel bersetzer auf die darunter liegenden Regeln abgebildet Wenn ein neues Ger t in die Anwendungsdom ne einf gt wird dann muss das Verhalten des Systems f r diesen Fall gekl rt sein Der Nutzer muss sagen wie das Ger t eingeordnet wird Der Nutzer kann auch festlegen wie sich das System beim n chsten Mal verhalten soll wenn ein neues Ger t hinzugef gt wird Damit kann das Standardverhalten f r diese Situation definiert werden Policen werden zerlegt in Regelbestandteile die an eine Syntax gebunden sind So erfolgt die Abbildung von Policies auf Regeln 4 1 2 Regeln Regeln befinden sich in der Kooperationsarchitek
123. on und einen Lautsprecher hat und so freigesprochen werden kann Die Bedie nung ist bei hohen Geschwindigkeiten einfacher als auf einem Handy mit kleineren Tasten Es kann das Telefonbuch an das Navigationsger t bermittelt werden und so k nnen Adres sen aus dem Handy in die Zielf hrung bernommen werden Die Verwaltung der Tasks erfolgt in einem Taskpool in dem alle angefallen Tasks gespei chert werden und dann in der Reihenfolge ausgef hrt werden Wie diese ausgef hrt werden h ngt von der Priori t eines Tasks ab und welche Ressourcen dieser zur Ausf hrung ben tigt K nnen Tasks immer generiert werden oder erst wenn die ben tigten Ger te und der Kontext zur Verf gung stehen 4 2 12 Ereignis Manager Prinzipiell erzeugt ersteinmal alles ein Ereignis Jedes Ger t welches an oder abgemeldet wird ist ein Ereignis Jede Kontext nderung ist ein Ereignis welche vom Kontextdienst registriert wird Die Anforderungen an den Freignis Manager sind die Behandlung von Ger teereignissen Warnung Fehler Status Notfall und Ereignisse wie Erinnerungen die den Nutzer direkt betreffen Aufgabe des Freignis Managers ist es den Ereignistyp anhand von Ereignisquelle und Kontext zu ermitteln Dazu kommuniziert diese Komponente mit dem Rule Layer und dem Kontextdienst Ermittlung von Ger ten die Ereignis darstellen k nnen Die optimale Darstellung des Ereignis bernimmt dann die Komponente Multimodaler Benutzerschnittstellen Manage
124. ontext wird hier in Pr dika ten erster Ordnung dargestellt Pr dikat Subjekt Wert Das Basismodell wird erweitert um boolsche Algebra union intersection complement So kann komplexes Wissen wie die Essensvorlieben der Familienmitglieder beschrieben werden www hpl hp com semweb jena2 htm 40 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN gt 2 g E Domain specific ontologies Vehicle d in ontol Home domain ontology GD owk Class gt rdfs subClass0f owl Property Abbildung 3 5 CONtext ONtology CONON 11 Reasoning SOCAM verwendet einen regelbasierten Ansatz basierend auf Logik erster Ordnung fiir das Reasoning auf Kontext Unterstiitzt werden zwei Arten des Reasonings Ontologiebasiertes Reasoning und vom Nutzer definiertes regelbasiertes Reasoning Abbildung 3 6 illustriert Beispiele einer Teilregelmenge basierend auf einer Forward Chaining Rule Engine user rdf type Elderly A user locatedIn Bedroom A user hasPosture LieDown A Bedroom doorStatus Closed A Bedroom lightLevel Low gt user status Sleeping user rdf type Elderly A user locatedIn room A TV locatedIn room A TV status On user status WatchingTV user rdf type Person A user locatedIn Bathroom WaterHeater status On Ba throom doorStatus Closed gt user status Showering Abbildung 3 6 Beispiele einer Teilregelm
125. pezifikationen wie z B audio mpeg content verwendet Ger te mit dem Eingabetypen audio mpeg eignen sich so f r den Task spiele Audio ab Von den Ger ten werden folgende Parameter spezifiziert der Typ Name und die Beschrei bung der jeweiligen Funktionalit t Als Kontextinformationen werden der Ort des Ger tes und die Ger tef higkeiten genutzt F r einen Fernseher sind das beispielsweise die Kon textinformationen Fernseher Bildschirmformat Wide Screen Bildschirmgr e stellt dar Audio Video Video Mpeg und Video Dvd 3 2 VERWANDTE ANSATZE 35 Darstellung eines Taskbeispiels welches der XML Sprache RDF beschrieben ist lt Play Movie Task gt lt iplay Task gt lt taskVerb gt PLAY lt taskVerb gt lt taskSubject gt lt Subject rdf ID Movie gt lt requires rdf resource AudioRenderer gt lt requires rdf resource VideoRenderer gt lt Subject gt lt taskSubject gt lt iplay Task gt lt Play Music Task gt lt iplay Task gt lt taskVerb gt PLAY lt taskVerb gt lt taskSubject gt lt Subject rdf ID Music gt lt requires rdf resource AudioRenderer gt lt Subject gt lt taskSubject gt lt iplay Task gt Implementierung Der Prototyp wurde in Java implementiert auf einer prototypischen Fernseherplattform mit dem J2ME Foundation Profile F r die Beschreibung der Ger te und Task Beschrei bungsschemata wurde OWL und RDF verwendet Die OWL
126. r Ereignisausl sung Ereignisse k nnen von Sensoren Ger ten Personen und durch Kontext nderungen siehe ContextProvider ausgel st werden Damit treten diese Entit ten als m gliche Ereignis ausl ser oder Ereignisquellen auf Ereignisbenachrichtigung Wenn ein Ger t am System angemeldet ist dann werden f r dieses Ger t EventListener registriert Alle Ereignisse die auf dem Ger t ausgel st werden werden an den zentralen Ereignis Manager bermittelt Dieser leitet das Ereignis an den Rule Layer weiter Dort wird dann mit Regeln ermittelt wie auf das Ereignis reagiert wird Ereignisbehandlung 1 Ereignis wird von einem Ger t ausgel st Jedes Ereignis wird als Kontextinformation betrachtet 2 Senden von Ereignis an die Middleware HomeController Der Ereignis Manager hat Listener f r dieses Ereignis registriert in Middleware und erh lt das Ereignis 3 Ereignis Manager leitet das Ereignis an den Rule Layer weiter 4 Es feuert eine entsprechende Regel und eine Aktion wird ausgel st 4 2 ARCHITEKTUR 69 5 Aus Aktion wird ein Task erzeugt der ausgefiihrt wird 6 Finden des passenden Empf ngers und Ausf hren des Tasks Ereignisklassen Ereignisse werden in Ereignisklassen unterteilt und semantisch beschrieben Das Format des Ereignisses ist standardisiert so dass es von der Middleware weiterverarbeitet werden kann Durch die Regeln welche in der Knowledge Base definiert sind wird die Reaktion au
127. r Stelle wird der Entwurf f r die Architektur vorgestellt Zuerst wird die Architek tur im berblick vorgestellt dann werden die einzelnen Komponenten mit ihren Aufgaben vorgestellt und zum Schluss wird das Zusammenspiel und der Signalfluss zwischen den Komponenten beschrieben Das System ist eine Anwendungsorientierte Middleware und befindet sich in der Anwendungsebene des OSI Referenzmodelles Entsprechend der Anforderung Nutzen von existierenden und verf gbaren heterogenen Ge r ten PCs Unterhaltungselektronik Haushaltsger te Mobile Ger te muss die Architektur f r ein Verteiltes System entwickelt werden welche verschiedene heterogene Ger te inte griert Es wird eine Dienste orientierte Architektur gew hlt siehe Abschnitt 3 5 Die einzelnen Ger te werden als Dienste realisiert und k nnen so lose gekoppelt werden Die Kommunika 4 2 ARCHITEKTUR 55 Device Cooperation Policy Interface Manager User Modelling User Profiling Devices Device A Rule Engine Policy to Rule Translator Device B Context Service Knowledge Base Reasoning Ontologies Event Listener Device Registry amp Classification Platform System Network OSGi Abbildung 4 2 Architektur tion zwischen den Diensten erfolgt ber Web Service Technologien Ein Ger t beziehungs weise eine Komponente unterscheidet sich von anderen Ger ten durch die Dienste die es anderen Subsystemen bereits
128. rd der aktuelle Kontext ber cksichtigt Eine alternative Herangehensweise f r die Umsetzung des Rule Discoverer ist der Decision Learner den Patrick Wustmann in seiner Diplomarbeit 29 entworfen hat Dieser lernt aus Nutzerentscheidungen und bestimmten Kontextdaten Daraus erstellt er eine Regelbasis und wenn wieder eine Situation mit diesem Kontext eintritt dann entschei det das System f r den Nutzer 4 2 10 5 Reasoner Ein Reasoner vergleicht die aktuellen Objektinstanzen mit den vorhanden Regeln in der Regelbasis und aktiviert eine Regel wenn die Bedingungen der Regeln erf llt sind Dazu muss der Reasoner auf die Regelbasis und die Knowledge Base zugreifen 4 2 10 6 Regelbasis Die Regelbasis enth lt alle Regeln die das Anwendungsverhalten des Systems in Situatio nen definieren und die Kooperation zwischen Ger ten definieren Dabei wird unterschieden in systemgenerierte Regeln und in nutzergenerierte Regeln Aus diesen Regeln werden die spezifischen Entscheidungen f r die Kooperation von Ger ten die im Smarthome auftreten k nnen festgelegt 66 4 KONZEPTION 4 2 10 7 Regel bersetzer Die hier beschriebenen Regeln werden in einer formalen Sprache beschrieben Dem Nutzer werden die Regeln in einer leicht verst ndlichen Sprache dargestellt da nicht erwartet werden kann dass er eine Regelsprache erlernt oder mit einem Ontologie Editor hantiert Es muss eine bersetzung stattfinden zwischen nat rlichsprachigen Regeln
129. rseits die Gefahr dass der Nutzer durch diese Entlastung weniger gefordert wird und die Vergesslichkeit zunimmt Hilflo sigkeit im Umgang mit fehlerhaften Arbeitsbedingungen von Ger ten und Anwendungen Dem Nutzer werden leicht verst ndliche Funktionen dargestellt Da die Ger te miteinander kooperieren entfallen f r den Nutzer viele Situationen in denen Fehler auftreten k nnen Im Fehlerfall wird dem Nutzer ein L sungsvorschlag angeboten so dass keine Gef hl der Hilflosigkeit mehr auftreten sollte Wie l sst sich messen dass das entwickelte System intuitiver als vergleichbare Systeme ist Das System ist intuitiver wenn es dem Nutzer den Umgang mit seiner elektronischen Umgebung erleichtert Offene Fragen e Untersuchung der Usability Wie einfach l sst sich das System vom Nutzer bedienen Welche Voraussetzungen ben tigt der Nutzer Muss er ein Fachmann sein Wie geht ein Laie damit um Gibt es Unterscheide zwischen jungen und lteren Nutzern Wird Fachwissen ben tigt e Wie ist die Performanz Erfolgt eine Antwort des Systems in Echtzeit oder wird ein Aktion Film erst aufgenommen nachdem Telefonat beendet ist e Wie kann der Nutzer eigene Regeln konfigurieren erfassen e Nutzerverhalten versus erwartetes Systemverhalten 91 7 Zusammenfassung Das Ziel dieser Diplomarbeit war es eine Middleware zu entwickeln die die nahtlose Inte gration und Kooperation von Ger ten erm glicht Dadurch soll im Umfeld des Ubiquitou
130. s Computing der Umgang mit der Technik f r den Nutzer intuitiver werden Im Zusammen hang mit der Context Awareness kann insbesondere lteren Menschen ein unabh ngigeres Leben erm glicht werden In Kapitel 2 werden Anwendungsbereiche in der Wohnumgebung identifiziert die typische Situationen lterer Menschen wie Notf lle Vergesslichkeit und Verzweiflung im Umgang mit fehlerhafter Technik vorstellen Besonders in diesen Situationen soll die entwickelte Middleware helfen Zuerst werden Szenarien beschrieben die ein realistisches Bild vom Ein satzbereich vermitteln Aus diesen werden Anwendungsf lle abgeleitet die Anforderungen f r die Konzeption und die sp tere Umsetzung aufstellen Zun chst wurden verwandte Ar beiten und existierende Technologien auf diese Anforderungen untersucht siehe Kapitel 3 Die daraus gewonnenen Erkenntnisse flossen direkt in den Entwurf der konzeptionellen Ar chitektur ein siehe Abschnitt 4 2 Desweiteren wurde der Einsatz von Ontologien zur Modellierung der Smart Environments untersucht F r die Modellierung vielf ltiger Anwendungsdom nen eignen sich Ontologien die mit der Web Ontology Language OWL beschrieben werden sehr gut OWL bietet den Vorteil der umfassenden semantischen Beschreibung von Konzepten und der Inter operabilit t zwischen den Ontologien Deshalb sind OWL Ontologien die erste Wahl bei Projekten mit dem Ziel der Entwicklung von Smart Environments und kontextbewu ten Infrastrukt
131. sache wird durch ein bestimmtes Ereignis ausgel st Das kann zum einen der Nutzer sein der verschiedene Ger te bedient und eine Aufgabe ausf hrt um so mit ihnen eine Ziel zu erreichen Ohne direkte Nutzerinteraktion wird die Kooperation basierend auf einem Regelwerk automatisch gestartet Interessant ist der Aspekt welche Ger te und mit welcher Funktion an der Kooperation beteiligt werden Die Kooperation wird realisiert durch die Orchestrierung der unterschiedlichene Dienste die von den Ger ten angeboten werden Der Home Controller enth lt die Anwendungs logik und ruft die verschiedenen Dienste auf Damit eine Ger t seinen Dienst oder seine Dienste anbieten kann muss es auf die Dienste anderer Ger te zugreifen Damit in diesem Prototypen der Videorekorder das aktuelle Fernsehprogramm f r den Nutzer aufnehmen kann muss der VideoAufnahmeDienst mit den Parametern aktuelles Fernsehprogramm also Fernsehsender und Dauer der Aufnahme aufgerufen werden Die Parameter werden durch den Home Controller ermittelt Dieser erh lt die Werte vom FernseherDienst F r die Beschreibung der m glichen Kooperationen zwischen Ger ten gibt es die soge nannten Tasks Diese definieren wie verschiedene Ger te miteinander kooperieren k nnen In einem Task wird definiert welche Ger tetypen beteiligt sind und welche Parameter und Daten von den Ger ten ben tigt werden siehe dazu Unterabschnitt 4 1 3 Der Home Con troller speichert dieses Wissen ber die
132. schten Ansatzes gebrachtet 92 7 ZUSAMMENFASSUNG hatte Kontextdaten werden im Protoyp durch Nutzereingaben simuliert Bisher wurde der Prototyp nur auf einem PC getestet Das bedeutet alle OSGi Bundles laufen in der freien OSGi Implementierung Knopflerfish auf einer virtuellen Maschine Als n chstes muss getestet werden wie OSGi Bundles auf heterogenen Hardware Plattformen instal liert werden k nnen und in einem solchen verteilten System lauff hig sind Dabei m ssen die Aspekte zur verteilten Kommunikation in OSGi und die Performance eines solchen Sy stems untersucht werden Dies wurde vorliegend nicht untersucht da es dem Schwerpunkt der Aufgabenstellung nicht entsprach Es konnte nur theoretisch untersucht werden ob die dynamische und nahtlose Integrati on und Kooperation dazu beitr gt den Umgang mit Technik intuitiver zu gestalten Die Annahme dass besonders lteren Menschen dadurch ein erleichtertes und unabh ngigeres Leben erm glicht werden kann kann nur unter Vorbehalt best tigt werden Es ist sicher lich eine gro e Hilfe wenn die Ger te automatisch f r den Nutzer Aufgaben erledigen ihn in allen erdenklichen Situationen unterst tzen und im Fehlerfall Hilfe organisieren Das kann aber auch dazu f hren dass der Nutzer sich zu sehr an die Unterst tzung gew hnt und dadurch noch abh ngiger M glicherweise wird ein Nutzer noch vergesslicher wenn sein Alltagsumfeld vollst ndig automatisiert ist und ihn auch an je
133. se haben eine Beschreibung ihrer Dienste und es soll untersucht werden ob und wie gut die automatische Klassifizierung funktioniert Der Laptop bietet Funktionalit ten die mit dem Fernseher und dem Videorekorder identisch sind Mit dem Laptop kann auch Vi deo von einer Quelle aufgezeichnet und vom Laptop abgespielt werden Das Radio bietet einen AudioWiedergabeDienst den auch der Fernseher bietet Das Handy hat die gleiche Funktionalit t wie das station re Telefon und wird automatisch in die Kategorie Telefon eingef gt Zur Verifikation wird der Versuch unternommen ein Ger t zu integrieren welches in keine der bekannten Kategorien einsortiert werden kann Die Integration muss in diesem Fall fehlschlagen und der Nutzer wird dar ber informiert dass dieses Ger t manuell in eine Kategorie eingef gt werden muss 5 1 6 Dienste Jedes Ger t in diesem Ansatz soll als Dienst OSGi Bundle umgesetzt werden und hat seine spezifische gekapselte Funktionalit t auf die mit Getter und Setter Methoden zuge griffen wird Ein Dienst ist zum Beispiel der Show TextService Dieser wird von der Waschmaschine vom Geschirrsp ler und Fernseher umgesetzt welche die F higkeit engl Capability ShowText haben Die Dienste ergeben sich aus den Ger ten und deren F higkeiten 84 5 IMPLEMENTIERUNG Suchen eines geeigneten Dienstes Eine Komponente die einen Dienst sucht findet den geeigneten Dienst anhand von se mantischen Beschreibungen G
134. sich au erhalb der Systemgrenze ist also extern Ger te sind einerseits Teil des Systems aber auch Akteure Den Akteuren k nnen folgende Rollen zugeordnet werden e Nutzer e Bewohner 14 2 IDENTIFIKATION DER ANWENDUNGSDOMANE Freund des Bewohners Familienangeh riger Schornsteinfeger Nachbar Anrufer System Ger tehersteller externe Terminplanungsanwendung eines Ger teherstellers Systemadministrator Ger t F r das bessere Verst ndnis der Anwendungsdom ne werden f r die oben genannten ab strakten Anwendungsf lle die folgenden detaillierten Beispiele aufgef hrt Anwendungsfall 1 Anwendungsfallname Akteure Anzeigen des Ger testatus Initiiert von Bewohner Kommuniziert mit abzufragendem Ger t Ereignisfluss 1 Der Bewohner ruft das Auswahlmenti zur Abfrage eines Ger testatus auf System zeigt vorhandene Ger te an Der Bewohner w hlt ein Ger t aus der Liste aus Das System fragt den Status des Ger tes ab Das Ger t schickt seinen Status an das System Das System leitet die Statusmeldung an das Ger t weiter das die Aufmerksamkeit des Bewohners hat Anfangsbedingungen Abschlussbedingungen Qualit tsanforderungen Keine Statusmeldung wurde auf dem Display angezeigt Der Bewohner erh lt die gew nschte Statusmeldung innerhalb von 5 Sekunden 2 2 ANWENDUNGSFALLE 15 Anwendungsfall 2 Anwendungsfallname Steuere Ger t fern Akteure Initiiert von
135. sich den L sungsvorschlag zu dem Fehler der Geschirrsp lmaschine anzeigen l sst 2 Als Janet in das Wohnzimmer kommt wird die Fehlermitteilung der Geschirrsp lma schine und die dazugeh rige Hilfestellung bereits auf dem gro en Fernseher angezeigt Mit dem Fernseher kann Janet besser interagieren da sie dazu die Fernbedienung nut zen kann mit der sie sehr vertraut ist bessere Interaktionsm glichkeit und auf dem Fernseher eine gro e bersichtliche Men f hrung mit Bildern und Sprache dargestellt werden kann 3 Die Hilfestellung empfiehlt bei diesem Problem den Hersteller zu kontaktieren um weitere Hilfe anzufordern 4 Janet w hlt auf dem Men den Punkt Hilfe vom Hersteller anfordern aus Das System stellt eine Internetverbindung zum Ger tehersteller her und sendet den Fehlerbericht an ihn 5 Auf Herstellerseite wird zu dem Fehler eine Fehlerl sung aus einer Datenbank her ausgesucht und an das System geschickt 6 Das System stellt fest dass Janet den Fehler nicht alleine beheben kann und die Hilfe von einem Fachmann ben tigt Dazu muss ein Reparaturtermin vereinbart werden Das System zeigt Janet den Men punkt Reparaturtermin vereinbaren an 7 Janet hat noch Garantie auf das Ger t und aktiviert den Men punkt Reparaturtermin vereinbaren Janets Terminkalenderanwendung verhandelt m gliche Termine f r die Reparatur und schl gt ihr diese vor Janet kann sich f r einen Termin entscheiden Dieser wird auch gleich in
136. sierung der ambienten Netzwerkinfrastruktur 2 Integration von innovativen Subsystem und Komponenten der Intelligenten Umge bung 3 Bereitstellung von fortgeschrittenen personalisierten angepasst an Nutzerpr feren zen kontextabh ngigen Diensten und Benutzerschnittstellen 4 Die einfache Entwicklung und Deployment und koordinierter Ablauf der nutzerbe zogenen Anwendungen 5 Orchestrierung und Koordination von Diensten und Anwendungen Dadurch laufen diese koordiniert ab und es gibt keine Konflikte zwischen den Features 6 Entwicklern werden High Level Kommandos bereitgestellt 7 Die Middleware ist kontextbewusst Kontextereignisse der intelligenten Umgebung werden an die Anwendungen und Dienste weitergeleitet Anwendungen haben durch Virtualisierungschicht high level Zugriff auf 8 Schicht zur Erfassung von Kontext und der Situationsmodellierung durch Reasoning und erm glichen von intelligenten Nutzerinteraktion 9 Anwendungs und oder Diensteanbieter sollen in der Lage sein existierende Dienste zu nutzen und zu kombinieren f r komplexere Dienste Dienste m ssen sich selbst advertisen beschreiben der F higkeiten Attribute und Utilities 10 Service Registry Directory ver ffentlichen und Auffinden von Diensten 3 2 6 Schlussfolgern auf Kontext im Smarthome Ein SWRL Ansatz Aktuelle Forschungsarbeit 20 aus dem Jahr 2007 dass ein kontextabh ngiges System im Smart Home Bereich vorstellt Der Ansatz basiert auf einer
137. sks Nutzer und System Tasks Systemlogik Komplexe Tasks werden aus atomaren Tasks zusammengesetzt Aus den vorhandenen Ger ten und ihren F higkeiten Eingabe Ausgabe Verarbeitung Kontrollfunktionen und verf gbaren Inhalten werden automatisch Tasks erstellt und dem Nutzer angeboten der sich dann entscheiden kann ob diese ausgef hrt werden Es werden dazu Nutzerw nsche Kontrollanfragen und die aktuelle Situation ber cksichtigt Das be schreibt die Tasks die sich aus der Konfiguration des Systems und dem aktuellen Zustand ergeben Tasks k nnen ebenfalls durch Regeln ausgel st werden deren Bedingungen erf llt sind Dann ist ein Task die Aktion die ausgef hrt wird und die Logik enth lt Eine Task Definition ergibt sich aus der Schnittstellen der beteiligten Ger te dem Kon text und wie diese miteinander interagieren k nnen Aus der Task Definition ergibt sich wie die Ger te miteinander integriert werden Dazu muss bekannt sein welche Ger te zur Verf gung stehen und wie diese mit einander kommunizieren Daf r werden im Vorfeld die entscheidenden Ger teparameter genau definiert Eingabe Ausgabe m gliche Interaktion Beispiel ist die Integration von einem Handy mit einem Navigationsger t Das Navigations ger t hat ein gr eres Display und auf diesem k nnen SMS besser gelesen und eingegeben werden Zus tzlich l t sich ein Telefonat ber das Navigationsger t annehmen weil dieses 68 4 KONZEPTION ein Mikrof
138. st dann werden die Eintr ge F higkeiten Status aktuell vom Ger t ausgef hrter Task in der Device Registry mit dem aktuellen Profil abgeglichen Daraufhin wird das Profil in der Knowledge Base aktualisiert Der Kon textdienst wird ber alle Kontext nderungen eines Ger t informiert die bei ihm registriert wurden und der Kontextdienst benachrichtigt alle Abonnenten Die Discovery und Publishing von Diensten erfolgt mit semantischen Attributen Die In tegration und Komposition von Diensten erfolgt aufgrund der semantischen Beschreibung von Diensten 4 2 ARCHITEKTUR 73 4 2 14 3 Semantic Service Discovery Diese Komponente dient dazu zu vorhandenem Kontext den passenden Dienst zu finden In einer Ubiquitous Computing Umgebung sind potentiell viele Ger te und damit viele Services vorhanden 23 Diese Komponente ermittelt zu einer Anfrage mit semantischen Attributen den geeigneten Dienst siehe dazu Semantic Web Services In 26 wird vorgeschlagen relevante Dienste in Pervasive Environments mit Hilfe von Semantik und Kontext zu finden Sie sagen dass eine auf String Vergleich basierende Service Beschreibung und Suche in Pervasive Environments nicht funktionieren kann da jeder Geratehersteller und somit Service Anbieter eine unterschiedliche Beschreibung ver wendet Aus diesem Grund muss die Beschreibung von Diensten semantisch erfolgen Daher erfolgt in dieser Arbeit die Umsetzung mit OWL und einem kontextabhangigen Ontologie
139. stem in einer Situation verhalten sollte Alle ausgefiihrten Regeln stehen in einer chronologischen Liste Falls der Nutzer Probleme haben sollte das Systemverhalten zu verstehen dann kann er die Regeln so nachvollziehen Je mehr Vorg nge und Situationen vom System automatisiert werden und dem Nutzer auf diese Weise Arbeit abgenommen wird desto gr er ist das Risiko dass der Nutzer die bersicht verliert welche Regeln im Hintergrund ablaufen Daher ist es wichtig dass der Nutzer jederzeit Zugriff auf die Ablauf der Regeln informieren kann Dazu geh ren auch verst ndliche Fehlerberichte die deutlich machen warum Regeln nicht ausgef hrt werden konnten 4 2 10 10 Regel Debugger Diese Komponente erm glicht es dem Administrator Regeln zu debuggen Damit lassen sich ausgef hrte Regeln gegebenenfalls r ckg ngig machen wiederholen oder k nnen mo difziert werden Von dem Nutzer kann nicht erwartet werden dass er das System auf dieser Ebene versteht 4 2 11 Taskmodellierung Wenn eine Regel feuert dann wird aus der Aktion ein Task modelliert Greift auf Daten in den Ontologien zu um zu ermitteln ob Task m glich ist Falls ein Ger t f r die Ausf hrung eines Tasks ben tigt wird dann kann es aktiviert werden Der Taskmodellierer greift auf das Repository zu Die A Box zu der Ger teontologie wird mit den Ger ten instantiiert F r die Ausf hrung von Regeln wird auf diese Instanzen zugegriffen Task Modell mit Interaktions Ta
140. t gestartet gestoppt und entfernt werden ohne dass das Gesamtsystem beendet werden muss Die einzelnen Komponenten sind lose gekoppelt dass hei t die Komponenten sind unabh ngig voneinander und der Code eines Bundles ist vor Zugriffen eines anderen Bundles gesch tzt Die Kooperation erfolgt durch das OSGi Connection Model Mit Package Connections werden statische Abh ngigkeiten zwischen Komponenten be zeichnet Service Connections sind dynamische Abh ngigkeiten zwischen Komponenten Probleme die sich aus dem dynamischen Verhalten der Service Connections ergeben wer den durch das dynamische Verhalten von Bundles verursacht Ein Bundle nutzt Services anderer Bundles und diese k nnen zur Laufzeit verschwinden Ein Bundle definiert mit Header in der Manifest Datei welche Pakete es import und welches es exportiert 3 5 Dienste Ein Dienst bietet einer Anwendung eine klar umrissene in der Regel technische Funktio nalit t ber eine Schnittstelle an 12 Eine Dienste orientierte Architektur zeichnet sich durch durch eine lose Kopplung zwischen den verschiedenen Diensten und einer hohen Koh sion innerhalb eines Dienstes aus Dien ste arbeiten unabh ngig voneinander Die Funktionalit t von Diensten ist gekapselt man spricht auch von Black Box Die Kommunikation erfolgt ber standardisierte Schnitt stellen und Datenaustauschformate Nach 3 ist Kopplung die Anzahl der Abh ngigkeiten zwischen Subsystemen und Koh sion ist ein
141. t can be used to characterise the situation of an entity An entity is a person place or object that is considered relevant to the interaction between a user and an application including the user and applications themselves 1 Kontext ist jede Information die genutzt werden kann um die Situation einer Entit t zu beschreiben Eine Entit t kann eine Person Platz oder Objekt sein welches als wichtig erachtet wird f r die Interaktion zwischen einem Nutzer und einer Anwendung den Nutzer und die Anwendung einschlie end 1 Dass hei t unter dem Begriff Kontext werden s mtliche Informationen verstanden die Umst nde und Auspr gungen einer Situation charakterisieren und relevant f r Interaktio nen zwischen Anwendern und einer Anwendung sein k nnen Dabei sind der Anwender und die Anwendung mit eingeschlossen Es gibt die folgenden verschiedenen Kategorien von Kontexten physischer technischer pers nlicher sozialer und anwendungsbezogener Kontext Kontextdaten k nnen an den verschiedensten Stellen innerhalb einer verteilten Anwendung erhoben werden M gliche Kontextquellen sind Sensoren Datenbanken Anwendungen Be nutzereingaben und Interaktionen die grunds tzlich verschieden also heterogen und ver teilt sind Heutige kontextabh ngige Anwendungen und Szenarien sind nur denkbar wenn die verschiedenen und verteilten Kontextdaten zusammengef hrt werden k nnen Ein Kon textdienst hat die Funktion Kontextdaten zusammenzufass
142. teht aus den Basiskonzepten Person Location Activity und Computational Entity Bei der Modellierung werden die Kontextdaten in direkten und indirekten Kontext klassifi ziert Direkter Kontext bezeichnet Kontextdaten die entweder direkt gemessen sensed oder definiert werden Indirekter Kontext entsteht durch Reasoning und Aggregation von direkten Kontextdaten Eine wichtiger Aspekt von Kontextdaten ist die Abh ngigkeit zwischen einzelnen Kon textdaten Diese muss modelliert werden da dadurch Beziehungen zwischen Entit ten angegeben werden und das ist ein Indiz f r die Zuverl ssigkeit und die Qualit t von Kon textdaten In dem Kontextmodell werden Kontextdaten durch Qualit tsattribute genauer spezifiziert Dies ist wichtig da z B gemessene Ortsinformationen innerhalb k rzester Zeit an Aktualit t und somit an Wert verlieren k nnen Es wird angenommen dass definierte Kontextdaten eine h here Zuverl ssigkeit haben als gemessene oder abgeleitete Daten Anhand dieser Klassifizierung der Kontextdaten und in Abh ngigkeit von der Zuverl ssigkeit der unterschiedlichen Kontextarten wird ber den Kontext geschlussfolgert In Kombination mit den Qualit tsattributen der Kontextdaten k nnen so Konflikte aufgesp rt und beseitigt werden Dieser Ansatz basiert auf OWL und nutzt die spezifischen Vorteile von OWL hinsichtlich der Modellentwicklung und der Verarbeitung der Ontologien Nachteilig an diesem Ansatz ist die Definition der Upper On
143. tellt Dienste sind Software Komponenten welche eigentlichen physischen Ger te vor dem Nutzer verbergen Dem Nutzer wird die Ger tefunktionalit t ber benutzerfreundliche Schnittstellen angeboten ber die er die Ger te bedient Die Dienste laufen auf einer Diensteplattform siehe Abschnitt 3 3 F r die Umsetzung wird eine OSGi Implementierung verwendet siehe Kapitel 5 Dazu wird jedes Ger t als Bundle realisiert wodurch eine einfache Verteilung realisiert wird Es gibt einen zentralen HomeController auf dem die Kernfunktionalit t der Komponenten installiert wird Auf al le Ger te die in der Anwendungsdom ne vorkommen k nnen und in das System integriert werden sollen wird der Teil der Middleware installiert der f r die Kommunikation mit dem HomeController notwendig ist Ger te auf denen die Middleware nicht direkt installiert werden kann da sie nicht die Hardware Voraussetzungen erf llen werden durch Technolo gien wie Jini Surrogate gekapselt In Abbildung 4 2 ist der Entwurf der Systemarchitektur mit den konzipierten Komponenten dargestellt Es gibt eine Unterscheidung zwischen physischen Ger ten und logischen Komponenten Auf einem Ger t k nnen mehrere logische Komponenten installiert werden Es ist ein verteiltes System und die einzelnen Komponenten k nnen aus Performanz Sicherheitsgr nden auf verschiedene Hardwareknoten verteilt werden Inttps surrogate dev java net 56 4 KONZEPTION Auf den Ger ten
144. tem ausgef hrt hat e Der Nutzer soll in die Ausf hrung von Regeln jederzeit eingreifen k nnen e Das System soll eine uniforme homogene Bedienung und Systemverhalten durch einheitliche Benutzerschnittstellen bieten Das gilt auch unterschiedliche Ger te und Ger te gleicher Kategorie aber von unterschiedlichen Herstellern e Die Kooperation der Ger te soll dahingehend optimiert werden dass dem Nutzer die beste Usability geboten wird e Verbesserung der Usability von Ger ten In jeder Situation soll das Ger t mit der besten Nutzbarkeit f r den Nutzer ausgew hlt werden Darstellen einer Text nachricht wie SMS auf dem Fernseher da dieser eine gr ere Schrift darstellen kann e ltere Menschen sollen das System bedienen k nnen Zu dieser Thematik m s sen Usability Tests durchgef hrt werden Prototypisches Haus bauen e Die Benutzerschnittstelle muss sich an den Kontext des Nutzers anpassen dass hei t an seinen Ort das Interaktionsger t oder seine Behinderungen e Barrierefreie Bedienung muss gegeben sein Interaktion mit Ger ten muss mit eingeschr nktem Seh und H rverm gen m glich sein Beispielsweise Verwen dung von kontrastreicher Schrift Keine Verwendung von hohen T nen Die 2 4 ZUSAMMENFASSUNG 25 Ger te intelligenten Gegenst nde sollen weitestgehend unmerklich den Nutzer unterst tzen 8 Technologische Erweiterbarkeit das hei t das System muss neue Ger te und Tech nologien integrieren k
145. teontologie ein Fakten die von Ger ten relevant sind werden durch die Ger teontologie bestimmt In erster Linie sind das die Dienste die das Ger t zur Verf gung stellt Weiter hin ist der Kontext des Ger tes relevant dass heisst wo befindet es sich und wer bedient 4 2 14 1 Device Registry Wenn sich das Gerat in der Anmeldungsphase beim HomeController anmeldet dann wird das Ger t in die Device Registry eingetragen Die Dienste eines Ger te werden mit einer semantischen Beschreibungssprache f r Dienste beschrieben und bei der Anmeldung an 72 4 KONZEPTION den HomeController wird diese Beschreibung an die Device Registry bertragen Wird ein Ger t aus der Anwendungsdom ne entfernt dann wird es abgemeldet und aus der Device Registry ausgetragen Meldet sich ein Gerat nicht in einem festgelegten Zeitintervall dann verbleibt es in der Device Registry aber der Status wird auf unbekannt ge ndert Wird ein Ger t ausgeschaltet dann verbleibt es im Repository und der Status wird auf inaktiv gesetzt Das Ger t wird bei der Ereignisbenachrichtigungs Komponente registriert und somit werden alle Ereignisse vom HomeController registriert und an die daf r registrierten EventListener propagiert Der aktueller Zustand des Ger tes wird durch seinen Kontext repr sentiert Die Device Registry informiert die Knowledge Base ber die nderung und f gt das neue Ger t hinzu Die Rule Engine wird von der Knowledge Base ber nderung
146. tology als Basis f r die Ableitung der Lower Ontologies da diese Herangehensweise die Allgemeing ltigkeit und die Erweiterbarkeit einschr nkt Dom nen spezifische Konzepte der Subdom ne die in der Upper Ontology nicht ber ck sichtigt wurden k nnen so nicht konsistent modelliert werden 3 1 5 Chen s Standard Ontology for Ubiquitous and Pervasive Applications SOUPA Der Entwurf von Chen et al siehe 4 w hlt ebenfalls eine ontologiebasierte Herange hensweise Es wird OWL f r die Kontextmodellierung verwendet und es wird Reasoning auf Kontext unterst tzt SOUPA ist eine Weiterentwicklung von CoBrA Ont um Kon zepte wie Document Event und Policy und somit Teil der Context Broker Architecture CoBrA CoBrA ist eine Architektur f r die Unterst tzung von kontextabh ngigen Syste men in der Intelligent Meeting Room Domain und bietet keine explizite Unterst tzung f r die Modellierung von allgemeinem Kontext in heterogenen Umgebungen Die semantische Inttp cobra umbc edu index html 30 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN Meeting mtg Region Es Calc Es lt lt owl imports CD SOUPA Core SOUPA Extension XML Namespace Abbildung 3 1 SOUPA Ontology 2004 06 4 Interoperabilit t ist nur gew hrleistet wenn alle teilnehmenden Anwendungen die SOU PA Ontologie verwenden beziehungsweise wenn die verwendeten Ontologien in SOUPA bersetzt werden
147. tsteuerung und Heizungssteuerung 1 Wenn niemand im Raum ist dann kann das Smarthome das Licht in diesem Raum ausschalten 2 Wenn jemand den Raum betritt dann kann das Smarthome das Licht in diesem Raum anschalten 44 3 VERWANDTE ARBEITEN UND EXISTIERENDE TECHNOLOGIEN 3 Wenn jemand zu Hause ist und die Temperatur eines Raumes kleiner ist als die Minimumtemperatur am Radiator in einem Raum dann soll das Smarthome den Radiator einschalten Die Resultate der Inferenzschicht werden wie auch bei Sensoren an den ereignisgesteuerten Bus ausgegeben an den Akteure z B gesteuerte Lampen Heizungen angeschlossen sind Ein Akteur abonniert Freignisse auf die er dann entsprechend reagiert Die generierten Ereignisse haben das gleiche Nachrichtenformat wie von Sensoren ausgel ste Ereignisse Implementierung Zum Testen der Architektur wurde ein Testfall implementiert Es wird die Robustheit des OSGi Ereignisgesteuerten Bus Event Admin getestet die teilweise Validit t der Ontologie den Schlu folgerungmechanismus und die ausgel sten Aktionen Der Prototyp basiert auf Knopflerfish einer v4 OSGi Implementierung welche Event Admin integriert hat Aus der Menge von m glichen regelbasierten OWL Reasonern wurde der freie Reasoner KAON2 ausgew hlt da er javabasiert ist und SWRL unterst tzt Das Szenario orientiert sich am Follow me Szenario 22 und ist wie folgt Es bewegt sich jemand im Raum und das System schaltet automatisch das Licht
148. tungsger te Schwarze Ware elektrische K che und Haushaltsger te Wei e Ware und Steuerungs 80 5 IMPLEMENTIERUNG ger te Heizung Licht F r die Modellierung der Ontologien wurde der Prot g OWL Editor in der Version 3 3 1 verwendet In der Ger teontologie wurden alle Ger teklassen die in dem Prototyp vor kommen modelliert Dann wurden die Individuen dieser OWL Klassen in die Ontologie eingeben Damit wurden die Verkn pfungen und die Modellierung auf Vollst ndigkeit ber pr ft Die Benennung der OWL Konzepte und der Attribute ist in Englisch da das die Standardsprache f r die Entwicklung von Ontologien ist Die Ontologie ist folgenderma en aufgebaut Das oberste Konzept ist das abstrakte Ger t Das Konzept Ger t hat die Eigenschaften engl Properties hasCapabilities hasEvent has Status inAwarenessOf isLocatedIn und ownedBy Das sind sogenannte Object Properties dass hei t sie haben als Wert ein Objekt sind mit einem anderen Objekt verbunden Mit den Objekt Attributen wird die Relation zwischen den Konzepten definiert Im Gegensatz dazu haben Datatype Properties nur einfache Datentypen als m gliche Werte Die Bedeu tung der Object Properties ist wie folgt e hasCapabilities ein Ger t besitzt multiple F higkeiten engl Capabilities pl e hasEvent ein Ger t hat multiple Ereignisse die es ausl sen kann e hasStatus ein Ger t hat einen Statustypen aus dem Status Konzept e inAwarenessOf damit wird
149. tur auf der mittleren Ebene Sie sind de taillierter als Policen und k nnen in verschiedenen Regelsprachen ausgedr ckt werden F r die Middleware ist es nicht entscheidend in welcher Regelsprache die Regeln umgesetzt wer den da es die bergeordneten Policen gibt Regeln bestimmen wie etwas gemacht werden soll Tasks bestimmen was exakt gemacht werden soll Regeln definieren die Ausf hrung von Tasks Regeln sind abh ngig vom Kontext des Nut zers F r jede Dom ne gibt es eine minimale Regelmenge die vorhanden sein muss um das Systemverhalten zu definieren Die Grundregeln f r Standardtasks sind vordefiniert Der Administrator kann zus tzlich Regeln definieren wenn es neue Ger te mit neuen Tasks gibt und Abh ngigkeiten zwischen verschiedenen Tasks geregelt werden sollen Das Systemverhalten wird definiert durch die Beschreibung der Regeln mit einer Regel 54 4 KONZEPTION sprache die dem Event Condition Action ECA Pattern folgt z B RuleML Jede Regel besteht hierbei aus einem Ereignis Teil einem Bedingungs Teil und einem Aktions Teil Zwischen Ereignissen und Kontextdaten wird hier nicht unterschieden Wenn von einem Ger t ein Ereignis ausgel st wird dann wird es als eine Kontext nderung betrachtet Das Ereignis wird von einem Ger t ausgel st In diesem Pattern wird durch das Ereignis ein Interesse modelliert z B an einem Wechsel in den Kontextdaten Condition steht f r eine Bedingung die vor Ausf hren der Akti
150. uch integrierbar sein Das System soll herstellerunabh ngig sein Das System soll unabh ngig von Netzwerk schnittstellen und dem Netzwerkprotokoll sein Das Ger t soll unabh ngig von dem verwendeten Betriebssystem integriert werden k nnen Die Kooperation zwischen verf gbaren heterogenen Ger ten soll erm glicht werden Teilnehmende Ger te sol len dem System ihre Dienste Funktionalit t zur Verf gung stellen Wie die Kom munikation zwischen Ger ten erfolgt spielt keine Rolle Entscheidend ist die se mantische Integration unabh ngig von einem bestimmten Protokoll Der Nutzer soll Ger te anmelden k nnen Zwischen Ger ten soll eine nahtlose Kooperation ohne vorherige Konfiguration m glich sein Der Nutzer soll dem Ger te nicht mitteilen m ssen wie es mit einem anderen Ger t kommuniziert oder welche Funktionalit ten es von diesem Ger t anzeigt Koopera tion von beliebigen Ger ten um dem Nutzer die beste Bedienung des Systems zu erm glichen Beispiel Das aktuelle Fernsehprogramm auf einem beliebigen Aufnahmeger t auf nehmen Ger te m ssen eine semantische Selbstbeschreibung haben Ger te beschreiben ihre Funktionalit t semantisch so dass diese vom System ver standen werden k nnen Die Ger te sollen sich selbst beschreiben so dass ihre Funktionalit ten vom System verstanden werden und in das Gesamtsystem inte griert werden k nnen Finden von Ger ten mit Suche nach deren F higkeiten Das System so
151. ur Maus oder per Stift mit einem Ger t interagieren In diesem Fall ist die Spracheingabe und Sprachausgabe f r die Interaktion mit einem Ger t besser geeignet In 28 wird ein Ansatz beschrieben wie die Modellierung multimodaler adaptiver Benut zerschnittstellen von Werkzeugen unterst tzt werden kann Mit diesem Ansatz lassen sich die geforderten abstrakten Benutzerschnittstellen erzeugen Eine Kernfrage des Benutzerschnittstellen Designs ist es die Benutzerschnittstelle so zu gestalten dass der Nutzer diese leicht handhaben kann und hier insbesondere der ltere Nutzer die Funktionen und Aufgaben eines jeden dargestellten Dienstes versteht 4 2 ARCHITEKTUR 63 Abstrakte Benutzerschnittstelle Um die Anforderung Kontrollieren von Funktionen eines entfernten Ger tes von einem ge eignetem Ger t aus Fernbedienung umzusetzen m ssen Funktionalit ten eines entfernten Ger tes auf dem lokalen Ger t dargestellt werden Die Funktionalit ten m ssen abstrakt definiert werden so dass sie auf den verschiedenen Ger tentypen angezeigt werden k nnen und der Nutzer dieses Funktionen aufrufen kann Eine Fragestellung die dabei aufgewor fen wurde ist und in weiteren Arbeiten n her zu untersuchen ist es herauszufinden wie die Funktionalit t eines entfernten Ger tes auf dem aktuellen Ger t des Nutzers integriert und pr sentiert werden kann Wenn Daten eingegeben werden und Kontrollelemente bet tigt werden dann m ssen diese erfasst
152. uren Regeln und Policen f r die nahtlose Kooperation und Integration von Ger ten zu finden war ein weiterer Bearbeitungsschwerpunkt Diesbez glich wurde in der Konzeption eine daf r entwickelte Dreischichtige Kooperationsarchitektur eingef hrt siehe Abschnitt 4 1 Sie definiert die Policen auf der obersten Regeln auf der mittleren und Tasks auf der untersten Schicht Es wird erl utert wie sich diese Schichten voneinander unterscheiden wie sie erstellt und f r die Kooperation und Integration verwendet werden Parallel zu der Konzeptionsphase wurde mit der Erstellung eines Prototypen begonnen In diesem wurden Konzepte implementiert um diese zu verifizieren So konnten bestimmte Probleme verdeutlicht werden Desweiteren zeigt der Prototyp die Realisierbarkeit des ge w hlten Ansatzes Er basiert auf OSGi Jedes Ger t welches in die Middleware integriert wird ist als Dienst also als OSGi Bundle realisiert Die Idee zur Verwendung von OSGi ist w hrend der Sichtung der verwandten Arbeiten entstanden Es wird bereits in Smar thomes f r die Vernetzung von Haushaltsger ten verwendet und in gro en Forschungspro jekten eingesetzt Der Prototyp erlaubt es allerdings nicht Regeln mit einem Rule Builder automatisch erstellen zu lassen Sie m ssen manuell in der Regelsprache SWRL beschrie ben werden Es wurde auch keine Anbindung an einen Kontextdienst implementiert da dies keinen weiteren Nutzen f r die Verifikation des hier gew n
153. vernetzungstechnologien siehe Abschnitt 3 3 und zu Web Services Als zentrale Instanz ist der Home Controller daf r verantwortlich Ger te zu finden und zu registrieren Eine Netzwerkverbindung ist f r die Vernetzung der Ger te zwingend erforder lich Ger te welche in die Umgebung hinzukommen auf denen die Middleware l uft und eine Netzwerkverbindung besteht suchen bei der Initialisierung nach dem Home Controller Das erfolgt wie bei Peer to Peer Netzwerken ber Discovery Protokolle Eine Suchanfrage wird per Broadcast in das Netzwerk gesendet Entweder wird dann der Home Control ler auf direktem Weg erreicht und dieser schickt eine Antwortnachricht zur ck an den Sender oder ein anderes Ger t in Reichweite welche bereits beim Home Controller regi striert ist antwortet auf die Suchanfrage Dieses Ger t arbeitet als Proxy und schickt die Adresse des Home Controllers als Antwort zur ck Wenn das suchende Ger t die Home Controller Adresse erhalten hat stellt es eine direkte Verbindung zu diesem her Wenn die Kommunikationsverbindung aufgebaut ist bermittelt das Ger t seine Beschreibungs daten zu Ger tedaten zur Funktionalit t und den Ger te internen Policy an den Home Controller Der Home Controller registriert das Ger t in der Device Registry siehe Unter unterabschnitt 4 2 14 1 und tr gt die Policies in der Knowlegebase ein Benutzerschnittstelle Der Home Controller hat eine bersichtliche Benutzerschnittstelle die
154. wendung der Regeln Je tiefer in der Hierarchie abgestiegen wird desto gr er ist die Flexibilit t f r das 50 4 KONZEPTION Policies a 2 Rules x d amp N Tasks 4 Abbildung 4 1 Dreischichtige Kooperationsarchitektur Bilden von Regeln Der Nutzer befindet sich in einer Alltagssituation in seiner Anwendungsdom ne Es tritt ein Ereignis auf auf das reagiert werden soll also eine Aktion ausgef hrt werden muss Das System erkennt die High level Situation Das System ermittelt dazu welche Ger te an dieser Situation beteiligt sind und den dazugeh rigen aktuellen Kontext Der Nutzer m chte f r diese Situation und dieses Freignis eine Police festlegen Dazu muss er wissen welche Aktionen und mit welchen Ger ten in dieser Situation m glich sind Damit der Nutzer Einstellungen vornehmen kann muss ihm die Situation verdeutlicht werden Das System zeigt dazu die beteiligte Ger te den Kontext und auftretende Ereig nisse an Das System erzeugt automatisch m gliche Regeln und zeigt diese dem Nutzer in mehreren Detaillierungsgraden an Zum Beispiel Es ist abends Das Licht ist ged mpft und der Nutzer liegt auf dem Bett Das System schlussfolgert aus diesem Kontext dass sich der Nutzer entspannt und nicht gest rt werden m chte Es tritt ein Ereignis auf Jemand klingelt an der Wohnungst r Die Aktion ist Zeige Videobild vom Eingang auf dem Fernseher an 4 1 1 Policen Policen sind h her
155. werden Administratorsicht In dieser Sicht nimmt der Administrator die Einstellung am System vor Der Administrator definiert feingranulare Regeln vor die von den Policen in der Benutzersicht verwendet werden Der Administrator legt fest wie neue Input Output Verarbeitungs Ger te 4 2 ARCHITEKTUR 59 dynamisch gefunden werden Dazu wird die existierende Ontologie f r jedes neue Ger t um ein Konzept erweitert Der Administrator hat als einzige Person direkten Zugriff auf die Ontologien Er erweitert die Regeln f r die Kooperation zwischen den Ger ten Wenn ein Ger t nicht automatisch in die Ontologie eingeordnet werden kann dann schaut sich der Administrator die Funktionalit ten des Ger tes an und f gt dieses manuell ein Der Standardfall sollte aber sein dass jedes auf dem Markt erh ltliche Ger t nahtlos in das System integriert werden kann ohne dass eine weitere Konfiguration erforderlich ist Wenn es bisher in dieser Umgebung keinen VideoRenderer gegeben hat das Konzept unbekannt war dann wird definiert dass ein VideoRenderer ein Ger t ist welches Inhalte vom Typ Video darstellt Falls es das Konzept f r den Inhaltstyp Video bisher noch nicht gab dann wird das Konzept Video unter darstellbaren Inhalten eingeordnet Das System ermittelt in diesem Augenblick wie das neue Ger t mit den existierenden Ger ten kooperieren kann Wird ein Videorekorder eingef gt dann ermittelt das System dass der Videorekorder Inha
156. werden was er tun muss e Ebenfalls wichtig ist die berwachung von Ger tefunktionen sowie die Statu sabfrage aller im System vorhandenen Ger te e m ssen Kontrollfunktionen auf einem geeigneten Ger t angezeigt werden k nnen e Auf einem geeigneten Ger t muss eine bersicht aller verf gbaren Ger te und deren Dienste abrufbar sein e Bei Ereignissen die eine Reaktion erfordern Notfall soll jemand informiert werden erst Recht wenn der Nutzer nicht erreichbar ist oder nicht auf das Er eignis reagiert Es muss dazu eine Priorit tsliste geben in der die Reihenfolge 2 3 ANFORDERUNGSANALYSE 21 IX der Benachrichtigungen festgelegt wird Familie Nachbar Feuerwehr Wei terleitung von Ereignissen Der Nutzer muss diese Ereigniskette definieren k nnen e Ereignisse werden dem Nutzer oder einer vorher definierten Gruppe von Nut zern angezeigt Dem Nutzer werden nur Ereignisse angezeigt die ihn interes sieren oder die er registriert hat Einstellen von Nutzerpr ferenzen Beispiel Wenn jemand an der T r klingelt soll der Nutzer dar ber auf einem Ger t informiert werden mit dem er gerade interagiert Oder der Nutzer soll ber Informationen auf einem Ger t benachrichtigt werden welches er als erstes abruft falls er nicht daheim war Wenn der Nutzer nicht da ist wird sein Nachbar dar ber informiert dass die Waschmaschine des Nutzers ausl uft Anzeige von m glichen Aktionen die mit Ger

Technische Universität Dresden

Contents

Download Pdf Manuals

Related Search

Related Contents

Technische Universit&auml;t Dresden

Contents

Download Pdf Manuals

Related Search

Related Contents

Technische Universität Dresden