gms | German Medical Science

GMS Medizinische Informatik, Biometrie und Epidemiologie

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (GMDS)

ISSN 1860-9171

Partizipative Entwicklung einer Middleware für AAL-Lösungen: Anforderungen und Konzept am Beispiel SOPRANO

Participatory development of a middleware for AAL solutions: requirements and approach – the case of SOPRANO

Originalarbeit

Suche in Medline nach

GMS Med Inform Biom Epidemiol 2008;4(3):Doc19

Die elektronische Version dieses Artikels ist vollständig und ist verfügbar unter: http://www.egms.de/de/journals/mibe/2008-4/mibe000078.shtml

Veröffentlicht: 28. Oktober 2008

© 2008 Balfanz et al.
Dieser Artikel ist ein Open Access-Artikel und steht unter den Creative Commons Lizenzbedingungen (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.de). Er darf vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Zusammenfassung

Dieser Beitrag beschreibt die technisch-funktionalen Grundzüge einer Middleware für Ambient Assisted Living (AAL) Anwendungen am Beispiel des Forschungsprojektes SOPRANO und umreißt die wichtigsten Anforderungsfaktoren an das technische System, sowie deren Erhebungs-Methodik. Die dargestellte Middleware ermöglicht den Aufbau flexibler, erweiterbarer und personalisierbarer AAL-Lösungen mit vergleichsweise geringem Aufwand. Das dargestellte technische Konzept umfasst den technischen Design-Ansatz, sowie insbesondere Komponenten, Eigenschaften und Funktionsweise der AAL-Plattform.

Neben der Erörterung des technischen Konzeptes wird ein weiterer Schwerpunkt gelegt auf die Methode der Anforderungserhebung und die ermittelten Anforderungen. Es wird Einblick gegeben wie in SOPRANO dem Problem begegnet wurde, sozio-technische Systemanforderungen nutzerzentriert zu „erheben“, obschon die Anwender-Zielgruppe hierzu kaum konkrete Vorgaben machen kann.

SOPRANO („Service oriented programmable smart environments for older Europeans“, http://www.soprano-ip.org/) ist ein europäisches Forschungsprojekt, das durch technische Infrastruktur älteren Menschen länger ein unabhängiges Leben in ihrer gewohnten Umgebung ermöglichen soll. SOPRANO konzentriert sich auf die Unterstützung innerhalb des Hauses und betont explizit positive Formen der Unterstützung (engl. well-being). Hierbei steht im Vordergrund, Hilfe nicht nur in Problem- oder Notfallsituationen sicherzustellen sondern ältere Menschen situationsabhängig gerade in alltäglichen Lebenssituationen zu unterstützen.

Schlüsselwörter: Ambient Assisted Living, Ambient Intelligence, partizipative Entwicklung, ontologiezentrierte Entwicklung, SOA, SODA, SOPRANO

Abstract

This paper describes the main features of a middleware for Ambient Assisted Living (AAL) applications, exemplified along the SOPRANO research project. The contribution outlines main requirements towards the technical system and the elicitation methodology.

The presented middleware allows for personalisation and flexible, extendible configuration of AAL solutions with low effort. Concerning the technical concept, the design approach as well as components, qualities and functionality of the AAL platform are depicted. Furthermore the methodology of requirements elicitation is discussed. It is explained how SOPRANO met the problem to elicit socio-technical system requirements in a user-centred manner, although the addressed target group is not expected to be able to express precise guidelines.

SOPRANO („Service oriented programmable smart environments for older Europeans“, http://www.soprano-ip.org/) is a research project funded by the European Commission, which aims at the provision of a technical (AAL) infrastructure to help elderly people to keep their independence and to stay in their familiar environment as long as possible.

SOPRANO focuses on in-house support and emphasises well-being. It is a main goal to secure situation-aware assistance and help not only in case of emergencies but particularly as well in activities of daily living.

Keywords: Ambient Assisted Living, ambient intelligence, participatory development, ontology-driven development, SOA, SODA, SOPRANO


1 Einleitung

Lösungen im Bereich des Ambient Assisted Living (AAL) zielen darauf ab Menschen, die im Alterungsprozess durch schwindende körperliche und geistige Gesundheit an Selbstständigkeit verlieren zu ermöglichen, in ihrer gewohnten Umgebung zu verbleiben und dennoch so weitgehend wie möglich ein selbstbestimmtes Leben in Würde zu führen. Im englischsprachigen Raum hat sich hierfür der Begriff des „Aging in Place“ herausgebildet.

AAL soll dabei durch den Einsatz von intelligenter Technologie die Lebensbedingungen alternder Menschen in ihrem Zuhause an ihre sich ändernden Bedürfnisse anpassen, so z.B. ihre Sicherheit gegen oder bei Notfallsituationen in ihrer Wohnung erhöhen, ggf. ihre Vitalwerte kontrollieren, Erinnerungsfunktionen unterstützen oder auch einer drohenden sozialen Isolierung entgegenwirken. Wenngleich AAL nicht auf die Betrachtung von Technik allein beschränkt sein darf und kann, also auch die soziale und organisatorische Einbindung von medizinischen Leistungserbringern, Freunden und Verwandten mitdenken muss, ist dennoch zur Erreichung der Ziele des AAL Technologie unerlässlich.

Typischerweise tragen unterschiedliche technologische Felder zu entsprechenden Lösungen bei, unter anderem Smart-Homes-Technologien, Ambient-Intelligence-Ansätze, Sensorik, Aktuatorik, Mensch-Maschine-Schnittstellen, eingebettete Systeme u.v.m. Lösungen benötigen mithin die Kooperation einer Vielzahl von Partner aus unterschiedlichen technischen und nicht-technischen Bereichen: Software-Entwicklung, Geräte-Entwicklung, Telecare/Telemedizin, sowie medizinische Leistungserbringer insbesondere häusliche Krankenpflegedienste.

SOPRANO ist ein von der Europäischen Kommission gefördertes Forschungsprojekt, das mit seinen fast 30 Partnern alle genannten Bereiche einbindet. Es hat sich zum Ziel gesetzt unter zentraler Nutzereinbindung ein AAL-System zu konzipieren und umzusetzen, das technisch auf einer offenen und erweiterbaren Plattform basiert, innovative Technologien wie Radar zur Personenortung oder die Nutzung von grafischen Avataren zur Kommunikationsunterstützung einbindet und dennoch flexibel anpassbar und personalisierbar bleibt [1]. SOPRANO konzentriert sich dabei auf die Unterstützung innerhalb des Hauses. Hier steht im Vordergrund, ältere Menschen situationsabhängig in alltäglichen Lebenssituationen zu unterstützen und somit das in der englischsprachigen Literatur verwendete Feld „well-being“ zu adressieren.

Nachfolgend wird in Abschnitt 2 zunächst die Methode der Anforderungserhebung und der Einbindung der Nutzer umrissen und in Abschnitt 3 die gefunden Anforderungen an das technische System dargestellt. Unter Nutzern werden dabei sowohl die durch AAL unterstützten Personen verstanden, als auch alle, die im Weiteren mit dem System umgehen, z.B. Pflegepersonal, Angestellte von Telecare-Anbietern oder auch Verwandte und Freunde der älteren Menschen. Abschnitt 4 erörtert im Detail die technisch-funktionalen Grundzüge der SOPRANO Ambient Middleware System und das generelle technische AAL-Konzept der vorgestellten Lösung. Abschließend werden die Ergebnisse zusammengefasst und ein Ausblick auf die weiteren Arbeiten im Rahmen dieser Plattform-Entwicklung gegeben (Abschnitt 5).


2 Anforderungserhebung als kollaborativer Lernprozess

Eine besondere Herausforderung stellte in SOPRANO die interdisziplinäre Definition der Anforderungen dar. Da es sich bei SOPRANO um einen sozio-technisch innovierenden Ansatz handelt, der sowohl bisherige Abläufe und Prozesse in der häuslichen Unterstützung alternder Menschen ändern wird, als auch neue Technologien hierzu anwenden und hervorbringen soll, ist eine geradlinige „Abfrage“ von Anforderungen bei den potenziellen Nutzern wie auch bei technischen und nicht-technischen Experten nicht durchführbar. Vielmehr war ein iterativer Lernprozess erforderlich, der in einem Wechselspiel zwischen „technology-push“ und „user requirements pull“ (bzw. „market pull“) eine valide Arbeitshypothese der innovativen Anforderungen (Nutzeranforderungen wie auch Systemanforderungen) hervorbringt.

2.1 Genereller methodischer Ansatz

Für eine kommerzielle Verwertbarkeit ist die Akzeptanz und Angemessenheit einer Lösung für spätere Nutzer (ältere Menschen, aber z.B. auch Pflege- und Telecare-Dienste) von höchster Wichtigkeit. Der methodische Ansatz in SOPRANO ist daher stark nutzerzentriert. Er basiert auf Konzepten des Experience and Application Research [2] und ist insbesondere angelehnt an den ISO Standard 13407 [3] „Human-centred design processes for interactive systems“. ISO 13407 sieht vier Schritte nutzerzentrierten Designs vor, die sich mit fortschreitender Entwicklung einer Lösung mehrfach wiederholen können: (1) Verstehen und Spezifizieren des Nutzungskontexts, (2) Spezifizieren von organisatorischen und Nutzeranforderungen, (3) Erstellen von Designs und Prototypen und (4) Assessment mit Nutzern.

Auf methodischer Ebene werden daher in SOPRANO partizipative Verfahren eingesetzt, die potenzielle Nutzer (im weiteren o.g. Sinne) des SOPRANO-Systems in allen Phasen des Innovationsprozesses (Ideenfindung, Anforderungsdefinition, Spezifikation, Entwicklung, Test) aktiv einbeziehen und in Wechselwirkung stehen mit den eher technisch orientierten Spezifikations- und später Entwicklungsschritten [4]. Der folgende Abschnitt zeigt exemplarisch den methodischen Rahmen des ersten Designzyklus in SOPRANO, der mit der initialen Festlegung der priorisierten Nutzer- und Systemanforderungen abgeschlossen wurde.

2.2 Methode der Anforderungserhebung

In Anlehnung an die o.g. vier Phasen wurde die in Abbildung 1 [Abb. 1] dargestellte Methode der Anforderungserhebung erarbeitet und durchgeführt.

Schritte 1+2: Zunächst wurden unter Ausnutzung von Expertenerfahrung aus den Bereichen Pflege und Gerontologie relevante Problemsituationen identifiziert, in die alternde Menschen zuhause geraten können. Diese umfassten auch Notfallsituationen aber insbesondere Alltagssituationen (z.B. verpasste Medikamenteneinnahme aufgrund Vergesslichkeit). Die initiale Darstellung des Nutzungskontext und der Nutzeranforderungen erfolgte anhand dieser Situationen und ihrer technisch-organisatorischen Analyse. Dazu wurden unter Einbezug der technischen Experten sowohl die Situationen als auch bereits die möglichen oder antizipierten innovativen technischen Unterstützungsmöglichkeiten des zu konzipierenden AAL-Systems erfasst. Problemsituationen, für die im Projektrahmen Lösungen oder zumindest evaluierbare Ansätze nicht in Aussicht standen, wurden ausgeschlossen.

Schritt 3: Die erste Sammlung von Situationen wurde im Weiteren zu 11 Szenarien aggregriert, welche jeweils eine Teilmenge der Situationen enthielt. Diese Szenarien stellen auf Basis von Beispielfällen Beteiligte, die Problemsituationen und die erwartete sozio-technische Reaktion von AAL-System und sozialem Umfeld dar, z.B. in folgender Art: „Nancy Norton is 75 years old. Nancy manages all things of daily living by herselves. Since some time Nancy forgets more and more, e.g., she left the house without locking the front door …“ Dabei galt es sehr ähnliche Situationen zu reduzieren, und vor allem sicherzustellen, dass die relevanten Problem-Bereiche Medizin, die psycho-soziale Domäne und Aktivitäten des täglichen Lebens (ADL) auch tatsächlich abgedeckt wurden. Beispielhafte Szenarien sind: “Medication: medication compliance support with nearby informal carer”, “Fall: adjusting care to increasing frailty”, “Open Door: safe and secure in the home environment”, “Remembering: coping with cognitive ageing”, “In Touch: combating social isolation”.

Schritt 4: Diese konsolidierten Szenarien – auf Basis von Expertenwissen gefertigte Anforderungshypothesen – wurden mit Nutzern, d.h. Fokusgruppen älterer Menschen und auch Fachpersonal (Pfleger etc.) diskutiert. Dabei galt es einerseits die Annahmen zu überprüfen, andererseits die Möglichkeit für neue nutzerseitige Ideen offen zu halten und dennoch die Technik weitestgehend im Hintergrund zu lassen. Hierzu wurde auf ein „Guardian-Angel-Konzept“ gesetzt. Zur Diskussion wird das System gegenüber dem Benutzer als imaginärer Agent eingeführt, der mit der Person interagieren kann. Der Guardian Angel als mentale Repräsentation des Gesamtsystems ermöglicht, dass explizite oder implizite Annahmen über die technische Machbarkeit bei der Ideengenerierung in den Hintergrund rücken. Nutzeranforderungen an das System und die Interaktionsformen mit dem System basieren so direkt auf der Erfahrungswelt älterer Menschen und sind deutlich weniger verzerrt durch Annahmen über aktuelle technische Möglichkeiten. Insgesamt wurden im Schritt 4 ca. 90 Personen (zu gleichen Teilen ältere Menschen und Fachpersonal) in 4 europäischen Ländern befragt (Deutschland, England, Niederlande, Spanien – an jeweils mehreren Orten).

Schritt 5: Die Ergebnisse der Validierung in Schritt 4 wurden durch eine Iteration der ersten Schritte in eine finalisierte Version der Szenarien überführt. Diese finalisierte Version der Szenarien als Anforderungskatalog an das zu entwerfende AAL-System ist nun im Weiteren die direkte Vorlage für die folgende Designphase der Systemspezifikation und Entwicklung.

Schritt i+: Auch in den Zyklen der technischen Umsetzung werden die Endnutzer aktiv in die Gestaltung des Systems einbezogen. Szenarien und Nutzeranforderungen werden Schritt für Schritt in Prototypen umgesetzt und wiederum durch Nutzer evaluiert. Zum Zeitpunkt dieser Darstellung wurde eine erste Evaluation von Zwischenergebnissen bereits durchgeführt. Dazu wurden ca. 70 Personen (55 ältere Menschen sowie Fachpersonal) in den genannten Ländern (DE, UK, NL, ES) mit verschiedenen Methoden detailliert befragt. Die Einschätzung der Endnutzer wird durch ein multidisziplinäres Expertenteam auf seine Umsetzbarkeit hin überprüft und im weiteren Design-Prozess berücksichtigt.

2.3 Ontologiezentrierte Entwicklung

Ein iterativer Lernprozess vollzieht sich nicht nur zwischen den Nutzergruppen und den technischen Entwicklungspartnern, sondern auch unter den technischen Partnern in unterschiedlichen Bereichen. Hier müssen die unterschiedlichen technischen Möglichkeiten und Grenzen der einzelnen möglichen Teilkomponenten zu einem Verständnis eines möglichen Gesamtsystems kombiniert werden.

Hierzu wurde auf einen ontologiezentrierten Entwicklungsprozess gesetzt, der Ontologien als „vermittelndes Artefakt“ nutzt. Dabei wird Ontologie im Sinne von Uschold & Grüninger [5] als „gemeinsames Verständnis einer bestimmten Domäne“ verstanden. Das Kernelement dieses Entwicklungsprozesses ist also der bewusste Einsatz von expliziten Repräsentationen des Domänenverständnisses zur Unterstützung des kollaborativen Lernprozesses. Die Entwicklung der Ontologie wird dabei durch einen Moderator vorangetrieben, der die jeweiligen Zwischenergebnisse in die unterschiedlichen Teilgruppen hineinträgt, so dass die Diskussion konstruktiv an einem gemeinsamen Verständnis ausgerichtet ist.

Im Gegensatz zu anderen modellbasierten Ansätzen für das Requirements Engineering setzt dabei die ontologiezentrierte Entwicklung auf eine Durchgängigkeit ohne Modellbrüche. Hierzu ist entsprechend dem Ontologiereifungsmodell von Braun et al. [6] eine graduelle Formalisierung erforderlich, die anfangs mit leicht verständlichen graphischen Modellierungssprachen arbeitet, z.B. erweiterterten Entity-Relationship Diagrammen.

Die Interaktion mit der benutzerzentrierten Vorgehensweise illustriert Abbildung 2 [Abb. 2]: die Ontologieentwicklung beginnt mit der Projektvision und existierenden Ansätzen. Das Ergebnis wurde im Rahmen von Schritt 1+2 der obigen Vorgehensweise validiert und weiterentwickelt. Die Nutzersituationen wurden mit Hilfe der Ontologie aus technischer Sicht auf ihre Machbarkeit hin untersucht, bevor in Schritt 3–5 die Situationen konsolidiert und validiert wurden. Die entsprechenden Anforderungen und Nutzerszenarien wurden dann wiederum übersetzt, um die Grundlage für die Systemarchitektur und das Systemverhalten zu dienen.


3 Konkrete Anforderungen

Im Rahmen des vorgestellten Vorgehens wurden Anforderungen sowohl aus der direkten Interaktion mit potenziellen Nutzern und Experten gewonnen, als auch durch Auswertung schon vorhandener Vorarbeiten und Richtlinien. Hierzu gehörte neben dem o.g. ISO Standard 13407 auch die ETSI-Richtlinie „Human factors; User experience guidelines; Telecare services“ [7], aus der wichtige generelle Richtlinien herangezogen wurden.

Die Darstellung der detaillierten funktionalen Anforderungen erfolgte mittels der Nutzungsszenarien, welche typische Nutzungsfälle/Problemsituation sowie das erwartete Systemverhalten beschreiben. Die Szenarien beinhalten zu diesem Zweck Beschreibungen von auftretenden „Events“ und den erwarteten „Aktionen“. Das zu entwickelnde SOPRANO-System soll schließlich – bei korrekter Konfiguration – in den entsprechenden Situationen wie in den beschriebenen Szenarien reagieren können. Es ist jedoch zu betonen, dass SOPRANO nicht auf nur diese Szenarien beschränkt ist und durch Konfiguration auch vergleichbare Nutzungsfälle ohne Architekturanpassungen und Erweiterungen abdecken muss.

Die als besonders wichtig identifizierten generellen Problembereiche sind dabei: Erkennen einer Abnahme sozialer Kontakte, Erhaltung von Gesundheit und Aktivität, Hilfe bei Vergesslichkeit, Hilfe bei der Einhaltung verordneter Medikation, Verbesserung der Sicherheit älterer Menschen (Ausschluss gefährlicher Situationen wie z.B. ein nicht abgeschalteter Herd) und Berücksichtigung von Haussteuerungs-Ansätzen.

Aus dem dargestellten Gesamtprozess ergaben sich folgende generelle funktionale und nicht-funktionale Haupt-Anforderungen an die zu entwickelnde SOPRANO AAL-Lösung:

  • Leichte Verständlichkeit für alle Nutzer (unterstütze Person, pflegende Personen …), dazu gehört insbesondere auch deterministisches und nachvollziehbares Systemverhalten.
  • Die Interaktionsmöglichkeiten mit dem AAL-System sollen für den Nutzer leicht zugänglich sein, zur Eingabe/Ausgabe sollen verschiedene Modalitäten nutzbar sein.
  • Anpassbarkeit auf die jeweilige zu unterstützende Person, d.h. ihre/seine spezifische Wohnsituation, Fähigkeiten, Einschränkungen und Präferenzen – auch über längere Zeit hinweg („Aging in Place“), sowie Skalierbarkeit bzgl. Anzahl der Installationen.
  • Zuverlässigkeit der Lösung und unkomplizierte Alarmierung in Notfallsituationen, dazu gehört auch die Nutzbarkeit in Verbindung mit Telecare-Installationen.
  • Gesetzeskonforme technische Lösung u.a. hinsichtlich datenschutztechnischer Vorgaben.

Nutzerkommentierungen unterstrichen darüber hinaus den strikten Willen der Nutzer die letztendliche Kontrolle behalten zu wollen, informiert zu werden, sowie bei Entscheidungen beteiligt zu sein, kurz, ihre Mündigkeit zu achten:

    • Kontrolle über das System zu behalten war unisono Anforderung aus allen Ländern.
    • Wenn das System handelt, soll es den Nutzer über alle Aktionen informieren.
    • Vor Installation soll zusammen mit dem Nutzer festgelegt werden, wo welche Sensoren installiert werden, sowie welche Funktionen aktiviert werden und welche nicht.

Speziellere Anforderungen, die zum Teil auch die Szenarien reflektieren waren auszugsweise:

    • Sprachausgaben des Systems sollen in vertrauten Stimmen erfolgen,
    • Fernsehsendungen sollen möglichst nicht durch Meldungen unterbrochen werden,
    • Bei Verwendung von Kameras sollen diese im inaktiven Zustand auf den Boden zeigen.

Aus technischer Sicht stellen die genannten Notwendigkeiten hinsichtlich leichter Integrierbarkeit von anderen Systemen (Telecare-Lösungen, Sensoren, Ausgabegeräte/Aktuatoren), Erweiterbarkeit und flexibler Anpassbarkeit von Geräten und Systemverhalten, sowie der Wunsch nach einer ökonomisch vertretbaren Skalierbarkeit der Lösung, folgende spezifische Anforderungen an das technische SOPRANO-System:

  • Es bedarf einer integrierenden „SOPRANO Ambient Middleware“, die Nutzereingaben und Umgebungsinformation im Haus erfassen, auswerten und darauf reagieren kann,
  • eine kontext-sensitive Ausführung der Reaktion ermöglicht in Abhängigkeit von vorhandenen Geräten/Services und der speziellen Befindlichkeit des Nutzers,
  • zur Erhöhung von Sicherheit und Zuverlässigkeit Telecare-Installationen einbindet, d.h. generell in der Lage ist, unterschiedliche verteilte Geräte und Systeme diensteorientiert, situationsabhängig zu steuern.

4 SOPRANO Ambient Middleware (SAM)

Abbildung 3 [Abb. 3] zeigt einen Überblick über das Konzept des SOPRANO-Systems. Wie erläutert konzentriert sich SOPRANO auf die Unterstützung innerhalb des Hauses. Die SOPRANO Ambient Middleware ist dabei Kernstück des Systems. SAM integriert Sensoren, Aktuatoren/Ausgabegeräte und weitere Systeme, hier insbesondere eine Standard-Telecare-Lösung. Alle angebundenen Geräte werden dabei in SOPRANO über ein OSGi-Framework als Services registriert (Service Oriented Device Architecture). Die integrierte Telecare-Komponente erhöht in SOPRANO durch erprobte technische Elemente die Sicherheit des Gesamtsystems sowie durch das organisatorische Telecare-Rahmenwerk die sozio-technische Einbettung SOPRANOs in eine ganzheitliche Pflege-/AAL-Lösung.

Im Weiteren wird im Detail die Funktion der SAM dargestellt, an einem Beispiel veranschaulicht und zu mobilen Ansätzen in Bezug gesetzt.

4.1 Aufbau und Funktion der SAM

Die Grundfunktion der SOPRANO Ambient Middleware ist das Einsammeln von Information durch die angeschlossenen Sensoren und Eingabemöglichkeiten, deren Analyse und darauf basierend die Auswahl und Ausführung von angemessenen Reaktionen durch angeschlossene Aktuatoren und Ausgabemöglichkeiten (s.a. [8]). SAM besteht aus den Unterkomponenten Context Manager, Procedural Manager und Composer (Abbildung 4 [Abb. 4], Abbildung 5 [Abb. 5]). Deren Zusammenwirken lässt sich in drei Schritten wiedergeben:

Schritt 1 – Erzeugen des Kontexts: Der Context Manager (CM) ist zunächst jene Komponente, welche das Einsammeln und Konsolidieren der Umgebungsinformation im AAL-Haus umsetzt, d.h. den Kontext der unterstützten Personen abbildet [9]. Dazu aggregiert er die eintreffenden Zustandsinformationen auf semantisch höherem Abstraktionsniveau (unter Nutzung von Schlussmechanismen) [10] und bietet den anderen Komponenten stets eine anfragbare Zustandsdatenbasis (Kontext), die nicht nur den aktuellen Zustand, sondern auch dessen Historie enthält (vgl. [11]). Kontext ist hierbei zu verstehen als die Summe aller zeitlichen, räumlichen, personen-bezogenen, organisatorischen und soweit relevant auch der erweiterten globalen Bedingungen in denen sich das Unterstützungsgeschehen abspielt (Kontext-Verständnis nach [12]). Beispiele sind hier: der aktuelle Aufenthaltsort der zu unterstützenden Person im Haus, die relevanten Merkmale der Person wie Einschränkungen im Sehen/Hören/der Bewegung, Termine zur Medikamenteneinnahme, Kontaktdaten von Bezugspersonen oder einer Pflegezentrale, Umgebungszustände wie eingeschalteter Herd oder Fernseher und die Verortung dieser Geräte, Raumtemperatur, Außentemperatur sowie schließlich auch technische Parameter wie das Vorhandensein bestimmter Sensoren, einer Telefonanbindung u.v.m.

Schließlich können sich andere Komponenten beim Context Manager für bestimmte Ereignisse registrieren, d.h. der CM überwacht die Elemente des aggregierten „High-Level Context“ (s.a. [13]) auf Veränderungen und erzeugt in einem regel-getriebenen Schritt Ereignisse (Events) im Falle von Änderungen der Kontextwerte.

Schritt 2 – Auslösen einer Reaktion: Der Procedural Manager (PM) nimmt Events, d.h. vom CM erzeugte Benachrichtigungen über Kontextänderungen und direkte Nutzeranforderungen (die von einer weiteren Komponente semantisch vorverarbeitet und aufbereitet werden) entgegen. Der PM basiert im Kern auf einem Regelsystem und verwaltet ECA-Regeln (ECA: Event, Condition, Action), die die Struktur <Ereignis, Kontextbedingungen, Workflow> besitzen. Wird eine bestimmte Regel aktiviert, so wird der darin enthaltene Workflow an den Composer übergeben, der diesen Workflow ausführt. Im Workflow sind dabei noch keine konkreten Dienstaufrufe enthalten sondern nur abstrakte Ziele, z.B. statt „optische Warnung durch Blinklicht“ steht dort nur „Warnung“.

Der Workflow wird zusammengesetzt aus vordefinierten, parametrisierten Einzelprozeduren aus einem Prozeduren-Repository. Der PM kann diese Prozeduren auf Basis von zusätzlicher Kontextinformation auf die aktuellen Gegebenheiten anpassen, z.B. eine abstrakte Anweisungsprozedur „Warnung der betreuten Person“ mit den Kontextinformationen „betreute Person ist taub“ und „betreute Person ist im Wohnzimmer“ konkretisieren in „optische Warnung der betreuten Person im Wohnzimmer“.

Schritt 3 – Ausführung des Workflows: Der Composer empfängt den abstrakten Workflow und setzt diesen kontext-abhängig und auf die Befindlichkeit der betreuten Person abgestimmt in den Aufruf real vorhandener Geräte/Dienste mit den korrekten, detaillierten Parametern um. Hierzu gehört die Ermittlung der jeweils aktuell und aktiv im System zugänglichen Dienste (durch eine OSGi Service-Registry), die intelligente Auswahl der zum Workflow passenden Dienste, sowie die Zusammenstellung der konkreten Parameter. So wird z.B. die abstrakte Anweisung „optische Warnung der Person im Wohnzimmer“ übersetzt in einen konkreten Text (Auswahl aus parametrisierten Standardsprachelementen), die Ermittlung des aktuell verfügbaren Ausgabegerätes als das eingeschaltete Fernsehgerät und der konkrete Aufruf des speziellen Services welcher den Warnungstext auf dem TV darstellt.

SAM ist ein sehr datenintensives Modul, für dessen Funktion mehrere systeminterne Datenbasen notwendig sind:

  • Procedure Template Database: Die Prozedur-Schablonen sind abstrakte Workflows, welche unabhängig vom jeweils installierten System und Kunden vorliegen und in der Beschreibung einen Formalismus nutzen ähnlich zu Geschäftsprozess-Schablonen [14]. Die Prozedur-Schablonen sind im System nicht aktiv und werden nicht vom PM ausgeführt. Bei der System-Installation und Pflege werden die für den Einzelfall sinnvollen Schablonen ausgewählt, ggf. konkretisiert mit kundenspezifischen Vorgaben und dann als Prozeduren instantiiert.
  • Procedure Database: Dies sind die konkreten, instantiierten Prozeduren. Sie werden vom Procedural Manager verwendet.
  • State Rule Database: Diese bietet zwei Sätze von Regeln. Bottom-up Regeln, welche im Context Manager verwendet werden, um aus vorhandenen Kontextfakten höherwertige Fakten abzuleiten und top-down Regeln, welche der Composer verwendet um abstrakte Reaktionspläne in mehrere konkrete Schritte aufzulösen. Diese Regeln können Abhängigkeiten vom Kontext beinhalten. Des Weiteren können neu ins System eingefügte Komponenten spezifische Regeln einbringen.
  • User Context Database: Diese enthält alle Kontext-Informationen. Dazu gehören statische, die z.B. Eigenschaften der zu unterstützenden Person oder des Hauses betreffen und bei der System-Installation oder Wartung eingepflegt werden müssen und dynamische, durch Sensoren erfasste Information (Temperatur, Zustände von Geräten etc.).

4.2 Ablaufbeispiel

Abbildung 5 [Abb. 5] zeigt ein konkretes Beispiel der Arbeitsweise der SOPRANO Ambient Middleware und orientiert sich an einem der definierten Nutzungsszenarien.

Rahmensituation: Nancy ist eine 75-jährige, zunehmend vergessliche Dame, die alleine im Haus ist und dabei ist dieses zu verlassen. Sie hat die Haustür geöffnet und will gehen.

Dem Context Manager sind aktuell durch Sensoren und kundenspezifische Konfiguration (u.a.) folgende Fakten bekannt: die betreute Person befindet sich an der Haustür und hat diese geöffnet (Infrarot-Sensoren, Türkontakte), das TV im Wohnzimmer ist eingeschaltet (Strom-Sensor), ein Fenster geöffnet (Fensterkontakt), die Türklingel (Klingelkontakt) wurde in der letzten Stunde nicht betätigt.

Wie dargestellt sind alle Sensoren durch die OSGi-Schicht mit SAM verbunden, das Sensor-Signal “Haustür geöffnet” erreicht den Context Manager. Aus den Fakten „Haustür geöffnet“, und „Türklingel wurde nicht betätigt“ schließt der CM den neuen Fakt, dass die Person das Haus verlassen will. Der PM hat sich beim CM für solch einen Statuswechsel (Person verlässt das Haus) registriert und bekommt diesen Event daher gemeldet. In der Regelbasis werden durch den Event „Person verlässt das Haus“ in Verbindung mit den Kontextbedingungen verschiedene Regeln ausgelöst und der Workflow „Person verlässt das Haus UND Probleme liegen vor → warne Person: TV-Set eingeschaltet, Fenster steht offen“ angestoßen.

Der Composer bekommt nun diesen abstrakten Workflow und muss ihn in konkrete, kontext-bezogene Service-Aufrufe umsetzten. Die Service-Suche erfolgt dabei über die OSGi-Schicht. Aus den zur Verfügung stehenden Ausgabe-Möglichkeiten (u.a. auch das TV-Set) wählt der Composer das in der Nähe der Tür befindliche SOPRANO-Interaktionsterminal, da sich dort die zu warnende Person befindet. Die entsprechende Meldung wird dabei in zwei Modalitäten dargestellt: als Text-Anzeige und als Sprachmeldung über den eingebauten Lautsprecher.

4.3 SAM und mobile Komponenten

Die dargestellte Middleware ist in der Lage eine weite Spanne unterschiedlicher Typen von Geräten einzubinden. Dazu gehören sowohl das „ambiente“ Sensorennetzwerk sowie auch potenziell mobile Komponenten. Dabei ist im aktuellen SOPRANO-System die Grenze zwischen „ambient“ und mobil fließend. Zunächst ist ein größerer Anteil verwendeter Sensoren drahtlos in das Gesamtsystem eingebunden, um Installationskosten so gering wie möglich zu halten. Des weiteren gibt es aus der gleichen Klasse von drahtlosen Standardkomponenten für Telecare-Systeme eine Reihe von (im engeren Sinne) mobilen Interaktionsgeräten: vom „personal radio trigger“ (der drahtlose, mitgeführte „rote Knopf“) über mobile Wechselsprechkomponenten bis zu am Körper mitgeführten Sensoren wie der Fall-Sensor (eine gute Übersicht aktueller kommerzieller Sensoren zeigt exemplarisch [15]).

Eine Stärke der SAM ist, dass sie solche existierenden und vergleichbare kommende Komponenten nicht nur technisch einbinden kann, sondern vor allem die logische Infrastruktur zur Verfügung stellt, um die diagnostischen und reaktiven Möglichkeiten im Sinne eines Assistenz-Systems wirksam werden zu lassen.

4.4 Verwandte Arbeiten

Ambient Assisted Living (AAL) speziell für ältere Mitbürger ist ein Bereich, in welchem nicht zuletzt aufgrund eines mit 600 Mio. € geförderten Aktionsplans der Europäischen Kommission [16] zurzeit eine Vielzahl von Forschungsarbeiten durchgeführt werden. Drei prinzipielle Gruppen von Systemen können unterschieden werden, die im Folgenden anhand einiger beispielhafter Vertreter vorgestellt werden, um deren Unterschiede zu SOPRANO deutlich zu machen (eine ausführliche Analyse bietet [17]):

  • Hausautomation (engl. Home Automation). Ziel der Systeme dieser Klasse ist es, den Wohnkomfort und die Sicherheit der Bewohner durch Automatisierung täglicher Aufgaben in Wohnhäusern zu erhöhen. Typischerweise werden diese System von Hardware- und Softwareexperten entwickelt, die eng mit den eigentlichen Geräteherstellern kooperieren. Aufgrund der technischen Herausforderungen, treten dabei Wissen von Domänenexperten und damit die speziellen Anforderungen älterer Menschen oft in den Hintergrund, was zu Systemen führt, die (bewusst oder unbewusst) auf jüngere Benutzer abzielen und von Senioren kaum zu bedienen sind. Beispiele für solche Systeme sind das INHOME-Projekt [18], welches auf die personalisierte Verwaltung von Audio- und Videomedien abzielt, sowie das Projekt EASY-LINE+ [19], das Intelligenz in Küchengeräte wie Kühlschränke und Waschmaschinen bringen will.
  • Agenten-basierte AAL-Systeme. Systeme dieser Gruppe zeichnen sich durch Geräte aus, die auf Basis von Agententechnologie autonom intelligent handeln. Alle Geräte einen Hauses bilden so ein emergent intelligentes Gesamtsystem. Durch Einbringen neuer Agenten kann ein solches System erweitert werden, allerdings ist hierfür eine gemeinsame Anstrengung von sowohl Technikern als auch Domänenexperten nötig. Zudem muss stets auf mögliche Interferenzen mit anderen intelligenten Geräten geachtet werden. Beispiele solcher Projekte sind das DynAMITE-Projekt [20], das mittels einer SodaPop-Infrastruktur [21] die Grundlage für eine selbstorganisierende Anwendung schafft, indem grundlegende Mechanismen für den Nachrichtenaustausch, für die Gruppenbildung und zur Konfliktauflösung angeboten werden. Ähnlich geht das PERSONA-Projekt [22] vor, das eine Bus-Technologie wählt, um die intelligenten Geräte verbinden zu können [23], sowie das AMIGO-Projekt [24], in welchem ein dienstorientierter Ansatz und Techniken der Dienstkomposition zum Einsatz kommen [25]. Jede Komponente implementiert so eigene Integrationsstrategien.
  • Monolithische intelligente Systeme. Systeme dieser Gruppe sind durch ein zentrales „Gehirn“ charakterisiert, welches in Form einer Blackbox arbeitet und die Intelligenz für alle angeschlossenen Geräte liefert. Solche Systeme basieren auf hoch spezialisierten Algorithmen meist unter Verwendung logischen Schließens. Erweiterungen am Gesamtsystem sind schwierig, da unabhängig austauschbare Komponenten fehlen. Forschungsprojekte dieser Kategorie sind das EMBASSI-Projekt [26], welches sich auf Intelligenz für Wohlzimmer und Fahrzeuge spezialisiert hat sowie das MAP-Projekt [27], das vorwiegend im Büro-Umfeld agierte. Ein neuerer Ansatz ist das europäische Projekt EMERGE [28], das Lösungen zur Reaktion auf Notfälle im Haus bereitstellen soll.

Bis heute hat keine der vorgestellten Lösungen eine hohe kommerzielle Aufmerksamkeit erreicht. SOPRANO zielt hier auf eine stärkere Marktorientierung und will die Ergebnisse durch Mitglieder des Konsortiums in massentaugliche Produkte überführen. Als Garant für einen Erfolg am Markt sehen wir die konsequente Nutzerfokussierung in der Entwicklung sowie die vorgestellte flexible Architektur, die es ermöglicht Geschäftsinteressen verschiedener Gruppen unabhängig voneinander zu unterstützen.


5 Zusammenfassung und Ausblick

In diesem Beitrag wurden die technisch-funktionalen Grundzüge einer Middleware für Ambient Assisted Living (AAL) Anwendungen am Beispiel des Forschungsprojektes SOPRANO dargestellt sowie die Erhebungs-Methodik der Anforderungen für dieses System und deren wichtigste Ergebnisse.

Die Anforderungs-Erhebung beruht auf einem iterativen und stark nutzerzentrierten, partizipativen Ansatz, beim dem die potenziellen Nutzer in allen Phasen des Innovationsprozesses (Ideenfindung, Anforderungsdefinition, Spezifikation, Entwicklung, Test) aktiv einbezogen werden. Eingehend erläutert wurde der erste Designzyklus in SOPRANO. In einem mehrschrittigen Verfahren zwischen Experten, Technikern und Anwendern wurden zu Szenarien verdichtete Problemsituationen zur Festlegung der priorisierten Nutzer- und Systemanforderungen erarbeitet. Als moderierende Verfahren wurden in der Evaluation mit Anwendern der „Guardian Angel“-Ansatz verwendet und zur konsistenten technischen Diskussion ein ontologiezentrierter Entwicklungsprozess. Als wesentliche Anforderungen wurden u.a. herausgestellt: Deterministisches und nachvollziehbares Systemverhalten, Anpassbarkeit auf den jeweilige zu unterstützende Person und Nutzbarkeit in Verbindung mit Telecare-Installationen.

Die beschriebene Middleware ermöglicht den Aufbau flexibler, erweiterbarer und personalisierbarer AAL-Lösungen mit vergleichsweise geringem Aufwand. Die Middleware ist in der Lage Nutzereingaben und Umgebungsinformation im Haus zu erfassen, auszuwerten und als Kontext zu repräsentieren, sowie regel-basiert und kontext-abhängig darauf zu reagieren. Die SOPRANO Ambient Middleware (SAM) besteht aus den Hauptkomponenten Context Manager (CM), Procedural Manager (PM) und Composer: der CM führt die eintreffenden Sensorinformationen zusammen und aggregiert diese zu Zuständen auf semantisch höherem Abstraktionsniveau. Andere Komponenten können sich beim CM für bestimmte Ereignisse registrieren. Auf der Basis dieser Ereignisse arbeitet der PM, der ECA-Regeln verwaltet, die die Struktur <Ereignis, Kontextbedingungen, Workflow> besitzen. Im Workflow sind noch keine konkreten Dienstaufrufe enthalten. Wird eine bestimmte Regel aktiviert, so wird der darin enthaltene Workflow an den Composer übergeben, der diesen Workflow ausführt und dabei anhand der verfügbaren Dienste und der Angemessenheit für die konkrete Person Dienste auswählt. Eine Stärke der SAM ist, dass sie die logische Infrastruktur zur Verfügung stellt um Dienste nicht nur technisch sondern aktiv organisatorisch einzubinden.

SOPRANO ist im Januar 2007 gestartet und hat inzwischen erfolgreich im Dialog von Anwendern, Fachexperten und technischen Partnern entsprechende Anwendungsfälle ausgearbeitet, eine AAL-Ontologie entwickelt und eine darauf aufsetzende Architektur entwickelt. Nach der Fertigstellung der Implementierung der Middleware und Anbindung der teilweise gezielt weiterentwickelten Sensoren und Aktuatoren wird das SOPRANO-System in vier europäischen Ländern (Großbritannien, Spanien, Niederlande, Deutschland) evaluiert. Zum einen findet eine Evaluierung der kompletten Funktionalität (also eines breiten Spektrums von Sensoren und Aktuatoren) im Rahmen spezieller Smart Homes statt. Zum anderen werden in geplanten 300 Haushalten unter realen Bedingungen jeweils Untermengen des SOPRANO-Gesamtssystems installiert werden, um so die flexible Konfigurierbarkeit für den Einsatz in existierenden Häusern und Wohnungen zu demonstrieren.


Anmerkung

Interessenkonflikte

Keine angegeben.

Danksagung

Die erörterten Ergebnisse wurden im Rahmen des von der europäischen Kommission geförderten Projektes SOPRANO (http://www.soprano-ip.org/) gewonnen. Die Autoren danken den Projekt-Partnern für die konstruktive Zusammenarbeit, welche die Ergebnisse erst ermöglicht hat, die hier stellvertretend von den Autoren vorgestellt werden.


Literatur

1.
Avatangelou E, Dommarco RF, Klein M, Müller S, Nielsen CF, Soriano MPS, Schmidt, Tazari MR, Wichert R. Conjoint persona-soprano workshop. In: Constructing Ambient Intelligence: AmI-07 Workshops Proceedings. Berlin: Springer, LNCS; 2008.
2.
European Commission. ISTAG Report on Experience and Application Research -Involving Users in the Development of Ambient Intelligence. Luxembourg: Office for Official Publications of the European Communities; 2004.
3.
DIN EN ISO 13407. Human-centred design processes for interactive systems. Berlin: Beuth; 1999.
4.
Santi M, Schmidt A, Beinhauer W, Klein M, Link J. SOPRANO - Partizipative Entwicklung dienstorientierter Infrastrukturen für das Ambient Assisted Living. In: 1. Deutscher Kongress Ambient Assisted Living (AAL 2008). VDE Verlag: 2008.
5.
Uschold M, Grüninger M. Ontologies: principles, methods, and applications. Knowledge Engineering Review. 1996;11(2):93-155.
6.
Braun S, Schmidt A, Walter A, Zacharias V. The Ontology Maturing Approach to Collaborative and Work-Integrated Ontology Development: Evaluation Results and Future Directions. In: International Workshop on Emergent Semantics and Ontology Evolution (ESOE), ISWC 2007. Busan/Korea; 2007.
7.
ETSI. Human factors; User experience guidelines; Telecare services (e-Health). ETSI DEG 202 487 V0.0.41; 2007.
8.
Wolf P, Klein M, Schmidt A. SOPRANO - An extensible AAL system for elderly people based on an open platform. In: 3rd Workshop on Artificial Intelligence Techniques for Ambient Intelligence (AITAmI'08), European Conference on Artificial Intelligence (ECAI 08), Patras, Greece, 21-22 July 2008. 2008.
9.
Satyanarayanan M. Pervasive Computing: Vision and Challenges. IEEE Personal Communications. 2001;8(4):10-7. DOI: 10.1109/98.943998 Externer Link
10.
Henricksen K, Indulska J. Developing context-aware pervasive computing applications: Models and approach. Journal of Pervasive and Mobile Computing. 2006;2(1):37-64. DOI: 10.1016/j.pmcj.2005.07.003 Externer Link
11.
Schmidt A. Ontology-Based User Context Management: The Challenges of Imperfection and Dynamics. In: International Conference on Ontologies, Databases and Applications of Semantics (ODBASE 2006), On the Move Federated Conferences (OTM 2006), Montpellier. Springer LNCS vol. 4275; 2006. p. 995-1011.
12.
Dey AK. Understanding and Using Context. Personal Ubiquitous Computing. 2001;5(1):4-7. DOI: 10.1007/s007790170019 Externer Link
13.
Winograd T. Architectures for context. Human-Computer Interaction. 2001;16.
14.
Sosunovas S, Vasilecas O. Precise notation for business rules templates. In: Proceedings of the 7th International Baltic Conf. on Databases and Information Systems, 2006. p. 55-60.
15.
TUNSTALL. Telecare sensor. http://www.tunstall.co.uk/products.aspx?PageID=81 [June 2008]. Externer Link
16.
AAL. The Ambient Assisted Living (AAL) Joint Programme. http://www.aal-europe.eu/ [August 2008]. Externer Link
17.
SOPRANO. Deliverable D1.1.2 "Review State of the Art and Market Analysis". 2007. http://www.soprano-ip.org/Documents/SOPRANO_D.1.1.2_SOTA_v12.pdf Externer Link
18.
INHOME Project. An intelligent interactive services environment for assisted living at home. STReP in the 6th Framework Programme of the European Union, 2007. http://www.ist-world.org/ProjectDetails.aspx?ProjectId=fdb62df32f954628a8308a0de08cbf6f&SourceDatabaseId=7cff9226e582440894200b751bab883f Externer Link
19.
EASY-LINE+ Project. Low cost advanced white goods for a longer independent life of elderly people. STReP in the 6th Framework Programme of the European Union, 2007. http://www.ist-world.org/ProjectDetails.aspx?ProjectId=ca0b9ff6bab04a69897afe30089dce62 Externer Link
20.
DynAMITE Project. Dynamic adaptive multimodal it ensenbles. Research project of the German Federal Ministry of Education and Research, 2004. http://www.dynamite-project.org Externer Link
21.
Hellenschmidt M, Kirste T. SodaPop: A Software Infrastructure Supporting Self-Organization in Intelligent Environments. In: Proc. of the 2nd IEEE Conference on Industrial Informatics, INDIN 04, Berlin, Germany, 24th-26th June, 2004.
22.
PERSONA Project. Perceptive spaces promoting independent aging. IP in the 6th Framework Programme of the European Union, 2007. http://www.aal-persona.org Externer Link
23.
Wichert R, Tazari M, Hellenschmidt M. Architectural Requirements of Ambient Intelligence. it - Information Technology. 2008;50(1):13-20.
24.
AMIGO Project. Ambient intelligence for the networked home environment. STReP in the 6th Framework Programme of the European Union, 2004. http://www.amigo-project.org Externer Link
25.
Magerkurth C, Etter R, Janse M, Kela J, Kocsis O, Ramparany F. An Intelligent User Service Architecture for Networked Home Environments. In: Proceedings of the 2nd Intl. Conference on Intelligent Environments, Athens, Greece, July 5-6, 2006. p. 361-70.
26.
EMBASSI Project. Multimodal assistance for infotainment and service infrastructures. Research project of the German Federal Ministry of Education and Research, 2001. http://www.embassi.de Externer Link
27.
Balfanz D, Schirmer J, Grimm M, Tazari MR. Mobile situation-awareness within the project MAP. Computers & Graphics. 2003;27(6):893-8. DOI: 10.1016/j.cag.2003.08.007 Externer Link
28.
EMERGE Project. Emergency monitoring and prevention. STReP in the 6th Framework Programme of the European Union, 2006. http://www.ist-world.org/ProjectDetails.aspx?ProjectId=1fe2539757f54f4595c792845e5dca13&SourceDatabaseId=7cff9226e582440894200b751bab883f Externer Link