- Alpen-Adria-Universität Klagenfurt

Transcrição

Wolfgang Rabl
Multimodale Interaktion
im Smart-Home-Bereich
Diplomarbeit
zur Erlangung des akademischen Grades
Diplom-Ingenieur
Angewandte Informatik
Alpen-Adria-Universität Klagenfurt
Fakultät für Technische Wissenschaften
Betreuer: Ass.-Prof. Mag. Dr. Gerhard Leitner
Begutachter: Univ.-Prof. Dipl.-Ing. Dr. Martin Hitz
Institut: Institut für Informatik-Systeme
27. August 2009
Ehrenwörtliche Erklärung
Ich erkläre ehrenwörtlich, dass ich die vorliegende wissenschaftliche Arbeit
selbstständig angefertigt und die mit ihr unmittelbar verbundenen Tätigkeiten selbst erbracht habe. Ich erkläre weiters, dass ich keine anderen als
die angegebenen Hilfsmittel benutzt habe. Alle ausgedruckten, ungedruckten
oder dem Internet im Wortlaut oder im wesentlichen Inhalt übernommenen
Formulierungen und Konzepte sind gemäß den Regeln für wissenschaftliche
Arbeiten zitiert und durch Fußnoten bzw. durch andere genaue Quellenangaben gekennzeichnet.
Die während des Arbeitsvorganges gewährte Unterstützung einschließlich signifikanter Betreuungshinweise ist vollständig angegeben.
Die wissenschaftliche Arbeit ist noch keiner anderen Prüfungsbehörde vorgelegt worden. Diese Arbeit wurde in gedruckter und elektronischer Form
abgegeben. Ich bestätige, dass der Inhalt der digitalen Version vollständig
mit dem der gedruckten Version übereinstimmt.
Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird.
(Unterschrift)
(Ort, Datum)
Danksagung
Ich bedanke mich sowohl bei Herrn Univ.-Prof. Dipl.-Ing. Dr. Martin Hitz
als auch bei Ass.-Prof. Mag. Dr. Gerhard Leitner für die Vergabe und
Betreuung der Diplomarbeit. Ihre fachliche und organisatorische
Unterstützung, sowie ihre Diskussionsbereitschaft und die daraus
resultierenden Denkanstöße waren eine große Hilfe bei der Erstellung dieser
Arbeit.
Besonders bedanken möchte ich mich bei meinem Studienkollegen Daniel
Felsing, der stets ein offenes Ohr für meine Probleme hatte und bei
zahlreichen Gesprächen wertvolle Beiträge einbrachte.
Ich bedanke mich weiters bei Markus Kurrent für die Korrektur der Arbeit.
Nicht zuletzt möchte ich mich bei all jenen bedanken, die mich während des
Studiums und bei der Erstellung dieser Arbeit so tatkräftig unterstützt
haben. Hier insbesondere meiner Familie, die meine Launen die ganze Zeit
über mit viel Geduld ertragen hat und ohne die dieses Studium gar nicht
erst möglich gewesen wäre.
Wer glaubt etwas zu sein,
hat” aufgehört etwas zu werden“
Sokrates
Inhaltsverzeichnis
1. Einleitung . . . . . . . . . . . . . . . .
1.1 Motivation . . . . . . . . . . . . .
1.2 Ziele von Smart-Home-Systemen .
1.2.1 Smart Living . . . . . . .
1.2.2 Ambient Assisted Living .
1.3 Visionen . . . . . . . . . . . . . .
1.4 Interaktionsmöglichkeiten . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2. Spektrum der Arbeit . . . . . . . . . . . . . . . .
2.1 Ausgangssituation . . . . . . . . . . . . . . .
2.2 Zielsetzung . . . . . . . . . . . . . . . . . .
2.2.1 Multimodales Interaktionsframework
2.2.2 Nutzungsszenarien . . . . . . . . . .
2.3 Eingrenzung des Themenbereichs . . . . . .
2.4 Weitere Vorgehensweise . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 8
. 8
. 9
. 9
. 10
. 10
. 11
3. Multimodale Interaktion
3.1 Allgemeines . . . .
3.2 Interaktionsmodi .
3.3 Fusion / Fission . .
3.4 Herausforderungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
4
5
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
13
15
19
4. Multimodale Frameworks und Projekte
4.1 XHTML+Voice (X+V) . . . . . .
4.2 EMBASSI . . . . . . . . . . . . .
4.3 AMIGO . . . . . . . . . . . . . .
4.4 MONA . . . . . . . . . . . . . . .
4.5 SerCHo-MASP . . . . . . . . . .
4.6 W3C MMI . . . . . . . . . . . . .
4.7 Bewertung . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
23
27
31
34
37
43
iv
5. Beschreibungssprachen im multimodalen Bereich .
5.1 Dialogbeschreibungen . . . . . . . . . . . . .
5.1.1 CCXML . . . . . . . . . . . . . . . .
5.1.2 SCXML . . . . . . . . . . . . . . . .
5.2 Generische UI-Beschreibungen . . . . . . . .
5.2.1 XIML . . . . . . . . . . . . . . . . .
5.2.2 UIML . . . . . . . . . . . . . . . . .
5.2.3 UsiXML . . . . . . . . . . . . . . . .
5.3 Datenaustauschformat (EMMA) . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
45
46
49
50
52
54
56
6. Konzeptioneller Entwurf . . . . . . . . . . . .
6.1 Statische Aspekte . . . . . . . . . . . . .
6.1.1 Interaktionsmanager . . . . . . .
6.1.2 Modalitäts- und Benutzermanager
6.1.3 Modalitätskomponenten . . . . .
6.1.4 HTTP-Service . . . . . . . . . . .
6.1.5 Applikationsservices . . . . . . .
6.2 Dynamische Aspekte . . . . . . . . . . .
6.2.1 Interaktion . . . . . . . . . . . .
6.2.2 Sessionmanagement . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
58
61
61
62
63
63
65
65
66
7. Implementierung . . . . . . . . . . . . . . . .
7.1 Verwendete Technologien . . . . . . . . .
7.1.1 OSGI . . . . . . . . . . . . . . .
7.1.2 Commons SCXML . . . . . . . .
7.1.3 CMU Sphinx . . . . . . . . . . .
7.1.4 FreeTTS . . . . . . . . . . . . . .
7.2 Umsetzung . . . . . . . . . . . . . . . . .
7.2.1 Interaktionsmanager . . . . . . .
7.2.2 Dialogservices . . . . . . . . . . .
7.2.3 Modalitätsadapter . . . . . . . .
7.2.4 Modalitäts- und Benutzermanager
7.2.5 Applikationen . . . . . . . . . . .
7.2.6 Modalitäten . . . . . . . . . . . .
7.3 Anwendung . . . . . . . . . . . . . . . .
7.3.1 Dialogbeschreibung . . . . . . . .
7.3.2 Schnittstellenbeschreibungen . . .
7.3.3 Applikationslogik . . . . . . . . .
7.3.4 Exemplarischer Ablauf . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
70
70
70
72
73
75
76
76
78
79
81
82
84
85
87
90
91
92
8. Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
v
9. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
A. MMI-Lifecycle-Events . . . . . . . . . . . . . . . . . . . . . . . . . 105
Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
1
Einleitung
1.1
Motivation
In den vergangenen Jahren haben sich die technischen Möglichkeiten in sämtlichen Gebieten zusehends weiterentwickelt. Die Menschen wurden und werden mehr und mehr mit neuen Technologien konfrontiert, welche ihr Leben
einfacher, unkomplizierter und lebenswerter machen sollen. So auch im Bereich des Eigenheims, welches sich immer weiter in Richtung einer integrierten, vernetzten und automatisierten Umgebung entwickelt. Durch Anreicherung mit moderner Computertechnik soll den Bewohnern und Bewohnerinnen
neue und bessere Lebensqualität geboten werden.
Diese Automatisierung und Vernetzung beschränkt sich aber nicht nur
auf grundsätzliche Gebäudefunktionen wie Licht und Heizung. Darüber hinaus gibt es auch Bestrebungen, sämtliche weitere Geräte des Haushaltes, wie
Fernseher oder Waschmaschine, auf solche Art zu vernetzen, um auch hier
eine komfortable Steuerung möglich machen zu können. Diese Entwicklung
ist natürlich sehr erfreulich, jedoch ergeben sich dadurch neue Fragen und
Probleme, auf die es bisher nur unzureichende Antworten gibt. Die Rede ist
hier insbesondere von der Interaktion der Benutzer mit den Häusern, die
sie bewohnen und die sie steuern möchten. Die Vergangenheit hat gezeigt,
dass selbst einfache Geräte wie Videorekorder oder Mobiltelefone den Benutzer überfordern und vom Gesichtspunkt der Usability relativ schlecht zu
bewerten waren. Im Bereich des Eigenheims wird dieses Problem noch viel
deutlicher sichtbar, da sich in dieser Umgebung eine Vielzahl von Geräten
befindet und die Komplexität den Benutzer schnell überfordern kann, sofern
nur Interaktionsmöglichkeiten existieren, die nicht auf dessen Bedürfnisse angepasst sind. Dazu kommt noch die Tatsache, dass diese Technologie einen
1.2 Ziele von Smart-Home-Systemen
sehr starken Einfluss auf das Leben der jeweiligen Nutzer nimmt und Probleme in der Bedienung eine erhebliche Auswirkung haben können, wie es zum
Beispiel der Fall ist, wenn aus diesen Gründen die Heizung im Winter nicht
gesteuert werden kann. Eröffnet man also den Benutzern die Möglichkeit, ihre Hausinstallation in diese Richtung zu erweitern, so muss man auch darauf
achten, ihnen Schnittstellen zur Verfügung zu stellen, die den jeweiligen Anforderungen entsprechen bzw. muss es eine einfache, zielführende Möglichkeit
geben, solche Schnittstellen definieren und generieren zu können [26].
Die Bestrebungen in diesem Gebiet werden unter dem Begriff Smart Home
zusammengefasst, auch wenn man auf dieser Ebene noch nicht wirklich von
Systemen sprechen kann, welche eine gewisse Intelligenz besitzen, wie diese
Betitelung suggeriert. Man möchte allerdings seit einiger Zeit einen Schritt
weitergehen und diesem Begriff wirklich Rechnung tragen, indem man versucht, die Gebäudesteuerung auf eine Stufe zu bringen, die man wirklich als
smart“ bezeichnen könnte. Der Grundgedanke hierbei ist folgender: Reichert
”
man eine Umgebung mit Technologie in Form von Sensoren und vernetzten
steuerbaren Geräten an, so sollte es möglich sein, ein System zu schaffen,
welches aufgrund der aktuellen Umgebung und historischer Daten Entscheidungen trifft, welche dem Wohle des dort befindlichen Benutzers zuträglich
sind. Diese Entscheidungsfindung und Ausführung kann sogar völlig ohne
den konkreten und aktiven Einfluss des Benutzers durchgeführt werden. In
diesem Zusammenhang spricht man auch von Ambient Intelligence (AmI) [3].
AmI überspannt viele Gebiete der Informatik. Hierzu zählen Sensorik,
Netzwerke, Human Computer Interfaces, Ubiquitous Computing, Künstliche
Intelligenz und vieles mehr. All diese Teilbereiche werden zusammengefasst,
um dieser Vision Rechnung zu tragen. Der Intention von Pervasive und Ubiquitous Computing folgend, soll der Computer so weit wie möglich in den
Hintergrund treten und für den Benutzer transparent sein. Um das zu erreichen, spielt natürlich auch ein gewisses Maß an künstlicher Intelligenz eine
Rolle, welche Situationen abschätzt und pro aktiv agieren kann, sehr wohl
aber auch in der Lage ist, geeignete Schnittstellen zur Verfügung zu stellen,
sollte der Benutzer explizit eine Tätigkeit ausführen wollen.
1.2
Ziele von Smart-Home-Systemen
Was wären nun also konkrete Einsatzmöglichkeiten von solchen Smart-HomeSystemen? Als erster Gedanke kommt einem wahrscheinlich die Vereinfachung des Lebens in solchen Umgebungen in den Sinn. Man muss sich nicht
2
länger mit lästiger Steuerung beschäftigen. Man ist nicht länger gezwungen,
zum Lichtschalter zu gehen, um das Licht zu dimmen, wenn eine künstliche Intelligenz diesen Wunsch auf irgendeine Art und Weise erkennt und
dementsprechend handelt. Dieser Bereich wird unter dem Begriff Smart Li”
ving“ geführt, hat sich als Ziel die Verbesserung der Lebensqualität gesetzt
und ist in der Tat ein wichtiger und interessanter Aspekt solcher Systeme [27].
1.2.1
Smart Living
Die ersten Forschungsaktivitäten für smarte Anwendungen gab es im Unternehmensbereich und in öffentlichen Einrichtungen. Hier ist es relativ einfach,
konkrete Ziele zu formulieren, da die jeweiligen Anforderungen schon recht
präzise von der Unternehmensstruktur vorgegeben werden. Die notwendigen
Arbeitsabläufe sind beispielsweise in Form von Geschäftsprozessen vorgegeben und werden auch häufig schon überwacht und bewertet. Die Effektivitätssteigerung bei der Einführung neuer Systeme kann auch relativ einfach
anhand von Werten wie etwa Produktivität, Effizienz oder Gewinn ermittelt
und bewertet werden und unterstützt somit eine Entwicklung in hohem Maße.
Geht man allerdings auf den Privatbereich über, ist es nicht mehr so
einfach, die angestrebten Ziele zu definieren und vor allem zu messen. Produktivität und Effizienz spielen hier nicht unbedingt eine Hauptrolle. In ihrer
Freizeit müssen und werden sich Menschen nicht an vorgegebene Abläufe halten. Die zur Verfügung stehende Zeit wird nach eigenem Gutdünken strukturiert und eingeteilt. Eine Vielzahl an ungeplanten Aktivitäten findet zu
willkürlichen Zeitpunkten statt und zur Verfügung stehende Ressourcen werden in zufälligen Mustern verwendet. Wie man hier leicht sehen kann, ist
die Herausforderung bei der Entwicklung von Smart-Home-Systemen um einiges größer und umfangreicher[23]. Ein weiterer erschwerender Faktor ist
auch in den unterschiedlichen Interessen der Bewohner zu sehen. In einem
Privathaushalt leben typischerweise mehrere Personen unterschiedlichen Alters und mit unterschiedlichen Vorlieben und Gepflogenheiten. Es reicht also
nicht aus, die Umgebung auf einen Benutzer bzw. eine Benutzergruppe hin
zu entwickeln, sondern es muss weiters das familiäre Zusammenspiel berücksichtigt werden [10].
Weitere Herausforderungen finden sich bei Ringbauer et al. [39]. Hier wird
aufgeführt, dass die Komplexität eines vollständig vernetzten Haushaltes sehr
hoch ist, was dessen konsistente Abbildung auf eine Benutzungsschnittstelle
schwierig macht. Außerdem gibt es nicht viele Forschungsergebnisse hinsicht-
3
lich der Verwendung unterschiedlicher Ein- und Ausgabegeräte. Bei simultaner Verwendung mehrerer Geräte muss auch auf die Konsistenz geachtet
werden.
1.2.2
Ambient Assisted Living
Ein weiteres Augenmerk bestehender Forschungsaktivitäten liegt in einem
etwas anderen Bereich. Hierbei geht es zum Einen um gesundheitlich und
geistig beeinträchtige Menschen und zum Anderen um ältere Leute. Es gibt
hier viele Fälle von betroffenen Personen, welche eigentlich noch recht gut
in der Lage wären, zu Hause in ihrer gewohnten Umgebung zu leben, wobei jedoch das Risiko gegeben ist, dass sie in Situationen kommen könnten,
die sie alleine nicht bewältigen können. Aufgrund der hohen Kosten für eine
Pflegekraft sind sie leider oft gezwungen, diese Umgebung zu verlassen und
in ein Heim oder eine Pflegeeinrichtung zu ziehen. Die Kosten hierfür steigen
stetig an, da sich ja eine andauernde Erhöhung des Bevölkerungsalters erkennen lässt. Umgekehrt dazu entwickelt sich die Technologie immer weiter
und wird immer kostengünstiger verfügbar. Daher bietet es sich gerade hier
an, die gewohnte Umgebung dieser Betroffenen zu einem Smart Home zu
erweitern und auszubauen, welches sie in weiterer Folge unterstützen kann
und ihnen hilft, ihr alltägliches Leben zu meistern [27].
Im Bereich Ambient Assisted Living, wie der Einsatz dieser Technologie
zur Unterstützung älterer und beeinträchtigter Menschen häufig bezeichnet
wird, stößt man allerdings auf einige weitere Schwierigkeiten. Man kann hier
nicht von der Wissenbasis eines dreißigjährigen Menschen ausgehen. Gerade im Bereich moderner Technologien zeigen sich naturgemäß große Wissenslücken, welche man bei der Planung und Umsetzung berücksichtigen
muss. Schon einfache Dinge, wie die Steuerung mit einer Maus, der Unterschied zwischen einem Mausklick und einem Doppelklick können eine zu
große Herausforderung darstellen und führen zu fehlerhaften Interaktionen
und zu Unverständnis und Frustration. Es ist hier also unumgänglich, dass
neben der grundsätzlichen Fragestellung nach Möglichkeiten, das Leben zu
vereinfachen und ein Weiterleben in der gewohnten Umgebung zu ermöglichen, auch die Problematik der Interaktion in Hinsicht auf die spezifischen
Zielgruppen, die mit dem unterstützenden System in Kontakt treten, zu beleuchten [16].
4
1.3 Visionen
1.3
Visionen
Um diese hochgesteckten Ziele, wie die Vereinfachung bzw. Ermöglichung
des Lebens im Eigenheim nun zu erreichen und umsetzen zu können, gibt
es naturgemäß mehrere Möglichkeiten. Man kann hier allerding zwei große
Visionen erkennen, welche in zwei gegensätzliche Richtungen weisen. Die eine
sehr weit verbreitete Vision wurde bereits zu Beginn dieser Arbeit angerissen.
Hierbei liegt das Ziel tatsächlich darin, dem Benutzer alle Arbeit abzunehmen
und ihm, auf welche Art auch immer, jeden Wunsch von den Augen abzulesen
und diesen in weiterer Folge dann auch umzusetzen. In diese Richtung geht
auch eine ganze Reihe von Forschungsaktivitäten und Entwicklungen. Das
Problem hierbei ist jedoch schnell ersichtlich und nicht einfach lösbar. Wie
kann man die Möglichkeiten solch eines Systems vergrößern und optimieren
und den Benutzern und Bewohnern des Hauses zur gleichen Zeit dennoch
eine ausreichende Kontrolle zugestehen? Hier geht es vor allem um die subjektiv erlebte Kontrolle, die Menschen sollen sich nicht von ihren eigenen vier
Wänden entmündigt fühlen, denn so etwas wäre nicht wirklich zielführend.
Man befindet sich hier eindeutig in einer sehr zwiespältigen Position, da man
ja versucht, die Abhängigkeit der Benutzer von der Verwendung unterschiedlichster Schnittstellen abzuschaffen bzw. zu verringern. Indem man dies tut,
stellt sich immer mehr die Frage, wer denn tatsächlich im Haus die Kontrolle hat, der Mensch oder der Computer. Hier eine Lösung zu finden, welche
HausbewohnerInnen immer mehr explizite Steuerungstätigkeit abnimmt und
ihnen aber gleichzeitig nicht den Eindruck vermittelt, auf eben diese Kontrollfunktion verzichten zu müssen, ist wohl einer der Kernpunkte auf den
man sich hier konzentrieren muss [10].
Es gibt allerdings auch Forschungsbestrebungen in eine gänzlich andere Richtung. Hier geht es nicht darum, den Bewohnern von Smart Home
Gebäuden Arbeiten abzunehmen und zu automatisieren, sondern die Menschen sollen vielmehr lernen, sich selbst in ihrer Umgebung besser zurecht zu
finden. Ein vorhandenes Computersystem soll sich hier um einiges subtiler
verhalten und den Bewohnern Informationen zur Verfügung stellen, damit
durch diese Unterstützung die anfallende Arbeit erleichtert wird und sich
außerdem ein Lerneffekt einstellen kann. Natürlich gibt es auch hier hohe
Anforderungen an die verwendeten Systeme, damit die notwendigen Informationen, und nur diese, zur genau richtigen Zeit durch das aktuell am besten geeignete Medium übermittelt werden. Der Benutzer soll dadurch in die
Lage versetzt werden, bessere Entscheidungen zu treffen, gleichzeitig sollte
er durch diese Vorgänge aber nicht gestört oder belästigt werden. Folgt man
solch einer Vision, ergeben sich zumindest keine Probleme damit, den Haus-
5
1.4 Interaktionsmöglichkeiten
bewohnern die Kontrolle zu entziehen oder sie gar zu entmündigen, was aus
psychologischer Sicht sicherlich als positiv zu bewerten ist [21].
Natürlich ist es klar, dass es nicht darum geht, eines dieser Extreme anzustreben, sondern versucht wird, einen guten Kompromiss zwischen beiden
zu finden. Der Schwerpunkt liegt dennoch auf Seiten der Automatisierung
der häuslichen Umgebung, was sich auch in den aktuell durchgeführten Forschungsaktivitäten und Projekten widerspiegelt. Gerade in dem oben erwähnten Punkt des Aging in Place bietet sich ja eine Kombination dieser Lösungsansätze an, da ältere Menschen zum Einen Tätigkeiten einfach nicht mehr
ausführen können, die ihnen die intelligente Umgebung also abnehmen muss.
Zum Anderen wären sie aber sehr wohl in der Lage, eine Vielzahl anderer
Tätigkeiten durchzuführen, sofern sie nur daran erinnert werden oder auch
nur eine Hilfestellung, in welcher Form auch immer, erhalten.
1.4
Interaktionsmöglichkeiten
Auf Grund der vielfältigen Anwendungsmöglichkeiten und der Unmenge an
vorstellbaren Szenarien ist die Komplexität der Interaktion sehr hoch und
wird in Zukunft auch rasch ansteigen. Die menschliche Leistungsfähigkeit
stößt hingegen in dieser Hinsicht alsbald auf eine natürliche Grenze. Aus diesem Grund existiert eine Kluft zwischen der Leistungsfähigkeit des Systems,
also der intelligenten häuslichen Umgebung, und der menschlichen Fähigkeit
und Motivation, die gebotenen Möglichkeiten vollständig oder auch nur teilweise zu nutzen [14].
Ein möglicher Weg diese Probleme zu umgehen bzw. abzuschwächen,
führt in seiner Vollendung zu einer Umgebung, welche die Bedürfnisse ihrer
Bewohner a priori erkennt und dementsprechend ohne direkte Benutzereingaben agieren kann. Da man allerdings durchaus davon ausgehen kann, dass
es immer Unklarheiten in der Bestimmung dieser Bedürfnisse geben wird und
die Bewohner sich durch solch ein Vorgehen entmündigt fühlen können, wird
eine Interaktion zwischen Mensch und Maschine immer notwendig sein. Aus
diesem Grund versucht man, diese durch Verwendung aufkommender neuer
Technologien zu verbessern.
Ein äußerst vielversprechnender Ansatz ist die Verwendung eines multimodalen Systems. Ausgehend von der Definition in [31] geht man hier von
der Möglichkeit aus, über mehrere Interaktionsformen hinweg zu kommunizieren. Der Begriff Multi“ bedeutet hier also mehr als eine Möglichkeit“
”
”
6
1.4 Interaktionsmöglichkeiten
und Modalität bezieht sich auf den Kommunikationskanal wie Sprache, Gesten oder dergleichen.
Da die einzelnen Kommunikationskanäle durch eine gewisse Kapazitätsgrenze eingeschränkt werden, die Verwendung mehrerer solcher Kanäle die
insgesamte Kommunikationskapazität aber erhöhen kann, handelt es sich dabei um einen effektiven Weg, der Komplexität Herr zu werden. Dazu kommt
weiters noch die Möglichkeit, jeweils auf die aktuelle Situation abgestimmte
Modalitäten verwenden zu können. Ein denkbares Beispiel wäre die Zubereitung eines Essens. Man hätte die Möglichkeit, über grafische Oberflächen
mit der Umgebung zu interagieren, um etwa Kochrezepte zu finden oder
Küchengeräte zu bedienen. Macht man sich im Zuge des Kochens allerdings
die Hände schmutzig, so könnte man alle weiteren Befehle mündlich erteilen.
Im optimalen Fall sollte solch ein Modalitätswechsel jederzeit möglich sein [7].
7
2
Spektrum der Arbeit
2.1
Ausgangssituation
Es gibt auf dem Markt inzwischen eine Unmenge an Lösungen für die Umsetzung und Installation eines Smart-Home-Systems. Aufbauend auf einer dieser
Technologien, nämlich dem FS20-System von Contronics/ELV beschäftigt
sich zum aktuellen Zeitpunkt eine weitere Diplomarbeit desselben Institutes
damit, eine Plattform zu schaffen, auf welcher man in weiterer Folge aufsetzen und in einer sinnvollen Abstraktionsebene weiterführende Forschungsarbeit durchführen kann. Diese Softwareinfrastruktur wird im ersten Schritt
zunächst die wichtigsten Sensoren und Aktoren des FS20-Systems modellieren, abbilden und zur Verfügung stellen. Weiters wird ein offenes Schnittstellendesign erarbeitet, auf dessen Basis verschiedenartige Interface- bzw. Steuerungsmöglichkeiten realisiert werden können. Die von den Komponenten gelieferten Informationen sollen zudem abgebildet und über diverse Schnittstellen abgefragt werden können, um so insgesamt eine leistungsfähige Basis für
die Entwicklung diverser Applikationen zu erhalten. Nachdem die Realisierung der Plattform parallel zu dieser Arbeit erfolgt, wird davon ausgegangen,
dass diese für die Entwicklung dieses darauf aufbauenden Projekts verfügbar
ist [15].
Auf der Ebene der Benutzerinteraktion gibt es für das FS20-System eine Reihe proprietärer Softwarelösungen. Zum Einen eine Entwicklung des
Herstellers selbst, das so genannte Homeputer-Studio und ein zugehöriger
Webserver zur Steuerung des Haushaltes mittels eines Webbrowsers. Zum Anderen eine allgemeinere Lösung namens IPSymcon. Das Homeputer-Studio
selbst ist allerdings in der Konfiguration und Bedienung etwas schwerfälliger
und bietet keine sehr große Funktionsvielfalt oder Erweiterungsmöglichkei-
2.2 Zielsetzung
ten. Die Installation neuer Komponenten und die Konfiguration des Systems
gestaltet sich als recht schwierig und zeitaufwändig. Auch der zugehörige
Webserver ist sehr rudimentär ausgeführt und stellt die möglichen Schaltvorgänge lediglich als eine Aneinanderreihung mehrerer Eingabefelder und
Dropdownboxen dar. Bei der Verwendung von IPSymcon hat man ein erheblich breiteres Funktionsspektrum zur Verfügung, erkauft sich dieses allerdings
mit einer weit höheren Komplexität beim Umgang mit der Software. Das
Erstellen von Web-basierten Interfaces funktioniert bei dieser Lösung besser
als bei dem Homputer-Webserver. Man bedient sich hierbei der Skriptsprache
PHP und hat dadurch die Möglichkeit, Interfaces relativ frei zu gestalten. Allen verfügbaren Softwarelösungen gemein ist allerdings, dass sie nur auf einer
Windows-Plattform laufen, kommerzielle Produkte sind und deren Sourcecode nicht frei verfügbar oder einsehbar ist. Aufgrund dessen sind die Erweiterungsmöglichkeiten, welche notwendig werden, sollte eine weiterführende
Forschungstätigkeit in diesem Bereich erfolgen, gar nicht bzw. nur eingeschränkt gegeben. Dazu kommt die Tatsache, dass keine der Lösungen eine
multimodale Interaktion überhaupt in Betracht zieht.
2.2
Zielsetzung
Aufgrund des großen Forschungsbedarfes soll eine grundlegende Plattform
entwickelt werden, welche wissenschaftliches Arbeiten im Bereich Smart
”
Home Interaktion“ möglich macht und vereinfacht, um in Zukunft UsabilityStudien o. Ä. einfach und rasch durchführen zu können. Die Realisierung
wird sich dazu in zwei größere Teilbereiche gliedern:
2.2.1
Multimodales Interaktionsframework
Die Basis der Arbeit stellt die erwähnte Plattform dar, welche in ihrer Endform eine API zur Verfügung stellen wird, um in vernünftiger Weise mit
den zugrunde liegenden Smart Home Komponenten interagieren zu können.
Aufbauend auf diesem Zugang soll ein Framework erstellt werden, welches
eine möglichst einfache Entwicklung von Smart Home Applikationen erlaubt.
Die Anforderungen an die Funktionalität des Frameworks können wie folgt
definiert werden: Die Interaktion der Benutzer mit den Anwendungen soll
über unterschiedliche Modalitäten möglich sein. In der Anfangsphase ist es
hinreichend, einen Zugang über graphische und sprachliche Modalitäten zu
ermöglichen. Einer späteren Erweiterung um zusätzliche Modalitäten soll allerdings nichts im Wege stehen. Die Entwicklung von Anwendungen und
die Synchronisierung der einzelnen involvierten Modalitäten soll einfach und
9
2.3 Eingrenzung des Themenbereichs
zuverlässig möglich sein. Eine weitere Anforderung besteht darin, die Benutzungsschnittstellen hinsichtlich Anwenderpräferenzen und Geräteeigenschaften adaptierbar halten zu können. Die Interaktionsmöglichkeiten sollen also
den Wünschen des aktuellen Benutzers entsprechend aufbereitet und angeboten werden. Geräteattribute, wie kleine Bildschirme oder eingeschränkte I/O
Möglichkeiten, sollen einen Einfluss auf das Erscheinungsbild der Schnittstelle haben können. Der Fokus bei der Implementierung von Anwendungen liegt
hier jedoch nicht auf den Endbenutzern des Systems, sondern auf Personen
mit Programmierkenntnissen, von einem grundlegenden Fachwissen ist also
auszugehen.
2.2.2
Nutzungsszenarien
Nach der Realisierung des Frameworks sollen grundlegende Nutzungsszenarien entworfen und umgesetzt werden. Dies verfolgt zum Einen den Zweck,
eine grundlegende Interaktion mit dem Smart Home möglich zu machen,
um die bereits verfügbare Infrastruktur nutzen zu können. Zum Anderen
soll mittels der Implementierung diverser multimodaler Applikationen auch
die Robustheit und Verwendbarkeit des entwickelten Frameworks getestet
werden. Darüber hinaus wird mit diesen Anwendungen auch die zugrunde
liegende Architektur von Felsing [15] auf ihre Anwendbarkeit geprüft.
2.3
Eingrenzung des Themenbereichs
Die Interaktion zwischen Benutzer und dem System soll über mehrere Interaktionsformen möglich sein. Diese unterscheiden sich zwar in ihrer Ausprägung (sprachlich, visuell ...), die über sie angebotenen Interaktionsmöglichkeiten sind jedoch in vielen Fällen die gleichen. Aus diesem Grund wäre es
wünschenswert, wenn man diese nur einmal abbilden müsste und anschließend die Charakteristiken der unterschiedlichen Interaktionsformen automatisch daraus generiert werden könnten. Im Zuge dieser Arbeit, welche den
ersten Schritt in diesen Bereich darstellt, ist es allerdings ausreichend, wenn
jeder Interaktionsform eine eigene Beschreibung zugrunde liegt. Auf eine
zukünftige Erweiterbarkeit wird jedoch geachtet.
Es soll für den Benutzer möglich sein, über sämtliche zur Verfügung stehenden Modalitäten Eingaben zu tätigen und auch während der Durchführung
einer Tätigkeit die Interaktionsform zu wechseln. Die Kombination der Eingaben mehrerer Modalitäten zur Generierung einer einzelnen Eingabe liegt
10
2.4 Weitere Vorgehensweise
allerdings außerhalb des Spektrums der Arbeit.
Außer Acht gelassen wird im Zuge der Arbeit auch das Thema Sicherheit.
Natürlich muss für eine Benutzerverwaltung auch ein Authentifizierungsund Autorisierungsvorgang existieren, dieser wird aber relativ elementar ausgeführt. Argumentieren kann man dies neben dem prototypischen Charakter
der Anwendung vor allem durch die Komponenten, welche in den untersten
Ebenen der Plattform verwendet werden und auf die diese UI-Architektur
aufsetzen soll. Die hier übertragenen Steuerungsdaten sind unverschlüsselt
und von Außenstehenden äußerst einfach zu manipulieren.
2.4
Weitere Vorgehensweise
Um die gesteckten Ziele zu erreichen, wird sich die weitere Vorgehensweise wie folgt gestalten: Da sich ein großer Teil der Aufgabenstellung mit der
Planung und Implementierung einer multimodalen Architektur befasst, werden zunächst die möglichen Interaktionsmodalitäten untersucht und im Hinblick auf ihre Anwendbarkeit im Smart Home Bereich klassifiziert. In weiterer
Folge werden bestehende diesbezügliche Technologien und Projekte in Augenschein genommen und deren Problemlösungsansätze diskutiert. Auch die
Beschreibungssprachen, welche in diesem Kontext Anwendung finden, werden auf ihre Relevanz hin untersucht.
Anschließend an diese theoretische Aufarbeitung der unterschiedlichen
Problembereiche folgt die Konzeptionierung des praktischen Teils dieser Arbeit. Hier wird ausgehend von den zuvor erworbenen Erkenntissen ein Framework bzw. eine Architektur bestimmt, anhand derer ein multimodales System
umgesetzt werden kann, welches die Anforderungen in der Zielsetzung erfüllt.
Im Rahmen der Konzeptionierung werden weiters die umzusetzenden Szenarien definiert, welche die grundlegende Haussteuerung ermöglichen sollen
Danach folgt eine Ausarbeitung über die praktische Umsetzung der Arbeit, welche die verwendeten Technologien kurz anreißt, die Anknüpfungspunkte an die zugrunde liegende Architektur [15] erläutert und Details über
die tatsächliche Implementierung des Systems aufzeigt. Abschließend folgt
eine Diskussion über die Ergebnisse der Arbeit im Hinblick auf die multimodalen Interaktionsmöglichkeiten.
11
3
Multimodale Interaktion
3.1
Allgemeines
Es existiert eine Reihe von unterschiedlichen Methoden zur Mensch-MaschineKommunikation. Die klassischen WIMP-Schnittstellen [6] zählen hier sicherlich zu den verbreitetsten Vertretern im grafischen Bereich. Auch die Verwendung von sprachgesteuerten Systemen ist heute nicht mehr unüblich
und findet vor Allem bei Telefonsystemen einen großen Anwendungsbereich.
Darüber hinaus existieren auch exotischere“ Schnittstellenvarianten, welche
”
sich nicht bzw. noch nicht wirklich durchgesetzt haben, aber insbesondere im
wissenschaftlichen Bereich ein reges Forschungsinteresse wecken. Unter Anderem betrifft dies dreidimensionale Schnittstellen, virtuelle Realitäten oder
haptische Ein- und Ausgabegeräte sowie die Erkennung von Gesten. Auch
Ansätze außerhalb der Computerdomäne sind denkbar, wie beispielsweise die
Verwendung von Einrichtungs- oder Kunstgegenständen zum Zwecke der Interaktion mit einem Computersystem. Die meisten dieser Interaktionsformen
sind bis zu einem gewissen Maße in einer Smart Home Umgebung durchaus
einsetzbar. Wie bereits zu Beginn der Arbeit erwähnt, könnte die Kontrolle
des Smart Homes durch die Benutzer jedoch erheblich verbessert werden,
indem man mehrere Modalitäten kombiniert und Ein- bzw. Ausgaben nicht
nur unimodal sondern multimodal ausführt.
Die Anfänge dieser Idee reichen zurück bis hin zu Richard Bolt [9] und
haben bis heute eine große Anzahl von Forschungsaktivitäten und Projekten
angestoßen, von denen einige nachfolgend auch beschrieben werden. Durchdachte multimodale Systeme erweitern den HCI-Bereich durch größere Flexibilität, einem natürlicheren Zusammenspiel von Mensch und Maschine sowie
ausdrucksstärkeren Interaktionsmöglichkeiten. Die Verwendung von Maus
3.2 Interaktionsmodi
und Tastatur stößt relativ rasch an Grenzen, geht es zum Besispiel um die
Navigation in bzw. Steuerung von virtuellen Umgebungen. Aus diesem Grund
werden Systeme benötigt, deren Ein- und Ausgabemöglichkeiten umfangreicher und sehr gut aufeinander abgestimmt sind [34].
Gut durchdachte multimodale HCI-Systeme haben eine Reihe von nicht
von der Hand zu weisenden Vorteilen. Die Kommunikation mit Benutzern
wird um einiges robuster, Fehler werden leichter erkannt und können verhindert werden. Eingabeverfahren sind häufig mit einer gewissen Fehlerwahrscheinlichkeit bzw. Mehrdeutigkeiten behaftet, welche durch die Kombination mehrerer Interaktionsformen gemildert oder gänzlich verhindert werden
können. Wie eben erwähnt, ist es allerdings wichtig, solche Systeme richtig
zu konzipieren und einzusetzen, da die Vorteile bei einer falschen Nutzung
multimodaler Systeme sehr rasch ins Gegenteil umschlagen können und diese
dadurch die Mensch-Maschine-Kommunikation erschweren können [22].
Abbildung 3.1 zeigt einen groben Überblick über multimodale Interaktion
und beschreibt die einzelnen Modalitäten als Kommunikationsmodi, welche
in Hinblick auf die menschlichen Sinne Sehen, Hören, Berühren, Riechen und
Schmecken definiert werden. Die Ein- und Ausgabemöglichkeiten von Computersystemen können ebenfalls einer oder mehrerer dieser Kategorien zugewiesen werden. Mit Hilfe der unterschiedlichen Interaktionsformen können
in der Folge verschiedenste Benutzungsschnittstellen konzipiert und umgesetzt werden. Ein Beispiel, welches in Abbildung 3.1 zu sehen ist, sind die
Attentive Interfaces“, welche kontextabhängig bestimmen, worauf Benutzer
”
gerade ihre Aufmerksamkeit richten, dies als zusätzlichen Input verwenden
und darüber hinaus auch den optimalen Zeitpunkt einer eventuellen Ausgabe anhand des Benutzerverhaltens ermitteln können. Wie in der Abbildung
ebenfalls zu sehen ist, sind die Anwendungsgebiete dieser Technologie mannigfaltig und jedenfalls auch im Smart Home Bereich zu sehen [22].
3.2
Interaktionsmodi
Ermöglicht man den Benutzern, mit einem System über mehrere Modalitäten
hinweg in Beziehung zu treten, so kann man grundsätzlich zwischen sequenzieller, simultaner und gemischter Interaktion unterscheiden[19]. Erfolgt die
Kommunikation sequenziell, so werden die Eingaben nacheinander über nur
eine der verfügbaren Modalitäten getätigt. Die verwendete Modalität kann
hier zwar nach einiger Zeit wechseln, dennoch bleibt sie in der Regel über
einen längeren Zeitraum dieselbe. Beispielsweise wird über einen kompletten
13
3.2 Interaktionsmodi
Abb. 3.1: Überblick über multimodale Interaktion. Angelehnt an Jaimes und
Sebe [22]
Workflow hinweg nur eine Spracheingabe akzeptiert. Bei simultaner Interaktion ist es demgegenüber möglich, zu jedem beliebigen Zeitpunkt jede beliebige
Modalität zu verwenden. Die Eingaben werden im System zwar dennoch in
der Reihenfolge ihres Eintreffens abgearbeitet, aber der Weg, über den sie
getätigt werden, ist nicht zwingend vorgegeben. Hier wäre das in der Einleitung erwähnte Kochbeispiel zutreffend und einzureihen. Als Letztes wäre
noch die gemischte Interaktion zu sehen. Hier können Eingaben ebenfalls
jederzeit über jede beliebige Modalität getätigt werden, jedoch werden sie
nicht nacheinander übermittelt, sondern bereits im Vorfeld, sofern semantisch sinnvoll, zu einer einzigen Eingabe zusammengefasst [56]. Ein Beispiel
für solch einen Modus wäre das Put that there“-Prinzip von [9]. Hier wird
”
ein Teil der Eingabe über die sprachliche Modalität geführt, indem man dem
System mitteilt, es möge ein bestimmtes Objekt an einen bestimmten Ort
legen. Die genauere Bestimmung des Objektes und des Ortes wird allerdings
zeitgleich über eine andere Modalität durchgeführt, indem man beispielsweise auf einer grafischen Oberfläche ein Symbol aus- und einen Zielort anwählt.
Eine weitere Unterscheidung ergibt sich durch Verwendung der verfügbaren Modalitäten in einer supplementären bzw. komplementären Kombination. Bei Ersterer werden über alle betroffenen Modalitäten die gleichen
grundsätzlichen Ein- und Ausgabemöglichkeiten zur Verfügung gestellt, welche sich aber natürlich in ihrer Ausprägung und dem verwendeten Medium
unterscheiden. Der Benutzer kann sich also für die in der aktuellen Situation
am besten geeignete Interaktionsvariante entscheiden. So wäre es denkbar,
eine bestimmte Telefonnummer während einer Autofahrt über einen Sprachbefehl zu wählen. In einer sehr lauten Umgebung, wie in einer Cafeteria, kann
allerdings auf die Möglichkeit der Eingabe über das Tastenfeld zurückgegriffen werden [35]. Weiters wäre es in dieser Situation nicht so tragisch, würde
14
3.3 Fusion / Fission
eine der Modalitäten wegfallen, da man sämtliche Eingaben auch über die
anderen noch verbliebenen durchführen könnte. Befindet man sich in komplementärem Betrieb, so bedeutet das, dass die Anzahl und Form der möglichen
Eingaben je nach verwendeter Modalität variieren kann. Hier muss natürlich
größere Aufmerksamkeit darauf gelegt werden, das System auch nach Wegfall von diversen Modalitäten weiterhin zuverlässig bedienbar zu halten. Ist
eine bestimmte Eingabe nur über einen Weg möglich und dieser fällt weg,
befindet man sich in einer unerwünschten Situation. Ein Ausweg wäre auch
hier das Anbieten supplementärer Alternativen, also einer Kombination aus
den beiden Modi [56, 19].
3.3
Fusion / Fission
Um nun die eben beschriebene gemischte Interaktion überhaupt möglich zu
machen, bedarf es natürlich gewisser Konzepte und Methoden, welche durchaus nicht als trivial zu bezeichnen sind. Der Prozess, mehrere multimodale
Eingaben zu einer zusammen zu fassen, wird im allgemeinen als multimodale
Fusion bezeichnet. Die entgegengesetzte Variante, also Ausgaben des Systems
dem Benutzer wieder semantisch korrekt über die verfügbaren Interaktionskanäle zu präsentieren, wird multimodale Fission genannt.
Wie gut und genau solche Fusionsmechanismen arbeiten, hängt neben
den verwendeten Modalitätstypen natürlich auch vom Abstraktionsniveau
und dem verwendeten Modell ab. Da das Ziel hierbei ein für den Menschen
natürlicher Informationsfluss ist, sollte auch das hierfür verwendete Modell
dementsprechend aufgebaut sein. Es wurden in der Vergangenheit diverse
neurologische Studien mit dem Ziel durchgeführt, zu erkennen, wie die Eindrücke von Bildern, Geräuschen und Berührungen bei Personen im Rahmen
einer zwischenmenschlichen Kommunikation zusammengeführt werden. Dabei wurden drei charakteristische Konzepte gefunden, welche im HCI-Bereich
von Bedeutung sind. Erstens ist die Reaktion auf mehrere schwache Eingangssignale um einiges höher als bei nur einem starken Eingangssignal, was
jedenfalls für die Anwendung multimodaler Benutzungsschnittstellen spricht.
Zweitens hängt die Art der Zusammenführung von Information aus unterschiedlichen Kanälen sehr stark vom aktuellen Kontext ab, in der sich das
Individuum gerade befindet. Ein- und dieselben Eingaben können also in
unterschiedlichen Situationen völlig unterschiedlich kombiniert werden. Drittens können, ausgehend vom aktuellen Kontext, irreguläre oder falsche Eindrücke eines Kommunikationskanals entweder ignoriert oder erneut geprüft
werden, was zu einer höheren Fehlertoleranz führt [36].
15
Wie in Abbildung 3.2 zu sehen, kann nun solch eine Fusion auf unterschiedlichen Ebenen stattfinden. Variante a) beschreibt hier eine Zusammenführung auf der Datenebene. Hier werden Sensordaten direkt miteinander kombiniert. Dies kann natürlich nur dann geschehen, wenn es sich dabei
um Sensordaten desselben Typs, bzw. um sehr eng gekoppelte Modalitäten,
wie zum Beispiel Sprache und Lippenbewegungen, handelt. Auch wird bei
dieser Art der Fusion nur das Ergebnis betrachtet und als eine einzelne gemeinsame Modalität angesehen, was in höheren Ebenen die Bewertung und
Bearbeitung schwieriger bis unmöglich macht [22]. Auf dieser Ebene können
also unterschiedliche Sensoren nicht zusammengeführt werden, und genau
aus diesem Grund ist diese Art der Fusionierung im HCI- und damit weiters
im Smart-Home-Bereich nicht oder nur sehr begrenzt einsetzbar [36].
Bei einer Fusion nach Variante b) werden die verschiedenen Eingaben
nach ihren Merkmalen und Charakteristiken untersucht. Anders als in a)
werden unterschiedliche Modalitäten hier einzeln erfasst und nach Genauigkeit und Zuverlässigkeit der Erkennung klassifiziert. Danach können diese zu
einer einzelnen Eingabe kombiniert werden, wobei dies anhand von aktuellen,
aber auch erst kürzlich getätigten Eingaben erfolgen kann [22]. Durch diesen Vorgang sind die Informationen auf dieser Ebene zwar etwas abstrakter,
allerdings auch toleranter gegenüber Störungen oder Sensorenfehlern. Diese
Art der Fusion eignet sich für die Anwendung bei stark gekoppelten Modalitäten am besten und es existiert hierfür auch eine Reihe von Techniken zur
Durchführung. Pantic nennt hier einige Beispiele, wie Kalman Fusion, künstliche Neurale Netze oder Hidden Markov Models [36].
Die dritte Möglichkeit zur Fusionierung wird in Variante c) beschrieben.
Hier werden zunächst alle Eingaben getrennt bewertet und analysiert. Erst
am Ende werden die fertig bearbeiteten Eingaben zusammengeführt. Diese
Methode findet sich in sehr vielen multimodalen Systemen wieder, da die
Zusammenführung auf den darunterliegenden Ebenen schwieriger umsetzbar
ist. Sie ist jedoch nicht die beste Variante. Dies aus dem einfachen Grund,
da die Kommunikation, wie bereits beschrieben, durchaus komplementär erfolgen kann und dadurch teilweise Eingaben in nur einer Modalität alleine
oft keinen Sinn ergeben und bereits vorher mit anderen kombiniert werden
müssen[36]. Ein Vorteil dieser Variante ist unter anderem die Möglichkeit,
jede Modalität getrennt voneinander trainieren und anpassen zu können. Sie
eignet sich recht gut für Eingabemethoden, welche temporär relativ lose gekoppelt sind oder großteils komplementäre Eingaben erlauben [22].
Foster [17] beschreibt den Terminus multimodale Fission“ als den Pro”
16
Abb. 3.2: Fusion mehrerer Modalitäten [36]
zess der Realisierung von Ausgaben über mehrere zur Verfügung stehende
Ausgabekanäle, sprich Modalitäten. Es handelt sich hier also um das entsprechende Pendant zur Eingabe über multimodale Fusion. Hierbei sind drei
grundsätzliche Schritte relevant und notwendig: Der zu übermittelnde Inhalt
muss zunächst ausgewählt und strukturiert werden. Danach kann festgelegt
werden, welcher Teil dieses Inhaltes wie und über welche Modalität übermittelt wird. Zu guter Letzt müssen die einzelnen Kommunikationskanäle
koordiniert werden, um am Ende ein einheitliches Gesamtbild zu ergeben.
Zum ersten Schritt kann nun folgendes gesagt werden: Die Auswahl und
Strukturierung von Inhalten multimodaler Anwendungen folgt sehr stark den
Prinzipien der Erstellung von Texten. Aus diesem Grund finden hier auch
dieselben Techniken Verwendung. Die Strukturierung kann hierbei in drei
Bereiche aufgeteilt werden. Zum Einen geht es um die Absicht, welche hinter den unterschiedlichen Äußerungen steht und welchen Einfluss sie auf den
Empfänger haben bzw. haben sollen. Zum Anderen geht es um die semantischen Beziehungen zwischen den formulierten Aussagen und den beinhaltenden Informationen. Und zu guter Letzt werden Objekte, Eigenschaften
und Beziehungen beschrieben, welche zum aktuellen Zeitpunkt im Fokus der
Aussage liegen [17].
Bei der Auswahl der geeigneten Ausgabemodalitäten geht es nun darum,
diejenige Kombination zu finden, welche die Daten am besten und verlustfreiesten übermitteln kann. Das Problem hierbei ergibt sich aus der Auswahl
der Modalitäten auf der Systemseite und aus der Aufgabe des erneuten Zu-
17
sammenfügens der Informationen auf der Empfängerseite. Für diese Aufgabe
ist folgendes Wissen wichtig und relevant (André [2], zitiert nach [17]):
Die Charakteristiken der verfügbaren Ausgabemodalitäten: Ausgabemodalitäten können anhand unterschiedlicher Eigenschaften charakterisiert werden. Die grundsätzlichste Eigenschaft ist hier sicherlich der Typ, nämlich
ob es sich um eine grafische, akustische oder haptische Modalität handelt.
Es gibt aber noch eine Reihe weiterer Eigenschaften, anhand derer eine
Unterteilung stattfinden kann. Beispiele wären hier dynamische/statische
oder linguistische/nicht-linguistische Ausprägungen.
Die Charakteristiken der präsentierten Informationen: Auch der Inhalt
kann, wie die Modalitäten selbst, anhand verschiedener Eigenschaften charakterisiert werden. Beispiele wären hier Dringlichkeit, Informationsdichte
oder Gültigkeitsdauer von Information.
Das Kommunikationsziel
Die vom Benutzer durchzuführende Aufgabe
Die Charakteristiken des Benutzers: Auch die Eigenschaften des Benutzers
können für eine Modalitätsauswahl beeinflussend sein. So könnten erwachsene Personen textlastigeren Output erhalten, wohingegen eine jüngere
Zielgruppe Informationen auf andere Art und Weise erhalten würden. Bei
Personen mit Hörschäden würden akustische Modalitäten nicht zur Ausgabe herangezogen etc.
Jegliche Einschränkungen der verfügbaren Ressourcen: Insbesondere im
Bereich mobiler Endgeräte stößt man relativ rasch an physikalische Grenzen, welche bei der Modalitätsausawahl in Betracht gezogen werden müssen.
Die Rede ist hierbei von kleinen Displays, begrenzter Rechenkapazität oder
Ähnlichem. Eine Kombination von Ausgabemedien ist also auch unter diesem Gesichtspunkt zu betrachten und anzupassen.
Der erste Schritt besteht nun darin, die gesamte Ausgabe in Teilbereiche zu gruppieren, welche in sich kompatibel sind. Zu jedem dieser Bereiche
werden nun die entsprechenden Repräsentationsformen ausgewählt, welche
in der Lage sind, die darin enthaltene Information auszugeben. Anschließend
wird anhand von definierten Regeln bestimmt, welche Repräsentationsform
aktuell verwendet werden soll. Solch eine Regel könnte beispielsweise lauten:
Gibt es sehr viel Information zu vermitteln, soll ein Medium gewählt wer”
den, welches diese Informationen dauerhaft darstellen kann“, hier wäre zum
Besipiel eine akustische Ausgabe nicht sinnvoll.
Sind die zu verwendenden Modalitäten definiert und gefunden, so geht es
nun noch darum, diese untereinander zu koordinieren und synchron zu hal-
18
ten. Die Inhalte müssen möglichst optimal an die Ausgabemedien aufgeteilt
und angepasst werden. Dies kann im einfachsten Fall anhand vordefinierter
Templates geschehen, allerdings bietet es sich auch hier an, Regeln zu definieren, anhand derer die Inhalte dynamisch in Form gebracht werden können.
Weiters ist die zeitliche Koordination insbesondere bei Verwendung von dynamischen Modalitäten wie Sprachausgabe wichtig, um sicherzustellen, dass
bestimmte Ausgaben auch zur richtigen Zeit erfolgen. Diese müssen zum
Einen sinnvoll in den Informationsfluss integriert werden, ihn zum Anderen
aber auch nicht stören. Eine asynchrone Ausgabe kann den Benutzer eher
verwirren, als dass sie ihm hilft, die übermittelten Informationen verarbeiten
zu können [17].
3.4
Herausforderungen
Wie bereits erwähnt, genügt es nicht, dem Benutzer einfach ein System zur
Verfügung zu stellen, bei dem er mehrere Interaktionsmöglichkeiten hat, um
eine schlagartige Verbesserung der Mensch-Maschine-Kommunikation zu erhalten. Die zugrunde liegenden Mechanismen, welche eine solche Interaktion
ermöglichen, müssen sehr gut durchdacht sein, um eine Effizienzsteigerung
zu erhalten. Diesbezüglich hat Oviatt bereits im Jahr 1999 einige häufige
Irrtümer und fälschliche Annahmen in Hinblick auf multimodale Systeme
erläutert, die nachfolgend in aller Kürze zusammengefasst werden [34].
Anwender eines multimodalen Systems wollen und werden nicht unbedingt
auch multimodal interagieren. Anwender empfinden die Möglichkeit einer
multimodalen Interaktion zwar als positiv, nehmen diese allerdings nicht
immer wahr. Ausgehend von menschlichen Kommunikationsmustern erfolgt ein großer Teil dieser Kommunikation auf einem unimodalen Weg.
Nur in bestimmten und vorhersehbaren Situationen ist die Wahrscheinlichkeit hoch, dass multimodale Kommunikationsmittel eingesetzt werden.
Dies erfolgt beispielsweise sehr häufig, wenn räumliche Informationen in
der Kommunikation inbegriffen sind. Als Beispiel sei auch hier wieder das
Put that there“-Prinzip erwähnt. Diese Tatsache ist gerade für den Fu”
sionsvorgang sehr interessant, da so eine Unterscheidung von zusammengehörenden bzw. semantisch disjunkten Eingaben getroffen werden kann.
Während der Sprache auf etwas zu deuten, ist nicht zwingend das häufigste
Interaktionsmuster. Gerade im Bereich der Gesten treten andere Muster,
wie zum Beispiel das Erstellen von Symbolen oder Grafiken, viel häufiger
auf und Systeme sollten auch dafür offen konzipiert werden.
19
Zusammenhängende Eingaben über unterschiedliche Modalitäten müssen
nicht synchron erfolgen. Erfordert ein gesprochener Befehl beispielsweise zusätzliche Information über einen anderen Informationskanal, kann es
durchaus vorkommen, dass zwischen beiden Eingaben einige Augenblicke
verstreichen. Zur Fusion genügt es also keineswegs, nur zeitgleich eintreffende Eingaben heranzuziehen - dafür verantwortliche Algorithmen müssen
darüber hinaus gehende Strategien zur Fusionierung implementieren.
Man kann nicht davon ausgehen, dass Sprache, sofern verfügbar, die primär
verwendete Modalität darstellt. Auch ist Sprache nicht zwingend der Kanal, über den die ersten Eingabesignale eintreffen. In den meisten Fällen
werden zuvor andere Modalitäten genutzt. Man darf bei der Entwicklung
von multimodalen Applikationen also die übrigen Modalitäten keineswegs
als unwichtiger erachten.
Ein großer Teil der Kommunikation erfolgt komplementär. Ein redundanter, supplementärer Modus wird demgegenüber nur selten verwendet.
Wie bereits erwähnt, führt die Verwendung mehrerer fehlerbehafteter Eingabemöglichkeiten, bei deren Kombination durchaus nicht zu einer größeren Fehlerhäufigkeit, sondern, ganz im Gegenteil, die einzelnen Modalitäten
ergänzen sich zu einem robusteren Eingabesystem.
Es hängt sehr stark von der jeweiligen Person ab, wie diese mit dem System
umgeht. Einige Menschen tätigen multimodale Eingaben simultan, andere
wiederum sequenziell. Zu erkennen ist aber, dass sich die Verwendungscharakteristiken einer jeweiligen Person mit der Zeit nicht verändern. Kann
ein System also zu Beginn feststellen, wie sich jemand verhält, kann dieses
Verhalten der gesamten Sitzung zugrundegelegt und die Erkennungsrate
somit gesteigert werden.
Jede Modalität unterscheidet sich grundsätzlich von allen anderen. Es ist
demnach nicht möglich, jedweden Inhalt zwischen unterschiedlichen Modalitäten durch einfaches Übersetzen zu transferieren. Es gibt natürlich
Teilbereiche, in denen das möglich ist, von einer Allgemeingültigkeit ist
jedoch nicht auszugehen.
Eine Effizienzsteigerung bei der Verwendung multimodaler Systeme im
Gegensatz zu unimodaler Interaktion ist zwar durchaus gegeben, stellt aber
nicht den einzigen und auch nicht den wichtigsten Vorteil dar. Viel mehr
wiegt hier die bereits erwähnte bessere Fehlererkennung bzw. Vermeidung
und natürlich auch die größere Flexibilität, die solche Systeme mit sich
bringen.
Diese Aussagen sind auch heute noch relevant und sollten bei der Entwicklung einer entsprechenden Plattform im Hinterkopf behalten werden.
20
4
Multimodale Frameworks und Projekte
Nachfolgend soll nun ein Überblick über entsprechende Frameworks und Projekte gegeben werden, welche sich mit Multimodalität befassen. Es werden
deren Ziele analysiert, deren Konzepte und Methodiken beleuchtet und ihre
Relevanz für die Umsetzung eines eigenen Prototypen diskutiert.
4.1
XHTML+Voice (X+V)
Wie der Name bereits vermuten lässt, handelt es sich bei dieser Technologie
um eine Kombination aus zwei Dokumenttypen bzw. Beschreibungssprachen.
Als Basis dient hier die XML-basierte Beschreibungssprache XHTML 1.0 [64],
welche vom W3C formuliert wurde und prinzipiell eine Weiterentwicklung
aus der ursprünglichen HTML-4.0-Spezifikation darstellt. Die Änderungen
betreffen großteils die XML-Konformität. HTML selbst ist in dieser Hinsicht
sehr tolerant und erlaubt das Erstellen von Dokumenten, welche nicht der
XML-Syntax entsprechen. Bei XHTML ist dies nicht mehr möglich und sämtliche erstellte Dokumente müssen aus validem XML-Code bestehen. Bei der
Erweiterung der Spezifikation auf XHTML 1.1 [63] wurde XHTML in eine
Sammlung unterschiedlicher Module zerlegt, welche jeweils eine bestimmte Funktionalität anbieten. Diese Module können nun beliebig in XHTMLDokumente eingebunden werden, um gewünschte Aufgaben zu übernehmen
und ergeben im Gesamtbild ein valides Dokument.
Durch diese Modularisierung wurde es möglich, XHTML mit VoiceXML
(VXML), bzw. einer Teilmenge davon, zu kombinieren. VoiceXML, ebenfalls eine XML-basierte Beschreibungssprache, wurde speziell dafür entwickelt, Audiodialoge zu definieren, um interaktive sprachgesteuerte Applikationen zu realisieren [57]. Man erstellt also XHTML-Dokumente, welche die
4.1 XHTML+Voice (X+V)
Beschreibung des grafischen Aufbaus der Benutzungsschnittstelle enthalten.
Innerhalb dieser Dokumente ist es nun möglich, mittels VXML den sprachlichen UI-Teil zu formulieren. In Abbildung 4.1 ist ein Beispiel für solch ein
XHTML+Voice Dokument zu sehen [65].
Abb. 4.1: Einfaches XHTML+Voice Dokument [65]
Wie man hier erkennen kann, wird im VXML-Tag (Zeilen 10-13) eine Audioausgabe formuliert, welche über einen Eventhandler in Zeile 17 angestoßen
wird, sobald der Benutzer mit der Maus auf den Textbereich klickt. Auf diese
Art und Weise können recht einfach audiovisuelle Benutzungsschnittstellen
entwickelt und implementiert werden.
Allerdings gibt es auch diverse Einschränkungen und Gründe die gegen
die Verwendung, vor allem im Smart-Home-Bereich, sprechen. Leider gibt es
von Seiten der Browserentwickler keine vernünftige Unterstützung für X+VInhalte, lediglich für Opera existiert ein Plugin, mit welchem solche Dokumente verarbeitet werden können. Des Weiteren sieht diese Spezifikation lediglich die Verwendung von sprachlichen und grafischen Modalitäten vor.
Eine Erweiterung von XHTML um zusätzliche Module, welche sich um andere Modalitäten kümmern, wäre zwar denkbar, wird von der Spezifikation
aber nicht abgedeckt. Darüber hinaus erfolgt die Verarbeitung der Inhalte und Benutzereingaben clientseitig und relativ eng gekoppelt. Gerade im
Smart Home Bereich sollten Benutzer jedoch auch über verschiedene Endgeräte hinweg multimodal mit der Umgebung interagieren können, was eine
verteilte oder zumindest serverseitige Verarbeitung der Ein- und Ausgaben
22
4.2 EMBASSI
notwendig macht.
Ein weiterer Kritikpunkt ist in der Formulierung der UI-Beschreibung zu
sehen. Jede der beiden Modalitäten muss separat definiert werden. Dies jedoch in ein- und demselben Dokument, was diesen Ansatz im Hinblick auf
übersichtliche und einfache UI-Entwicklung schwächt. Hinzu kommt noch die
Tatsache, dass zur Verknüpfung dieser beiden Modalitäten Scripte notwendig sind, welche bei größeren Dokumenten auch einen nicht unerheblichen
Teil des Umfangs darstellen. Der Trend in der UI-Entwicklung geht aber hin
zu semantisch höherwertigen Schnittstellenbeschreibungen, wobei aus einer
allgemeinen Formulierung sämtliche Modalitätsausprägungen abgeleitet werden können. Auch aus diesem Grund ist XHTML+Voice für größere Projekte
nicht unbedingt geeignet [20].
4.2
EMBASSI
Das EMBASSI-Projekt lief über einen Zeitraum von vier Jahren bis zu seinem Ende im Jahr 2003 und wurde vom Bundesministerium für Bildung und
Forschung in Deutschland gefördert. Hinzu kamen Beteiligungen von Seiten
der Industrie und diversen Hochschulen, wobei am Ende 19 unterschiedliche
Partner, darunter auch Firmen wie Sony oder Grundig, an der Umsetzung
mitgewirkt haben. Im Vordergrund stand hier das Problem der Interaktion
mit einer komplexen und unüberschaubaren Umgebung, in der selbst einfache Aufgaben, wie das Programmieren eines Videorekorders, den Benutzer
überforderten, von komplizierteren Aufgaben ganz zu schweigen. Die Ziele,
die bei diesem Projekt konkret im Mittelpunkt standen, lassen sich wie folgt
formulieren [18]:
Ermitteln eines einheitlichen und psychologisch fundierten Models zur systematischen Entwicklung von Assistenzsystemen unter Einbeziehung multimodaler Benutzungsschnittstellen.
Die Umsetzung einer Designumgebung, welche auf dem zuvor definierten
Modell fußt und die Arbeit von Entwicklern unterstützt und bereichert.
Die Entwicklung einer generischen Architektur, um solche Assistenzsysteme umsetzen und realisieren zu können.
Die Entwicklung von Werkzeugen, um multimodale Komponenten einfach
und modular implementieren zu können.
Das Konzept hinter EMBASSI geht, im Gegensatz zu den meisten anderen Projekten in diesem Bereich, weg von einer funktionalen Betrachtungsweise hin zu einer zielbasierten Interaktion. Man beschränkt sich bei der
23
4.2 EMBASSI
Interaktion mit den diversen Endgeräten also nicht nur darauf, deren Funktionen wie beispielsweise Ein“, Aus“ oder Play“ bei einem Videorekorder
”
”
”
direkt zu steuern, sondern hat vielmehr das gewünschte Ergebnis im Auge.
In dem genannten Beispiel wäre das also das Betrachten eines bestimmten
Videofilmes. Eine solche Herangehensweise hat natürlich den Vorteil, von
den vielen verschiedenen Gerätetypen abstrahieren zu können. Geräte verschiedener Hersteller können durchaus denselben Funktionsumfang besitzen,
präsentieren diesen jedoch auf unterschiedliche Art und Weise. Diese Differenz kann für den Anwender verwirrend sein [18].
Nachfolgend soll nun ein Überlick über die in EMBASSI entwickelte und
verwendete Architektur gegeben werden. Diese besteht aus einem Zusammenschluss von Agenten, welche sich jeweils um spezielle Aufgaben kümmern.
Dies geschieht weiterhin in unterschiedlichen Ebenen, in welchen mit jeweils
unterschiedlich abstrakten Daten gearbeitet wird. Die Kommunikation zwischen Agenten auf verschiedenen Ebenen wird über genau spezifizierte Protokolle durchgeführt. Verwendung findet hierbei KQML, eine XML-basierte
Sprache, welche häufig in agenten-basierten Systemen Einsatz findet. Die
Intelligenz des Gesamtsystems ergibt sich also aus dem Zusammenspiel der
einzelnen Agenten des Systems und nicht aus einer zentralen Datenstruktur
heraus [13].
Der Aufbau dieser Architektur ist in Abbildung 4.2 ersichtlich und kann
in folgende Teilbereiche gegliedert werden:
Eingabebezogene Komponenten: Hierunter fallen Komponenten, welche
Benutzereingaben in Empfang nehmen können. In der Abbildung sind
diese als I-Komponenten gekennzeichnet. Für jeden Interaktionstyp bzw.
für jede Modalität kommt hierbei eine darauf spezialisierte Komponente
zum Einsatz. Jede Eingabe wird in eine geräteunabhängige Repräsentation gebracht, welche sich für die weitere Verarbeitung besser eignet. Die
Weiterverarbeitung der Benutzereingaben erfolgt anschließend in den FKomponenten. Hier erfolgt eine Abstraktion und Überführung in semantische Beschreibungen, welche die Intentionen des Benutzers widerspiegeln. Abschließend werden diese Informationen in der PMI-Komponente
(polymodal input module) fusioniert, um dadurch zu einer integrierten
semantischen Repräsentation der Benutzereingaben zu gelangen. Um diese Vorgänge durchführen zu können, bedarf es natürlich Informationen
bezüglich der Umgebung und des Kontextes, in dem sich das System befindet. Diese Informationen werden im Kontext Manager C verwaltet und
können von den einzelnen Komponenten jederzeit in Anspruch genommen
24
4.2 EMBASSI
Abb. 4.2: EMBASSI Architektur. Angelehnt an Elting et al. [13]
werden. Die Fusion erfolgt hierbei nach der bereits beschriebenen 2. Variante (Abbildung 3.2 b). Erhält der PMI über eine beliebige F-Komponente
Daten, welche einen bestimmten Zeitraum betreffen, so stellt er an die
übrigen registrierten F-Komponenten Anfragen, ob auch diese für dieses
Intervall relevante Daten besitzen. Erst wenn von allen Komponenten eine Antwort vorliegt, sei sie positiv oder negativ, wird der Fusionsvorgang
durchgeführt. Auf diese Weise wird sichergestellt, dass alle relevanten Informationen für eine korrekte Fusionierung vorliegen [13].
Dialogmanager D: Diese zentrale Komponente hat die Aufgabe, aus den
eingegangenen Informationen die jeweilige Intention der Benutzer zu ermitteln um dann, nach eventueller Rückfrage nach weiterem Input, diese
anschließend in die Tat umzusetzen. Um diese Aufgaben zu erfüllen, arbeitet der Dialogmanager auf einem logik-basierten Ansatz und verwendet
das eingegangene Wissen, um Schlussfolgerungen und notwendige weitere Handlungen unter Zuhilfenahme einer grundlegenden Wissenbasis und
Regelbeschreibung zu inferieren. Anhand der Eingaben werden also Ziele (Goals) definiert, welche anschließend abgeleitet werden. Anzumerken
ist hierbei im übrigen der Schritt von einer verteilten Anordnung in einer
frühen Version von EMBASSI, umgesetzt durch mehrere D-Komponenten
hin zu einer zentralen Implementierung in der finalen Version, bei der nur
eine D-Komponente existiert [13, 18].
25
4.2 EMBASSI
Komponenten zur Umsetzung: Hierzu existieren in dieser Architektur so
genannte Assistenten (A-Komponenten), welche auf ein jeweiliges Aufgabengebiet spezialisiert sind und vom Dialogmanager nach der Auswertung
der Benutzerintention angesprochen werden, um die gewünschten Tätigkeiten auszuführen. Dabei werden Änderungen im System nicht direkt
durch diese Assistenten durchgeführt, sondern sie bedienen sich zur Umsetzung wiederum spezieller X-Komponenten, die abstrakte Repräsentationen von realen Gerätefunktionen anbieten. Über diese X-Komponenten
werden letztendlich die notwendigen Schaltfunktionen durchgeführt und
eine Änderung in der realen Umgebung bewirkt [13].
Ausgabebezogene Komponenten: Als Komplement zur Eingabe existieren hier auch vergleichbare Komponenten mit ähnlichen, wenn auch mit
entgegengesetzten Aufgaben. Auf der Ausgabenseite existiert eine PMOKomponente (polymodal output module), welche sich für die multimodale
Fission verantwortlich zeigt. Hierzu benötigt sie laut 3.3 unter anderem
Wissen über die Eigenschaften und Einschränkungen aller verfügbaren
Ausgabemodalitäten, das Kommunikationsziel und die Benutzercharakteristiken. Informationen über Erstere müssen von den jeweiligen Geräten
zur Verfügung gestellt werden, wenn sie sich am System anmelden. Eine Klassifizierung erfolgt mittels der Bernsen-Taxonomie (Vgl. [12]) in
Kategorien wie linguistisch/nichtlinguistisch, statisch/dynamisch etc. Das
Kommunikationsziel wird vom Dialogmanager anhand der Eingaben inferiert, zur Benutzeridentifizierung ist auch eine Gesichtserkennung angedacht, aber nicht genauer ausgeführt worden. Nachdem die zu übermittelnden Inhalte auf die zur Verfügung stehenden Modalitäten aufgeteilt
wurden, werden die abstrakten UI-Beschreibungen in den R-Komponenten
gerendert und anschließend über die O-Komponenten ausgegeben [12].
Das EMBASSI-Projekt ist ohne Zweifel sehr umfangreich und beinhaltet
eine große Anzahl interessanter Konzepte, welche auch nachfolgende Forschungsarbeiten geprägt haben. Auch wurde am Ende des Projektes der
verfügbare Sourcecode im Rahmen der OpenEmbassi-Initiative veröffentlicht
und stellt sicher eine mögliche Grundlage für weiterführende Arbeiten in diesem Bereich dar.
Es gibt natürlich auch einige Kritikpunkte, die gegen EMBASSI sprechen. So fehlen nach der Einstellung des Projektes 2003 entsprechende Ansprechpartner für auftretende Fragen, wobei auch die Dokumentation der implementierten Komponenten nicht immer in ausreichendem Maße verfügbar
bzw. existent ist. Ein Großteil der Implementierung ist unter der GPL frei
verfügbar, es gibt allerdings auch einige Programmteile, welche von Firmen-
26
4.3 AMIGO
partnern entwickelt wurden und unter anderen Lizenzen laufen. Neben diesen
kleineren Kritikpunkten existiert auch ein etwas größerer, der unter Anderem
in [5] angesprochen wird. Hierbei geht es um die monolithische Struktur der
EMBASSI-Architektur. Erweiterungen sind nur sehr schwer und aufwändig
durchzuführen, insbesondere, da die zentrale Komponente, der Dialogmanager, auf spezialisierten Algorithmen und logischem Schließen basiert.
4.3
AMIGO
Bei dem AMIGO-Projekt, welches im Jahr 2004 startete und bis Februar
2008 lief, handelte es sich um ein von der EU gefördertes Programm, in dessen Rahmen eine Middleware geplant und implementiert werden sollte, um
heterogene Systeme auf einer interoperablen Plattform zusammenführen zu
können. In diesem Projekt gibt es, wie auch bei EMBASSI, eine sehr große
Beteiligung von Seiten der Industrie, was sich durch die Mitarbeit von 15
Unternehmen und Forschungseinrichtungen äußerte. Die Ziele waren ebenfalls in eine ähnliche Richtung definiert, deckten jedoch einen noch größeren
Bereich ab. Eine besondere Anforderung betraf die Offenheit des Systems
gegenüber Änderungen oder Erweiterungen. Diese sollten nicht nur einfach
und rasch, sondern vor allem auch zur Laufzeit dynamisch durchführbar sein.
Gerade diese Eigenschaft fehlte ja bei EMBASSI großteils, was Weiterentwicklungen auf dessen Basis sehr erschwerten. Aus diesem Grund folgt die
AMIGO-Architektur nun einem serviceorientiertem Paradigma [44].
Hier setzt sich die Gesamtapplikation aus mehreren voneinander getrennten Einheiten zusammen, welche auch als Services bezeichnet werden. Ein
solches Service bietet eine bestimmte Funktionalität an und verfügt über
wohldefinierte Schnittstellen, mithilfe derer es mit der Außenwelt kommuniziert. Weiters existiert eine Service-Infrastruktur, welche das Suchen, Finden und Verwenden von Services ermöglicht. Es ist weiterhin möglich, Services über diverse Netzwerke zu übertragen und in einem anderen System
verfügbar zu machen. Auf diese Weise lassen sich neue Funktionalitäten einfach in bestehende Systeme einfügen. Dies ist auch von einem wirtschaftlichen
Standpunkt aus gesehen sehr interessant, da zum Beispiel Softwareerweiterungen von Kunden einfach und schnell gekauft, über das Internet bezogen
und automatisch in das bestehende System integriert werden können [24].
Als Grundlage findet bei AMIGO konkret das OSGI-Framework als serviceorientierte Plattform Verwendung, welches in einem späteren Kapitel dieser
Arbeit auch näher beleuchtet wird [43].
Wie bereits erwähnt, ist das AMIGO-Projekt sehr umfassend und um-
27
4.3 AMIGO
28
fangreich, was sich ebenfalls in der Architektur in Abbildung 4.3 widerspiegelt. Was im Kontext dieser Arbeit von Interesse ist, sind die intelligenten
User-Services und hierbei insbesondere das User-Interface-Service, weswegen
diese in der Folge näher erläutert werden.
Abb. 4.3: AMIGO-Architektur (vgl. [43])
Kontext Management Service: Dieses Service ist vergleichbar mit dem Kontextmanager im EMBASSI-Projekt. Hier werden Informationen hinterlegt,
welche den aktuellen Zustand des intelligenten Zuhauses widerspiegeln. Zu
diesem Zweck werden physische Sensoren, laufende Anwendungen, Internetapplikationen und viele weitere Informationsquellen herangezogen. Die
übrigen laufenden Services können über die definierte Schnittstelle zum
Kontext Management Service auf diese Informationen zugreifen und ihr
Verhalten dementsprechend anpassen [43].
Sicherheit/Privatsphäre: Ein wichtiger Aspekt im Smart-Home-Bereich ist
natürlich auch die Sicherheit. Dieses Service kümmert sich um Benutzerauthentifizierung bzw. -autorisierung genauso wie um Geräte- und Benutzerregistrierungen. Darüber hinaus befasst es sich auch mit der Wahrung der
Privatsphäre. Da mehrere Personen auf das System zugreifen können, muss
dafür gesorgt sein, dass sämtliche persönliche Daten einer Person von den
übrigen nicht eingesehen werden können [29].
Ereignisse/Benachrichtigung: Dieser Service ist sehr eng mit dem Kontext Management verküpft und stellt grundlegende Funktionalitäten zur
Verfügung, um Änderungen im aktuellen Smart Home Kontext zu registrieren. Anwendungen, welche sich für verschiedene Ereignisse interessieren,
können sich hier registrieren und werden bei einer Änderung benachrichtigt [43].
4.3 AMIGO
29
Benutzerprofile: Damit Applikationen optimal arbeiten und Ein- bzw. Ausgaben auf bestmöglichem Wege funktionieren, müssen diese auf den jeweiligen Benutzer abgestimmt werden. Dies kann durch in Anspruchname dieses Services geschehen. Zu diesem Zweck werden hier Benutzermodelle und
Profile erstellt und auf dem neuesten Stand gehalten, welche im wesentlichen eine Sammlung von individuellen Benutzerpräferenzen darstellen.
Benutzer können dem System zunächst über eine grafische Schnittstelle
ihre Vorlieben mitteilen, welche im ersten Schritt statisch hinterlegt werden. Diese Informationen werden im Laufe der Zeit immer wieder mit dem
impliziten Feedback des Benutzers verglichen und gegebenenfalls angepasst
bzw. erweitert. Bei einer Anfrage einer Applikation findet über diese Daten
eine Inferenz statt, an derem Ende die Nutzerpräferenzen retourniert werden, welche für die gegebene Situation relevant sind. Des Weiteren gibt es
auch noch die Möglichkeit, die Profile mehrerer Benutzer zu einem Gesamtprofil zu vereinen, was notwendig wird, wenn mehrere Personen gleichzeitig
in eine Handlung involviert sein sollten (sich also beispielsweise bei einer
Ausgabe über den Fernseher im selben Raum mit diesem befinden) [1].
Benutzungsschnittstellen: Dieser Bereich stellt nun den für die vorliegende
Arbeit interessantesten dar und befasst sich mit der multimodalen Interaktion zwischen den Benutzern und der Smart Home Umgebung. Abbildung
4.4 zeigt die diesem Service zugrundeliegende Architektur.
Abb. 4.4: AMIGO UIS Architektur (vgl. [29])
4.3 AMIGO
Dieses Service stellt nun also eine generische Plattform dar, welche
unter Zuhilfenahme der anderen eben erläuterten Services eine homogene multimodale Schnittstelle zur intelligenten Umgebung anbietet. Die
Interaktion mit dem System kann über viele verschiedene Geräte erfolgen, welche jeweils eine oder auch mehrere Modalitäten unterstützen. Ein
PDA kann so beispielsweise als grafische Benutzungsschnittstelle genutzt
werden, aber auch die Eingabe von Gesten mittels Eingabestift ermöglichen. Für die unterschiedlichen Ein- und Ausgabemodalitäten zeichnen
nun auch unterschiedliche Services innerhalb des UIS verantwortlich. Das
GUI-Service generiert anhand anwendungsspezifischer Beschreibungen konkrete Ausprägungen der geforderten grafischen Schnittstellen und deren
Funktionalitäten. Das Sprachservice kümmert sich um die Ausgaben über
Lautsprecher bzw. Eingaben über Mikrofone, wobei diese natürlich auch
für weiterführende Aufgaben wie Benutzerlokalisierung und -verfolgung
herangezogen werden können. Zuletzt existiert noch das Gestenservice,
welches sich um die Akquisition von 2D- und 3D-Gesteneingaben kümmert.
Hierbei kann es sich ebenso um Stylus-Eingaben über einen PDA handeln,
wie auch um die Daten von Beschleunigungssensoren innerhalb von tragbaren Geräten. In der Architektur selbst sind diese drei Services konkret
vorhanden. Durch die serviceorientierte Strukturierung ist es aber ohne
weiteres möglich weitere, vielleicht spezialisiertere, Services einzuführen.
Eine Ebene darüber kümmert sich ein dediziertes Service um die Zusammenführung der Eingaben der unterschiedlichen Modalitäten, also um
die multimodale Fusion. Der nun vorhandene zusammengeführte Input
wird danach dem UI-Manager übergeben, welcher diesen einer entsprechenden Applikation zuordnet und übergibt. Des Weiteren liegt es in seinem Verantwortungsbereich, für die Synchronisation des aktuell stattfindenden Dialoges zu sorgen. Tätigt der Anwender gerade eine Eingabe über
Modalität A, so soll es möglich sein, jederzeit innerhalb des Dialoges auf
Modalität B zu wechseln, was sowohl bei supplementärer als auch bei komplementärer Interaktion eine zentrale Rolle spielt. Ein auf der selben Ebene angesiedelter Service zur impliziten Sprachinteraktion kümmert sich um
die Verarbeitung von indirekten Benutzereingaben. Eingaben müssen nicht
immer aktiv erfolgen, sondern können auch aus dem Anwenderverhalten
heraus interpretiert werden. Solche Informationen werden zunächst erfasst
und dem Kontext hinzugefügt, bis sie in ihrer Gesamtheit als konkrete Eingabe interpretiert werden können. Hierbei ist die Bezeichnung des Services
eventuell verwirrend, denn neben sprachlichen Informationen werden auch
sämtliche weiteren unbewussten Eingaben erfasst und verarbeitet.
30
4.4 MONA
Zuletzt sind noch das Multigeräte- und Modalitätsberater-Service zu
nennen, welche sich darum kümmern, zu einer bestimmten Aufgabe bzw.
zu einem konkreten Szenario passende Geräte und Modalitäten zu finden und auszuwählen. Eine Anwendung stellt, wenn ein Kommunikationswunsch vorliegt, einen so genannten interaction request“ an das UIS,
”
welcher hier nach Informationen durchsucht wird, die bei einer Modalitätsauswahl hilfreich sein könnten. So könnte bei einer Kommunikation in
privatem Rahmen ein PDA bzw. Handy als Ausgabemedium gewählt werden. Öffentliche Kommunikation könnte aber im Gegensatz dazu über den
Fernseher im Wohnzimmer durchgeführt werden [29].
Die im AMIGO-Projekt erstellte Architektur stellt in der Tat eine interessante Möglichkeit dar, multimodale Interaktion möglich zu machen. Auch
der Fokus auf den Smart Home Bereich trifft den Kern der vorliegenden Aufgabenstellung sehr gut und die hier erarbeiteten Konzepte sollten bei einer
Konzeption eines multimodalen Frameworks nicht außer Acht gelassen werden. Eine direkte Verwertung dieser Komponenten ist allerdings leider nicht
möglich. Obwohl im Rahmen der Implementierung des AMIGO-Projektes erhebliche Mengen an Sourcecode generiert und auch frei zugänglich gemacht
wurden, ist gerade im Bereich der UIS nichts Greifbares vorhanden. Die auf
der AMIGO-Webseite hinterlegten Deliverables legen zwar die Existenz einer
Implementierung der UIS nahe, welche aber im Repository nicht aufzufinden
ist. Auch bei einer direkten Nachfrage bei dem Betreiber des Repositories
konnte diesbezüglich nicht weitergeholfen werden. In diesem Zusammenhang
sei auch hier wieder das selbe Problem erwähnt, welches auch schon bei EMBASSI zutage tritt: Mit dem Ende des Projektes endete auch der offizielle
Support und es existieren keine spezifischen Ansprechpartner mehr.
4.4
MONA
Das MONA-Projekt wurde im Jahr 2003 gestartet und bis Ende 2004 aktiv
betrieben. Auch hier bestanden die Projektteilnehmer aus unterschiedlichen
Firmen wie Kapsch, Mobilkom Austria oder Siemens. Wie bei den bereits
beschriebenen Projekten geht es um die multimodale Interaktion zwischen
Anwendern und Computersystemen, allerdings geht der Fokus etwas stärker
in eine andere Richtung. Auch wenn man sich in diesem Bereich natürlich mit
der Einbindung und Umsetzung multimodaler Interaktion beschäftigen muss,
geht es im MONA-Projekt vor allem auch um die Abstrahierung der verschiedenen Benutzungsschnittstellen. Die Entwicklung multimodaler Applikationen soll nicht durch die getrennte Spezifizierung der betreffenden Schnittstellen charakterisiert sein, sondern es sollte vielmehr eine einzelne, abstraktere
31
4.4 MONA
32
Schnittstellendefinition Verwendung finden [4].
Eine Applikation im MONA-Projekt stellt anstelle von getrennten UIBeschreibungen, wie XHTML für grafische Interfaces oder VXML für sprachliche Modalitäten, eine einzige abstrakte Spezifikation zur Verfügung. Ein
spezieller Präsentationsserver transformiert diese allgemeine Beschreibung
anschließend in Sprachen, welche für die verschiedenen Modalitäten verständlich sind. Da dieser Vorgang automatisch ablaufen kann, wird einem Anwendungsentwickler hier ein großer Arbeitsaufwand erspart. Weiters ist das System auf diese Weise einfach durch neue Modalitäten erweiterbar, da hierzu
lediglich der Präsentationsserver um die Fähigkeit erweitert werden muss,
auch für diese Interaktionsform UI-Beschreibungen aus der abstrakten Definition heraus rendern zu können. Eine Übersicht über die MONA-Architektur
ist in Abbildung 4.5 zu sehen [4].
Abb. 4.5: MONA-Architektur [4]
Im Rahmen des MONA-Projektes wurden allerdings nur die Zielsprachen
HTML, XML und X+V unterstützt, was die Anwendbarkeit für generischere multimodale Applikationen zunächst einschränkt, wobei, wie gesagt, eine
Erweiterung auf andere Zielsprachen einfach umsetzbar sein sollte. Clientseitig laufen die Anwendungen von MONA browserbasiert, da dies eine Reihe
von Vorteilen mit sich bringt. So erhält man dadurch sehr einfach eine gute
Geräteunabhängigkeit, da ein Großteil der am Markt verfügbaren Geräte bereits mit hochwertigen Webbrowsern ausgerüstet ist und man sich nicht mit
gerätespezifischen Eigenschaften wie Betriebssystemen oder Unterstützung
für diverse Programmiersprachen befassen muss. Weiters befindet sich die
Applikationslogik zentralisiert auf dem Server, was eine Weiterentwicklung
4.4 MONA
und Wartung stark vereinfacht [4]. Ein Nachteil dieser browserbasierten Umsetzung findet sich in der Einschränkung wieder, dass eine Kommunikation
nur von der Clientseite angestoßen werden kann. Es ist also nicht möglich,
neue Informationen ohne weiteres zu den Clients zu senden. Bei MONA umging man dieses Problem mit einem Browser-Plugin, welches diese fehlende
Funktionalität zur Verfügung stellte. Natürlich verliert man dadurch eine gewisse Flexibilität, da dieses Plugin in jedem einzelnen Endgerät installiert
werden muss [66].
Zur Formulierung der abstrakten UI-Beschreibungen fand eine angepasste
Form von UIML Verwendung, worauf in einem nachfolgenden Teil dieser Arbeit noch genauer eingegangen wird. Bei der Umsetzung diverser Testszenarien traten gewisse Probleme an die Oberfläche, welche vor allem die Anwendungsentwicklung selbst betrafen. Durch die Verwendung einer abstrakten
UI-Beschreibung und somit auch abstrakter und nicht konkret formulierter
und vorstellbarer Interface Widgets war ein konventioneller Design-Ansatz
schwierig. Für Entwickler selbst ist es einfacher, anhand von konkreten Skizzen oder Storyboards zu planen und zu kommunizieren, als auf dieser neuen
abstrakten Ebene. Hinzu kommt das Problem, dass sich das Aussehen der
endgültigen gerenderten Benutzungsschnittstellen nicht genau voraussagen
lässt, was ja im Prinzip die Intention hinter dieser Abstrahierung ist, die Anwendungsentwickler aber genau dadurch auch stark verunsichert [4].
Um diese Problematik zu entschärfen, wurde ein spezieller Editor auf
Java-Basis entworfen und implementiert, welcher das UI-Design vereinfachen
sollte. Mittels dieses Werkzeugs ist es möglich, Änderungen in der abstrakten Beschreibung sehr einfach und rasch in den daraus generierten speziellen
Beschreibungssprachen mit zu verfolgen und dadurch quasi eine EchtzeitVorschau zur Verfügung zu haben [32].
Abschließend kann zum MONA-Projekt gesagt werden, dass im Kontrast
zu den bisher vorgestellten Projekten der Fokus eher auf die UI-Generierung
bei multimodalen Applikationen gelegt wurde und sich dieses Projekt der
Multimodalität auf einer anderen Ebene annähert. Leider existieren keine frei
zugänglichen Codeteile, was eine direkte Verwendung und Adaptierung ausschließt, wobei die hier erarbeiteten Konzepte generischer UI-Beschreibungen
durchaus interessant sind und in weitern Kapiteln noch aufgearbeitet werden.
33
4.5 SerCHo-MASP
4.5
SerCHo-MASP
Das vom Bundesministerium für Wirtschaft und Technologie in Deutschland
geförderte Projekt SerCHo steht für Service Centric Home und befasst sich,
wie die bereits vorgestellten Projekte, mit der Entwicklung eines Lösungsansatzes im Bereich intelligenter Umgebungen. Es geht hier wiederum um die
Integration aller im Haushalt befindlichen Geräte in ein Gesamtsystem, mit
welchem der Anwender mittels intuitiver Schnittstellen einheitlich auf seine
Umgebung Einfluss nehmen und verfügbare Services nutzen kann [28].
Im Rahmen dieses Projektes wurde unter anderem die so genannte MultiAccess Service Plattform (MASP) entwickelt. Das Ziel hierbei war es, eine
multimodale Interaktion zu ermöglichen, wobei die Vorgehensweise bei der
Konzeption und Umsetzung im Grunde an das MONA-Projekt erinnert, aber
noch viel weitgreifender ausgeführt wird. Auch hier wird davon ausgegangen, dass unterschiedliche Abstraktionsstufen existieren, wobei Elemente einer Stufe auf eine andere abgebildet werden können. Anders als bei MONA
geht man hier allerdings nicht nur von zwei Ebenen aus und beschränkt sich
auch nicht nur auf die UI-Beschreibung, sondern bildet die gesamte Anwendung, ausgehend vom Dialog- und Aufgabenmodell bis hin zum finalen UI
einer entsprechenden Modalität, als unterschiedlich abstrakte Modelle ab,
welche untereinander über Mappings in Beziehung stehen [30].
Abb. 4.6: MASP-Modellstruktur. Angelehnt an Blumendorf et al. [8]
Die Struktur der Multi Access Service Plattform ist in Abbildung 4.6
ersichtlich. Wie man sehen kann, besteht sie aus einer Reihe unterschiedlicher Modelle und Mappings, die diese Modelle untereinander verbinden. Neben der bekannten und häufig gebrauchten Funktion der Überführung eines
Modelles in ein anderes, können Mappings darüberhinaus auch zur Synchronisierung verwendet werden, wobei der Fokus im Rahmen dieses Projektes
auch genau darauf liegt. Durch die Verbindungen, die diese Mappings darstel-
34
4.5 SerCHo-MASP
len, können Änderungen in einem Modell auf die damit verbundenen Modelle
übertragen und das Gesamtsystem somit synchron gehalten werden. Darüber
hinaus können Änderungen am und im System dadurch auch zur Laufzeit
durchgeführt werden, was eine Entwicklung sicherlich vereinfacht [8].
Das Aufgabenmodell beinhaltet hierbei die Anwendungsfunktionalität und
verwendet dazu eine aufgabenbezogene Herangehensweise. Im Fokus stehen
also zu erledigende Aufgaben und ihre kausalen Abhängigkeiten untereinender. Diese werden in Form von Concurrent Task Trees erfasst, welche die
Aufgaben in einem gemeinsamen Baum darstellen, wobei jeder Knoten, also
jede Aufgabe wiederum in ihre Teilaufgaben unterteilt werden kann [11]. Ein
Beispiel ist in Abbildung 4.7 zu sehen.
Abb. 4.7: Concurrent Task Tree. Angelehnt an De Boeck et al. [11]
Das Domänenmodell geht einen Schritt weiter und definiert die notwendigen Objekte, welche in sich den internen Status der Applikation widerspiegeln
und bei der Abarbeitung der Aufgaben manipuliert werden. Dazu werden
sowohl die Strukturen der notwendigen Objekte definiert, als auch die konkreten Instanzen zur Laufzeit verwaltet. Eine Statusänderung des Systems,
und somit eine Änderung dieser Instanzen, kann nun auf zwei verschiedenen
Wegen geschehen. Auf der einen Seite kann das Servicemodell Änderungen
herbeiführen. Dieses Modell dient als Schnittstelle zur Systemseite und kann
Aktionen im Backend auslösen bzw. dortige Vorgänge erkennen und diese
Informationen in der MASP verfügbar machen [8].
Auf der anderen Seite stellt das Interaktionsmodell die Verbindung nach
35
4.5 SerCHo-MASP
außen hin zum Anwender dar, welcher auf diesem Wege ebenfalls Einfluss
auf den Systemstatus nehmen kann. Zu diesem Zweck werden abstrakte
Benutzungsschnittstellen definiert, welche modalitätsunabhängig den Inhalt
und Aufbau der notwendigen UI´s beschreiben. Ebenso wie im MONAProjekt kommen universelle UI-Beschreibungssprachen zum Einsatz. Prinzipiell können hier aufgrund der Offenheit der Architektur verschiedenste Modellierungssprachen verwendet werden. In der konkreten Umsetzung findet
allerdings nicht wie bei MONA UIML, sondern UsiXML, eine andere Modellierungssprache, Verwendung, welche aber ebenso im nachfolgenden Kapitel
erläutert wird. Aus diesen abstrakten Beschreibungen werden in der Folge
modalitätsspezifische Schnittstellen generiert und dem Anwender präsentiert
[8].
Als fünfte Komponente dieser Struktur existiert weiters noch das Kontextmodell, welches den aktuellen Status der Umgebung beinhaltet. Hier
werden also Sensorinformationen gesammelt, welche beispielsweise für die
UI-Generierung herangezogen werden können. Durch die Verbindung der Modelle über definierte Mappings findet nun die Synchronisierung bzw. Kommunikation statt [8]. Innerhalb des Aufgabenmodells werden aus der Gesamtmenge aller Aufgaben diejenigen selektiert, welche für den aktuellen Zustand
der Anwendung relevant sind und als so genanntes enabled task set“ zusam”
mengefasst [11]. Ein Zustandsübergang kann in der Folge Vorgänge innerhalb
des Servicemodells und damit im Backend-Bereich triggern, aber natürlich
auch Auswirkungen auf das Interaktionsmodell und damit auf die angebundenen Benutzungsschnittstellen haben. Für all diese Vorgänge werden natürlich
auch das Domänenmodell und das Kontextmodell herangezogen, da der Systemstatus und der aktuelle Kontext natürlich eine große Rolle spielen. Durch
die Änderung in einem Modell werden also alle weiteren Modelle beeinflusst
[8].
Zusammenfassend kann gesagt werden, dass bei diesem Projekt dieselben Ziele verfolgt werden wie bei den bisher vorgestellten, wobei durch den
modellbasierten Zugang ein gänzlich anderer Weg eingeschlagen wird. Die
grundsätzlichen Komponenten, wie zum Beispiel die Dialogführung im Aufgabenmodell, die Kontextakquirierung im Kontextmodell oder die Ansteuerung von Smart Home Komponenten mittels des Servicemodells sind auch in
diesem Projekt zu finden. Die modellbasierte Umsetzung ist allerdings etwas
Neues und sicherlich ein interessanter und vielversprechender Ansatz. Gerade im Bereich der Benutzerinteraktion, also im Rahmen des Interaktionsmodells, gibt es allerdings noch größeren Forschungsbedarf [8], da hier unter
Anderem dieselben Problembereiche wie in MONA zu sehen sind, nämlich
36
4.6 W3C MMI
die Unvorhersehbarkeit der generierten Schnittstellen aus den abstrakten Beschreibungen heraus und auch die Vorgänge der multimodallen Fusion und
Fission betreffend. Gegenüber den bisherigen Projekten ist allerdings äußerst
positiv zu bemerken, dass sich dieses Projekt gegenwärtig noch in Entwicklung befindet und aktiv vorangetrieben wird.
4.6
W3C MMI
Es gibt seit einiger Zeit auch vom World Wide Web Consortium ausgehende Bestrebungen Multimodalität, vor allem im Web-Bereich, zu definieren und Lösungs- sowie Umsetzungsmöglichkeiten aufzuzeigen. Zu diesem
Zweck wurde 2002 im Rahmen des W3C die Multimodal Interaction Working
Group gegründet, welche zunächst Use Cases und Anforderungen für und an
multimodale Applikationen definieren sollte. Im nächsten Schritt wurde das
W3C Multimodal Interaction (MMI) Framework entwickelt und veröffentlicht. Hierbei handelt es sich nicht um ein konkretes, verwendbares Framework, sondern um eine Empfehlung, wie diesbezügliche Implementierungen
aussehen sollten. Es handelt sich weiters um einen Entwurf, der keinen Anspruch auf Vollständigkeit erhebt und sich bis heute in einer stetigen Weiterentwicklung begriffen sieht [50]. Die Veröffentlichung der aktuellen und
fünften Version dieses Entwurfs fand am 16. Oktober 2008 statt [58]. Ausdrücklich zu beachten und nochmals erwähnt sei hierbei der Typ dieses Dokumentes als Entwurf, der Artikel kann sich also jederzeit ändern oder durch
eine neuere Version ersetzt werden.
Der Fokus des MMI-Frameworks liegt wie gesagt darin, ein generelles
und flexibles Framework zu schaffen, in welchem modalitätsspezifische Komponenten miteinander interagieren können. Dabei spielt es keine Rolle, ob
diese Komponenten von verschiedenen Herstellern produziert werden oder
inwiefern sie von sich aus schon in der Lage sind, mit anderen Geräten zu
kommunizieren. Es werden nur sehr wenige Einschränkungen und Regeln definiert, denen Komponenten genügen müssen, um innerhalb des Frameworks
arbeiten zu können. Die Ziele hinter dem MMI-Framework können wie folgt
formuliert werden:
Kapselung: Die Architektur soll keine Annahmen über den internen Aufbau
der angschlossenen Komponenten treffen.
Verteiltheit: Die Architektur soll auch verteilte Implementierungen ermöglichen.
Erweiterbarkeit: Die Integration neuer Modalitäten und Komponenten soll
37
4.6 W3C MMI
einfach durchführbar sein.
Rekursivität: Es soll möglich sein, eine Instanz dieses Frameworks in ein
anderes Framework einzubetten, um dort als einzelne Komponente zu erscheinen.
Modularität: Die Architektur soll Daten-, Kontroll- und Präsentationsschicht getrennt halten.
Im Rahmen des MMI-Frameworks bilden XML-basierte Dokumente unterschiedlicher XML-Namensräume den Kern einer jeden Applikation. Je
nach Modalität kommen unterschiedliche Sprachen zum Einsatz, wobei eine
Sprache durchaus für mehrere Modalitäten anwendbar sein und eine Modalität auch mittels mehrer Sprachen beschrieben werden kann. Es existiert
ein ganz bestimmtes Wurzeldokument, welches im Zentrum des Frameworks
steht und die generellen Abläufe und Funktionen beschreibt. Innerhalb der
diversen Komponenten werden diese Beschreibungen zur Laufzeit abgearbeitet und bestimmen ihr Verhalten. Ein wesentlicher Teil des Frameworks
beschreibt und regelt die Kommunikation zwischen den Komponenten. Diese
sind lose gekoppelt und kommunizieren ausschießlich mittels wohldefinierter
asynchroner Nachrichten, so genannter MMI-Lifecycle-Events, untereinander, auf die nachfolgend noch näher eingegangen wird. Abbildung 4.8 zeigt
die MMI-Architektur in einem groben Überblick [58]. Wie in der Abbildung
zu sehen ist, besteht die Architektur aus fünf Teilbereichen:
Abb. 4.8: MMI-Architektur. Angelehnt an den W3C Working Draft [58]
Laufzeitumgebung: Sie stellt die grundlegende Infrastruktur zur Verfügung,
um die Kommunikation zwischen den Komponenten zu ermöglichen. Sie
initialisiert und startet zu Beginn lokale Komponenten und baut Verbin-
38
4.6 W3C MMI
dungen zu entfernten Komponenten auf. Vereinfacht gesagt, bildet sie die
grundlegende Struktur, in der die übrigen Komponenten agieren können.
Interaktionsmanager: Er kümmert sich um die Abarbeitung aller Events,
welche zur Laufzeit generiert und versendet werden. Dazu bedient er sich
der Beschreibungen im zentralen Wurzeldokument, welche ihm diesbezüglich
Instruktionen über die Vorgehensweise liefern. Auf welcher Basis, also in
welchem Format dieses Dokument verfasst ist, ist nicht eingeschränkt und
kann beliebig gewählt werden. Vorgeschlagen wird jedoch die Verwendung
von SCXML, welche nachfolgend noch genauer erläutert wird. Der Interaktionsmanager ist weiters verantwortlich für die Synchronisierung der Daten und des Informationsflusses über mehrere Modalitäten hinweg, für die
Haltung applikationsspezifischer Informationen und ebenso für die Kommunikation mit dem Backend oder externen Komponenten.
Kontextkomponente: Die delivery context component stellt einen Zugangspunkt zum aktuell vorhandenen Kontext dar. Über diese Komponente
können Abfragen getätigt werden, um Informationen beispielsweise über
Nutzerpräferenzen oder Gerätekonfigurationen zu erlangen. Natürlich ist
es außerdem auch möglich, Änderungen im Kontext durchzuführen.
Datenkomponente: Diese dem Runtime Framework untergeordnete Komponente kümmert sich um die Haltung der applikationsspezifischen Daten
und um die Kommunikation mit dem Backend. Während es für den Interaktionsmanager einfach möglich sein soll, auf diese Komponente zuzugreifen, sollen andere Komponenten, insbesondere angeschlossene Modalitäten, nicht dazu in der Lage sein. Dies aus dem einfachen Grund, dass
eine Konsistenz innerhalb des Frameworks nur dann gegeben ist, wenn der
Interaktionsmanager in den Informationsfluss miteinbezogen wird und er
sich damit auch um die Synchronisierung kümmern kann. Welche Sprache zur Kommunikation mit dem Backend Verwendung finden soll, ist im
Entwurf des W3C nicht genauer spezifiziert und bleibt den jeweiligen Implementierungen überlassen.
Modalitätskomponenten: Diese dienen dazu, unterschiedliche Ein- und Ausgabemodalitäten auf einem oder mehreren Geräten zu steuern. Sämtliche
Interaktion mit dem Endanwender fällt also in diesen Bereich. Da das MMI
Framework diese Komponenten als so genannte Black Boxes“ betrachtet,
”
spielt deren innere Umsetzung und Funktionalität absolut keine Rolle. Einzig und allein die Art der Kommunikation nach außen, hin zum Runtime
Framework, ist definiert und muss eingehalten werden.
Das eben erwähnte Interface zwischen Modalitäten und dem Runtime
Framework stellt die zentrale und wichtigste Schnittstelle innerhalb des Frameworks dar. Wie bereits erwähnt, erfolgt die Kommunikation asynchron,
39
4.6 W3C MMI
mittels definierter Events. Die Komponenten müssen also dementsprechend
in der Lage sein, solche Events zu empfangen, zu senden und zu verarbeiten.
Wichtig dabei ist weiters, dass die sendenden Komponenten, sowohl auf der
Anwender- als auch auf der Systemseite, keine Ziele für die von ihnen versendeten Events vorgeben. Darum kümmert sich das Runtime Framework und
hier insbesondere der Interaktionsmanager. Der genaue Vorgang der Übertragung von Events ist im Entwurf auch nicht weiter geregelt, abgesehen von
zwei Einschränkungen. Alle Events müssen zuverlässig übertragen werden
bzw. muss im Fehlerfall eine Nachricht an den Absender zurückgehen und
die Events müssen in der Reihenfolge beim Empfänger ankommen, in der sie
vom Sender abgeschickt wurden. Dies bezieht sich wohlgemerkt nur auf einen
konkreten Absender. Generieren zwei unterschiedliche Quellen ein Event, ist
die Reihenfolge des Eintreffens beim Ziel nicht vordefiniert und zufällig [58].
Der Entwurf des W3C beinhaltet in der aktuellen Version 18 unterschiedlichen Eventtypen. Diese dienen großteils zur Koordinierung der Multimodalität und aller betroffenen Komponenten, nur ein kleiner Teil befasst sich mit
der Übermittlung anwendungsspezifischer Informationen. Die Events selber
sind wiederum nichts anderes als XML-Dokumente in einem vordefinierten
Schema. In der Folge werden die wichtigsten Eventtypen herausgefasst und
näher erläutert. Eine umfassende Auflistung aller Life-Cycle-Events ist im
Anhang zu finden.
NewContextRequest: Dieses Event wird von einer Modalitätskomponente an das Runtime Framework gesendet. Damit fordert diese einen neuen
Kontext an, in dem sie agieren kann. Der Begriff Kontext wird in diesem
Rahmen allerdings anders gehandhabt, als es in den bisher besprochenen
Projekten der Fall war. Ein Kontext im MMI-Framework bezeichnet den
Zeitraum, in dem eine einzelne andauernde Interaktion des Systems mit
dem Benutzer stattfindet. Dies kann im einfachsten Fall eine kurze unimodale Kommunikation über eine grafische Schnittstelle sein. Ein Kontext
kann sich allerdings auch über längere Zeit und über mehrere Modalitäten
hinweg erstrecken, wenn während der Verwendung der grafischen Schnittstelle beispielsweise auch eine Sprachsteuerung mit ins Spiel kommt. Es
spielt dabei keine Rolle, ob Modalitäten der Interaktion beitreten oder
diese verlassen, solange es sich im Prinzip um einen gemeinsamen Vorgang handelt. Gerade im Bereich der Webanwendungen könnte man den
hier verwendeten Kontextbegriff auch recht treffend als Session bezeichnen. Der Aufbau eines Life-Cycle-Events sei beispielgebend für alle übrigen anhand des NewContextRequest-Events in Abbildung 4.9 dargestellt.
Prinzipiell beinhaltet dieses Event lediglich eine Quellenangabe im source
40
4.6 W3C MMI
Attribut, eine laufende Nummerierung innerhalb des requestID Attributes
(beide in Zeile zwei ersichtlich) und verschiedene Medientypen (Zeilen drei
und vier), welche von der aussendenden Komponente unterstützt und verstanden werden. Weiters existiert noch ein allgemeiner Datenbereich (Zeile
fünf bis neun), der in sämtlichen Eventtypen vorhanden ist und implementierungsspezifische Daten enthalten kann, welche in diesem Entwurf nicht
näher spezifiziert werden.
Abb. 4.9: NewContextRequest MMI Life-Cycle-Event [58]
NewContextResponse: Zu beinahe allen Eventtypen existieren zugehörige
Bestätigungsevents, die an den Aussender retourniert werden. Zum Einen
wird dadurch eine erfolgreiche Übertragung sichergestellt, zum Anderen
werden zusätzliche Informationen zurückgesendet. War die Generierung
eines neuen Kontexts erfolgreich, so werden in diesem Event sowohl eine
Erfolgsmeldung als auch eine Id des neuen Kontexts zurückgesendet. War
die Kontexterstellung nicht erfolgreich, so enthält das Event eine Statusmeldung und auch eine genaue Problembeschreibung. Weiters enthalten
sind auch hier wieder die unterstützten Medientypen, die nun allerdings
auch hinsichtlich des Frameworks eingeschränkt wurden und nur noch diejenigen Typen beinhalten, die von beiden Partnern unterstützt werden.
StartRequest: Dieses Event wird vom Runtime Framework zu den Modalitäten gesendet und beinhaltet die Aufforderung, eine bestimmte Interaktion zu beginnen. Diesbezügliche Informationen sind entweder in XMLDokumentform selbst in dem Event vorhanden oder es existiert eine URL,
welche auf das entsprechende Dokument verweist. Im Anschluss daran
muss die empfangende Komponente ein StartResponse-Event zurücksenden.
ExtensionNotification: Dieses Event hebt sich von allen anderen ab und besitzt weiters auch als einziges kein entsprechendes Bestätigungsevent. Es
dient dazu, applikationsspezifische Informationen zu kapseln und zu übertragen. Da dieser Informationsfluss in beide Richtungen erfolgen kann, sind
sowohl das Runtime Framework als auch die Modalitätskomponenten in
41
4.6 W3C MMI
der Lage es zu generieren, zu senden und zu empfangen. Die anwendungsbezogenen Daten werden hierbei innerhalb des Datensegments des Events
platziert.
In diesem Entwurf wird weiters, wenn auch nur kurz, auf Sicherheitsaspekte eingegangen. Es existiert auch hier keinerlei Einschränkung in Bezug auf
das zu verwendende Sicherheitssystem, es werden jedoch jene Eigenschaften
beschrieben, welche absolut notwendig sind, um ein Mindestmaß an Sicherheit zu gewährleisten. Diese sind neben Authentifizierung, Autorisierung und
Integrität auch die Gewährleistung der privaten Natur der übertragenen Daten und die Sicherstellung, dass eine Duplizierung der Daten nicht möglich
ist. Der Sender soll dementsprechend nicht in der Lage sein, eine einmalig
abgeschickte Nachricht nochmals exakt gleich zu generieren und auch der
Empfänger soll eine empfangene Nachricht nicht vervielfältigen oder weiterleiten können [58].
Zusammenfassend kann zu dem Entwurf des W3C folgendes gesagt werden: Im Kontrast zu den zuvor beschriebenen Projekten veranschaulicht dieser das Vorgehen bei einer möglichen Implementierung eines multimodalen
Frameworks um einiges plastischer. Dies hat natürlich den Grund, dass bei
dem W3C-Framework genau diese Beschreibung der Vorgehensweise im Fokus liegt und auch keine eigene Implementierung angestrebt wird. Die anderen erwähnten Forschungsgruppen hatten demgegenüber ja einen funktionstüchtigen Prototyp im Auge. Neben den zitierten Veröffentlichungen existieren im Bereich des W3C MMI Frameworks noch eine Reihe weiterer Dokumente, welche sich mit konkreten Teilbereichen des Frameworks und dortigen
Umsetzungsmöglichkeiten befassen. Auf diese wird im weiteren Verlauf der
Arbeit auch noch teilweise Bezug genommen. Ein positiver Punkt betrifft
hier wieder den Entwicklungsstatus. Die MMI-Arbeitsgruppe ist schon seit
geraumer Zeit im multimodalen Bereich aktiv und das Framework insofern
auf einem sehr fundierten und aktuellen Stand. Durch die tatkräftige Weiterentwicklung kann man auch davon ausgehen, dass sich die Anwendbarkeit
und der Nutzen des Frameworks in der Zukunft gewiss noch steigern wird.
Genau hier kann man allerdings auch einen Nachteil erkennen. Gründet man
ein Projekt auf Basis dieses Entwurfes, so kann es möglicherweise dazu kommen, dass sich der Entwurf in der Zukunft in eine Richtung entwickelt, der
man innerhalb des laufenden Projektes nicht so einfach folgen kann.
Aufgrund der Tatsache, dass es sich beim Urheber dieses Frameworks um
das World Wide Web Consortium handelt, liegt der Fokus natürlich klarerweise im Bereich der Webanwendungen. Als physische Ausprägung von Mo-
42
4.7 Bewertung
dalitätskomponenten werden aus diesem Grund Clientsysteme beschrieben,
auf denen MMI-Applikationen in einem Webbrowser laufen. Gewissermaßen
könnte man diesen Entwurf also auch als eine Weiterentwicklung des X+VAnsatzes verstehen, bei dem die enge Kopplung der Inhalte aufgelöst und eine
eher serverseitige Abhandlung der Multimodalität gegeben ist. Aufgrund der
abstrakten und allgemein anwendbaren Konzepte spricht hier aber nichts gegen eine Ausdehnung des Anwendungsbereiches über Webanwendungen hinaus. Rich-Client-Applikationen können aufgrund des Blackbox-Konzeptes der
Modalitäten ebenfalls einfach in das Framework integriert werden, sofern sie
die entsprechende Eventschnittstelle unterstützen. Als Übertragungsprotokoll kann neben HTTP auch auf andere Technologien zurückgegriffen werden
etc.
4.7
Bewertung
Betrachtet man sich nun sämtliche vorgestellten Frameworks und Projekte,
so kann man diese in ihrer Gesamtheit wie folgt bewerten: Ein Großteil der
Projekte bedient sich einer sehr ähnlichen grundlegenden Struktur beim Aufbau der verwendeten Architektur. Konkret kann man bei EMBASSI, AMIGO
und MONA sehr gut erkennen, dass sie allesamt ähnliche Komponenten verwenden und diese auf ähnliche Art und Weise miteinander verküpfen. So
fällt einem aufmerksamen Betrachter beispielsweise das Vorhandensein einer
zentralen Steuerungskomponente ins Auge, welche zumeist als Interaktionsmanager betitelt wird und sich mit der Koordinierung der Multimodalität
innerhalb der entsprechenden Projekte befasst. Natürlich ist die innere Funktionsweise unterschiedlich, aber ihre Aufgabe nach außen hin ist vergleichbar.
Auch die Wichtigkeit des Zustandes der aktuellen Umgebung wird allgemein
gewürdigt und anerkannt, was sich in unterschiedlichen Ausführungen von
diversen Kontextmanagern äußert.
Betrachtet man dazu den Entwurf des W3C, ist es auch sehr schön zu
sehen, wie dieser die Entwicklung von multimodalen Systemen vereinfachen
und vereinheitlichen will, indem auch er dazu sehr viele Elemente aus diesen
Projekten heranzieht und auf einen gemeinsamen Nenner bringt. Aufgrund
der Parallelität der Projekte und des W3C MMI Frameworks ist es schwierig
zu sagen, wer hier wen in welchen Bereichen beeinflusst hat; dass es eine Beeinflussung gab, ist jedenfalls unumstritten. Dies lässt sich zum Beispiel am
MONA-Projekt erkennen, welches sich teilweise an das MMI-Framework anlehnt und darauf aufbaut [66]. Man kann also durchaus sagen, dass es sich bei
dem W3C MMI Framework um eine Zusammenfassung der grundlegenden
und ähnlichen Konzepte vieler Projekte handelt, welche sich erfolgreich mit
43
4.7 Bewertung
Multimodalität befassen und befassten. Betrachtet man die Tatsache, dass
diese Projekte zum Einen, wie im Fall AMIGO, keinen öffentlich verfügbaren
Sourcecode anbieten und zum Anderen von ihrem Aufbau eher ungeeignet
für eine Weiterentwicklung sind - führt man sich beispielsweise die monolithische Architektur von EMBASSI vor Augen - so kann man die Vorzüge
der W3C-Variante erkennen. Diese bietet zwar ebenfalls keine implementierten Komponenten, aber vereint die Vorteile der einzelnen Projekte zu einem
Entwurf, auf dessen Basis man relativ einfach ein funktionierendes System
entwickeln könnte.
Dem gegenüber steht der Ansatz, der sich im SerCHo-MASP Projekt wiederfindet. Auch hier sind die grundlegenden Komponenten dieselben, jedoch
wird die Verbindung auf eine etwas andere Art und Weise realisiert. Durch
die Verwendung von Mappings als Synchronisierungsmechanismen zwischen
den vorhandenen Modellen kommt es zu mehreren Abstraktionsstufen und
zu einer längeren Kette unterschiedlich abstrakter Modelle, der auf Seiten
der übrigen Projekte eine einfachere Gliederung gegenübersteht. Der Ansatz
besticht vor allem durch seine Flexibilität und die Möglichkeit, Änderungen
zur Laufzeit durchführen zu können. Allerdings beschreitet ein weit größerer
Teil der Forschungsarbeiten im multimodalen Bereich den Weg, den auch der
W3C-Entwurf vorgibt. Dieser scheint zur Erreichung der in der vorliegenden
Arbeit definierten Ziele doch einfacher, überschaubarer und besser geeignet
zu sein. Die anfangs beschriebene XHTML+Voice-Kombination alleine ist
aufgrund ihrer doch sehr engen Kopplung der Modalitäten als Grundlage
nicht geeignet, zumal sie, wie gesagt, im W3C-Ansatz auch teilweise wiederzufinden und dort auch besser umgesetzt ist.
44
5
Beschreibungssprachen im
multimodalen Bereich
Wie bei der Durchsicht der existierenden Frameworks und Projekte sehr
schnell klar wird, existiert bereits eine Reihe von Auszeichnungssprachen, um
verschiedene Aspekte der multimodalen Interaktion abzubilden und beschreiben zu können. Sei es der Dialogfluss, der UI-Aufbau oder die Übermittlung
von Daten zwischen Komponenten eines Frameworks - es können in allen
Bereichen unterschiedlichste Sprachtypen zum Einsatz kommen. Aus diesem
Grund befasst sich dieses Kapitel damit, eine Übersicht und Klassifizierung
eben dieser Beschreibungssprachen zu geben.
5.1
5.1.1
Dialogbeschreibungen
CCXML
Die unter der Bezeichnung Call Control eXtensible Markup Language bekannte Auszeichnungssprache wurde vom W3C entwickelt. Sie ist in ihrer
Form, ähnlich dem zuvor erläuterten MMI-Framework, als Entwurf zu betrachten, welcher sich nach wie vor in Bearbeitung befindet. Die erste Version
wurde im Jahr 2002 veröffentlicht, auf die eine Reihe weiterer Publikationen
folgte und schließlich in der Version von 2007 die bisher aktuellste Ausgabe
darstellt. Es existiert zudem bereits eine große Anzahl an Umsetzungen in
Telefonapplikationen diverser Unternehmen [62, 61].
Das ursprüngliche Ziel dieses Entwurfs war die Entwicklung einer deklarativen Auszeichnungssprache um den Kontrollfluss innerhalb von Telefonanwendungen angeben und steuern zu können. Die bisher verwendete Sprache
VXML, welche bereits im vorherigen Kapitel XHTML+Voice angesprochen
wurde, dient für sich genommen im Grunde ebenfalls zur Dialogmodellierung, allerdings in einer eingeschränkten Form und auf Sprachanwendungen
5.1 Dialogbeschreibungen
beschränkt. Des Weiteren hat der Dialogfluss innerhalb solcher Sprachanwendungen eher linearen Charakter, und eine Unterstützung für Ereignisse,
die zu einem beliebigen Zeitpunkt auftreten können, ist begrenzt. Durch die
Einführung von CCXML ist nun eine Steuerung übergreifend über mehrere
solcher Telefonanwendungen möglich. Unter Anderem können damit Telefonkonferenzen verwaltet oder Informationen mit externen Systemen ausgetauscht werden. Auch eine asynchronere Form der Dialogmodellierung wird
dadurch ermöglicht [48].
In ihrer aktuellen Form ist diese Auszeichnungssprache aber nicht nur auf
das Anwendungsfeld der Telefonie beschränkt, sondern eigenet sich grundsätzlich sehr gut zur Modellierung der Steuerung aller Arten von Dialogsystemen.
Dies ergibt sich nicht zuletzt aus der Tatsache, dass CCXML zwar unter dem
Gedanken der Erweiterung von VXML-Funktionalität entwickelt wurde, diese beiden Sprachen aber dennoch voneinander unabhängig und auch für sich
alleine lauffähig und anwendbar sind.
Eine CCXML-Applikation besteht nun aus einer Reihe von CCXMLDokumenten, welche einen Interpreter steuern. Hierzu werden bei Bedarf einzelne Sessions generiert, welche im Prinzip dieselben CCXML-Beschreibungen
als Grundlage heranziehen und für sich abarbeiten. Hierbei können durchaus
mehrere Sessions dieselbe Beschreibung zur gleichen Zeit verwenden und diese parallel und getrennt voneinander bearbeiten. Eine Session befindet sich
zu einem konkreten Zeitpunkt in einem bestimmten Zustand, welcher durch
diverse Ereignisse in einen anderen übergeführt werden kann. Weiters existiert eine Reihe von Verbindungen hin zur Außenwelt, welche den einzelnen
Sessions zugeordnet sind und zwischen diesen ausgetauscht werden können.
Für diese Dialoge kommen wiederum Sprachen wie VXML zu Anwendung,
welche die konkrete Interaktion mit dem Benutzer durchführen können und
eventuelle Eingaben an die CCXML-Session retournieren. Die Kommunikation erfolgt hierbei großteils mittels Events, welche Informationen zwischen
den CCXML-Sessions und den Dialogen zur Benutzerinteraktion übermitteln
und anhand derer der Dialogfluss gesteuert wird [62].
5.1.2
SCXML
2005 wurde, ebenfalls vom W3C, mit der Spezifizierung einer weiteren Auszeichnungssprache begonnen, welche in der aktuellen Version vom Mai 2008
vorliegt. Diese basiert zum Teil auf den Erkenntnissen und Erfahrungen von
CCXML und versucht, dessen etwas rudimentäreres Zustandsautomatenkonzept durch die Verwendung von Harel State Charts zu erweitern. Durch die
46
von David Harel eingeführte Methodik, Zustandsautomaten zu beschreiben
wurden die Modellierungsmöglichkeiten diesbezüglich umfassend erweitert.
Die von ihm vorgeschlagene Notation wurde aus diesem Grund auch in die
Unified Modeling Language (UML) übernommen. Die Darstellung in UML
erfolgt allerdings in einer grafischen Form, weshalb im Rahmen von SXCML
versucht wird, eine XML-basierte Repräsentation zu entwickeln. Durch die
interessanten und sehenswerten bisherigen Ergebnisse wird unter anderem
auch darüber nachgedacht, die Erkenntnisse von SCXML bei der Erweiterung von CCXML einzubringen und das dortige Zustandsautomatenkonzept
in Zukunft auf Basis von SCXML zu fußen [60, 59].
Ein Beispieldokument, welches eine Stoppuhr modelliert, ist in Abbildung
5.1 und 5.2 ersichtlich [45]. Hier ist sehr schön zu erkennen, wie die Zustände
und Zustandsübergänge ausgehend von der grafischen Modellierung in XMLForm übergeführt werden können und dort state und transition Tags bilden.
Ausgeführt wird solch ein Zustandsübergang durch das Auftreten des dort
spezifizierten Events.
Abb. 5.1: Stoppuhr-Diagramm (UML Annotation) [45]
Es ist klar, dass es sich hier um ein recht einfaches Beispiel handelt. Durch
die Verwendung von Harel State Charts können weitaus komplexere Vorgänge
beschrieben werden. Einzelne Zustände können zum Beispiel durch eine Reihe von Unterzuständen beschrieben werden. Dies kann sogar so weit gehen,
dass innerhalb eines Zustandes ein weiterer SCXML-Interpreter angestoßen
wird und sich ein anderer Zustandsautomat um die Abbarbeitung eines Dokumentes kümmert, das quasi die Unterzustände des Aufrufers beinhaltet.
Auf diese Weise können gewisse Teilbereiche sehr schön modularisiert werden, was einer Entwicklung in hohem Maße entgegenkommt. Es ist weiters
möglich, einen nebenläufigen Zustand zu definieren. Bestimmte darin ent-
47
Abb. 5.2: Stoppuhr-SCXML [45]
haltene Unterzustände werden als Startpunkte definiert, was zur Folge hat,
dass sich der Automat bei Erreichen dieses parallelen Zustandes in sämtlichen so markierten Unterzuständen gleichzeitig befindet. Diese können nun
wiederum beliebige Übergänge zu anderen dort enthaltenen Zuständen definieren. Der Automat verlässt diese Parallelität erst wieder, wenn einer dieser
Übergänge auf einen externen Zustand verweist [60].
Es ist außerdem möglich, innerhalb eines SCXML-Interpreters ein Datenmodell zu halten, welches anwendungsspezifische Informationen enthalten kann. Dieses Datenmodell kann in der Folge durch bestimmte Events
verändert werden und selbst auch Einfluss auf die Zustandsübergänge des
Automaten nehmen, da ein Zustandsübergang nicht nur, wie erwähnt, an
das Auftreten eines bestimmten Events, sondern weiters noch an konkrete
Bedingungen gekoppelt werden kann. Mittels spezieller Tags wie send und
invoke ist es möglich, mit externen Komponenten zu interagieren und in
Abhängigkeit des Zustandsautomaten Aktionen im Backend zu triggern oder
umgekehrt durch Aktionen im Backend eine Zustandsänderung des Automaten herbeizuführen [60].
Für die Abarbeitung von SCXML-Dokumenten existieren bereits, wie
auch bei CCXML, eine Reihe von entsprechenden Interpretern. Zu erwähnen
seien hierbei unter anderem eine Implementierung unter C++ mit der Bezeichnung Qt SCXML Engine sowie eine Umsetzung für Java im Rahmen
48
5.2 Generische UI-Beschreibungen
des Apache Commons Projektes. Obwohl es sich auch bei SCXML um einen
Entwurf handelt, welcher in der Zukunft gewiss noch Änderungen durchlaufen wird, kann durch das Verwenden dieser grundlegenden Plattformen
zumindest teilweise sichergestellt werden, dass sich Änderungen am SCXMLEntwurf nicht so gravierend auf ein laufendes Projekt auswirken, da diese ja
im verwendeten Interpreter durch das betreuende Projektteam entsprechend
berücksichtigt und nachgezogen werden.
Abschließend gesagt sei hier nun, dass sich ein Großteil der betrachteten Projekte bei der Modellierung der Dialogsteuerung auf diverse Beschreibungssprachen stützt, die Entwürfe des W3C allerdings gewiss eine sehr gute Grundlage für eine eigene Umsetzung bilden würden. Hier insbesondere
die Auszeichnungssprache SCXML, da diese in gewisser Weise eine Weiterentwicklung von CCXML darstellt, schon mit dem Fokus auf multimodale
Applikationen entwickelt wurde und eine größere Funktionsvielfalt mit sich
bringt. Ein Nachteil sei hier allerdings ebenfalls noch erwähnt: Zum aktuellen Zeitpunkt existieren keine ausreichenden Werkzeuge um SCXML-Dialoge
einfach und übersichtlich auf einer grafischen Basis entwickeln zu können.
Die einzige Möglichkeit besteht zur Zeit darin, eine im Rational Software
Architect erstellte UML-Darstellung mittels eines Plugins in SCXML-Form
überzuführen.
5.2
Generische UI-Beschreibungen
Ein recht großer Teil der Anwendungsentwicklung befasst sich mit der Formulierung und Implementierung von diversen Benutzungsschnittstellen. Obgleich der Aufwand im unimodalen Bereich schon nicht zu unterschätzen ist,
potenziert sich das Problem, sobald man den Bereich multimodaler Applikationen betritt. Hier muss nun nicht nur auf eine Art von UI Rücksicht
genommen und darauf hin entwickelt werden, sondern man muss sich mit
vielen verschiedenen Schnittstellenarten befassen. Jede verwendete Modalität benötigt dazu aber eine jeweils eigene Form der Beschreibungssprache,
mittels derer ihre Inhalte definiert werden können. Grafische Ausprägungen
werden beispielsweise mittels HTML-Dokumenten oder Java Swing Objekten und Codezeilen beschrieben, wärend für sprachliche Modalitäten etwa
VXML zum Einsatz kommen kann.
Aufgrund dieser Tatsachen wurde relativ rasch ersichtlich, dass es eine enorme Vereinfachung bei der Applikationsentwicklung darstellen würde,
hätte man eine einzige generische UI-Beschreibungssprache zur Verfügung,
die von allen Modalitäten verstanden und zur Erstellung von konkreten
49
Schnittstellen jeglicher Modalität herangezogen werden kann. Es existieren
zum aktuell mehrere solcher generischer UI-Beschreibungssprachen, auf welche in der Folge näher eingegangen wird. Das grundlegende Konzept liegt jedoch den meisten, und sämtlichen hier beschriebenen, Sprachen zugrunde. Sie
stellen selbst keine konkrete Schnittstellenbeschreibung zur Verfügung, welche von den unterschiedlichen Modalitäten verstanden werden muss, sondern
formulieren diese in einer abstrakten Form. Diese Beschreibungen werden
mittels unterschiedlichster Mechanismen zu konkreten modalitätsbezogenen
Ausführungen übergeführt, womit in der Folge eine Darstellung überhaupt
erst ermöglicht wird.
5.2.1
XIML
Der Begriff XIML steht für Extensible Interface Markup Language. Diese
Auszeichnungssprache wurde von RedWhale Software mit dem Start im Jahr
1998 entwickelt, um genau die eben beschriebenen Probleme zu lösen. Die
Entwicklung erfolgte bis 2001 unternehmensintern, daran anknüpfend wurde das XIML-Forum gegründet, um die Sprache auf öffentlicher Basis unter
der Mitwirkung von Wirtschaft und Wissenschaft weiterzuentwickeln, anzupassen und in weiterer Folge schließlich zu einem Standard zu etablieren [38].
Konkret ging es bei der Entwicklung von XIML darum, eine entstandene Lücke in der Softwareentwicklung zu schließen, bei der Interoparabilität
zwar ein sehr großer Begriff war und angestrebt wurde, der Fokus jedoch
zumeist nur auf dem standardisierten Austausch von Applikationsdaten lag.
Die Übermittlung von Interaktionsdaten blieb dabei zumeist ausgeklammert.
Unter Interaktionsdaten versteht man in diesem Zusammenhang Informationen, welche den Aufbau von Benutzungsschnittstellen angeben, die zu verwendenden Schnittstellenelemente definieren und das Zusammenspiel dieser
Elemente beschreiben [37].
Zur Formulierung der Benutzerinteraktion definiert XIML fünf unterschiedliche Schnittstellenkomponenten, wovon drei auf einer abstrakten Ebene zu liegen kommen, während die zwei weiteren konkretere Komponenten
darstellen [37].
Aufgabenkomponente: Hier werden Aufgaben und Prozesse abgebildet,
welche von der Benutzungsschnittstelle unterstützt werden sollen. Relevant ist hierbei aber einzig und allein der Anteil der Aufgaben, welche eine
Benutzerinteraktion voraussetzen. Diese Komponente soll also nicht dazu
dienen, die Applikationslogik zu erfassen, sondern lediglich eine Beschreibung des Interaktionskontexts liefern.
50
Domänenkomponente: Diese beinhaltet Objekte, welche für eine Benutzerinteraktion relevant sind und diesbezügliche Daten enthalten.
Benutzerkomponente: Diese beinhalten Informationen über die in die Interaktion involvierten Benutzer. Es werden beispielsweise relevante Personendaten hinterlegt.
Präsentationskomponente: Hier werden relevante Interaktionselemente definiert, welche später zu konkreten Objekten innerhalb der generierten
Schnittstellen werden. Beispiele wären hier Eingabefelder für konkrete Werte oder die Eingabemöglichkeit von Werten innerhalb eines bestimmten
Bereichs, was in der Folge möglicherweise als Schieberegler in einer Schnittstelle umgesetzt werden könnte. Es geht hier also darum, die Interaktionselemente möglichst abstrakt zu halten, damit diese später je nach aktueller Modalität unterschiedlich in konkrete Ausprägungen überführt werden
können.
Dialogkomponente: Die Möglichkeiten, welche dem Benutzer zur Verfügung
stehen, um Einfluss auf die Schnittstelle nehmen zu können, werden hier
definiert und hinterlegt. Weiters wird hier auch der Dialogfluss beschrieben,
welcher die Navigationsmöglichkeiten innerhalb der Schnittstelle regelt.
Diese Komponenten alleine ergeben allerdings noch keine komplette UIBeschreibung. Dazu sind weiters noch Relationen erforderlich, welche zwei
oder mehrere Elemente miteinander verknüpfen. Dies kann innerhalb einer
Komponente geschehen oder auch komponentenübergreifend. Mittels dieser
Relationen kann beispielsweise ein bestimmtes Datenobjekt der Domänenkomponente mit einem Element der Präsentationskomponente verknüpft werden. Die Menge der Relationen spiegelt also gewissermaßen das Design der
Benutzungsschnittstelle wider, Abläufe innerhalb der Schnittstelle zur Laufzeit sind nichts anderes als Manipulationen dieser Relationen.
Neben Komponenten und Relationen spielen außerdem noch Attribute
eine Rolle. Elemente innerhalb von XIML können dadurch bestimmte Werte annehmen, wobei hier einfache Datentypen, aber auch andere Elemente
zugewiesen werden können. Ein Element kann also mehrere Eigenschaften besitzen, welche sich als Attribut-Wert-Paare daarstellen. Verknüpfungen durch
Relationen können neben der Elementebene zudem auch zwischen Attributen realisiert werden [37].
Verwendet man nun also XIML, um multimodale oder auch nur plattformübergreifende Schnittstellen zu generieren, so erhält man am Ende eine
einzige XIML-Definition, welche die notwendigen Daten, den Navigationsfluss und eine Beschreibung der durchzuführenden Aufgaben beinhaltet. Im
51
ersten Schritt kann man nun geräte- und modalitätsspezifische Präsentationselemente definieren, aus denen über spezielle Konverter konkrete Schnittstellenbeschreibungen generiert werden können. Um zu der angestrebten Abstraktion zu gelangen, definiert man in der Folge zwischengeschaltete Präsentationselemente, welche von Interfacedesignern zur UI-Definition verwendet
werden können und die über vordefinierte Relationen auf die entsprechenden
konkreten Präsentationselemente verweisen. Abbildung 5.3 verdeutlicht diesen Vorgang [37].
Abb. 5.3: UI-Generierung auf mehrere Zielplattformen [37]
XIML stellt in seiner Form einen sehr interessanten, allgemeinen und umfassenden Ansatz dar, Schnittstellenbeschreibungen allgemein definieren zu
können. Das Problem an diesem Ansatz ist das Fehlen von Werkzeugen, welche Entwicklern den Umgang mit dieser Sprache erleichtern könnten. Weiters
wurde bei der Entwicklung von XIML ein Hauptaugenmerk auf den WebBereich gelegt, was zur Folge hatte, dass öffentlich verfügbare Konverter von
XIML hin zu Zielsprachen nur für den Webbereich entwickelt wurden, wie
zum Beispiel der flashbasierte Ansatz von [49].
5.2.2
UIML
Im Jahr 1997 begann die Arbeit an einer weiteren Auszeichnungssprache,
deren Anwendungsbereich in der UI-Beschreibung lag. Die Firma Harmonia
entwickelte neben einigen weiteren Unternehmen die User Interface Markup
Language bis zu einer vorläufigen Endversion im Jahr 2004 in der Version 3.0.
In der Folge wurde im Rahmen von OASIS (Organization for the Advancement of Structured Information Standards) ein UIML-Kommitee gegründet,
welches die Weiterführung der Spezifikation und die Standardisierung übernahm [52].
Aufgrund der bisherigen Bemühungen dieses Kommitees exisitert heute
ein Entwurf über die UIML-4.0-Spezifizierung. Die letzte aktuelle Version
dieses Entwurfes datiert auf Jänner 2008, kann und wird sich aber, ebenso
52
wie der SCXML-Entwurf des W3C, in der Zukunft noch weiterentwickeln
und ändern. Bei der User Interface Markup Language handelt es sich um eine deklarative herstellerunabhängige kanonische XML-basierte Metasprache
zur Schnittstellendefinition. Zur Umsetzung der konkreten UI´s kann auch
hier wiederum entweder eine Übersetzung in die jeweilige Zielsprache erfolgen
oder auch eine direkte Interpretierung durch das zugrundeliegende Endgerät
stattfinden. Die Sprache geht in ihrer Intention allerdings nicht ganz so weit
wie zum Beispiel XIML, bei der ja aus einer generellen Beschreibung heraus entsprechende Schnittstellen im Idealfall automatisch generiert werden
können, sondern befasst sich mehr mit der Aufgabe, die unterschiedlichen
Beschreibungen dieser Schnittstellen zusammenzufassen und in einheitlicher
Art und Weise in einem einzelnen Dokument zu vereinen. Anders formuliert
bedeutet das, dass UIML den Anwendungsentwicklern nicht die Arbeit abnimmt, konkrete Benutzungsschnittstellen zu entwickeln, ihnen aber ein einheitliches Schema vorgibt, mit dessen Hilfe sie die Struktur der erarbeiteten
UI´s formulieren und abbilden können [53]. Weiters beschränkt sich UIML
auf die Formulierung der UI-Beschreibungen selbst und klammert Aufgaben
und Dialogkonzepte anders als in XIML oder dem nachfolgend erläuterten
UsiXml weitestgehend aus bzw. beschäftigt sich damit auf einem sehr konkreten Abstraktionsniveau [40].
Bereits während der Entwicklung von UIML wurde großer Wert darauf
gelegt, entsprechende Werkzeuge zu implementieren, welche zum Einen die
Arbeit damit erleichtern und zum Anderen die Überführung in möglichst
viele Zielsprachen ermöglichen. So wurden von der Firma Harmonie im Rahmen ihrer Tätigkeit Renderer geschrieben, die Überführungen nach HTML,
Java oder VoiceXML durchführen konnten. Der Support für diese Tools ist
heutzutage leider nicht mehr gegeben, auch die Verlinkungen auf der Webseite von UIML [52] sind leider nicht mehr aktuell. Es gibt allerdings Nachfolgeprodukte wie LiquidApps und darin inbegriffen LiquidUI, welches eine
diesbezügliche Funktionalität zu Verfügung stellt. Nach Anfrage bei Harmonie selber kann aber ein Großteil dieser Renderer immer noch von Harmonie
bezogen werden [53].
Die Beschreibung eines UI´s in UIML erfolgt nach dem in Abbildung
5.4 gezeigten Schema. Die Schnittstelle selbst definiert sich nach vier Eigenschaften. Die Struktur spiegelt wider, welche Elemente in welcher Anordnung
enthalten sind, die Ausführungsform beschreibt, wie sich die Schnittstelle
darzustellen hat, sei es durch die Schriftart, verwendete Farben oder Ähnliches. Ein wichtiger Punkt betrifft natürlich auch den Inhalt der Schnittstelle
insgesamt und den der einzelnen Elemente. Zu guter Letzt ist auch noch das
53
Abb. 5.4: UIML-Modell. Angelehnt an UIML Version 4.0: Committee Draft
[53]
Verhalten relevant, welches die einzelnen UI-Komponenten an den Tag legen, wenn eine Interaktion stattfindet. Neben diesen Eigenschaften, welche
die Schnittstelle selbst beschreiben, gibt es die Logik dahinter, welche die
Verbindung zu Anwendungen und Datenquellen beschreibt und Präsentationen, die das Mapping auf konkrete Geräte und Plattformen angeben [53].
5.2.3
UsiXML
Die Abkürzung UsiXML steht für USer Interface eXtensible Markup Language und befasst sich im Wesentlichen ebenfalls mit der geräte-, plattformund modalitätsunabhängigen Darstellung von Benutzungsschnittstellen. Wie
bereits erwähnt, findet UsiXML neben diversen anderen Frameworks auch
im SerCHo-MASP-Projekt erfolgreich Anwendung. Auch hier geht es, wie
schon bei den bereits beschriebenen Sprachen XIML und UIML, nicht um
die Einführung einer neuen Schnittstellenbeschreibungssprache, anhand derer konkrete Implementierungen erfolgen können, sondern um die Generierung abstrakter Beschreibungen, welche erst durch weiteres Rendering in
bereits etablierte Formate wie XHTML oder VXML übergeführt werden
müssen. Auch sollen bei Weitem nicht alle denkbaren Ausprägungen von
UI-Elementen unterstützt werden, da dies viel zu weit führen würde, sondern lediglich eine definierte Teilmenge davon [54].
Im Gegensatz zu UIML existieren in UsiXML vier unterschiedliche Abstraktionsebenen, nämlich das Aufgabenmodell, das abstrakte UI, das konkrete UI und schließlich das finale UI. Reiht man UIML in diese Kategorisierung ein, so werden lediglich die Ebenen des konkreten und finalen UI´s
davon abgedeckt. Hier ist auch sehr schön zu erkennen, warum UsiXML im
SerCHo-MASP-Projekt Anwendung findet. Auch dort werden diese Abstraktionsstufen entsprechend definiert und stimmen überein [67].
54
Das Aufgabenmodell beschreibt die verschiedenen interaktiven Aufgaben, welche vom Benutzer des Systems durchgeführt werden müssen, sowie die Domänenobjekte, welche im Zuge des Interaktionsvorganges manipuliert werden. Die Darstellung der Modelle erfolgt auch hier wiederum mittels Concurrent Task Trees (CTT). Das abstrakte UI definiert Schnittstellen
nun absolut modalitätsunabhängig. Es beinhaltet abstrakte Container, abstrakte indivduelle Komponenten und Verknüpfungen zwischen beiden. Diese
Komponenten repräsentieren unterschiedliche Aspekte wie Eingabe, Ausgabe
oder Navigation und sind Abstrahierungen diverser grafischer und sprachlicher Toolkits. Da sich auf dieser Ebene noch kein Modalitätsbezug herstellen
lässt, ist es hier noch nicht möglich festzustellen, wie die Komponenten konkret aussehen werden. Das konkrete UI geht nun genau diesen Schritt weiter
und führt die abstrakten Beschreibungen auf die jeweiligen Modalitäten über,
allerdings noch auf einer allgemeinen Basis, auf der die Schnittstellen noch
geräte- plattformund toolkitunabhängig formuliert werden. Dies ist, wie
man sehen kann, auch die Ebene, auf der UIML Schnittstellen beschreibt.
Das finale UI spiegelt dementsprechend die Benutzungsschnittstellen wider,
die auf konkreten Plattformen und Geräten laufen [40].
Weiters existieren Transformationsregeln, welche angeben, wie Elemente
von einer Ebene auf eine andere überführt werden können. Mittels dieser
Regeln können Schnittstellen auf allen Ebenen ausgehend von Aufgabenmodellen teilweise automatisch generiert werden. Weiters ist es bei jedem
Übergang möglich, manuell auf die Transformation einzuwirken und das Ergebnis nach Wunsch anzupassen bzw. zu ergänzen [40].
Zu erwähnen sei in diesem Zusammenhang auch die exzellente Werkzeugunterstützung, welche für UsiXml existiert. Es stehen grafische Werkzeuge für
jede Ebene zur Verfügung und erleichtern die Arbeit sehr stark. Aufgabenmodelle können beispielsweise einfach mit IdealXML erstellt und modifiziert
werden, Transformationen werden grafisch mit TransformiXML bearbeitet
und so weiter [54].
Zusammenfassend kann nun Folgendes gesagt werden: Es existiert eine Vielzahl von Auszeichnungssprachen zur Beschreibung von Benutzungsschnittstellen. In dieser Arbeit wurden drei der interessantesten vorgestellt
und erläutert. UIML stellt in dieser Konstellation die elementarste dar, da sie
das Hauptaugenmerk wirklich darauf legt, mittels einer einheitlichen Sprache
eine Vielzahl von Benutzungsschnittstellen formulieren zu können. Weniger
im Fokus steht hier jedoch das Generieren von Schnittstellen aus abstrakten
Beschreibungen heraus. Mit dieser Problematik beschäftigen sich XIML und
55
5.3 Datenaustauschformat (EMMA)
UsiXML, wobei wohl Letzterer der Vorzug gegeben werden sollte, da hier die
Unterstützung durch diverse Werkzeuge wirklich eine Erleichterung bei der
Entwicklung darstellt, auf die bei XIML leider verzichtet werden muss.
5.3
Datenaustauschformat (EMMA)
Bei der Verwendung mehrerer Modalitäten im Rahmen einer Interaktion werden, wie bereits in Kapitel 3 erläutert, häufig Eingaben über mehrere Kanäle
getätigt, die semantisch in Zusammenhang stehen und erst durch eine geeignete Zusammenführung die Benutzerintention erkennen lassen. Um diese
Fusionsvorgänge ermöglichen bzw. erleichtern zu können, wurde eine entsprechende Sprache entwickelt, mit der Eingaben auf semantischer Ebene erfasst
und übermittelt werden können. Diese Extensible MultiModal Annotation
markup language (EMMA) basiert wie die bereits beschriebenen Sprachen
ebenfalls auf XML und stellt eine einfache Syntax zur Verfügung, mit der
Eingaben oder vielmehr deren Interpretationen erfasst werden können. Es
steht eine Reihe von EMMA-Tags zur Verfügung, um mit Unsicherheiten,
unterschiedlichen Interpretationsmöglichkeiten und weiteren im multimodalen Bereich auftretenden Besonderheiten umgehen zu können [46].
Abb. 5.5: Beispiel des möglichen Aufbaus eines EMMA-Dokumentes [46]
Abbildung 5.5 illustriert den Aufbau eines EMMA-Dokumentes am Beispiel einer Spracheingabe, für die im System zwei unterschiedliche Interpretationen möglich wären. Zu sehen ist in diesem Beispiel insbesondere die Verwendung eines one-of -Tags in Zeile drei, der wiederum zwei unterschiedliche
56
5.3 Datenaustauschformat (EMMA)
Interpretationen (Zeile 5-15 und 16-20) der erfolgten Benutzereingabe beinhaltet. Schön zu erkennen sind hier auch die verwendeten emma:confidenceAttribute, welche angeben, mit welcher Wahrscheinlichkeit die entsprechenden Interpretationen zutreffend sind. Eine Übersicht der definierten EMMATags sowie deren Attribute findet sich auf der W3C-Webseite [46].
57
6
Konzeptioneller Entwurf
Nach der Aufarbeitung der existierenden multimodalen Frameworks und deren Grundlagen im theoretischen Teil dieser Arbeit, soll nun nachfolgend ein
Konzept erarbeitet werden, auf dem ein konkretes multimodales Framework
implementiert und umgesetzt werden kann. Dieses soll, aufbauend auf der
Arbeit von Felsing [15], die Steuerung eines Smart Homes ermöglichen.
6.1
Statische Aspekte
Ausgehend von Kapitel 4, in dem eine Reihe von Forschungsprojekten und
Frameworks betrachtet und verglichen worden ist, scheint der vielversprechendste Ansatz für die Umsetzung eines multimodalen Frameworks darin
zu liegen, den Empfehlungen vom W3C zu folgen. Wie sich herausgestellt
hat, bedienen sich sehr viele Projekte in diesem Bereich derselben grundlegenden Konzepte, die von der W3C Multimodal Interaction Working Group
in ihrem Multimodal Interaction Framework quasi zusammengefasst und vereinheitlicht wurden.
Durch die Wahl des W3C-Vorschlages ergibt sich eine Reihe von Vorteilen bei der Implementierung. Zum Einen existieren bereits viele Technologien, die für die Umsetzung der verschiedenen Komponenten herangezogen
werden können. Welche davon konkret zum Einsatz kommen, wird im nachfolgenden Kapitel ersichtlich. Zum Anderen können die einzelnen Komponenten gewissermaßen inkrementell“ implementiert werden. In einer ersten
”
Version erfolgt die Umsetzung also auf einer einfachen, überschaubaren Ebene, um sicherzustellen, dass das gesamte Framework im Rahmen einer Diplomarbeit umgesetzt werden kann und lauffähig ist. Spätere Erweiterungen
6.1 Statische Aspekte
können dementsprechend leicht durchgeführt werden, indem die Implementierung einer jeweiligen Komponente ersetzt wird, um so zu einer erweiterten
Funktionalität zu gelangen. Zur Illustration sei hier auf die Beispiele der Eingrenzung des Themenbereichs in Kapitel 2 verwiesen. Es werden also in der
ersten Version zum Beispiel keine generischen Schnittstellenbeschreibungen
Anwendung finden. Es müssen für eine Schnittstelle mehrere Dokumente bereitgestellt werden, sofern diese auf mehreren Plattformen bzw. Modalitäten
gerendert werden soll. Eine etwaige multimodale Fusion bzw. Fission wird
ebenfalls nur rudimentär behandelt und erfolgt allenfalls nach Variante 3.2c
aus Kapitel 3. Es wird nachfolgend aber jedenfalls noch erläutert, an welcher
Stelle der Architektur eine Erweiterung der fehlenden Funktionalität vorgenommen werden kann.
Als Grundlage für die Umsetzung erweist sich des Weiteren eine serviceorientierte Architektur, wie sie auch im AMIGO-Projekt vorgeschlagen wird,
als vorteilhaft. Durch die Verwendung dieses Architekturprinzips wird weitgehend sichergestellt, dass die einzelnen Komponenten einfach ausgetauscht
und Erweiterungen bzw. Änderungen rasch durchgeführt werden können.
Dies kann sogar zur Laufzeit erfolgen und bietet damit sehr gute Möglichkeiten bei der Anwendungsentwicklung. Neue Servicekomponenten können über
das Internet eingespielt werden, was es einfacher macht, mehrere verteilte
Standorte mit den jeweiligen aktuellen Komponenten zu versorgen. Im Hinblick darauf, dass dieses Framework zu Forschungszwecken eingesetzt werden
wird, ist diese Flexibilität natürlich noch entscheidender und zu begrüßen.
In Abbildung 6.1 ist nun eine Architektur zu sehen, die auf den Vorschlägen des W3C aufbaut, dessen Konzepte in einen serviceorientierten
Rahmen bringt und um diverse Funktionalitäten erweitert, um am Ende
ein kohärentes, funktionierendes und implementierbares Konzept zu erhalten. Darüberhinaus muss aber wie gesagt auch sichergestellt werden, dass
die hier entwickelte Architektur mit der aus [15] kompatibel ist, bzw. darauf aufsetzen kann. Aus eben diesem Grund finden hier dieselben Ebenen
Verwendung wie auch in [15]. Der rechte Teil der Abbildung, namentlich das
Kontextservice und diverse Systemservicekomponenten, veranschaulicht die
Anknüpfungspunkte an diese zugrunde liegende Plattform und stellt somit
keinen Bereich dar, der im Zuge der vorliegenden Diplomarbeit umgesetzt
wurde.
Ein Großteil der Architektur befindet sich, wie man sehen kann, in der
Middlewareschicht und stellt den Kern dar, auf dem sämtliche umgesetzten UI Anwendungen aufsetzen. Auf der Anwendungsschicht befinden sich
59
60
Abb. 6.1: Architekturmodell
Services, die die verschiedenen umgesetzten UI Anwendungen darstellen. In
der physikalischen Schicht sind die Modalitäten abgebildet, die auf diversen
Endgeräten laufen und über die der Benutzer seine tatsächlichen Eingaben
tätigen und Systemausgaben erhalten kann. In Der Arbeit von Felsing [15]
existiert weiters noch eine Sensor-Plattform-Schicht, die im Rahmen dieser
Arbeit allerdings nicht ins Gewicht fällt und aus Gründen der Übersichtlichkeit nicht dargestellt wird. Hier könnten eventuell Netzwerkproxies umgesetzt
werden, über die weitere Modalitäten über andere Kanäle, wie zum Beispiel
UPNP, angebunden werden können. Nachfolgend werden nun die einzelnen
Servicekomponenten erläutert und ihr Zusammenspiel dargelegt.
6.1.1
Interaktionsmanager
Die wichtigste Komponente dieser Architektur stellt der Interaktionsmanager dar, der sich in der Middlewareschicht befindet. Ihm obliegt die zentrale
Aufgabe, sämtlichen Datenverkehr von und zu den Modalitäten zu steuern.
Weiters verwaltet er den Dialogfluss aller aktiven multimodalen Anwendungen. Im W3C-Draft wird zur Dialogsteuerung die Verwendung von SCXML
vorgeschlagen. Aus dem Grund wird auch in der der vorliegenden Arbeit
zugrunde liegenden Architektur SCXML als Auszeichnungssprache des Interaktionsmanagers verwendet. Durch die Serviceorientierung der Architektur findet die Ausführung der Dialogsteuerung allerdings nicht direkt im IM
statt, sondern in explizit dafür vorgesehenen weiteren Dialogservices. Der IM
seinerseits verwaltet diese Dialogservices und stellt ihnen die zur Ausführung
notwendigen Dokumente und Ressourcen zur Verfügung. Durch diese Aufteilung geht man hier allerdings auch einen Schritt weiter als im W3C-Entwurf
selbst. Dieser definiert den Interaktionsmanager mit seiner Dialogführung als
quasi monolithisches Objekt, das eine dedizierte Methodik zur Dialogsteuerung, SCXML, verwendet.
In der Architektur der vorliegenden Arbeit ist es aber ohne weiteres denkbar, neben SCXML-Dialogservices beliebige andere zu verwenden, solange
die Schnittstellen nach außen hin die gleichen bleiben. So ist es hier also
möglich, beispielsweise CCXML als Dialogsprache zu verwenden oder den
Dialogfluss innerhalb der Dialogservices mittels eines logik-basierten Ansatzes zu formulieren, wie dies auch in EMBASSI [13] gehandhabt wird. Solch
eine Flexibilität wird im W3C-Entwurf zwar für eventuelle nachfolgende Entwurfsversionen kurz angerissen, ist in der aktuellen Version aber wie gesagt
nicht vorhanden. Durch dieses Konzept ist der Interaktionsmanager natürlich
auch in der Lage, die Dialogsteuerung für beliebig viele parallel laufende Anwendungen zu übernehmen, indem für jede Applikation jeweils ein eigenes
Dialogservice erzeugt wird. Diese Servicegenerierung findet wiederum in einer Dialogservice Factory statt. Im Diagramm zu sehen ist hier, neben den
n Dialogservices für die einzelnen Applikationen, noch ein weiteres. Das hat
die Aufgabe, das Verhalten des IM selbst zu beschreiben, um diesen nicht
hardcodiert ausführen zu müssen und auch hier flexibel bleiben zu können.
6.1.2
Modalitäts- und Benutzermanager
Diese Komponente dient dazu, Geräte und Benutzerprofile zu verwalten.
Hierzu bedient sie sich des Kontext-Services, mit dem sie mittels Queries
kommuniziert. Verbindet sich ein Benutzer mit dem System, werden über
61
dieses Service gerätespezifische Informationen in den Kontext eingefügt, die
im späteren Verlauf dazu dienen, angepasste Benutzungsschnittstellen zur
Verfügung stellen zu können. Weiters können Benutzerpräferenzen angefordert werden, die ebenfalls den Aufbau und die Gliederung der bereitgestellten
UI´s beeinflussen können. Ein Beispiel hierfür könnte eine Einstellung sein,
bei der ein Benutzer es bevorzugt, das Menü immer nur auf dem PDA zu
sehen, sofern er mit einem verbunden ist, um den PC-Monitor für die übrige
Darstellung freizuhalten.
Vergleicht man diesen Part mit den Ausführungen des W3C, so ergibt
sich eine teilweise Überschneidung der Funktionalität. Der im W3C-Entwurf
ausgeführten Kontextkomponente obliegt die Verwaltung des gesamten Kontextes, sowohl der Benutzer und modalitätsbezogenen Bereiche, als auch aller
übrigen Kontextdaten. In dieser Architektur würde das wiederum eher auf
das Kontext-Service zutreffen, das ja den gesamten Smart Home Kontext verwaltet. Der Modalitäts- und Benutzermanager hingegen kümmert sich unter
Zuhilfenahme des Kontext-Services lediglich um benutzer- und modalitätsbezogene Informationen und ermöglicht einen einheitlichen Zugriff auf diese
Daten. Des Weiteren werden auch Authentifizierungs- und Autorisierungsmechanismen von diesem Service bereitgestellt.
6.1.3
Modalitätskomponenten
Diese Komponenten befinden sich außerhalb der SOA-Plattform auf den verwendeten Geräten selbst, die die Benutzungsschnittstellen darstellen. Diese
können unterschiedlichste Ausprägungen haben und über verschiedene Protokolle angebunden sein. Hier sind sowohl browserbasierte Lösungen als auch
Rich-Client-Anwendungen möglich. Bei der Umsetzung im Rahmen der Diplomarbeit wird der Schwerpunkt allerdings auf erstere Möglichkeit gelegt, da
sich dadurch auf einfache Art und Weise eine gewisse Plattformunabhängigkeit erreichen lässt. Zu beachten ist hier außerdem, dass es sich bei einer
Modalitätskomponente nicht um ein Gerät selbst handelt, sondern um eine
Modalität, die auf einem Gerät verfügbar ist. Hat man über einen einzelnen PC Zugriff über ein GUI und eine Sprachsteuerung, so wird dies hier
mit zwei unterschiedlichen Komponenten erfasst. Die Komponenten stellen
die Benutzungsschnittstellen lediglich dar, ohne vom zugrundeliegenden Interaktionsmodell zu wissen. Weiters sind sie als Blackboxes konzipiert, was
bedeutet, dass sie Informationen über den Status und Änderungen des Modells erhalten, aber ihre Reaktion darauf bzw. die innere Umsetzung nach
außen hin nicht ersichtlich ist.
62
6.1.4
HTTP-Service
Die Verbindung mit den externen Geräten wird hier mittels eines HTTPServices möglich gemacht. Selbstverständlich kann durch die Einführung weiterer Verbindungsservices die Bandbreite an möglichen und unterstützten
Kommunikationsprotokollen beliebig erweitert werden. Durch die Fokussierung auf eine browserbasierte Umsetzung der Modalitätskomponenten stellt
HTTP jedoch die naheliegendste Option dar. Bei diesem Protokoll existiert
jedoch keine Möglichkeit, Daten direkt vom Server zu den einzelnen Clients
zu übermitteln. Diese müssen zuerst eine Abfrage stellen und Daten explizit
anfordern. Im MONA-Projekt wurde zur Lösung des Problems ein Browserplugin verwendet. Im Rahmen dieser Arbeit wird allerdings ein clientseitiges
Polling Anwendung finden, sprich, die Clients werden in festgelegten Intervallen Daten vom Server abrufen. Dies zum Einen, um jeden Browser ohne
weiteren Installationsaufwand verwenden zu können, und zum Anderen aufgrund der begrenzten Zahl an Clients, die im Rahmen der Forschungsaktivitäten hier zeitgleich aktiv sind. Eine Änderung dieses Verfahrens, sollte sie
notwendig werden, ist jedenfalls einfach möglich.
6.1.5
Applikationsservices
Jedes dieser Services beinhaltet die Logik einer eigenen multimodalen Anwendung. Wie bereits erwähnt, benötigt der Interaktionsmanager zur Abarbeitung der Dialogsteuerung Dokumente, die diesen Dialog beschreiben. Die
Applikationsservices stellen dementsprechend ein für ihre jeweilige Aufgabe
formuliertes Dokument zur Verfügung. In der nachfolgenden Implementierung wird es sich dabei um das SCXML-Format handeln. Es steht jedem
Service frei, andere Formate zu verwenden, sofern eine entsprechende Service
Factory existiert, die Dialogservices auf Basis dieses anderen Dokumentenformates generieren kann. Weiters liegt es in der Verantwortung dieser Services, Beschreibungen für sämtliche Benutzungsschnittstellen zu liefern, die
für die jeweilige Anwendung benötigt werden. Dies stellt leider zurzeit einen
gewissen Aufwand dar, der in der Zukunft allerdings durch die Verwendung
genereller UI-Beschreibungssprachen abgefedert werden könnte.
Die Applikationsservices haben weiterhin die Möglichkeit, auf den Smart
Home Kontext zuzugreifen. Benutzer- oder modalitätsbezogene Informationen werden vorrangig über den Benutzer- und Modalitätsmanager bezogen.
Allgemeiner Kontext kann direkt über den Kontextmanager akquiriert werden. Diese Informationen können anwendungsintern verwendet werden, aber
auch bereits bei der Generierung der Dialog- oder UI-Beschreibungen. Beispielsweise könnte eine Anwendung über die Benutzerpräferenzen erkennen,
63
dass es sich im aktuellen Fall um einen blinden Anwender handelt und
dementsprechend nur sprachliche Modalitäten in die Interaktion miteinbeziehen.
Eine weitere wichtige Funktion der Applikationsservices besteht darin,
mit dem Smart Home selbst zu interagieren. Wenn über die multimodale
Schnittstelle ein Steuerungsbefehl eingeht, also zum Beispiel das Licht in einem Raum eingeschaltet werden soll, so muss dies auch in irgendeiner Form
umgesetzt werden. Diese Umsetzung geschieht dadurch, dass ausgehend vom
verantwortlichen Applikationsservice die für den Schaltvorgang notwendigen
Geräteservices gesucht werden, die auf der zugrundeliegenden Plattform von
Felsing [15] existieren und die entsprechenden Endgeräte repräsentieren. Über
diese Geräteservices können die Schaltvorgänge anschließend einfach durchgeführt werden. Das Ergebnis, in diesem Fall also das Einschalten sämtlicher
Lampen in einem Raum, wird über den Kontext wieder ersichtlich und kann,
da die Applikation ja Zugang zu diesem Kontext hat, wieder auf den Benutzungsschnittstellen dargestellt werden.
Einen Spezialfall stellt in diesem Zusammenhang das Administrationsservice dar. Im eigentlichen Sinne handelt es sich hierbei ebenfalls um eine Applikation im multimodalen Kontext, jedoch mit einer festgelegten Funktion.
Dieses Service kümmert sich um die Verwaltung der aktuell mit dem System
verbundenen Modalitäten. Es regelt, welche Modalität welcher Anwendung
zugewiesen ist und welche Modalitäten sich zusammen in einer Gruppe, einer Session befinden. Im Rahmen des W3C verwendet man hierfür wie gesagt
auch den Begriff des gemeinsamen Kontextes. Dieser darf allerdings nicht mit
dem Smart Home Kontext verwechselt werden. Er beschreibt vielmehr, welche Modalitäten gerade zusammen in einer Benutzerinteraktion tätig sind.
Obwohl sich das Konzept auf den Entwurf des W3C stützt, wird die vorliegende Arbeit im weiteren Verlauf im Sinne der Eindeutigkeit hierfür im
Weiteren den Begriff Session verwenden.
Die Basis, aufgrund derer diesbezügliche Entscheidungen vom Administrationsservice getroffen werden, kann unterschiedlich sein. Eine Ausprägung,
die auch innerhalb der ersten Implementierung umgesetzt wird, überlässt
dem Benutzer selbst diese Entscheidungskraft. Dem Benutzer wird also angezeigt, welche Modalitäten gerade aktiv sind, ob und an welche Anwendung
sie gerade angebunden sind und wie ihre Gruppierung untereinander aussieht. Der Benutzer selbst kann die Modalitäten anschließend umgruppieren
und für einzelne Modalitäten oder Modalitätsgruppen Anwendungen starten.
64
6.2 Dynamische Aspekte
Es wären natürlich auch andere Ausprägungen möglich, die zum Beispiel
mittels Kontext und Reasoning eine Gruppierung bzw. Umgruppierung der
Modalitäten vornehmen und Anwendungen starten. Hätte man Kontextdaten über die genaue Position von Menschen und Geräten zur Verfügung,
so könnte man auf dieser Grundlage beispielsweise ein Administrationsservice entwerfen, das immer diejenigen Modalitäten eines Benutzers zusammenfasst, die sich gerade im selben Raum befinden und diese Gruppierung
ändert wenn der Benutzer den Raum wechselt. Dadurch wäre es möglich,
ein so genanntes follow-me-Szenario umzusetzen, bei dem eine Anwendung
den Hausbewohnern über die Displays mehrerer Räume hinweg folgt, sofern
sie diese durchqueren. Selbstverständlich würde solch ein Administrationsservice dementsprechend auch Benutzerpräferenzen auswerten, die unter anderem angeben, für welche Benutzer und/oder Anwendungen dieses Verhalten
überhaupt erwünscht ist.
Anzumerken sei weiterhin, dass für eine umfassende Funktionalität des
Frameworks zumindest ein solches Service existieren muss, durchaus aber
mehrere zeitgleich existieren können.
6.2
6.2.1
Dynamische Aspekte
Interaktion
Der Informationsaustausch innerhalb der SOA-Plattform erfolgt zum Einen
gemäß des serviceorientierten Prinzips über die angebotenen Funktionen der
an der Interaktion beteiligten Services selbst. Zum Anderen existiert ein
Nachrichtenbus, der unter anderem zur Übermittlung von Steuerungssignalen
zwischen den Applikationsservices und den Geräteservices verwendet wird.
Dementsprechend wird solch ein Steuerungssignal nicht direkt an ein spezifisches Geräteservice geschickt, sondern es wird eine Nachricht mit einem entsprechenden Topic versendet, die von sämtlichen Geräteservices empfangen
wird. Nur diejenigen, die sich in der Folge für diese Nachricht verantwortlich
sehen, verarbeiten sie und führen diverse Funktionen aus.
Zwischen der SOA-Plattform und den externen Modalitäten selbst findet
eine andere Form des Datenaustausches statt, der vom W3C spezifiziert und
im entsprechenden Kapitel theoretisch andiskutiert wurde. Es handelt sich
um die MMI-Lifecycle-Event-API. Wie bereits erwähnt, existiert eine Reihe
von 18 unterschiedlichen Eventtypen, die bei der Steuerung der Modalitäten
Verwendung findet. Diese kann man in der Art ihrer Funktion grob in zwei
Klassen einteilen. Zum Einen existieren Typen wie das NewContextRequest-
65
, ClearContextRequest- oder das StatusRequest Event mit ihren zugehörigen Antwort-Events, über die anwendungsunabhängig die Ankopplung und
Verwaltung von Modalitäten koordiniert werden kann. Events dieser Typen
werden also vorranging vom Interaktionsmanager selbst versendet bzw. empfangen, unabhängig von der Applikation, die hier im Hintergrund eine Rolle
spielt. Zum Anderen werden Eventtypen wie zum Beispiel das ExtensionNotification Event nur anwendungsintern verwendet und deshalb auch nur von
den Dialogservices der Applikationen selbst verarbeitet. Als das Datenformat,
mit dem die Informationen innerhalb der Nachrichten gekapselt werden, findet EMMA Verwendung
6.2.2
Sessionmanagement
Der Lebenszyklus einer Modalitätskomponente erstreckt sich über die drei
Phasen des Verbindungsaufbaus, der Interaktion zwischen Benutzer und diversen multimodalen Applikationen und des Verbindungsabbaus. Der genaue
Ablauf dieser Abschnitte wird nun durch die folgenden Sequenzdiagramme
dargestellt.
Abb. 6.2: Sequenzdiagramm - Login fehlgeschlagen
Zum Verbindungsaufbau sei ergänzend erwähnt, dass innerhalb des W3CEntwurfes nicht genau spezifiziert wird, wie die Authentifizierung bzw. Autorisierung durchzuführen ist. Auch existieren innerhalb der MMI-LifecycleEvents keine diesbezüglichen Properties. Aus diesem Grund wird dieser Part
in der Konzeption wie folgt umgesetzt. Die erste Nachricht, die das Framework von einer neuen Modalitätskomponente erhält, ist das NewContextRequest-Event. Weiters besitzen alle Eventtypen laut W3C-Spezifikation einen
66
Abb. 6.3: Sequenzdiagramm - Login erfolgreich
allgemeinen Datenbereich, in dem implementierungsspezifische Informationen übermittelt werden können. Für die korrekte Anmeldung der Modalität
im System ist es hier nun zwingend notwendig, dass innerhalb des Datenbereichs des ersten NewContextRequest-Events die Authentifizierungsinformationen, wie Benutzername und Passwort, enthalten sind. Auch optionale Benutzer oder Modalitätseigenschaften können darüberhinaus noch enthalten
sein. In den Abbildungen 6.2 und 6.3 ist nun der Login-Vorgang im negativen
und positiven Fall ersichtlich.
Das initiale Event von der Modalität zum Interaktionsmanager ist wie
erwähnt ein NewContextRequest-Event, das alle notwendigen benutzer- und
modalitätsspezifischen Daten enthält. Der Interaktionsmanager stellt damit
eine Authentifizierungsanfrage an den Modalitäts- und Benutzermanager, der
seinerseits eine Anfrage an das Kontext-Service richtet, um an die entsprechenden Benutzerdaten zu gelangen. Sind diese verfügbar, erfolgt der Authentifizierungsvorgang. Ist dieser nicht erfolgreich, kommt es zu einer entsprechenden Rückantwort an den Interaktionsmanager, der seinerseits ein
NewContextResponse-Event generiert, das eine negative Antwort sowie eine
Problembeschreibung beinhaltet. Dieses Event wird danach an die Modalitätskomponente gesendet.
Ist die Benutzerauthentifizierung jedoch erfolgreich, so werden im Datenmodell des Interaktionsmanagers die relevanten Informationen der Modalität
und des Benutzers für die spätere Verwendung hinterlegt und ein NewContextResponse-Event erzeugt, das eine positive Statusmeldung und die der
67
Modalität nun zugewiesene ContextId (SessionId) beinhaltet.
Abb. 6.4: Sequenzdiagramm - Zuweisung einer Applikation zu einer Session
Einer Session können im Laufe ihrer Existenz mehrere multimodale Applikationen zugewiesen werden. Die Abläufe bei so einer Zuweisung sind in
Abbildung 6.4 zu sehen. Hierfür erzeugt der Interaktionsmanager ein neues Dialogservice, das den Dialog zu einer dedizierten Anwendung abarbeiten soll. Dazu muss dieses neue Service eine Anfrage an das entsprechende Anwendungsservice stellen, das daraufhin, in Abhängigkeit von diversen Benutzerpräferenzen, ein SCXML-Dokument generiert und retourniert.
Mit Hilfe dieser Dialogbeschreibung kann das Dialogservice nun den Dialog
starten und dem Interaktionsmanager diesen erfolgreichen Start mitteilen.
Dieser aktualisiert daraufhin sein internes Datenmodell und hält fest, dass
diese Session nun genau diese Anwendung bearbeitet. Die weiteren Schritte hängen nun natürlich von der jeweiligen Anwendung ab. Im Allgemeinen
ergibt sich jedoch ein relativ einheitlicher Startvorgang. Es erfolgt eine Anforderung der Inhaltsbeschreibungen an den Anwendungsservice, der diese
Inhalte entsprechend den Modalitätspräferenzen aufbereitet und zurückgibt.
Daraufhin werden diese innerhalb eines StartRequest-Events an die Modalitäten übermittelt, was diese dazu veranlasst, ihre Darstellung anhand der
UI-Beschreibungen neu aufzubauen und mit einem StartResponse-Event zu
bestätigen. Sämtliche weiteren Abläufe sind nun applikationsspezifisch und
lassen sich nicht verallgemeinern. Beispiele dazu finden sich in Kapitel 9, wo
68
im Rahmen eines Szenarios einige Abläufe illustriert werden.
Abb. 6.5: Sequenzdiagramm - Verbindungstrennung
Während eine Modalität aktiv und mit dem Framework verbunden ist,
werden kontinuierlich Statusinformationen hin und her gesendet wie das in
Abbildung 6.5 gezeigt wird. Kommt es hierbei zu einem Timeout, so ist
die Modalität nicht mehr länger aktiv und muss dementsprechend entfernt
werden. Eine Modalität kann durch ein StatusResponse-Event auch explizit
mitteilen, dass sie nun offline geht, indem das Statusfeld des Events einen
entsprechenden Eintrag enthält. Das Entfernen selbst geschieht über den
Modalitäts- und Benutzermanager. Nachdem die Modalität entfernt wurde, überprüft der Interaktionsmanager des Weiteren, ob es sich hierbei um
das letzte Mitglied in der jeweiligen Session gehandelt hat. Ist dies der Fall,
so beendet er das zugehörige Dialogservice ebenfalls. Existieren noch weitere Modalitäten, so informiert er das Dialogservice lediglich über das Fehlen
der Modalität, damit dieser in der Folge darauf reagieren kann, sofern dies
notwendig sein sollte.
69
7
Implementierung
In diesem Kapitel wird nun ausgehend von dem zuvor erstellten Konzept die
konkrete Umsetzung erläutert und veranschaulicht. Zu diesem Zweck werden zunächst die wichtigsten verwendeten Technologien herausgegriffen und
in aller Kürze vorgestellt. Anschließend werden die Anknüpfungspunkte an
die zugrunde liegende Plattform der parallelen Diplomarbeit [15] dargestellt,
sowohl was die Kontextakquirierung als auch was den Zugriff auf die unterschiedlichen Smart Home Komponenten betrifft, um eine Grundlage zu
bilden, auf der die konkrete Implementierung geschildert werden kann.
7.1
7.1.1
Verwendete Technologien
OSGI
Die OSGI (Open Services Gateway Initiative) Allianz wurde im Jahr 1999
gegründet und setzte sich als Ziel die Entwicklung einer Spezifikation für die
Umsetzung einer offenen und einheitlichen Plattform, auf der serviceorientiert gearbeitet werden kann. Softwarekomponenten, gekapselt als einzelne
Services, sollten einfach und koordiniert entwickelt, vertrieben und verwaltet werden können. Diese Spezifikation wurde ausgehend von ihrer Urform
in Version 1.0 stetig weiterentwickelt und steht heute in der Version 4.1
zur Verfügung. Es existiert bereits eine Reihe von Java-basierten Umsetzungen dieser Spezifikation, sowohl auf kommerzieller als auch auf OpenSource-Basis. Bekannte Open-Source-OSGI-Frameworks wären unter anderem Knopflerfish, Apache Felix oder Equinox, wobei letzteres direkt innerhalb der Entwicklungsumgebung Eclipse integriert ist. Auch Eclipse selber
basiert im Übrigen auf OSGI. Bei Equinox handelt es sich selbst auch um
das Framework, das bei der Implementierung im Rahmen dieser Arbeit Verwendung findet [51].
7.1 Verwendete Technologien
Der Aufbau des OSGI-Frameworks ist sehr schön am Schichtenmodell in
Abbildung 7.1 zu sehen. Über alle Ebenen hinweg erstreckt sich das OSGISicherheitsmodell, das auf der Java-2-Spezifikation aufsetzt und diese erweitert. Die Verwendung dieser Schicht ist optional, sie wird auch in der Implementierung im Rahmen der Diplomarbeit lediglich zur Benutzerauthentifizierung eingesetzt.
Abb. 7.1: OSGI Schichtenmodell, angelehnt an die OSGi Service Platform
Core Specification [33]
Auf der Modulebene werden Softwarekomponenten als sogenannte Bundles beschrieben. Konkret handelt es sich bei einem Bundle um eine JARDatei, die Java-Klassen, OSGI-spezifische Informationen und zusätzliche Ressourcen beinhaltet, die zusammen eine bestimmte Funktionalität bereitstellen. Innerhalb einer OSGI-Plattform stellen diese Bundles die einzige Möglichkeit dar, Java basierte Anwendungen zu entwickeln. Sie können auch sehr
einfach an eine andere OSGI-Plattform übermittelt und dort zur Laufzeit
integriert werden [33].
Die einzelnen Bundles unterliegen außerdem einem definierten Lebenszyklus, den sie durchlaufen. Sie befinden sich zu einem bestimmten Zeitpunkt
immer in einem gewissen Status. Nach der erfolgreichen Integration eines
Bundles in das Framework befindet sich dieses im installed -Zustand. Sind alle
Ressourcen verfügbar, die das Bundle benötigt, um lauffähig zu sein, so geht
es in den resolved -Status über. Nun kann es jederzeit gestartet werden. Ist
dies der Fall, so wechselt es in den starting-Zustand, in dem initiale Funktionen ausgeführt werden, die im Bundle selbst definiert wurden. Anschließend
befindet es sich im active-Status und die Funktionalität des Bundles steht im
Framework zur Verfügung. Beim Deaktivieren geht das Bundle in den stopping-Zustand über, in dem angegebene Finalisierungsmethoden angestoßen
werden. Nach der Deinstallation befindet es sich im uninstalled -Zustand und
71
kann nicht mehr verwendet oder gestartet werden [33].
Bundles stellen ihre Funktionalität wiederum als Services zur Verfügung.
Ein Service ist in diesem Fall ein Java-Objekt, das vom jeweiligen Bundle,
wenn es aktiv wird, über ein oder mehrere Java-Interfaces in einem gemeinsamen Serviceregister eingetragen wird. Ein Bundle kann dabei eine Vielzahl
von Services beinhalten und registrieren. Durch diese Eintragung sind wieder andere Bundles in der Lage, die entsprechenden Services zu finden, für
sich zu binden und in weiterer Folge auch zu verwenden. Wird ein Bundle
gestoppt, so werden auch die von ihm bereitgestellten Services aus dem Register entfernt und alle davon abhängigen Services benachrichtigt [33].
Auf dieser Grundlage ist es nun sehr komfortabel möglich, Service orientiert zu entwickeln. Die im Framework verfügbaren Services lassen sich
einfach suchen und verwenden, neue Services können leicht integriert werden. Bestehende Services können ohne großen Aufwand durch andere ersetzt
werden. Die Open-Source-Implementierungen sind inzwischen sehr ausgereift.
Es existiert eine große Zahl an bereits verfügbaren Services, auf die man im
Rahmen einer Softwareentwicklung zurückgreifen kann und nicht erst selbst
implementieren muss. Alle diese Punkte und auch die Tatsache, dass OSGI
in sehr vielen Projekten erfolgreich eingesetzt wird (z.B. im AMIGO-Projekt
[44]), sprechen für eine Verwendung dieser Technologie als Basis für die Implementierung im Zuge dieser Arbeit.
7.1.2
Commons SCXML
Ausgehend von der Spezifikation der Dialogbeschreibungssprache SCXML,
die in Kapitel 7 bereits beschrieben wurde, gibt es eine Reihe von Implementierungen, welche darauf basierende Zustandsautomaten realisieren. Eine
solche Implementierung findet im Rahmen des Apache-Commons-Projektes
statt und trägt die Bezeichnung Commons SCXML. Commons SCXML ist
aktuell in der Version 0.9 verfügbar und stellt eine umfassende Umsetzung des
W3C-Entwurfes dar. Aufgrund der Tatsache, dass sich der zugrunde liegende
Entwurf stetig verändert und weiterentwickelt, wird auch die Implementierung ständig den neuen Anforderungen angepasst. Den Kern der Commons
SCXML API kann man dennoch als stabil bezeichnen, da hier auch der Entwurf relativ final zu sein scheint. Andere Bereiche, wie die Beschreibung des
Datenmodells oder Elemente wie das invoke-Tag, mit dem man innerhalb
eines Zustandsautomaten einen weiteren instanziieren kann, werden sich in
Zukunft sehr wahrscheinlich noch ändern, um der W3C-Spezifikation genügen
zu können [45].
72
Für die Verwendung dieser Technologie als Laufzeitumgebung der Zustandsautomaten im praktischen Teil dieser Arbeit sprechen neben der guten und weitreichenden Umsetzung der Spezifikation noch weitere Punkte: Commons SCXML basiert auf der Programmiersprache Java, die auch
hauptsächlich zur Implementierung des praktischen Teils herangezogen wird,
nicht zuletzt durch die Verwendung der Equinox-OSGI-Plattform als Ausgangsbasis, die ja gleichfalls in Java implementiert wurde. Des Weiteren existiert eine sehr große und auch sehr aktive Community, die zur Weiterentwicklung von Commons SCXML beiträgt und auftretende Fragen beantworten
kann [45].
Hinzu kommt noch die Tatsache, dass es kein großes Problem darstellt, auf
dieser Technologie basierende Zustandsautomaten als Services innerhalb von
OSGI verfügbar zu machen. Auch frameworkspezifische Erweiterungen sind
ohne großen Aufwand zu integrieren, wie beispielsweise die Generierung von
MMI-Lifecycle-Events durch ein Tag innerhalb eines SCXML-Dokumentes.
7.1.3
CMU Sphinx
Das Sphinx-Spracherkennungssystem wurde an der Carnegie Mellon University entwickelt und liegt aktuell in der Version 4 vor. Es basiert wie die bereits erwähnten Technologien ebenfalls auf Java und ist als Open Source frei
verfügbar. Bei der Entwicklung waren neben dem CMU auch noch Firmen wie
Sun Microsystems und Mitsubishi beteiligt. Die Architektur von Sphinx-4 ist
in Abbildung 7.2 ersichtlich. Sie kann grob in drei größere Module unterteilt
werden, wobei jedes dieser Module von Applikationen angesteuert werden
kann, die Sphinx zur Spracherkennung verwenden. Weiters ist der Aufbau
auch innerhalb dieser Komponenten sehr stark modularisiert, wodurch das
ganze Framework sehr flexibel wird, betrachtet man im Vergleich andere
Spracherkennungsprogramme oder auch Vorgängerversionen von Sphinx 4.
Das Frontend ist dafür verantwortlich, Sprachsignale zu empfangen und
in bearbeitbare Blöcke zu unterteilen, sowie den Beginn und das Ende einer
Spracheingabe festzustellen. Hierbei werden unterschiedliche Modi wie clickto-talk oder push-to-talk unterstützt. Bei Ersterem gibt der Benutzer durch
eine Eingabe den Start der Spracheingabe bekannt und das System ermittelt
das Ende. Bei Letzterem wird sowohl der Start- als auch der Endpunkt vom
Benutzer festgelegt [25].
Der Linguist enthält eine zur Dekodierung erforderliche Wissensbasis in
73
Abb. 7.2: Sphinx-4 Architektur, angelehnt an Walker et al. [42]
Form von Sprach- und Akustikmodellen sowie auch ein Aussprachewörterbuch. Die Aufgabe dieser Komponente ist die Generierung eines Suchgraphen, mit dessen Hilfe der Dekodierer in der Folge eine Spracherkennung
durchführen kann. Wie alle Teile der Architektur ist auch dieser Part austauschbar und ermöglicht somit die Verwendung einer auf die jeweilige Situation angepassten Wissensbasis. Bei einfachen Implementierungen, die nur
einige unterschiedliche Wörter in den Spracheingaben zu erwarten haben,
kann eine sehr einfache und schnelle Umsetzung eingesetzt werden. Bei einem
umfangreicheren Vokabular kann man sich für eine komplexere Wissensbasis
entscheiden. Das Sprachmodell beinhaltet hierbei die Struktur der Sprache,
also welche Wörter in welcher Reihenfolge und Wahrscheinlichkeit auftreten
können. Das Akustikmodell dient zum Mapping der eingegangenen Sprachlaute über das Frontend auf bearbeitbare Eingaben und Wortfragmente. Das
Aussprachewörterbuch stellt für sämtliche Wörter des Sprachmodells dar,
wie diese ausgesprochen werden. Diese Aussprache bricht die Wörter in kleinere Unterteilungen und Wortfragmente, die ihrerseits im Akustikmodell zu
finden sind [42].
Im Dekoder-Modul erfolgt anschließend die eigentliche Spracherkennung.
Auf der einen Seite erfolgt der Input der im Frontend ermittelten Sprachfragmente, auf der anderen Seite bekommt er vom Linguisten einen entsprechenden Suchgraphen übermittelt. Es handelt sich dabei um einen gerichteten Graphen, dessen Knotenpunkte Zwischenzustände einer Spracherkennung darstellen. Hierbei kann man differenzieren zwischen Knoten, die die
Sprachfragmente anhand des Akustikmodells identifizieren und sozusagen auf
74
der untersten Ebene direkt mit den eingegangenen Sprachinformationen arbeiten, und Knoten, die eine Ebene darüber anhand des Wörterbuches und
Sprachmodells darauf aufbauend Wortteile und Wörter bilden können. Die
Übergänge zwischen den Zuständen sind durch Wahrscheinlichkeiten gewichtet. Mit Hilfe dieses Suchgraphen werden nun aus den erhaltenen Eingaben
Hypothesen generiert und Ergebnisobjekte gebildet, die alle Pfade durch den
Suchgraphen enthalten, die zu einem Endzustand geführt haben. Weiters
werden noch die Wahrscheinlichkeiten aller Wege festgehalten. Dieses Ergebnisobjekt wird dann anschließend an die Applikation retourniert. Die Anwendungen, die Sphinx-4 zur Spracherkennung verwenden, haben darüberhinaus
noch die Möglichkeit, kontrollierend auf diesen Dekodierungsvorgang einzuwirken und so selbst ein Teil des Spracherkennungsvorganges zu werden [42].
7.1.4
FreeTTS
Sphinx-4 findet also Verwendung bei der Erkennung und Verarbeitung von
Spracheingaben. Als Gegenpart dazu eignet sich das von Sun entwickelte
FreeTTS (text-to-speech) System. Es wurde, wie die übrigen vorgestellten
Technologien, ebenfalls in Java umgesetzt und basiert auf zwei früher entwickelten Systemen. Zum Einen auf flite, das wie auch Sphinx an der Carnegie
Mellon University in C implementiert wurde, zum Anderen auf Festival unter
C++, für das Sun Microsystems verantwortlich zeichnet. FreeTTS versucht
nun, die Vorteile von flite, die vor allem in der guten Performance zu finden
waren, und die Flexibilität von Festival in einer gemeinsamen Implementierung zu vereinen [47].
Um von einem geschriebenen Text zu einer gesprochenen Ausgabe zu
gelangen, sind eine Reihe von Schritten notwendig, die FreeTTS durchlaufen
muss [41]:
Textnormalisierung: Hier wird der zu verarbeitende Text in eine Reihe von
Wörtern umgewandelt. Auch Spezialfälle wie Zahlen, Zeiten oder Datumsangaben werden hier in entsprechende Wörter überführt.
Linguistische Analyse: Im Rahmen dieser Analyse werden semantische Informationen wie die Phrasierung der einzelnen Wörter extrahiert.
Lexikalische Analyse: In diesem Schritt werden die einzelnen Silben der
Wörter ermittelt und ihre Betonung festgelegt. Dies geschieht anhand eines
Wörterbuches oder, wenn kein passender Eintrag gefunden werden kann,
auch auf Basis einfacher Mappings von Buchstaben zu Lauten.
Prosodiegenerierung: Es genügt nicht, einfach die eben ermittelten Silben
nacheinander wiederzugeben. Bei der Aussprache sind noch weitere Fak-
75
7.2 Umsetzung
toren zu berücksichtigen, wie zum Beispiel Tonhöhen- oder Lautstärkeunterschiede, Dauer einer Aussprache und auftretende Pausen. Solche Sprachinformationen werden in diesem Schritt hinzugefügt.
Sprachsynthese: Hier findet die eigentliche Generierung von Audiosignalen
statt, basierend auf den zuvor ermittelten Informationen. Dieser Schritt
ist der arbeitsintensivste, da hier eine Reihe von Gleitkommaoperationen
durchgeführt werden müssen.
Durch die Verwendung von Java mit einem sehr gut optimierenden Compiler als Grundlage und durch die Vereinigung der positiven Charakteristiken
der beiden anderen erwähnten text-to-speech-Technologien konnte eine signifikante Verbesserung der Leistungsfähigkeit erzielt werden, was ebenfalls sehr
für die Verwendung von FreeTTS als text-to-speech-Software spricht [41].
7.2
Umsetzung
Die Umsetzung der im vorangegangenen Kapitel vorgestellten Architektur
erfolgt nun mittels der eben erläuterten Technologien. Als Grundlage dient
die serviceorientierte OSGI-Plattform, auf der die einzelnen Komponenten als
Bundles registriert werden und deren Funktionalität als Services im OSGIFramework verfügbar gemacht wird. Da solche Services innerhalb von OSGI
über ihre Schnittstellen definiert und registriert werden, ist deren Definition
und Strukturierung hier von zentraler Bedeutung. Nachfolgend werden Implementierungsdetails aller im Konzept vorgestellten Komponenten gegeben,
und es wird insbesondere auf deren Schnittstellen zu anderen Services hin
Bezug genommen. Abbildung 7.3 zeigt dazu ein entsprechendes Komponentenmodell.
7.2.1
Interaktionsmanager
Der Interaktionsmanager stellt, wie bereits erwähnt, die zentrale Komponente in dieser Architektur dar. Aus diesem Grund exportiert er eine Reihe
von Services mit den entsprechenden Schnittstellen, um den übrigen Komponenten eine Kommunikation mit ihm zu ermöglichen. Erwähnt sei hierbei
nochmals, dass die Steuerung selbst nicht innerhalb dieser Komponente erfolgt, sondern als eigener SCXML-Dialog ausgelagert ist. Das führt zu einer
größeren Flexibilität. Diese Auslagerung betrifft auch sämtliche Dialoge aller laufenden Applikationen. Die Servicefactory, die sich um die Generierung
der einzelnen Dialogservices kümmert, ist aus Gründen der Übersichtlichkeit
nicht in dem Diagramm aufgeführt. Die exportierten Schnittstellen ergeben
sich hierbei wie folgt:
76
7.2 Umsetzung
77
Abb. 7.3: Komponenten und Schnittstellen
IDialogEngineConnector: Über die hier enthaltenen Methoden erfolgt eine Kommunikation der Dialogkomponenten mit dem Interaktionsmanager.
Über die Methode receiveInternalEvent werden Ereignisse, welche in dem
Dialog ausgelöst werden, der den Interaktionsmanager steuert, übermittelt.
In der Folge können intern im Interaktionsmanager Funktionsaufrufe erfolgen und dem Ereignis entsprechende Aktionen gesetzt werden. Über receiveApplicationInputEvent werden applikationsspezifische Ereignisse von
den Dialogkomponenten entgegengenommen und an die zugehörige Applikationskomponente weitergeleitet. Komplementär dazu werden über receiveOutboundMMIEvent Dialogereignisse empfangen, die zur Aussendung
von MMI-Lifecycle-Events führen, um mit den angeschlossenen Modalitäten zu kommunizieren. Über dialogFinished wird dem Interaktionsmanager mitgeteilt, dass der entsprechende Dialog in einem Endzustand angekommen ist und beendet wurde.
IModalityConnector: Über diese Schnittstelle und ihre einzige Methode
receiveInboundMMIEvent werden eingehende MMI-Lifecycle-Events empfangen.
IMMIApplicationConnector: Diese Schnittstelle dient wie die zuvor erläuterte zum Empfang von Ereignissen, diesmal jedoch auf der Anwendungsseite
mittels receiveApplicationOutputEvent.
7.2 Umsetzung
Schnittstelle
IDialogEngineConnector
Methode
reveiveInternalEvent
receiveApplicationInputEvent
receiveOutboundMMIEvent
dialogFinished
IModalityConnector
receiveInboundMMIEvent
IMMIApplicationConnector
receiveApplicationOutputEvent
IMMIAdministrationConnector startApplication
moveModality
getContextListing
Tab. 7.1: Schnittstellenübersicht Interaktionsmanager
IMMIAdministrationConnector: Einen Sonderfall der Anwendungen stellen die erwähnten Administrationsapplikationen dar. Diese verfügen neben
der Funktionalität normaler Anwendungen über die Möglichkeit, steuernd
in die Verwaltung von Modalitäten einzugreifen, die an das Framework
angebunden sind. Dazu bedienen sie sich der folgenden Methoden innerhalb dieses Interfaces: Mittels getContextListing kann eine Übersicht aller
momentan aktiven Sessions und Modalitäten angefordert werden. Über
startApplication kann einer laufenden Session und somit aller zugeteilten Modalitäten innerhalb dieser Session, eine andere MMI-Applikation
zugewiesen werden. Die bereits aktive Anwendung wird hierbei beendet.
Mittels moveModality ist es möglich, eine Modalität von einer Session in
eine andere zu verschieben. Dazu muss allerdings noch Folgendes gesagt
werden: Eine Modalität aus einer Session zu entfernen, kann die laufende Session gefährden. Existierten Interaktionsmöglichkeiten nur über diese
eine Modalität, so sind sie nach deren Entfernung natürlich nicht mehr
verfügbar. Aus diesem Grund müssen Anwendungen, die komplementäre
Modalitäten verwenden, auch Maßnahmen treffen, die verhindern, dass eine Session unbrauchbar werden kann. Auch das Einbringen einer Modalität
in eine bereits laufende Session ist mit Schwierigkeiten verbunden, da der
Status, in dem sich die Anwendung der Session gerade befindet, übermittelt werden muss. Weitere Details hierzu finden sich in der Folge bei der
Beschreibung der Applikationskomponenten.
7.2.2
Dialogservices
Die Dialogservices basieren in der aktuellen Implementierung auf SCXMLBeschreibungen und bieten ihrerseits ein Interface, über das der Interaktionsmanager auf die Funktionen dieser Services Zugriff nehmen kann. Es ist auch
78
7.2 Umsetzung
79
ohne weiteres möglich, das System um einen zusätzlichen Dialogservicetyp
zu erweitern, der eine andere Form der Dialogbeschreibung verwendet und
versteht. Die hier verwendete Schnittstelle trägt die Bezeichnung IDialogEngine. Über die Methoden start und stop kann die Abarbeitung des jeweiligen
Dialogs begonnen oder beendet werden. Mittels isRunning kann der diesbezügliche Status auch abgefragt werden. Es existiert keine eigene Methode,
über die dem Service eine Dialogbeschreibung übermittelt werden kann, da
dies bereits bei der Initialisierung des Dialogservices durch die Servicefactory festgelegt wird. Sehr wohl gibt es aber natürlich Möglichkeiten, auf den
internen Dialogablauf Einfluss zu nehmen:
Schnittstelle
Methode
IDialogEngine start
stop
isRunning
receiveMMIEvent
receiveApplicationEvent
Tab. 7.2: Schnittstellenübersicht Dialogservices
Mittels receiveMMIEvent werden MMI-Lifecycle-Events vom Service empfangen, die von den angeschlossenen Modalitäten eingehen und die für diesen
Dialog bestimmt sind, also quasi Eingaben von Benutzerseite darstellen. Die
Methode receiveApplicationEvent dient zur Übermittlung von Informationen von der Anwendungsseite her. Hierbei ist zu beachten, dass ein solches
Applikationsereignis durchaus nicht nur auf den Ablauf eines einzelnen Dialogservices Einfluss nehmen muss. Es können zu einem beliebigen Zeitpunkt
mehrere Dialoge im Rahmen einer einzelnen Anwendung laufen, wenn mehrere Sessions dazu aktiv sind. Ein applikationsseitiges Event, wie zum Beispiel
die Änderung des Status einer Lampe von AN auf AUS, kann und muss in
sämtlichen multimodalen Sessions bearbeitet werden, die diese Lampe zu einem bestimmten Zeitpunkt abbilden.
7.2.3
Modalitätsadapter
Zur Kommunikation mit den angeschlossenen Modalitäten außerhalb des Frameworks dienen die so genannten Modalitätsadapter. Diese sind in der Lage,
die MMI-Lifecycle-Events über unterschiedliche Protokolle zu versenden und
zu empfangen. In Rahmen der Implementierung wird ein konkreter Modalitätsadapter umgesetzt, mit dessen Hilfe über HTTP kommuniziert wer-
7.2 Umsetzung
80
den kann. Daraus resultiert auch die Bezeichnung des Services als HTTPAdapter. Es ist ohne weiteres möglich, zusätzliche Adapterservices hinzuzufügen, um weitere Protokolle zu unterstützen. Der Interaktionsmanager integriert neu gefundene Services durch die Unterstützung der zugrunde liegenden SOA-Plattform automatisch in die Kommunikationsvorgänge. Die Verwendung von HTTP sollte im Zuge der ersten Realisierung durchaus ausreichend sein, da dieses Protokoll sehr verbreitet ist und bereits die Einbindung
vieler Geräte auf einfachem Wege erlaubt. Das Interface eines Modalitätsadapters, IModalityAdapter, stellt folgende Funktionalität zur Verfügung:
Schnittstelle
Methode
IModalityAdapter establishConnection
rearangeConnection
closeConnection
sendMMIEvent
Tab. 7.3: Schnittstellenübersicht Modalitätsadapter
Die Methode establishConnection dient dazu, Informationen über eine
Modalität, wie die aktuelle Session in der sie sich befindet, zu hinterlegen,
bzw. eine Modalität im HTTP-Adapter zu registrieren. Dies geschieht, nachdem die Modalität im System erfolgreich eingeloggt wurde. Mittels rearangeConnection wird eine eventuelle Änderung der Zugehörigkeit bearbeitet,
also der Transfer einer Modalität von einer Session in eine andere. Über
closeConnection wird mitgeteilt, dass eine bestimmte Modalität nicht mehr
aktiv ist, sei es auf Grund eines Timeouts oder durch ein Logout, und deren Informationen gelöscht werden sollen. Die eben beschriebenen Methoden
sind im Prinzip nicht für sämtliche Modalitätsadapter interessant und notwendig. Im Falle von HTTP als Kommunikationsprotokoll sind sie es aber.
Hier ist es nicht möglich, Informationen auf direktem Weg an die Clients zu
übermitteln, da HTTP ein solches Vorgehen nicht unterstützt. Ein Informationsaustausch kann jeweils nur von der Clientseite initiiert werden. Aus diesem Grund müssen vom Framework ausgehende Nachrichten in einem Puffer
zwischengespeichert werden, ehe sie im Zuge eines kontinuierlichen Pollingverfahrens vom Client abgeholt werden. Dies macht es notwendig, Informationen über die Modalitäten an den Puffer zu knüpfen um sicherzustellen,
dass sämtliche Modalitäten auch alle notwendigen Nachrichten erhalten. Die
wichtigste Funktionalität wird über sendMMIEvent bereitgestellt, nämlich
das Versenden von MMI-Lifecycle-Events. Solch ein Vorgang würde sich im
Falle dieses speziellen HTTP-Services in Form des Ablegens eines Events in
7.2 Umsetzung
81
den entsprechenden Modalitätspuffer darstellen.
7.2.4
Modalitäts- und Benutzermanager
Dieses Service dient, wie bereits erwähnt, zur Verwaltung von Benutzer- und
Modalitätsinformationen. Dementsprechende Funktionalität wird durch die
Methoden der IUserModalityManagerService-Schnittstelle bereitgestellt. Eine der wichtigsten Methoden ist hierbei attachModality, die bei einem Verbindungsaufbau mit einer neuen Modalität Verwendung findet. Hier wird auf
das Kontextservice zurückgegriffen, um den über eine bestimmte Modalität
zugreifenden Benutzer zu authentifizieren. Bei einem Erfolg werden weitere
Parameter sowohl aus den initialen Informationen beim Verbindungsaufbau
als auch aus dem Kontextservice extrahiert und ins System übermittelt. Der
Interaktionsmanager kann in weiterer Folge eine Registrierung der neuen Modalität vornehmen. Weitere Methoden wie isUser, isAdministrator oder hasRole liefern Informationen bezüglich der Benutzerrollen. Diese sind relevant
dafür, welche Anwendungen der Benutzer ausführen kann und auch, inwiefern er Rechte innerhalb bestimmter Applikationen besitzt.
Schnittstelle
Methode
IUserModalityManagerService attachModality
isUser
isAdministrator
hasRole
addNewUser
updateUser
deleteUser
getUser
registerUserListener
unregisterUserListener
savePersistent
Tab. 7.4: Schnittstellenübersicht UMM
Die übrige Funktionalität, die diese Schnittstelle anbietet, zeigt sich verantwortlich für die Benutzerverwaltung. Es können neue Benutzer angelegt
und bestehende gelöscht oder bearbeitet werden. Hier ist außerdem zu beachten, dass im Zuge der prototypischen Entwicklung kein besonderes Augenmerk auf die Sicherheitsaspekte gelegt worden ist. Zurzeit ist es nach diesem
Schema jedem Service innerhalb des Frameworks möglich, Benutzerinformationen zu ändern, was in einem Produktivsystem selbstverständlich nicht der
7.2 Umsetzung
Fall sein dürfte. Die zugrunde liegende OSGI-Plattform stellt allerdings eine
Reihe von Werkzeugen zur Verfügung, mittels derer ein ausreichendes Sicherheitskonzept umgesetzt werden kann. So könnte damit der Zugriff auf
diese administrativen Methoden eingeschränkt und nur speziellen autorisierten Services gestattet werden.
7.2.5
Applikationen
Die bisher beschriebenen Komponenten stellen von einem konzeptionellen
Gesichtspunkt her eher den statischen Teil des Frameworks dar, der sich in
Zukunft nicht ändern muss, sofern man mit der gegebenen Funktionalität
wie zum Beispiel SCXML als Dialogbeschreibungssprache oder HTTP als
Kommunikationsprotokoll zufrieden ist. Im Gegensatz dazu stehen die Applikationsservices. Diese enthalten jeweils die Funktionalität einer bestimmten
multimodalen Anwendung. Geht es also darum, das System um einen konkreten Anwendungsfall zu erweitern, geschieht dies dadurch, dass ein neues
Applikationsservice in das Framework eingebunden und dadurch eine neue
Funktionalität für den Benutzer verfügbar gemacht wird. Die Funktionalitäten aller aktiven Applikationsservices summieren sich im Endeffekt zum
kompletten Funktionsumfang des multimodalen Interaktionsframeworks. Die
Anzahl, Art und Vielfalt der im System aktuellen Applikationsservices kann,
von diesem Standpunkt aus gesehen, durchaus als dynamisch bezeichnet werden. Vor allem auch dadurch, dass die Services zur Laufzeit hinzugefügt,
geändert oder entfernt werden können.
Sämtliche Informationen, die für eine multimodale Anwendung von Belang sind, werden über die IMMIApplication-Schnittstelle bereitgestellt. Darunter fallen grundlegende Daten wie Anwendungsname oder eine Kurzbeschreibung der Funktionalität, die über die Methoden getName und getInformation bezogen werden können. Ebenso interessant ist natürlich der
Dialogtyp der Anwendung, also welche Art der Dialogbeschreibung hier Verwendung findet. Im Normalfall wird es sich dabei um SCXML-Dokumente
handeln. Mittels getDialogDescriptionSource kann eine URI zur jeweiligen
Dialogbeschreibung bezogen werden. Diese wird vom Interaktionsmanager
bei der Initiierung eines neuen Dialogservices für diese Anwendung benutzt,
um eine entsprechende Beschreibung zu akquirieren. Die Beschreibung der
Inhalte und des Aufbaus der Benutzungsschnittstellen selbst hängt von den
Modalitäten ab, die die Anwendung unterstützt. Nach dem Entwurf des
W3C können diese Inhalte entweder innerhalb eines MMI-Lifecycle-Events
direkt übermittelt werden, oder es wird lediglich eine URI mitgesendet, anhand derer die Inhalte bezogen werden können. Die erste Möglichkeit ei-
82
7.2 Umsetzung
Schnittstelle
IMMIApplication
Methode
getApplicationId
getName
getInformation
getDialogDescriptionSource
getDialogDescriptionType
receiveEvent
getAuthorizationRoles
supportsModalityShift
IMMIAdministrationApplication addContext
removeContext
addModality
removeModality
changeModalityContext
Tab. 7.5: Schnittstellenübersicht Applikationen
ner inline-Übermittlung ist vom Anwendungsstandpunkt her recht einfach,
da die MMI-Lifecycle-Events mitsamt ihrem Inhalt entweder direkt in einer Applikationsfunktion generiert werden können oder der Inhalt im Zuge
der Dialogbeschreibungsgenerierung in diese eingebettet wird. Wird im Gegensatz dazu nur eine URI übermittelt, muss jedoch sichergestellt werden,
dass die Inhalte am definierten Ort auch abrufbar sind. Wie das erfolgen
kann, hängt sehr von dem verwendeten Übertragungsverfahren ab. In der
aktuellen Umsetzung, die stark webbasiert arbeitet, läuft dieser Vorgang wie
folgt ab, Erweiterungen können in der Zukunft analog dazu erfolgen: Die Anwendungskomponenten veröffentlichen neben dem Anwendungsservice selbst
noch zusätzliche Services mit anderen Schnittstellen, über die die Inhalte
abgerufen werden können. Modalitätsadapter halten in der Serviceregistrierung Ausschau nach solchen Services und veröffentlichen anschließend den
über sie erhaltenen Inhalt für die an sie angeschlossenen Modalitäten. Im
nachfolgenden Kapitel wird dieser Vorgang anhand eines Beispiels noch etwas anschaulicher erläutert.
Über die Methode getAuthorizationRoles werden die Rollen definiert, die
autorisiert sind, diese Anwendung zu verwenden. Wie bereits erwähnt, ist
es außerdem wichtig festzustellen, ob eine Anwendung mit dem Hinzufügen
neuer Modalitäten zur Laufzeit umgehen kann. Es handelt sich hierbei meist
nicht um Trivialfälle, sondern es muss ein erhöhter Aufwand getrieben werden, um die Synchronität aller Modalitäten innerhalb einer Session sicherzu-
83
7.2 Umsetzung
stellen. Über die Methode supportsModalityShift kann nun geprüft werden,
ob die Anwendung damit umgehen kann und Events, die das Eintreten einer neuen Modalität in die Session ankündigen, bearbeitet werden. Ist dies
nicht der Fall, so darf ein Wechsel einer Modalität in eine laufende Session dieser Anwendung nicht stattfinden. Der gegenteilige Fall, also das Ausscheiden einer Modalität aus einer laufenden Session, muss allerdings von
jeder Anwendung unterstützt werden, da die Verbindung zu einer Modalität
jederzeit abbrechen kann. Insbesondere Anwendungen mit komplementären
Modalitäten müssen sich mit diesem Problem befassen und Events, die das
Ausscheiden einer Modalität ankündigen, verarbeiten.
Die zentrale Methode dieser Schnittstelle stellt aber sicherlich receiveEvent dar, mittels derer Ereignisse innerhalb eines laufenden Dialoges dieser
Anwendung empfangen und notwendige Funktionen, wie zum Beispiel das
Ansteuern von Aktoren im Smart Home, ausgeführt werden können.
Einen erwähnten Spezialfall stellen Applikationen dar, deren Funktion die
Administration der angeschlossenen Modalitäten ist. Dazu stellen diese über
eine zusätzliche Schnittstelle IMMIAdministrationApplication eine Kommunikationsmöglichkeit mit dem Interaktionsmanager zur Verfügung, um administrative Informationen empfangen zu können. Über die Methode addContext wird die Existenz einer neuen Session mitgeteilt und mit removeContext
wird über die Entfernung einer bestehenden Session berichtet. Dasselbe geschieht auf der Modalitätsseite durch addModality und removeModality. Über
eine letzte und wichtige Methode changeModalityContext wird der Wechsel
einer Modalität von einer Session in eine andere angezeigt. Mithilfe dieser
Methoden und der bereits erläuterten in der IMMIAdministrationConnector
Schnittstelle auf Interaktionsmanagerseite kann eine Anwendung die Verteilung der verfügbaren Modalitäten überwachen und auch steuern. Da es
sich hierbei ebenfalls um eine multimodale Anwendung handelt, kann diese
Steuerung vom Benutzer ausgehen oder aber auch ohne Benutzerinteraktion im Hintergrund laufen und anhand des aktuellen Smart-Home-Kontexts
agieren.
7.2.6
Modalitäten
Innerhalb des multimodalen Frameworks existiert eine Reihe von unterstützenden Services zur Generierung von MMI-Lifecycle-Events. Modalitätsadapter
kümmern sich um das Versenden und Empfangen dieser Nachrichten. Diese Funktionalität muss nun natürlich auch clientseitig verfügbar sein, wenn
sich nicht jede Anwendung selbst darum kümmern soll. Zu diesem Zweck
84
7.3 Anwendung
wurden im Laufe der vorliegenden Arbeit zwei Bibliotheken implementiert,
welche die clientseitige Kommunikation über das HTTP-Protokoll, das Polling und die MMI-Lifecycle-Event-Generierung vereinfachen. Es handelt sich
hierbei zum einen um eine JavaScript-Bibliothek für webbasierte Clientsysteme, die im Besonderen für die verbreiteten Browser Internet Explorer, Firefox und Opera optimiert wurde und lediglich in den HTML-Code inkludiert
werden muss. Der Empfang von MMI-Lifecycle-Events kann von Scripts innerhalb der HTML-Seiten anschließend über eine definierte Funktion stattfinden. Framework-spezifische Aufgaben, wie zum Beispiel das Senden von
keep-alive-Nachrichten, laufen im Hintergrund automatisch ab und bedürfen
keiner weiteren Aufmerksamkeit von Seiten der Entwickler. Zum anderen
wurde eine entsprechende Funktionalität auch als Java-Bibliothek umgesetzt,
die von Java-Anwendungen genutzt werden kann, um mit dem multimodalen
Framework zu kommunizieren.
7.3
Anwendung
Die Aufgabenstellung dieser Arbeit umfasst aber nicht nur die Erstellung
eines multimodalen Frameworks, sondern fordert ebenso die Sicherstellung
einer grundlegenden Funktionalität, um mit dem Smart Home und allen enthaltenen Komponenten interagieren zu können. Zu diesem Zweck wurde eine
Reihe von Szenarios definiert und umgesetzt, die in der Folge kurz beschrieben werden. Ein weiterer Vorteil bei der Umsetzung solcher Szenarien durch
multimodale Applikationen ist überdies die Verifizierung der Anwendbarkeit
des Frameworks selbst.
Zum Einen geht es nun also darum, das Smart Home und die darin
befindlichen Komponenten zu steuern bzw. deren aktuellen Status abfragen zu können. Zu diesem Zweck befasst sich eine Applikation damit, diese
Steuerung über mehrere unterschiedliche Geräte und Modalitäten hinweg
zu ermöglichen. Auf der visuellen Seite werden browserbasierte graphische
Schnittstellen angeboten, die sich in Abhängigkeit der Geräteeigenschaften
wie beispielsweise der Bildschirmgröße anpassen. Eine Unterteilung ist in zwei
Kategorien vorgesehen: in mobile Geräte auf der einen und Standgeräte auf
der anderen Seite. Diese erhalten jeweils eine unterschiedliche Schnittstellenbeschreibung. Erstere visualisieren die Informationen mittels einer einfacheren und graphisch weniger aufwändigen Listenansicht der Räume, der
darin befindlichen Geräte sowie deren aktuellen Status. Letztere stellen den
Zustand des Smart Homes auf einem Grundriss dar, einer graphischen Wiederspiegelung des Hausgrundrisses, in dem die Geräte mittels entsprechender
Symbole repräsentiert sind. Auf der sprachlichen Seite wird die beschriebene
85
7.3 Anwendung
Shinx-4-Technologie zur Spracheingabe und -erkennung, sowie FreeTTS zur
Sprachausgabe verwendet, um Informationen während des Navigierens durch
die Anwendung auszugeben.
Zum Anderen darf auch der wichtige Punkt des Administrierens des
Smart Homes nicht aus den Augen gelassen werden. Es muss eine Möglichkeit der Benutzerverwaltung gegeben sein. Benutzer müssen neu angelegt,
gelöscht und bearbeitet werden können. Darüber hinaus soll es auch möglich
sein, benutzerspezifisch Rollen zu vergeben, um deren Status und Verantwortlichkeiten festlegen zu können. Andere Applikationen können anschließend
über den Benutzer und Modalitätsmanager auf diese Rollen Zugriff nehmen
und ihre angebotenen Funktionen auf dieser Grundlage anpassen.
Um eine Steuerung der Komponenten überhaupt erst durchführen zu
können, müssen diese zuallererst natürlich konfiguriert werden. Dem System
muss bekannt sein, das es sich bei Gerät A zum Beispiel um eine dimmbare
Lampe handelt, die sich innerhalb des Wohnzimmers befindet. Solche Informationen werden neben anderen im Smart Home Kontext verwaltet und
müssen über den Kontextmanager bekanntgemacht werden. Die Administrierung selbst funktioniert ebenfalls auf Basis eines Grundrisses, auf dem zu
Beginn sämtliche Orte innerhalb des Smart Homes definiert werden können.
Neben der Ortsbezeichnung werden auch deren Umrisse auf dem Grundriss
angegeben. Auf diese Weise gelangt man am Ende zu einem kompletten Schema, das zeigt, welche Bereiche des Grundrisses welchen Ort des Smart Homes
spezifizieren. Weiters werden sämtliche noch nicht konfigurierten Komponenten aufgelistet und können auf dem Grundriss positioniert werden.
Eine weitere implementierte Anwendung wurde bereits einige Male im
Zuge der Arbeit erwähnt. Es handelt sich hierbei um diejenige, mit deren
Hilfe die bestehenden Sessions und angebundenen Modalitäten verwaltet werden können und die bislang als MMI-Administrations-Applikation bezeichnet
wurde. Auch diese ist wie alle anderen im Grunde eine multimodale Anwendung, mit einer in diese Richtung erweiterten Funktionalität.
Zur Implementierung dieser Applikationen sei noch zu sagen, dass im administrativen Bereich der multimodale Faktor eher im Hintergrund stand.
So ist die Konfiguration der Smart-Home-Komponenten nur graphisch auf
einem Standgerät möglich. Dies aus dem einfachen Grund, weil die administrativen Tätigkeiten zwar äußerst wichtig sind, aber nicht so häufig ausgeführt werden müssen. Außerdem ist eine Konfiguration auch sehr mühsam,
wenn sie beispielsweise auf einem mobilen Endgerät mit beschränkten In-
86
7.3 Anwendung
teraktionsmöglichkeiten, wie einem kleinen Bildschirm, durchgeführt werden
soll. Anders bei den Applikationen, die tagtäglich und zur Steuerung des
Smart Homes verwendet werden. Hier kann eine mögliche Multimodalität
große Vorteile bringen, weshalb auch bei der Umsetzung der Steuerungsanwendung großer Wert auf die Einbindung mehrerer Modalitäten gelegt wurde.
Ausgehend von den Umsetzungen dieser Anwendungen soll nun in der
Folge die Herangehensweise beim Entwickeln von multimodalen Applikationen auf Basis dieses Frameworks erläutert werden. Im Konkreten wird dies
anhand des Beispiels der Steuerungsanwendung geschehen, da es sich hier
um diejenige handelt, welche den größten Fokus auf die Einbindung unterschiedlicher Modalitäten legt.
7.3.1
Dialogbeschreibung
Der erste Schritt bei der Erstellung einer multimodalen Applikation umfasst
die Erstellung einer Dialogbeschreibung, welche das vorgesehene Szenario in
ausreichender Weise beschreibt. Zum aktuellen Zeitpunkt wird es sich dabei
um ein SCXML-Dokument handeln, dessen URI dem Interaktionsmanager
über die definierte Schnittstelle bekanntgemacht wird und die dieser heranzieht, um ein neues Dialogservice zu initialisieren, sollte diese Anwendung
innerhalb einer Session gestartet werden. Hier sei nochmals verdeutlicht, dass
es sich dabei nur um die Beschreibung des Dialoges handelt. Die Ausführung
geschieht in den Dialogservices für die unterschiedlichen Sessions, was bedeutet, dass eine Anwendung zur gleichen Zeit durchaus parallel innerhalb
mehrerer Sessions aktiv sein kann.
In Abbildung 7.4 ist das Zustandsdiagramm zu sehen, welches den Dialog
für die Steuerungsanwendung widerspiegelt, allerdings zur Veranschaulichung
auf einer etwas einfacheren Ebene. Der grundlegende Ablauf ist darauf ersichtlich und soll im Nachfolgenden erläutert werden.
Der Start der Anwendung ist geprägt durch Initialisierungsvorgänge. Hier
geht es vor allem darum, den zugehörigen Modalitäten den Beginn einer
neuen Anwendung mitzuteilen. Es werden also diverse StartRequest-MMILifecycle-Events gesendet, welche ihrerseits Informationen über den Schnittstellenaufbau beinhalten oder zumindest auf entsprechende Dokumente verweisen. Auf diese Weise wird sichergestellt, dass die entsprechenden Modalitäten auf dem neuesten Stand sind und nachfolgende Events auch entsprechend verarbeiten können. Bei dieser konkreten Anwendung werden drei unterschiedliche StartRequest-Events generiert und gesendet. Eines initialisiert
87
7.3 Anwendung
Abb. 7.4: Zustandsdiagramm der Beispielapplikation
die grafischen Modalitäten auf mobilen Endgeräten, ein zweites diejenigen
von Standgeräten und das dritte ist schließlich an sprachliche Modalitäten
gerichtet.
Im Anschluss an diese Initialisierungsphase werden nun zwei parallele
Abläufe angestoßen, der Zustandsautomat befindet sich also zu einem Zeitpunkt in zwei verschiedenen Zuständen. Einerseits wird auf Meldungen gewartet, welche vom Applikationsservice generiert werden. Ändert sich beispielsweise der Zustand eines Gerätes im Smart Home, wird das Anwendungsservice davon in Kenntnis gesetzt und übermittelt diese Information nun an
alle aktiven Dialogservices, die gerade unter dieser Applikation laufen. Wird
die Meldung dort empfangen, erfolgt eine entsprechende Bearbeitung. Im
Normalfall handelt es sich dabei um die Generierung und Versendung von
MMI-Lifecycle-Events, die den Modalitäten über die Statusänderung berichten. Die Verarbeitung dieser Information innerhalb der Modalitäten erfolgt
unterschiedlich und ist für das Framework selbst aufgrund des black-boxParadigmas irrelevant. Ist die Bearbeitung beendet, geht der Automat wieder
auf den Wartezustand zurück und ist bereit für den Empfang der nächsten
Applikationsnachricht.
88
7.3 Anwendung
Auf der anderen Seite wird der aktuelle Zustand der Anwendung festgehalten. Nach der Initialisierung und beim Start wurde noch keinerlei Auswahl
von der Benutzerseite her getroffen, was sich im Startzustand widerspiegelt.
Interagiert der Benutzer nun über eine der angeschlossenen Modalitäten, so
wird seine Aktion mittels eines MMI-Lifecycle-Events übermittelt und der
Automat geht in einen entsprechenden anderen Zustand über. Im konkreten
Fall wählt der Benutzer also entweder einen Ort oder ein Gerät aus und es erfolgt ein Zustandsübergang nach Ort ausgewählt bzw. nach Gerät ausgewählt.
Innerhalb dieser Zustände erfolgt wiederum eine Abfolge von Tätigkeiten. Es
werden Events an alle Modalitäten gesendet, um diese Änderung zu publizieren. Die Modalitäten verarbeiten diese Information und aktualisieren ihre
Anzeige. Im Grundriss würde bei einer Ortsauswahl der aktuelle Ort beispielsweise hervorgehoben, sprachliche Modalitäten würden diese Änderung
durch eine Sprachausgabe kundtun. Zwischen diesen drei Zuständen kann
beliebig hin und her gewechselt werden. Kommt es nun zu einer Eingabe, die
die Statusänderung einer Komponente zum Ziel hat, so wird dies im Zustand
Gerätestatus ändern behandelt. Hier werden Nachrichten an das Applikationsservice gesendet, die dort die entsprechenden Vorgänge auslösen. Zu beachten ist hier im Besonderen, dass zu diesem Zeitpunkt keine Informationen
an die anderen Modalitäten gesendet werden, sondern nur eine Kommunikation mit dem Backend vorliegt. Wenn die entsprechenden Aktionen vom
Applikationsservice ausgeführt worden sind, so sendet es eine Nachricht an
das Dialogservice, welches diese, wie bereits erwähnt, bearbeitet. Erst dort
werden Informationen an die Modalitäten ausgesendet. Die Vorgehensweise
ist vor allem deshalb notwendig, weil ja mehrere Dialogservices zu einer Applikation in mehreren Sessions zeitgleich laufen können. Auf diese Weise wird
sichergestellt, dass eine Änderung des Systems, die in einer Session angestoßen wurde, auch an alle übrigen Sessions und deren Modalitäten übermittelt
wird.
Wird zu einem beliebigen Zeitpunkt ein MMI-Lifecycle-Event empfangen,
in welchem das Ende der Anwendung gefordert wird, so geht der Automat
einfach in den Endzustand über. Es ist hier nicht notwendig, weitere Informationen an die Modalitäten oder an das Applikationsservice zu übermitteln.
Durch das Beenden des Automaten erkennt das Framework selbstständig das
Ende der Anwendung innerhalb der Session, stoppt das beendete Dialogservice und generiert ein neues, welches die Standardanwendung beinhaltet, die
läuft, solange keine andere Anwendung aktiv ist. Durch den Start dieser Anwendung werden wiederum Events an alle betreffenden Modalitäten gesendet
und deren Status wird dadurch automatisch aktualisiert.
89
7.3 Anwendung
7.3.2
Schnittstellenbeschreibungen
In der Initialisierungsphase werden also Schnittstellenbeschreibungen an die
angebundenen Modalitäten gesendet. Es handelt sich dabei um Dokumente
unterschiedlichen Typs, die innerhalb des Applikationsservices generiert werden. Hier können alle möglichen Auszeichnungssprachen Verwendung finden.
Auf der visuellen Seite wird in der konkreten Umsetzung HTML verwendet,
welches dynamisch aus JSP generiert wird. Zur Anbindung an das Framework existiert die erwähnte JavaScript-Bibliothek, die einfach in die HTMLBeschreibung eingebunden werden kann. Der Audiobereich wird durch eine
relativ unkomplizierte Beschreibung des darzustellenden Inhaltes abgedeckt,
in der die auszugebenden Sätze als Texte annotiert und die möglichen Benutzereingaben darauf mittels JSGF-Grammatiken [55] definiert werden. Die
Modalitäten geben bei der Registrierung im System diejenigen Dokumenttypen bekannt, die von ihnen unterstützt werden. Mittels dieser Information
entscheidet der Interaktionsmanager, welche MMI-Lifecycle-Events an welche Modalitäten gesendet werden sollen. Innerhalb der Applikation bzw. in
der Dialogbeschreibung wird bei der Eventgenerierung lediglich der entsprechende Typ angegeben. Ist ein Event für alle Typen zulässig, so wird einfach
kein Typ spezifiziert.
Die Übermittlung der UI-Beschreibungen kann direkt innerhalb der MMILifecycle-Events im Datenbereich erfolgen. In diesem Fall muss der Inhalt
lediglich generiert und in den Nachrichten verpackt werden. Der zweite Fall
stellt sich etwas aufwändiger dar. Hier wird lediglich eine URI an die Modalitäten versendet, anhand derer die Inhalte zuerst bezogen werden müssen.
Das setzt natürlich voraus, dass diese unter der angegebenen URI auch hinterlegt wurden. Das Verfahren hierzu erklärt sich wie folgt: Neben dem Applikationsservice selbst registriert die Applikationskomponente noch weitere
Services in der Service Registry, über deren Schnittstellen typbezogen Inhalte in unterschiedlichen Auszeichnungssprachen akquiriert werden können.
Die entsprechenden Modalitätsadapter suchen in der Service Registry nach
solchen Services und veröffentlichen deren Inhalte unter der spezifizierten
URI. Im konkreten Fall registriert die Applikationskomponente also Services
unter den Schnittstellen IMMIJSPApplication und IMMIServletApplication.
Ersteres Service ermöglicht es dem Modalitätsadapter, über die Methode getResourcePath die zu veröffentlichenden Dokumente zu finden, bei denen es
sich in diesem Fall um JSP-Dateien handelt, und über getBeans auch die
dazu notwendigen Java-Beans zu beziehen. Damit können nun die visuellen Modalitäten über die angegebene URI auf die Inhalte Zugriff nehmen.
Das zweite Service dient zur Bereitstellung von Servlets, die über die Metho-
90
7.3 Anwendung
de getApplicationServlets vom Modalitätsadapter bezogen und veröffentlicht
werden. Auf diesem Wege beziehen in der Folge die sprachlichen Modalitäten
ihre Inhaltsbeschreibungen. Einer Erweiterung dieser Serviceklassen, um Inhalte vielfältiger publizierbar zu machen, steht hier nichts im Wege.
Der Nachteil, der sich im UI-Bereich offenbart, wurde bereits früher in
der Arbeit erwähnt. Es müssen für jeden unterstützten Modalitätstyp unterschiedliche Beschreibungen generiert werden, was durch die Verwendung
generischer UI-Beschreibungssprachen wie UIML, XIML, USIXml oder ähnliche sicherlich verbessert werden kann. Für den ersten Prototyp ist dies
allerdings noch nicht notwendig, eine Erweiterung ist jedoch möglich, führt
man sich das eben erläuterte Konzept vor Augen. Ein zusätzliches Rendering
Service könnte beispielsweise nach Applikationsservices Ausschau halten, die
solche generischen UI Beschreibungen publizieren. Diese könnten anschließend in die unterschiedlichsten Formate umgewandelt und auf demselben
Wege, wie es zur Zeit die Applikationskomponenten durchführen, den Modalitätsadaptern wieder zur Verfügung gestellt werden. Natürlich kann diese
Konvertierung auch in den Modalitätsadaptern selber geschehen. Es sind also
sicherlich mehrere Wege dazu denk- und umsetzbar.
7.3.3
Applikationslogik
Im Zuge der Dialogführung einer multimodalen Anwendung kommt es selbstverständlich zu Einflussnahmen auf die Komponenten innerhalb des Smart
Homes. Umgekehrt kann sich eine Änderung des Smart-Home-Kontexts auf
laufende Applikationen auswirken. Als einfaches Beispiel sei hier das Einschalten einer Lampe genannt. Über eine Benutzungsschnittstelle wird ein
diesbezüglicher Wunsch empfangen und im Dialogservice bearbeitet. Dieses
sendet eine Nachricht an das Anwendungsservice und stößt dadurch Funktionen an, die das Einschalten der Lampe als Ergebnis haben. Nachdem sich
der Status der Lampe und somit der Kontext geändert hat, wird wiederum
das Anwendungsservice darüber in Kenntnis gesetzt. Dieses reagiert darauf
entsprechend und sendet ein Aktualisierungsevent an die laufenden Dialoge,
die daraufhin alle angeschlossenen Modalitäten benachrichtigen.
Die dazu notwendigen Abläufe innerhalb des Anwendungsservices müssen
selbstverständlich definiert und implementiert werden. Die Applikationslogik
stellt sozusagen das Bindeglied zwischen dem multimodalen Framework und
der darunterliegenden Smart-Home-Plattform dar.
91
7.3 Anwendung
7.3.4
Exemplarischer Ablauf
Nachfolgend soll nun anhand eines konkreten Beispiels der genaue Ablauf im
Zuge einer multimodalen Sitzung geschildert werden. Der zugrunde liegende Anwendungsfall bildet hierzu folgende Aktionen ab: Es erfolgt zu Beginn
ein Login über eine graphische Modalität A, welche darauf hin sämtliche zur
Verfügung stehenden Applikationen aufzeigt. Über das Navigationsmenü erfolgt der Wechsel hin zur Modalitätsübersicht, auf der zu diesem Zeitpunkt
lediglich diese eine aktive Modalität gelistet wird. Nun registriert sich eine
weitere, diesmal jedoch sprachliche, Modalität B am System. Dieser Vorgang
ist über Modalität A nachvollziehbar, da in diesem Augenblick die Darstellung erweitert und die Liste um B ergänzt wird. Mittels einer, in der Folge
über Modalität A gestarteten Anwendung zur Grundrissübersicht, kann nun
eine Lampe innerhalb des Smart Homes eingeschaltet werden. Eine solche Aktivität hat zu dem Zeitpunkt keine Auswirkung auf Modalität B, da dort noch
keine Applikation gestartet wurde und dementsprechend keine Aktualisierungen nötig sind bzw. durchgeführt werden. Nach Beenden der Anwendung zur
Grundrissübersicht erfolgt wiederum die Navigation zur Modalitätsübersicht,
wo nun die beiden aktiven Modalitäten verbunden und in eine gemeinsame
Gruppe verschoben werden. Ein erneuter Start der Grundriss-Übersicht zeigt
nun deutlich, dass beide Modalitäten aktiv und synchron laufen, visueller
Output über die graphische Oberfläche von A und akustische Ausgaben über
die sprachliche Modalität B übermittelt werden. Um die zuvor eingeschaltete Lampe wieder auszuschalten, wird sie graphisch über A selektiert und
sprachlich über B deaktiviert.
Nach der Navigation auf die Anmeldeseite des Frameworks mittels eines
Browsers erfolgt die Eingabe der Benutzerdaten. Nach der Eingabe werden
diese innerhalb eines, in Abbildung 7.5 dargestellten, MMI-Lifecycle-Events
(Zeile 6-9)verpackt und zusätzlich mit weiteren modalitätsbezogenen Informationen (Zeile 10-17) an den, im Framework befindlichen, Interaktionsmanager versendet.
Über den Interaktionsmanager wird nach Empfang dieses Events der
UserModalityManagerService bemüht, um den neuen Benutzer zu authentifizieren. Im Erfolgsfall wird ein neuer Kontext für diese Modalität generiert,
darin modalitätsspezifische Informationen hinterlegt und die grundsätzliche
Administrationsanwendung gestartet. Mit dem Retournieren des zugehörigen NewContextResponse-Events (Abbildung 7.6) wird die Modalität über
ihre Identifikation (Zeile 2, target-Attibut) sowie den zugeordneten Kontext
(Zeile 3, context-Attribut) informiert und der Login-Vorgang beendet.
92
7.3 Anwendung
93
Abb. 7.5: Initiales NewContextRequest-Event
Im Zuge des Startens der Administrationsanwendung werden StartRequest-Events an alle existierenden Modalitäten innerhalb des entsprechenden
Kontextes gesendet. Konkret befindet sich natürlich nur die eben registrierte
Modalität innerhalb dieses Kontextes. Das an sie gerichtete MMI-LifecycleEvent ist in Abbildung 7.7 zu sehen. Welcher Inhalt übermittelt (Zeile 3,
mmi:contentURL Bereich) wird, hängt von den spezifizierten Parametern
der Applikation ab. In diesem Fall muss der Medientyp übereinstimmen und
eine entsprechende Bildschirmauflösung zugrunde liegen.
Abb. 7.6: NewContextResponse-Event
Abb. 7.7: StartRequest-Event der Administrationsanwendung
7.3 Anwendung
Mit dem Empfang dieses Events beginnt die Modalität damit, den übermittelten Inhalt darzustellen und auf Benutzereingaben bzw. weitere MMILifecycle-Events zu warten. Im vorliegenden Anwendungsfall findet nun ein
Wechsel auf die Modalitätsübersicht statt. Dieser erfolgt durch eine benutzerseitige Eingabe, worauf hin ein applikationsinternes ExtensionNotification-Event, wie in Abbildung 7.8, generiert und übertragen wird. In diesem
Fall reicht zur Identifizierung des Events der Bezeicher innerhalb des NameTags aus (Zeile 3). Serverseitig geschieht der Zustandsübergang im SCXMLAutomaten der zugehörigen Applikation, der in der Folge wieder die Aussendung von ExtensionNotification-Events an die Modalitäten triggert, um
diese über den Wechsel der Ansicht in Kenntnis zu setzen. In der nun dargestellten Übersicht ist zur Zeit natürlich nur eine aktive Modalität abgebildet. Registriert sich nun die zweite, sprachgesteuerte Modalität B, so wird
diese Änderung ebenfalls durch ExtensionNotification-Events publiziert und
die Darstellung an den angeschlossenen Modalitäten angepasst. Ein Wechsel
zurück zur Anwendungsübersicht erfolgt analog zur vorhergehenden Beschreibung.
Abb. 7.8: ExtensionNotification-Event zum Wechsel zur Modalitätsübersicht
Im nächsten Schritt startet die Anwendung zur Grundrissübersicht. Hier
wird wiederum ein ExtensionNotification-Event generiert, welches am Server den Anwendungswechsel auslöst. Dazu wird ein neuer SCXML-Automat
instanziert, welchem die SCXML-Beschreibung der Anwendung zur Grundrissübersicht zu Grunde liegt. Durch dessen Start werden wie schon bei der
Administrationsapplikation StartRequest-Events ausgesendet, welche die angebundenen Modalitäten innerhalb des Kontextes aktualisieren. Dieser initiale Zustand ist in Abbildung 7.9 zu ersehen. In den Zeilen 8-16 wird ein
MMI-Lifecycle-Event zur Initialisierung aller mobilen Geräte generiert (Zeile
10-12) und versendet (Zeile 13). Die Zeilen 18-26 sowie 28-35 erledigen die
selbe Aufgabe für normale bzw. sprachgesteuerte Modalitäten.
Auf dem nun dargestellten Grundriss kann die Lampe selektiert und aktiviert werden, was wiederum über anwendungsinterne ExtensionNotification-Events mit dem Server synchronisiert wird. An diesem Punkt sei die Verwendung vom EMMA-Beschreibungen erwähnt, welche verwendet werden um
solche Benutzereingaben semantisch zu erfassen. Das gesamte MMI-Lifecycle-
94
7.3 Anwendung
Abb. 7.9: Startzustand des SCXML Automaten der Grundrissübersicht
Event zur Lampenselektion ist in Abbildung 7.10 ersichtlich. Die Zeilen 6 bis
12 umfassen den EMMA-Bereich, in dem sich Informationen des ausgewählten Aktors befinden (Zeile 8,9). Der Schaltvorgang selbst wird serverseitig
über die API der Arbeit von Felsing [15] durchgeführt. Die zweite Modalität
empfängt in dieser Zeit kein MMI-Lifecycle-Event, da sie sich in einem anderen Kontext als Modalität A befindet und keine Anwendung läuft, welche
auf Aktorzustände Einfluss nehmen könnte.
Bei Beenden der Anwendung geht der zugehörige SCXML-Automat in
den Endzustand über. Der Interaktionsmanager erkennt dies und startet
in der Folge einen neuen SCXML-Service, welcher die Standardanwendung
beinhaltet. Über die dadurch erzeugten StartRequest-Events wird auch Mo-
95
7.3 Anwendung
Abb. 7.10: ExtensionNotification-Event zur Lampenselektion inklusive
EMMA-Beschreibungen
dalität A auf den neusten Stand gebracht. Anschließend erfolgt in der Modalitätsübersicht eine Zusammenführung der beiden am System registrierten
Modalitäten A und B in die selbe Gruppe bzw. den selben Kontext. Hierzu findet die, in der Schnittstelle zwischen Administrationsanwendung und
Interaktionsmanager definierte, Methode moveModality Verwendung. Diese
triggert den frameworkinternen Vorgang der Neuzuteilung von Modalität B
in die Gruppe der Modalität A. Wie bereits erwähnt, ist dieser Vorgang nicht
immer möglich. Die in der Zielgruppe laufende Anwendung muss diesen Modalitätswechsel auch unterstützen. Im Falle der gerade laufenden Standardanwendung ist dies der Fall. Der Beitritt einer neuen Modalität ist hier
insofern geregelt, als das nach dem Eintritt des Neuzuganges die Ansicht
auf die Anwendungsübersicht zurückgesetzt wird, und alle Modalitäten, also
auch die Neue, mit StartRequest-Events bedacht werden.
Beide Modalitäten laufen zu diesem Zeitpunkt synchron. Events, die durch
Benutzereingaben ausgelöst werden, werden wie bereits gezeigt an das Framework versendet. Die dort angestoßenen Vorgänge können wiederum Events
auslösen, die die Darstellung in allen beiden Modalitäten aktualisieren. Erfolgt nun ein erneuter Start der Anwendung zur Grundrissübersicht, so wird
die visuelle Darstellung durch Audiokommentare ergänzt und Spracheingaben zur Steuerung sind möglich. Selbstverständlich gestalten sich die ausgetauschten Nachrichten je nach Inhaltstyp der Zielmodalität anders. Die
graphische Modalität A wird nicht die selben Nachrichten empfangen wie
die sprachliche Modalität B. In der aktuellen Umsetzung der Anwendung
zur Grundrissübersicht werden auf graphischer Ebene Zustandsänderungen
mittels ExtensionNotification-Events übermittelt. Sprachliche Modalitäten
96
7.3 Anwendung
erhalten im Gegensatz dazu bei jeder Änderung ein StartRequest-Event mit
den entsprechenden Inhalten. Erstere halten also einen Status aufrecht, welcher durch neue Events aktualisiert wird, wohingegen Letztere immer von
Neuem initialisiert werden. Dies stellt natürlich nur eine mögliche Umsetzungsvariante dar, weitere sind vorstellbar.
Als finalen Schritt innerhalb des definierten exemplarischen Ablaufes folgt
nun noch die Selektion der Lampe über Modalität A, was über ein ExtensionNotification-Event übertragen wird sowie das Ausschalten der Lampe,
was durch die Verwendung der StartRequests im Sprachbereich mittels des
zugehörigen DoneNotification-Events an das Framework kommuniziert wird.
97
8
Diskussion
In der vorliegenden Arbeit wurde ein Framework konzipiert und in der Folge
auch implementiert, mit dem multimodale Applikationen zum Zwecke wissenschaftlicher Forschungsarbeit erstellt werden können. Nach der Definition
der Anforderungen an das System wurde eine Reihe von bestehenden Frameworks und Projekten mit ähnlicher Zielsetzung gesucht und begutachtet.
Die daraus gewonnenen Erkenntnisse waren bei der anschließenden Konzeptionierung von zentraler Bedeutung. Die Entscheidung, den Vorschlag des
W3C als Grundlage zu nehmen, erwies sich als durchaus zielführend. Da bei
dem Vergleich der bestehenden Projekte auch gewisse Ähnlichkeiten in den
jeweils verwendeten Konzepten zu erkennen war und diese ebenfalls im W3C
Entwurf grob abgebildet wurden, ergab sich dadurch eine solide Basis für das
der vorliegenden Arbeit zugrundeliegende Konzept.
Im Verlauf der Implementierung wurde ebenfalls die Anwendbarkeit der
zugrunde liegenden Plattform von [15] getestet und die Steuerung der SmartHome-Komponenten sowie der Zugriff auf den Smart-Home-Kontext als ausreichend empfunden. Im Zuge der Implementierung, speziell der multimodalen Applikationen zeigte sich, dass anhand der bereitgestellten Schnittstellen
sämtliche notwendigen Tätigkeiten ausgeführt werden konnten.
Dank der Verwendung von OSGI als serviceorientierte Basis für die Implementierung wurde eine ausreichend hohe Flexibilität des Frameworks sichergestellt, was insbesondere im Hinblick auf den wissenschaftlichen Anwendungsbereich des Frameworks eine große Rolle spielt. Die Nachteile, die durch
diese Lösung erkauft wurden, wirken sich im Gegenzug dazu nicht bzw. nur
in sehr geringem Maße aus. Es muss gesagt werden, dass es sich bei der hier
implementierten Lösung um ein zentrales System handelt. Sowohl was die
99
Steuerung der Smart-Home-Komponenten als auch die Verwaltung der angebundenen Geräte und Modalitäten zur Benutzerinteraktion betrifft. Kommt
es zu einer Störung dieses Systems, so ist man unter Umständen nicht mehr
in der Lage, auf seine Umgebung Einfluss zu nehmen und beispielsweise Lichter ein- und auszuschalten. Sollte das System in der Zukunft produktiv in
einem Zuhause eingesetzt werden, so muss man sich zuvor Gedanken über
die Ausfallsicherheit und eine Verteilung bzw. Redundanz innerhalb des Systems machen. OSGI bietet hier gewiss auch Lösungsmöglichkeiten an, auf
die man in solch einem Fall zurückgreifen könnte. Im Bereich von wissenschaftlichen Forschungsprojekten, wie beispielsweise Usabilitystudien diverse
multimodale UI´s betreffend, ist es allerdings vorteilhafter, ein einfaches und
leicht erweiter- und veränderbares System zur Verfügung zu haben, um rasch
neue Prototypanwendungen realisieren zu können.
Während der Umsetzung der unterschiedlichen multimodalen Anwendungen gab es allerdings auch Anlass zur Kritik genau diesen Punkt betreffend.
Die Verwendung von SCXML als Beschreibungssprache zur Abbildung der
Abläufe innerhalb der Applikation führt zwar zu einer großen Flexibilität, die
sich allerdings durch eine fehlende Werkzeugunterstützung schwierig handhaben lässt. Es gibt zur Zeit fast keine Programme, mit denen SCXMLBeschreibungen auf einfache Art und Weise, vielleicht grafisch, erstellt werden können. Es ist lediglich ein Plugin für den Rational Software Architect verfügbar, das UML-Diagramme in eine SCXML-Darstellung exportieren kann. Eine andere Möglichkeit wäre es, UML-Zustandsdiagramme mittels
XSLT in SCXML-Dokumente überzuführen. Diese Lösungen sind allerdings
nicht wirklich umfassend oder zufriedenstellend und in dieser Hinsicht gibt es
sicher noch einen Entwicklungsbedarf. Die in der vorliegenden Arbeit verwendeten SCXML-Dokumente wurden mit einem Texteditor erstellt, was insbesondere bei umfangreicheren Anwendungen bald zu einem Problem werden
könnte.
In den vorhergehenden Kapiteln wurde an einigen Stellen darauf hingewiesen, dass für die Beschreibung der einzelnen Schnittstellen jeweils eigene dafür geeignete Beschreibungssprachen zum Einsatz kommen. Auch
wurden Möglichkeiten dargelegt, durch die Verwendung von universellen UIBeschreibungssprachen wie z.B. XIML [49] oder UIML [52] eine Vereinfachung bei der Implementierung multimodaler Anwendungen zu erzielen. Dies
geschah allerdings nur auf theroetischer Ebene, die Umsetzung im Rahmen
der vorliegenden Arbeit stützte sich dennoch auf verbreitete Sprachen für
spezielle UI-Bereiche wie XHTML oder VXML. Ein Grund hierfür war die
einfachere Umsetzung des Frameworks, um den Aufwand der Implementie-
100
rung im Rahmen einer Diplomarbeit zu halten, wobei eine Erweiterung in
der Zukunft durchaus angedacht wurde. Ein weiterer Grund hierfür waren
allerdings auch die Problematiken, die solche generischen Schnittstellen mit
sich bringen. Durch die automatische Generierung vieler UI´s aus einer Beschreibung heraus verliert man zum Teil die Kontrolle über das Aussehen
der finalen Schnittstellen. Projekte, die sich damit befassen, versuchen diese
Probleme auf unterschiedliche Weise zu lösen. Im MONA [4] Projekt arbeitet
man ja beispielsweise mit einem entsprechenden Editor, der das Aussehen der
UI´s in Echtzeit berechnet und darstellt. Eine zufrieden stellende endgültige
Lösung ist hier allerdings noch nicht zu sehen, was entsprechende Forschungsarbeit in diesem Bereich notwendig macht.
Ein sehr großer Vorteil des implementierten Frameworks ist in der Plattformunabhängigkeit zu sehen. Durch die Verwendung von Java als Grundlage ist man an keine konkrete Plattform gebunden. Da sämtlicher Datenaustausch zwischen diesem Java-basiertem Framework und den Modalitätskomponenten mittels eines XML-basierten Nachrichtenformates geschieht,
ergeben sich überdies noch weitere Freiheiten bei der Umsetzung der Modalitätskomponenten. So müssen diese nicht ebenfalls in Java implementiert
werden, auch viele andere Programmiersprachen wie z.B. C++ sind ohne weiteres denkbar, solange sie nur die definierte MMI-Event-API unterstützen.
Bei der Implementierung im Zuge der vorliegenden Arbeit wurde neben Javabasierten Sprachmodalitäten wie erwähnt auch browserbasierte graphische
Modalitäten erstellt. Dadurch ergibt sich eine sehr große Vielfalt an Geräten,
die in der Lage sind, mit dem Framework zu interagieren, solange sie über
einen entsprechenden Browser verfügen, mithilfe dessen die Nachrichten des
Frameworks interpretiert werden können. Gerade in diesem Bereich gab es
zwar einige Komplikationen, da unterschiedliche Browser identische Inhalte
nicht unbedingt identisch verarbeiten. Diese wurden aber im Zuge der Implementierung einer Javascript-Bibliothek überwunden, vor Allem durch die
Beschränkung auf die verbreiteten Browser Internet Explorer, Firefox und
Opera. Durch die Verwendung all dieser Mechanismen wurde mit überschaubarem Aufwand ein großer Anwendungsbereich geschaffen.
Zusammenfassend kann gesagt werden, dass die in der Zielsetzung definierten Anforderungen an das System durch die implementierte Umsetzung
erreicht wurden. Die Interaktion mit den Smart-Home-Komponenten ist dadurch über verschiedene Modalitäten hinweg möglich. Beispielapplikationen
wurden sowohl für visuelle als auch für sprachliche Modalitäten entwickelt
und ermöglichen eine umfangreiche Einflussnahme der Bewohner auf ihre
Umgebung. Anhand des verfügbaren Kontexts können Anpassungen erfol-
101
gen, sowohl das Aussehen der Schnittstellen als auch die Administration
der Modalitäten betreffend. Die Anforderung, die im Rahmen der vorliegenden Arbeit noch nicht gänzlich erfüllt werden konnte, ist die Einfachheit
der Entwicklung neuer multimodaler Anwendungen. Dies im Hinblick auf
die fehlende Werkzeugunterstützung bei der Dialogbearbeitung und die Verwendung von schnittstellenspezifischen Beschreibungssprachen anstelle einer
generischen Variante.
9
Ausblick
Betrachtet man sich die Entwicklungen der letzten Jahre und die aktuelle Situation, wird schnell klar, dass im Smart-Home-Bereich ein großer
Handlungs- und Forschungsbedarf existiert. Die realisierbaren Möglichkeiten
vergrößern sich von Tag zu Tag, wohingegen die Bewohner dieser intelligenten Umgebungen unfähig sind, diese auch vollständig auszuschöpfen, vielmehr noch, sie durch die Funktionsvielfalt überwältigt und erdrückt werden.
Mittels der Implementierung, die im Zuge von [15] und der hier vorliegenden
Arbeit realisiert wurde, ist es möglich, auf diesem Gebiet Forschungsarbeit
zu leisten und weiterführende Studien zu betreiben, um diese Probleme zu
dämpfen und zu beseitigen. Aufgrund des Rahmens einer Diplomarbeit war es
selbstverständlich nicht möglich, in jedem Bereich zu einer gänzlich zufriedenstellenden Lösung zu gelangen. Die deshalb notwendigen Einschränkungen
wurden aber bereits zu Beginn der Arbeit formuliert und stellen gleichzeitig
weiterführende Tätigkeiten dar, welche in zukünftigen Projekten aufgegriffen
und umgesetzt werden können.
Dazu zählen sicherlich die eben erwähnten Probleme der fehlenden Werkzeugunterstützung bei der Dialogentwicklung sowie die Tatsache, dass bisher
keine generischen UI-Beschreibungen Verwendung finden. Hierzu sei auch
noch Folgendes zu sagen: Einige der erwähnten generischen Schnittstellenbeschreibungssprachen, UsiXML sei hier als Beispiel genannt, arbeiten mit
unterschiedlich abstrakten Modellen die ausgehend vom einem Aufgabenmodell über mehrere Schritte hin zu einem finalen UI und auch einer Dialogbeschreibung führen. Auch die SerCHo-MASP fußt auf solch einem Konzept.
Demgegenüber steht die manuelle Erstellung von Dialogbeschreibungen in
der der vorliegenden Arbeit zugrundeliegenden Implementierung. Eine Kombination dieser beiden Konzepte kann sich in weiterführenden Arbeiten je-
103
doch sicher als zielführend erweisen. Ausgehend von den Erkenntnissen in [67]
ist dies jedenfalls durchführbar. Die automatische Generierung von UI- und
Dialogbeschreibungen kann aus einem anfänglichem Aufgabenmodell heraus
geschehen. Die dadurch erhaltenen Dokumente können in der Folge manuell
nachbearbeitet und danach wieder auf die nächste Modellebene übergeführt
werden, wo sich dieser Vorgang wiederholt. Bei einer Erweiterung des Frameworks um generische Schnittstellenbeschreibungen ist dieser Punkt sicherlich
ebenfalls ins Auge zu fassen und verspricht interessante Ergebnisse.
Ein Augenmerk sollte des Weiteren auch auf die Prinzipien der multimodalen Fusion und Fission gelegt werden, welche in der vorliegenden Arbeit
zwar theoretisch behandelt, in der praktischen Umsetzung allerdings ausgeklammert wurden. Durch einen Ausbau des Frameworks in diese Richtung kann sicherlich eine große Erweiterung der multimodalen Interaktionsmöglichkeiten erzielt werden.
Soll das Framework in Zukunft auch in einem produktiven Umfeld erfolgreich eingesetzt werden, so muss man sich überdies noch mit den Sicherheitsaspekten auseinandersetzen. Sicherheit zum Einen im Hinblick auf potenzielle
Angriffe von außerhalb. Die aktuelle Implementierung beinhaltet wie gesagt
nur sehr rudimentäte Authentifizierungs- und Autorisierungsmechanismen,
welche relativ einfach überwunden werden können und jedenfalls verbessert
werden sollten. In diesem Zuge sollte man sich übrigens auch mit den unteren Architekturebenen befassen, da das aktuell verwendete FHZ-System zur
Gebäudesteuerung die Daten unverschlüsselt überträgt und ebenfalls einen
sehr guten Angriffspunkt darstellt. Zum Anderen geht es hier noch um die
Ausfallsicherheit des Systems. Da es sich um eine zentrale Lösung handelt,
kann eine Störung merkbare Konsequenzen nach sich ziehen, welche sich auf
die Bewohner des Smart Homes negativ auswirken können, falls sie beispielsweise nicht mehr in der Lage sind, Lichter ein oder aus zu schalten.
Den größten Bereich zukünftiger Arbeiten stellen natürlich die multimodalen Anwendungen selbst dar, welche auf Basis dieses Frameworks realisiert
werden können. Die Möglichkeiten sind hierbei sehr vielfältig. Unterschiedlichste Schnittstellenvariationen können auf unterschiedlichen Modalitäten
erzeugt und in Usabilitystudien analysiert werden, es ist möglich, verschiedene Kombinationen von Modalitäten zu erproben und zu verfeinern, diverse
Smart-Home-Szenarien können abgebildet und getestet werden etc.
104
Zusammenfassend kann gesagt werden, dass das implementierte und im
Rahmen der vorliegenden Arbeit diskutierte Framework eine Grundlage bildet, auf der Forschung im multimodalen Bereich möglich ist, und welches
sich in der Zukunft auf vielfältige Weise erweitern, verbessern und den Anforderungen anpassen lässt.
A
MMI-Lifecycle-Events
Nachfolgend findet sich eine Auflistung der MMI-Lifecxcle-Events, wie sie vom
W3C spezifiziert wurden und in der vorliegenden Arbeit Verwendung finden.
newContextRequest (Modalitätskomponenten → Interaktionsmanager):
<mmi:mmi xmlns="http://www.w3.org/2008/04/mmi-arch" version="1.0">
<mmi:newContextRequest source="someURI" requestID="request-1">
<media id="mediaID1>media1</media>
<media id="mediaID2">media2</media>
<mmi:data>
<user>
</name>
</password>
</user>
<device>
</properties>
</device>
</mmi:data>
</mmi:newContextRequest>
</mmi:mmi>
newContextResponse (Interaktionsmanager → Modalitätskomponenten):
<mmi:newContextResponse target="someURI" requestID="request-1" status="success" context="URI-1">
<media>media1</media>
<media>media2</media>
</mmi:newContextResponse>
</mmi:mmi>
prepareRequest (Interaktionsmanager → Modalitätskomponenten, URI mit Verweis auf externe Schnittstellenbeschreibung):
<mmi xmlns="http://www.w3.org/2008/04/mmi-arch" version="1.0">
<mmi:prepareRequest source="someURI" context="URI-1" requestID="request-1">
<mmi:contentURL href="someContentURI" max-age="" fetchtimeout="1s"/>
</mmi:prepareRequest>
</mmi>
106
prepareRequest(Interaktionsmanager → Modalitätskomponenten, Schnittstellenbeschreibung innerhalb des Events):
<mmi:prepareRequest source="someURI" context="URI-1" requestID="request-1" >
<mmi:content>
<vxml:vxml version="2.0">
<vxml:form>
<vxml:block>Hello World!</vxml:block>
</vxml:form>
</vxml:vxml>
</mmi:content>
</mmi:prepareRequest>
</mmi:mmi>
prepareResponse (Modalitätskomponenten → Interaktionsmanager, Erfolgsfall):
<mmi:prepareResponse source="someURI" context="someURI" requestID="request-1" status="success"/>
</mmi:mmi>
prepareResponse (Modalitätskomponenten → Interaktionsmanager, Fehlerfall):
<mmi:prepareResponse source="someURI" context="someURI" requestID="request-1" status="failure">
<mmi:statusInfo>
NotAuthorized
</mmi:statusInfo>
</mmi:prepareResponse>
</mmi:mmi>
startRequest (Interaktionsmanager → Modalitätskomponenten, URI mit Verweis
auf externe Schnittstellenbeschreibung):
<mmi:startRequest source="someURI" context="URI-1" requestID="request-1">
<mmi:contentURL href="someContentURI" max-age="" fetchtimeout="1s">
</mmi:startRequest>
</mmi>
startResponse (Modalitätskomponenten → Interaktionsmanager):
<mmi:startResponse source="someURI" context="someURI" requestID="request-1" status="failure">
<mmi:statusInfo>
NotAuthorized
</mmi:statusInfo>
</mmi:startResponse>
</mmi:mmi>
doneNotification (Modalitätskomponenten → Interaktionsmanager):
<mmi:doneNotification source="someURI" context="someURI" status="success" requestID="request-1" >
<mmi:data>
...
</mmi:data>
</mmi:doneNotification>
</mmi:mmi>
cancelRequest (Interaktionsmanager → Modalitätskomponenten):
<mmi:cancelRequest context="someURI" source="someURI" immediate="true" requestID="request-1">
</mmi:cancelRequest>
</mmi>
107
cancelResponse (Modalitätskomponenten → Interaktionsmanager):
<mmi:cancelResponse source="someURI" context="someURI" requestID="request-1" status="success"/>
</mmi:cancelResponse>
</mmi:mmi>
pauseRequest (Interaktionsmanager → Modalitätskomponenten):
<mmi:pauseRequest context="someURI" source="someURI" immediate="true" requestID="request-1"/>
</mmi>
pauseResponse (Modalitätskomponenten → Interaktionsmanager):
<mmi:cancelResponse source="someURI" context="someURI" requestID="request-1" status="success"/>
</mmi:mmi>
resumeRequest (Interaktionsmanager → Modalitätskomponenten):
<mmi:resumeRequest context="someURI" source="someURI" requestID="request-1"/>
</mmi>
resumeResponse (Modalitätskomponenten → Interaktionsmanager):
<mmi:resumelResponse source="someURI" context="someURI" requestID="request-2" status="success"/>
</mmi:mmi>
extensionNotification (Applikationsspezifisches Event, beide Richtungen sind möglich):
<mmi:extensionNotification name="appEvent" source="someURI" context="someURI" requestID="request-1" >
<applicationdata/>
</mmi:extensionNotification>
</mmi:mmi>
clearContextRequest (Interaktionsmanager → Modalitätskomponenten):
<mmi:clearContextRequest source="someURI" context="someURI" requestID="request-2"/>
</mmi:mmi>
statusRequest (Interaktionsmanager → Modalitätskomponenten):
<mmi:statusRequest requestAutomaticUpdate="true" source="someURI" requestID="request-3"/>
</mmi:mmi>
statusResponse (Modalitätskomponenten → Interaktionsmanager):
<mmi:statusResponse automaticUpdate="true" status="alive" source="someURI" requestID="request-3"/>
</mmi:mmi>
Abbildungsverzeichnis
3.1
3.2
Überblick über multimodale Interaktion. Angelehnt an Jaimes
und Sebe [22] . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Fusion mehrerer Modalitäten [36] . . . . . . . . . . . . . . . . 17
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Einfaches XHTML+Voice Dokument [65] . . . . . . . . . . . .
EMBASSI Architektur. Angelehnt an Elting et al. [13] . . . .
AMIGO-Architektur (vgl. [43]) . . . . . . . . . . . . . . . . .
AMIGO UIS Architektur (vgl. [29]) . . . . . . . . . . . . . . .
MONA-Architektur [4] . . . . . . . . . . . . . . . . . . . . . .
MASP-Modellstruktur. Angelehnt an Blumendorf et al. [8] . .
Concurrent Task Tree. Angelehnt an De Boeck et al. [11] . . .
MMI-Architektur. Angelehnt an den W3C Working Draft [58]
NewContextRequest MMI Life-Cycle-Event [58] . . . . . . . .
22
25
28
29
32
34
35
38
41
5.1
5.2
5.3
5.4
47
48
52
5.5
Stoppuhr-Diagramm (UML Annotation) [45] . . . . . . . . . .
Stoppuhr-SCXML [45] . . . . . . . . . . . . . . . . . . . . . .
UI-Generierung auf mehrere Zielplattformen [37] . . . . . . . .
UIML-Modell. Angelehnt an UIML Version 4.0: Committee
Draft [53] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel des möglichen Aufbaus eines EMMA-Dokumentes [46]
6.1
6.2
6.3
6.4
6.5
Architekturmodell . . . . . . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm - Login fehlgeschlagen . . . . . . . . . . . .
Sequenzdiagramm - Login erfolgreich . . . . . . . . . . . . . .
Sequenzdiagramm - Zuweisung einer Applikation zu einer Session
Sequenzdiagramm - Verbindungstrennung . . . . . . . . . . .
60
66
67
68
69
7.1
OSGI Schichtenmodell, angelehnt an die OSGi Service
form Core Specification [33] . . . . . . . . . . . . . . .
Sphinx-4 Architektur, angelehnt an Walker et al. [42] .
Komponenten und Schnittstellen . . . . . . . . . . . .
Zustandsdiagramm der Beispielapplikation . . . . . . .
71
74
77
88
7.2
7.3
7.4
Plat. . .
. . .
. . .
. . .
.
.
.
.
54
56
109
7.5
7.6
7.7
7.8
Initiales NewContextRequest-Event . . . . . . . . . . . . . . . 93
NewContextResponse-Event . . . . . . . . . . . . . . . . . . . 93
StartRequest-Event der Administrationsanwendung . . . . . . 93
ExtensionNotification-Event zum Wechsel zur Modalitätsübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.9 Startzustand des SCXML Automaten der Grundrissübersicht . 95
7.10 ExtensionNotification-Event zur Lampenselektion inklusive EMMABeschreibungen . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Tabellenverzeichnis
7.1
7.2
7.3
7.4
7.5
Schnittstellenübersicht
Interaktionsmanager
Dialogservices . . . .
Modalitätsadapter .
UMM . . . . . . . .
Applikationen . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
79
80
81
83
Literaturverzeichnis
[1] 1ST Amigo Project Deliverable D4.7 Intelligent User Services User Modeling and Profiling Service Software Developers Guide.
Techn. Ber., http://www.hitech-projects.com/euprojects/amigo/
deliverables/amigo_3_d4.7_final.pdf, 2008.
[2] André, E.: The Generation of Multimedia Presentations. In: R. Dale, H. M. und H. Somers (Hrsg.): A Handbook of Natural Language
Processing: techniques and applications for the processing of language as
text, S. 305–327. Marcel Dekker Inc., 2000.
[3] Augusto, J. C. und P. J. McCullagh: Ambient Intelligence: Concepts and Applications.. Comput. Sci. Inf. Syst., 4(1):1–27, 2007.
[4] Baillie, L., R. Schatz, R. Simon, H. Anegg, F. Wegscheider,
G. Niklfeld und A. Gassner: Designing Mona: User Interactions
with Multimodal Mobile Applications. HCI International 2005, 11th International Conference on Human-Computer Interaction, 2005.
[5] Balfanz, D., M. Klein, A. Schmidt und M. Santi: Partizipative
Entwicklung einer Middleware für AAL-Lösungen. GMS Medizinische
Informatik, Biometrie und Epidemiologie, 4(3), 2008.
[6] Beaudouin-Lafon, M.: Instrumental interaction: an interaction model for designing post-WIMP user interfaces. In: CHI ’00: Proceedings
of the SIGCHI conference on Human factors in computing systems, S.
446–453, New York, NY, USA, 2000. ACM.
[7] Blumendorf, M., S. Feuerstack und S. Albayrak: Multimodal
user interfaces for smart environments: the multi-access service platform. In: AVI ’08: Proceedings of the working conference on Advanced
visual interfaces, S. 478–479, New York, NY, USA, 2008. ACM.
[8] Blumendorf, M., G. Lehmann, S. Feuerstack und S. Albayrak:
Executable Models for Human-Computer Interaction. In: Proc. of DSVIS 2008 , 2008.
[9] Bolt, R. A.: “Put-that-there”: Voice and gesture at the graphics interface. In: SIGGRAPH ’80: Proceedings of the 7th annual conference on
Computer graphics and interactive techniques, S. 262–270, New York,
NY, USA, 1980. ACM.
[10] Davidoff, S., M. K. Lee, C. Yiu, J. Zimmerman und A. K. Dey:
Principles of Smart Home Control . In: Ubicomp, S. 19–34, 2006.
[11] De Boeck, J., C. Raymaekers, E. Cuppens, T. De Weyer und
K. Coninx: Task-based Abstraction of Haptic and Multisensory Applications. In: Proceedings of EuroHaptics 2004 , S. 174–181, Munchen,
DE, June 2004.
[12] Elting, C. und G. Möhler: Modeling Output in the EMBASSI Multimodal Dialog System. Multimodal Interfaces, IEEE International Conference on, 0:111, 2002.
[13] Elting, C., S. Rapp, G. Möhler und M. Strube: Architecture and
implementation of multimodal plug and play. In: ICMI ’03: Proceedings
of the 5th international conference on Multimodal interfaces, S. 93–100,
New York, NY, USA, 2003. ACM.
[14] Englert, R. und G. Glass: Architecture for Multimodal Mobile Applications. In: 20th International Symposium on Human Factors in Telecommunication, 2006.
[15] Felsing, D.: Eine erweiterbare Smart Home Plattform auf Basis des
FS20 Systems. Diplomarbeit, Alpe-Adria Universität Klagenfurt, 2009.
[16] Fisk, A. D. und W. A. Rogers: Psychology and Aging: Enhancing
the Lives of an Aging Population. Current Directions in Psychological
Science, 11:107–110(4), June 2002.
[17] Foster, M. E.: State of the art review: multimodal fission. Techn.
Ber., Public deliverable 6.1, COMIC project, 2002.
[18] Herfet, T., T. Kirste und M. Schnaider: EMBASSI multimodal
assistance for infotainment and service infrastructures. Computers and
Graphics, 25(4):581–592, 2001.
112
[19] Honkala, M. und M. Pohja: Multimodal interaction with xforms.
In: ICWE ’06: Proceedings of the 6th international conference on Web
engineering, S. 201–208, New York, NY, USA, 2006. ACM.
[20] Honkala, M. und M. Pohja: Multimodal interaction with xforms.
In: ICWE ’06: Proceedings of the 6th international conference on Web
engineering, S. 201–208, New York, NY, USA, 2006. ACM.
[21] Intille, S. S.: Designing a Home of the Future. IEEE Pervasive Computing, 1(2):76–82, 2002.
[22] Jaimes, A. und N. Sebe: Multimodal Human Computer Interaction: A
Survey. Computer Vision and Image Understanding, 108(1-2):116–134,
October 2007.
[23] Kidd, C. D., R. Orr, G. D. Abowd, C. G. Atkeson, I. A. Essa,
B. MacIntyre, E. D. Mynatt, T. Starner und W. Newstetter:
The Aware Home: A Living Laboratory for Ubiquitous Computing Research. In: CoBuild ’99: Proceedings of the Second International Workshop on Cooperative Buildings, Integrating Information, Organization,
and Architecture, S. 191–198, London, UK, 1999. Springer-Verlag.
[24] Kontogiannis, K., G. A. Lewis und D. B. Smith: A research agenda for service-oriented architecture. In: SDSOA ’08: Proceedings of the
2nd international workshop on Systems development in SOA environments, S. 1–6, New York, NY, USA, 2008. ACM.
[25] Lamere, P., P. Kwok, W. Walker, E. Gouva, R. Singh, B. Raj
und P. Wolf: Design of the CMU Sphinx-4 Decoder . In: In 8th
European Conf. on Speech Communication and Technology (EUROSPEECH), 2003.
[26] Leitner, G., D. Ahlstroem und M. Hitz: Usability Key Factor of
Future Smart Home Systems. Home Informatics and Telematics: ICT
for The Next Billion, 241:269–278, 2007.
[27] Leitner, G., M. Hitz und D. Ahlstrom: Applicability and Usability
of Off-the-Shelf Smart Appliances in Tele-Care. In: AINAW ’07: Proceedings of the 21st International Conference on Advanced Information
Networking and Applications Workshops, S. 881–886, Washington, DC,
USA, 2007. IEEE Computer Society.
113
[28] Loesch, K. und S. Albayrak: SerCHo - ein ganzheitlicher
Lösungsansatz mit innovativen Plattformen und Diensten zur Erschließung von wirtschaftlichen Potenzialen im Zukunftsmarkt Heimvernetzung.
http://130.149.154.94/fileadmin/files/SERCHO_
Whitepaper.pdf, 2006.
[29] Magerkurth, C., R. Etter, M. Janse, J. Kela, O. Kocsis und
F. Ramparany: An intelligent user service architecture for networked
home environments. IET Conference Publications, 2006(CP518):v1–
361–v1–361, 2006.
[30] Marco Blumendorf, S. F. und S. Albayrak: Multimodal User
Interaction in Smart Environments: Delivering Distributed User Interfaces. In: European Conference on Ambient Intelligence: Workshop on
Model Driven Software Engineering for Ambient Intelligence Applications, 2007.
[31] Nigay, L. und J. Coutaz: A design space for multimodal systems:
concurrent processing and data fusion. In: CHI ’93: Proceedings of the
INTERACT ’93 and CHI ’93 conference on Human factors in computing
systems, S. 172–178, New York, NY, USA, 1993. ACM.
[32] Niklfeld, G., H. Anegg, A. Gassner, M. Jank, G. Pospischil,
M. Pucher, R. Schatz, R. Simon und F. Wegscheider: Device
independent mobile multimodal user interfaces with the MONA Multimodal Presentation Server . In: Proccedings of the Eurescom summit
2005 on Ubiquitous Services and Applications, 2005.
[33] osgi.org: OSGi Service Platform Core Specification. 2007.
[34] Oviatt, S.: Ten myths of multimodal interaction. Commun. ACM,
42(11):74–81, 1999.
[35] Oviatt, S.: Taming recognition errors with a multimodal interface.
Commun. ACM, 43(9):45–51, 2000.
[36] Pantic, M. und L. Rothkrantz: Toward an affect-sensitive multimodal human-computer interaction. 91(9):1370–1390, September 2003.
[37] Puerta, A. und J. Eisenstein: XIML: A Universal Language for
User Interfaces. http://www.ximl.org/documents/XimlWhitePaper.
pdf, 2001.
114
[38] Puerta, A. und J. Eisenstein: XIML: a common representation for
interaction data. In: IUI ’02: Proceedings of the 7th international conference on Intelligent user interfaces, S. 214–215, New York, NY, USA,
2002. ACM.
[39] Ringbauer, B., D. F. Heidmann und J. Biesterfeldt: When a
house controls its master. Universal design for smart living environments. In: Proceedings of 10th Int. Conf. on Human-Computer Interaction, Crete, Greece, 2003.
[40] Stanciulescu, A., Q. Limbourg, J. Vanderdonckt, B. Michotte und F. Montero: A transformational approach for multimodal web
user interfaces based on UsiXML. In: ICMI ’05: Proceedings of the
7th international conference on Multimodal interfaces, S. 259–266, New
York, NY, USA, 2005. ACM.
[41] Walker, W., P. Lamere und P. Kwok: FreeTTS - A Performance
Case Study [TR-2002-114 ] . Techn. Ber., Sun microsystems, 2002.
[42] Walker, W., P. Lamere, P. Kwok, B. Raj, R. Singh, E. Gouvea, P. Wolf und J. Woelfel: Sphinx-4: A Flexible Open Source
Framework for Speech Recognition [TR-2004-139 ] . Techn. Ber., Sun
microsystems, 2004.
[43] Webseite: AMIGO Architecture - http: // www. hitech-projects.
com/ euprojects/ amigo/ software. htm , zuletzt besucht: Juli 2009.
[44] Webseite: AMIGO Introduction - http: // www. hitech-projects.
com/ euprojects/ amigo/ amigo. htm , zuletzt besucht: Juli 2009.
[45] Webseite: Commons SCXML - http: // commons. apache. org/
scxml/ , zuletzt besucht: Juli 2009.
[46] Webseite: EMMA: Extensible MultiModal Annotation markup language - http: // www. w3. org/ TR/ emma/ , zuletzt besucht: Juli 2009.
[47] Webseite: FreeTTS 1.2: A speech synthesizer written entirely in the JavaTM programming language - http: // freetts. sourceforge. net/
docs/ index. php , zuletzt besucht: Juli 2009.
[48] Webseite: Introduction to CCXML - http: // www. voxeo. com/
library/ ccxml. jsp , zuletzt besucht: Juli 2009.
[49] Webseite: Kisla Interactive - http: // ximl. com/ , zuletzt besucht:
Juli 2009.
115
[50] Webseite: Multimodal Interaction Activity - http: // www. w3. org/
2002/ mmi/ , zuletzt besucht: Juli 2009.
[51] Webseite: OSGi Alliance - http: // www. osgi. org/ , zuletzt besucht: Juli 2009.
[52] Webseite: UIML.org - http: // www. uiml. org/ , zuletzt besucht: Juli 2009.
[53] Webseite: User Interface Markup Language (UIML) Version 4.0:
Committee Draft - http: // www. uiml. org/ , zuletzt besucht: Juli
2009.
[54] Webseite: UsiXml.org -http: // www. usixml. org , zuletzt besucht:
Juli 2009.
[55] Webseite: W3C: JSpeech Grammar Format - http: // www. w3. org/
TR/ jsgf/ , zuletzt besucht: Juli 2009.
[56] Webseite: W3C: Multimodal Interaction Requirements - http: //
www. w3. org/ TR/ mmi-reqs/ , zuletzt besucht: Juli 2009.
[57] Webseite: W3C: Voice Extensible Markup Language (VoiceXML) Version 2.0 - http: // www. w3. org/ TR/ voicexml20/ , zuletzt besucht:
Juli 2009.
[58] Webseite: W3C Working Draft: Multimodal Architecture and Interfaces - http: // www. w3. org/ TR/ 2008/ WD-mmi-arch-20081016/ , zuletzt besucht: Juli 2009.
[59] Webseite: W3C Working Draft: State Chart XML (SCXML) State
Machine Notation for Control Abstraction 1.0 - http: // www. w3. org/
TR/ 2005/ WD-scxml-20050705/ , zuletzt besucht: Juli 2009.
[60] Webseite: W3C Working Draft: State Chart XML (SCXML) State
Machine Notation for Control Abstraction 1.0 - http: // www. w3. org/
TR/ scxml/ , zuletzt besucht: Juli 2009.
[61] Webseite: W3C Working Draft: Voice Browser Call Control CCXML Version 1.0 - http: // www. w3. org/ TR/ 2002/
WD-ccxml-20020221/ , zuletzt besucht: Juli 2009.
[62] Webseite: W3C Working Draft: Voice Browser Call Control CCXML
Version 1.0 - http: // www. w3. org/ TR/ ccxml/ , zuletzt besucht: Juli
2009.
116
[63] Webseite: W3C XHTML Modularization 1.1 - http: // www. w3.
org/ TR/ 2006/ WD-xhtml-modularization-20060705/ , zuletzt besucht: Juli 2009.
[64] Webseite: XHTML 1.0 The Extensible HyperText Markup
Language (Second Edition) - http: // www. w3. org/ TR/ 2002/
REC-xhtml1-20020801/ , zuletzt besucht: Juli 2009.
[65] Webseite: XHTML+Voice Profile 1.2 - http: // www. voicexml.
org/ specs/ multimodal/ x+ v/ 12/ , zuletzt besucht: März 2009.
[66] Wegscheider, F., T. Dangl, M. Jank und R. Simon: A multimodal interaction manager for device independent mobile applications. In:
WWW Alt. ’04: Proceedings of the 13th international World Wide Web
conference on Alternate track papers & posters, S. 272–273, New York,
NY, USA, 2004. ACM.
[67] Winckler, M., J. Vanderdonckt, A. Stanciulescu und F. Trindade: Cascading Dialog Modeling with UsiXML. S. 121–135, 2008.
117

- Alpen-Adria-Universität Klagenfurt

Transcrição

Documentos relacionados

PDF / 33 kB - Forschungszentrum Jülich

7.¨Ubung ” Nebenläufige und verteilte Programmierung“

PG-Antrag - Lehrstuhl 5 für Programmiersysteme

Besuchen Sie uns: Autohaus Glinicke GmbH www.glinicke

Marketing Guide

Das Noether-Theorem in der klassischen Feldtheorie

Eklat im Leinwiger Rat - Leuphana Universität Lüneburg

Neue gamona Netzwerkseite zu RF Online

Hintergrund-Informationen zum Artikel ” Neue Bilder für die

Aktueller Kursflyer - Food