Sprachbedienung im Automobil: Teilautomatisierte Entwicklung benutzerfreundlicher Dialogsysteme (German Edition)

Sprachbedienung im Automobil Teilautomatisierte Entwicklung benutzerfreundlicher Dialogsysteme

Stefan W. Hamerich

Sprachbedienung im Automobil Teilautomatisierte Entwicklung benutzerfreundlicher Dialogsysteme

ABC

Stefan W. Hamerich Harman/Becker Automotive Systems GmbH Söflinger Str. 100 89077 Ulm [email protected]

ISBN 978-3-642-01615-8 e-ISBN 978-3-642-01616-5 DOI 10.1007/978-3-642-01616-5 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer-Verlag Berlin Heidelberg 2009 Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Einbandentwurf: eStudio calamar S.L., Figueres/Berlin Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Danksagung

Das vorliegende Buch resultiert aus meiner langen Leidenschaft f¨ ur das Thema der automatischen Sprachverarbeitung und entstammt meiner Dissertation in der Informatik an der Universit¨ at Hamburg. Da die Erstellung dieser Schrift viel Zeit und Arbeit erfordert hat, m¨ ochte ich an dieser Stelle einigen Personen danken, die einen gr¨ oßeren Beitrag zum Gelingen meines Promotionsprojekts und zur vorliegenden Ver¨ offentlichung geleistet haben. An erster Stelle danke ich meinem Betreuer und Doktorvater Walther von Hahn von der Universit¨ at Hamburg. Er hat noch zu Studienzeiten mein Interesse am Thema der Sprachverarbeitung geweckt und nach Abschluss meines Studiums und Wechsel in die Industrie mein Promotionsvorhaben von Anfang an sehr unterst¨ utzt. Er gab mir wertvolle Hinweise und war mir ein großer Motivator in den Sinnkrisen der Dissertation. Und obwohl ich als externer Doktorand selten pers¨ onlich in Hamburg anwesend war, f¨ uhlte ich mich stets allerbestens betreut und danke f¨ ur E-Mails und Telefonate aus dem Urlaub und nach Feierabend sehr herzlich. Meinem selbst erkorenen zweiten Beteuer Wolfgang Minker von der Universit¨ at Ulm danke ich f¨ ur seine hilfreichen Anmerkungen und Tipps, stete Nachfragen und f¨ ur die Vermittlung wertvoller Diplomanden. F¨ ur seine Unterst¨ utzung in der Vorbereitung meiner Disputation danke ich ebenfalls herzlich. Außerdem danke ich ihm sehr f¨ ur die nicht nachlassende Motivation dieses Buchprojekts und die Herstellung des Kontakts mit dem Springer-Verlag. Ich bedanke mich ausdr¨ ucklich bei Wolfgang Menzel von der Universit¨at Hamburg daf¨ ur, dass er sich ohne vorherige Absprachen als dritter Gutachter meiner Arbeit zur Verf¨ ugung gestellt hat. Es hat mich gefreut, auf diese Art mit einem mir wohlbekannten Professor aus Studententagen wieder in Kontakt zu treten. F¨ ur die wohlwollende Unterst¨ utzung und F¨orderung meines Promotionsvorhabens neben meiner Berufst¨ atigkeit bei Harman/Becker bin ich Marcus Hennecke, Gerhard Hanrieder und Udo Haiber sehr dankbar. Ein großer Dank f¨ ur administrative Unterst¨ utzung geht an Karin Jarck und Cristina Vertan von der Universit¨ at Hamburg.

VI

Des Weiteren danke ich meinen Kollegen von Harman/Becker f¨ ur ihren Anteil am Gelingen meines Promotionsvorhabens, besonderen Dank f¨ ur großen Einsatz und Unterst¨ utzung schulde ich dabei: Dirk Aicher, Dirk B¨ uhler, Rainer Gruhn, Viola Hoff, Bernd Iser, Thomas Krippgans, Patrick Langer, Volker Schleß, Lena Wang, Rita Winter und Stefan Zimmermann. Ein tiefer Dank gilt meinen Eltern f¨ ur ihre stete Unterst¨ utzung und nicht nachlassende Motivation. F¨ ur ihre Unterst¨ utzung, ihr Verst¨ andnis und ihre Geduld danke ich meiner Frau Sandra. Die Erstellung der Dissertation hat uns in den letzten Jahren unz¨ ahlige gemeinsame Tage und Stunden gekostet. Ich freue mich sehr darauf, k¨ unftig mehr Zeit mit ihr und unserer kleinen Familie zu verbringen. Schlussendlich danke ich Frau Eva Hestermann-Beyerle vom SpringerVerlag f¨ ur ihr Interesse am Thema und dieser Ver¨offentlichung.

Ulm im Fr¨ uhjahr 2009 Stefan Hamerich

Inhaltsverzeichnis

1

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Rahmenbedingungen dieses Buches . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Dialogsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Das Schichtenmodell der Sprachdialogmodellierung . . . . . . . . . . 4 1.4 Motivation und Zielsetzung des Buches . . . . . . . . . . . . . . . . . . . . . 6 1.5 Sprachdialogsysteme im Automobil . . . . . . . . . . . . . . . . . . . . . . . . 7 1.6 Das Werkzeug DiaGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7 Der proaktive TMC-Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.8 Aufbau des Buches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2

Grundlagen der Dialogtheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 2.1 Dialog und Außerung .................................... 2.2 Dialogregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Dialogakte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Dialogmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Zustandsbasierte Modellierung . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Regelbasierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Planbasierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Statistische Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.5 Dialogmodellierung in automobilen Systemen . . . . . . . . . 2.5 Dialogsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Dialogstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Direktive Dialogstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Reaktive Dialogstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3 Kooperative Dialogstrategie . . . . . . . . . . . . . . . . . . . . . . . . 2.6.4 Mischformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Dialogdom¨ ane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Dialogziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 Dialogparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10 Dialogdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 13 14 15 16 17 17 18 18 19 21 22 22 22 22 23 23 24 24 25 26

VIII

Inhaltsverzeichnis

3

Sprachdialogsysteme im Automobil . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Warum Sprache im Automobil? . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Systemdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Sprachdialogsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Sprachbediensystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Systemanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Hardwareanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Integration in automobiles HMI . . . . . . . . . . . . . . . . . . . . . 3.3.4 Bedienbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Spracheingabe und akustische Vorverarbeitung . . . . . . . . 3.4.2 Spracherkennung und Parsing . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 Dialogmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Headunit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.5 R¨ uckmeldungen des Systems . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Systemintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Funktionalit¨ aten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Nummernwahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Namenswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 Zieleingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.4 Radiosteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.5 Steuerung des Medienspielers . . . . . . . . . . . . . . . . . . . . . . . 3.6.6 Internetzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.7 Funktionszuw¨ achse am Beispiel Linguatronic . . . . . . . . . . 3.7 Vergleich mit serverbasierten Dialogsystemen . . . . . . . . . . . . . . . 3.7.1 Anwendungsdom¨ anen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.3 Beispielsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.4 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Dialogsysteme im Alltag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 31 31 32 32 32 33 34 35 35 36 37 39 39 40 41 44 44 45 46 47 48 48 49 49 50 51 54 56 56 58

4

Benutzerfreundliche Sprachdialoge im Automobil . . . . . . . . . . 4.1 Benutzerfreundlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Benutzerfreundlichkeit von Sprachdialogen . . . . . . . . . . . . . . . . . . 4.3 Evaluation von Sprachdialogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Performanzevaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 Benutzerevaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Vergleichende Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Evaluationsm¨ oglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Wizard of Oz Versuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ¨ 4.4.2 Uberwachte Systembenutzung . . . . . . . . . . . . . . . . . . . . . . . 4.4.3 Simulierte Benutzertests . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61 61 62 67 67 68 68 69 69 69 70

Inhaltsverzeichnis

IX

4.4.4 Besonderheiten f¨ ur die Dom¨ ane der Sprachbedienung im Automobil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Ans¨ atze f¨ ur benutzerfreundliche Sprachdialoge . . . . . . . . . . . . . . 4.5.1 Nat¨ urliche Sprache als Problem? . . . . . . . . . . . . . . . . . . . . 4.5.2 Adaptive Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.3 Dialogstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.4 Pr¨ asentation von Ergebnislisten . . . . . . . . . . . . . . . . . . . . . 4.5.5 Sprachausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70 71 71 73 75 76 76 77

5

Beschreibung von Sprachdialogen . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Programmierung von Dialogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Dialogbeschreibungssprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 GDML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Weitere Sprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Vergleich GDML und VoiceXML . . . . . . . . . . . . . . . . . . . . 5.3 Grammatikbeschreibungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 BNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 JSGF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 GSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4 SRGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79 79 80 81 86 90 95 96 96 97 98 99

6

Teilautomatisierte Modellierung von Dialogen . . . . . . . . . . . . . 101 6.1 Graphischer Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.1.1 CSLU-Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.1.2 REWARD-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.3 DiaMod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1.4 GUIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 6.1.5 VoiceObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.2 Textueller Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.2.1 GEMINI-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7

Das Entwicklungswerkzeug DiaGen . . . . . . . . . . . . . . . . . . . . . . . . 111 7.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.1.1 Betriebssystem und Programmiersprache . . . . . . . . . . . . . 112 7.1.2 Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.1.3 Einsatzszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.1.4 Dialogbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.1.5 Dialogmodellierungsart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.1.6 Editierbarer Dialogquellcode . . . . . . . . . . . . . . . . . . . . . . . . 113 7.1.7 Beschleunigung der Dialogerstellung . . . . . . . . . . . . . . . . . 114 7.1.8 Schnelles Aufsetzen von neuen Projekten . . . . . . . . . . . . . 114 7.1.9 Unterst¨ utzung von Codebibliotheken . . . . . . . . . . . . . . . . . 114

X

Inhaltsverzeichnis

7.2 7.3

7.4 7.5

7.1.10 Einfachere Integration von neuen Schnittstellen . . . . . . . 115 7.1.11 Einbindung von Compiler und Ablaufumgebung . . . . . . . 115 7.1.12 Konsistenz zwischen Grammatik und Dialog . . . . . . . . . . 115 7.1.13 Zukunftssicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 7.1.14 Softwarequalit¨ at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Entwicklung von DiaGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Eigenschaften von DiaGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.3.1 Systemanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.3.2 Wartung und Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . 117 7.3.3 Nutzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.3.4 Quellcodeeditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.3.5 Kontextmen¨ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 7.3.6 Projektbearbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.3.7 Schnittstellenerweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 7.3.8 Dialoge kompilieren und testen . . . . . . . . . . . . . . . . . . . . . . 122 7.3.9 Konsistenz zwischen Grammatik und Dialog . . . . . . . . . . 123 7.3.10 Erstellung benutzerfreundlicher Dialoge . . . . . . . . . . . . . . 125 Evaluation von DiaGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8

Proaktiver TMC-Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 8.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 8.1.1 Proaktiver Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 8.1.2 TMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 8.2 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 8.3 Idee f¨ ur proaktive TMC-Dialoge . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 8.4 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 8.5 Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 8.6 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 8.7 Konstruktion des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 8.7.1 Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 8.7.2 Dialogerstellung mit DiaGen . . . . . . . . . . . . . . . . . . . . . . . . 135 8.7.3 TMC-Service Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . 135 8.7.4 Konstruktionsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 8.8 Evaluation des Sprachdialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 8.8.1 Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 8.8.2 Evaluation des TMC-Dialogs . . . . . . . . . . . . . . . . . . . . . . . . 138 8.8.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 8.8.4 Bewertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . 145 8.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

9

Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 9.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Inhaltsverzeichnis

XI

DiaGen Benutzerprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Beispieldialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 B.1 Ohne Umleitungsalternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 B.2 Mit Umleitungsalternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Abk¨ urzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

1 Einleitung

Die nat¨ urlichsprachliche dialogische Kommunikation mit Maschinen ist bereits seit langer Zeit ein Traum der Menschheit. Nie mehr m¨ ussten Gebrauchsanleitungen gelesen werden; Videorekorder, Waschmaschinen und andere n¨ utzliche Helfer w¨ urden ganz einfach auf die per Sprache vorgetragenen W¨ unsche ihrer Benutzer reagieren und gegebenenfalls nachfragen, wenn sie etwas nicht verstanden haben. Im Idealfall sollte dann auch irgendwann die Kommunikation mit dem eigenen PC so einfach sein, wie die mit dem legend¨aren Bordcomputer auf dem Raumschiff Enterprise. Seit mehr als dreißig Jahren gibt es Bestrebungen, diesem Idealziel m¨oglichst nahe zu kommen. So ist seit den 1970er Jahren das Grundprinzip der statistischen Spracherkennung bekannt [Jelinek 1976] und an der Universi¨at Hamburg wurde mit HAM-RPM eines der ersten Dialogsysteme vorgestellt [von Hahn et al. 1978]. Schon in den 1980er Jahren stellte die IBM einen Spracherkenner vor, der auf einem handels¨ ublichen PC arbeitete [Averbuch et al. 1986]. Fast gleichzeitig wurden erste gesprochen-sprachliche Dialogsysteme vorgestellt [Allen et al. 1982, Niedermair 1987]. Diktiersysteme f¨ ur den heimischen PC sind mittlerweile in jedem Kaufhaus erh¨ altlich und in der Telekommunikation sind sprachgesteuerte Auskunftsysteme – wie die automatische Fahrplanauskunft der Bahn (vgl. Abschnitt 3.7.3) – schon lange nicht mehr ungew¨ohnlich. Selbst im Automobil ist die Sprache inzwischen angekommen: 1996 wurde das Sprachbediensystem Linguatronic zum ersten Mal Kunden von Mercedes-Benz angeboten (siehe Abschnitt 3.6.7). Inzwischen ist die Sprachsteuerung im Kfz nicht mehr auf einen Fahrzeughersteller beschr¨ ankt; fast jeder große Hersteller bietet eine Sprachsteuerung, zumindest f¨ ur das Telefon, an [Hanrieder 2004]. Dass Sprachtechnologie nicht mehr nur ein reines Forschungsthema ist, belegen Studien [Rademacher 2004] und Unternehmens¨ ubernahmen (v.a. durch Nuance/Scansoft und Microsoft) in den letzten Jahren. Es gibt mehrere Firmen, die ausschließlich oder zu einem großen Teil mit dieser Technologie ihr Geld verdienen. Angefangen von der akustischen Vorverarbeitung, u ¨ber Spracherkennung, Dialogbeschreibungen und Dialogmodellierungswerkzeuge,

2

1 Einleitung

bis hin zur Sprachsynthese. Zus¨ atzlich gibt es mehrere Komplettanbieter, welche die gesamte Sprachsteuerung einer Telefonzentrale anbieten. Doch auch wenn die Grundlagen von Sprachdialogsystemen seit mehreren Jahren bekannt sind, sie als Produkte bereits verkauft werden und Benutzererfahrungen vorliegen, gibt es noch gen¨ ugend Forschungsbedarf. Dieser Bedarf ist besonders hoch im Bereich der automobilen Sprachsysteme, die als eingebettete Systeme eine wenig beachtete, aber durchaus bemerkenswerte, Rolle unter den Dialogsystemen einnehmen. Die Besonderheit der automobilen Systeme liegt allerdings nicht nur in ihrer Einbettung ins Automobil, sondern auch darin, dass sie als Nebenaufgabe (engl. secondary task ) zur haupts¨achlich wichtigen Fahraufgabe lediglich die geteilte Aufmerksamkeit des Fahrers haben. Damit unterscheiden sie sich deutlich von den telefonbasierten Systemen, welche in der Regel die alleinige Aufmerksamkeit des Nutzers genießen. Auf Grund dieser Besonderheiten widmet sich das vorliegende Werk den automobilen Sprachsystemen. Insbesondere geht es dabei um das Dilemma der Modellierung von Dialogen f¨ ur den automobilen Einsatz.

1.1 Rahmenbedingungen dieses Buches Das vorliegende Buch entstand als Hintergrundforschung aus der beruflichen Praxis des Autors in der Forschung und Produktentwicklung von automobilen Sprachbediensystemen bei der Firma Harman/Becker Automotive Systems (HBAS) in Ulm. Dabei sind die Ergebnisse jedoch nicht produktgebunden und daher der Produktentwicklung weit voraus. Die grundlegende Idee f¨ ur das Thema dieses Werkes entstammt der Mitarbeit im EU-gef¨ orderten Forschungsprojekt GEMINI, welches sich mit der semiautomatischen Generierung von telefonischen Sprachdialogapplikationen aus einer Datenbankbeschreibung besch¨ aftigte (mehr dazu in Abschnitt 6.2.1). Da jedoch aus Sicht des Autors im Projekt GEMINI einige grundlegende Punkte nicht bearbeitet wurden, entstand der Gedanke, diese innerhalb des vorliegenden Buches zu vertiefen. Bedingt durch die berufliche Orientierung auf automobile Systeme und die gr¨ oßeren Herausforderungen an die Dialogmodellierung f¨ ur diese Systeme wurde diese Ausarbeitung dann auf die Anwendungsform der Kfz-Systeme u ¨bertragen. Der Autor konnte dabei sowohl auf die Erfahrungen des GEMINI-Projekts, wie auch auf die technische Infrastruktur von HBAS zur¨ uckgreifen. Letzteres bot vor allem die M¨oglichkeit ein im Rahmen des vorliegenden Werkes erstelltes prototypischen Dialogsystem in einem Demonstrationsfahrzeug einzusetzen.

1.2 Dialogsysteme Aufbauend auf der Sprechakttheorie (siehe Abschnitt 2.3) bedeutet ein Dialog im Rahmen dieses Werkes eine zielorientierte sprachliche Interaktion. Wenn

1.2 Dialogsysteme

3

ein kommunikatives Ziel im Dialog mit einem sprachverarbeitenden System erreicht werden kann, heißt dieses System Dialogsystem. Verarbeitet dieses System gesprochene Sprache, wird es auch gesprochen-sprachliches Dialogsystem genannt.1 Wenn in diesem Buch von einem Sprachdialogsystem (SDS) die Rede ist, ist immer der Systemtyp gemeint, wie er im folgenden dargestellt wird. Die einzelnen Komponenten eines solchen Systems sind schematisch auf Abbildung 1.1 dargestellt.

Abbildung 1.1. Schematischer Aufbau eines Dialogsystems

Die Spracheingabe erfolgt in ein Mikrofon, welches anschließend das aufgenommene Signal an den Spracherkenner weitergibt. Dieser f¨ uhrt die eigentliche Erkennung durch und errechnet aus dem Sprachsignal eine Wortfolge. Die Wortfolge wird anschließend syntaktisch und semantisch analysiert. In Abh¨ angigkeit des Analyseergebnisses wird dann eine Aktion ausgef¨ uhrt (diese kann auch außerhalb des Dialogsystems stattfinden, wenn beispielsweise eine Datenbank abgefragt oder ein Navigationssystem gesteuert wird). Basierend auf der Aktion wird im n¨ achsten Schritt eine R¨ uckgabe ermittelt und aus dieser z.B. mittels einer Sprachsynthese eine sprachliche Antwort generiert. Eine detailliertere Darstellung dieser Komponenten erfolgt in Abschnitt 3.4. Vor einigen Jahrzehnten gab es wenige Spezialisten, welche ein solches System entwickeln konnten und die zugrundeliegende Technologie u ¨berblickten. Die zunehmende Forschung und technologische Weiterentwicklung f¨ uhrten zu einer Spezialisierung in einzelnen Teilaspekten der Sprachverarbeitung. Vor allem der große Erfolg der statistischen Spracherkennung f¨ uhrte zu einer ersten Auftrennung von Spezialgebieten. Mathematiker und Ingenieure betrieben eine konsequente Weiterentwicklung der Verarbeitung der gesprochenen Sprache (engl. speech), w¨ ahrend Informatiker der k¨ unstlichen Intelligenz 1

In diesem Werk wird meist nur der Terminus Dialogsystem“ verwendet, gemeint ” sind aber immer gesprochen-sprachliche Systeme.

4

1 Einleitung

zusammen mit Psychologen und Linguisten die Verarbeitung geschriebener Sprache (engl. language) weiterentwickelten. Damit entstand das Dilemma der Teilung des Entwicklungsprozesses von Sprachdialogsystemen in die Signalebene auf der einen und die Dialogebene auf der anderen Seite. In Abh¨angigkeit der Systemdom¨ ane, der fachlichen Kenntnisse und M¨oglichkeiten, aber auch der Pr¨ aferierung von speech oder language wurde die grammatikalische Analyse (also das Parsing) zum einen oder anderen Teil hinzugerechnet. Die Spezialisierung ging innerhalb dieser beiden Gebiete2 weiter, so dass sich die Spracherkennung u.a. in akustische Vorverarbeitung, Signalverarbeitung, phonetische Verarbeitung und statistische Verarbeitung aufgesplittet hat. Auf der Dialogseite ist eine Spezialisierung in linguistische Verarbeitung, sprachtechnologische Verarbeitung, Wissensverarbeitung und Ergonomie3 erfolgt. Dieses Dilemmas ist sich die Forschergemeinschaft inzwischen bewusst geworden. Die Einsicht, dass die Modellierung einer wirklich intelligenten Maschine f¨ ur nat¨ urlichsprachliche Dialoge nur mit vereinten Kr¨aften von Linguisten und Ingenieuren zum Ziel gelangen kann, ist erfolgt. Das Verst¨andnis f¨ ur einen u ¨bergreifenden Ansatz zur Modellierung von Sprachdialogen ist allerdings noch nicht komplett vorhanden.

1.3 Das Schichtenmodell der Sprachdialogmodellierung Als L¨ osungsansatz f¨ ur das im vorherigen Abschnitt angesprochene Dilemma wird in diesem Buch erstmals ein Schichtenmodell der Sprachdialogmodellierung propagiert. Dieses Modell bildet ebenfalls die n¨otige Interdisziplinarit¨at in strukturierter Form ab und dient als Grundlage f¨ ur das vorliegende Werk. Zus¨ atzlich ordnet das Modell von oben nach unten die einzelnen Themen von abstrakten Konzepten zur konkreten Implementierung. Damit kann auch der Modellierungsprozess insgesamt veranschaulicht werden. Die schematische Darstellung des Modells kann Abbildung 1.2 entnommen werden. Ein Sprachdialog als Mensch-Maschine-Schnittstelle wird von menschlichen Benutzern bedient. F¨ ur diese ist die Benutzerfreundlichkeit einer solchen Schnittstelle das Wichtigste u ¨berhaupt. Eine Sprachschnittstelle muss ergonomisch sinnvoll und benutzbar ausgef¨ uhrt werden, dies gilt insbesondere bei Einsatz im Automobil, da ein System dort trotz geteilter Aufmerksamkeit 2

3

Zu manchen Zeiten konnte schon fast von einer Glaubensrichtung gesprochen werden. Das schwierige Miteinander von Statistikern und Linguisten illustriert sehr gut der ber¨ uhmte Ausspruch von Frederick Jelinek, der ab Ende der 70er Jahre einer der Pioniere der statistischen Spracherkennung bei der IBM war: Whenever I fire a linguist our system performance improves.“. Auf der anderen ” Seite hielt der ber¨ uhmte Linguist Noam Chomsky Statistik f¨ ur ein illegitimes Mittel in der Sprachverarbeitung. [Jelinek 2005] Auch als psychologische Komponente oder unter usability oder Mensch-Maschine Schnittstelle bekannt.

1.3 Das Schichtenmodell der Sprachdialogmodellierung

5

Abbildung 1.2. Schematischer Aufbau des Schichtenmodells der Sprachdialogmodellierung

m¨ oglichst perfekt benutzbar sein sollte. Um dies grunds¨atzlich zu erm¨oglichen, bildet die Kenntnis des Begriffs Usability und der dahinter stehenden Konzepte der (kognitiven) Ergonomie eine der wichtigsten Grundlagen f¨ ur die Modellierung von Sprachdialogen. Daher stellt die Benutzerfreundlichkeit die oberste Schicht im skizzierten Schichtenmodell dar. Bei der Benutzung eines Sprachdialogs spielt selbstverst¨andlich auch die Kommunikation eine wichtige Rolle. Ohne Kenntnis der Kommunikationsregeln und deren Grundlagen kann kein guter Sprachdialog entstehen. Sehr wichtig ist vor allem, nach welchen Regeln Kommunikation zwischen Partnern abl¨ auft. Eine Antwort bieten die Grice’schen Maximen an, welche als wichtige Grundlage in Kapitel 2 behandelt werden. Diese Kommunikationsregeln sind Bestandteil der zweiten Ebene des genannten Schichtenmodells. F¨ ur die folgende dritte Ebene des Modells spielt die sprachliche Kommunikation eine besondere Rolle, damit sind Erkenntnisse der Linguistik relevant. F¨ ur die Modellierung von Sprachdialogen ist es sehr wichtig, zumindest die Grundlagen der, dem Dialogsystem zugrundeliegenden nat¨ urlichen Sprache, ¨ sowie die Begrifflichkeiten Dialog und Außerung zu kennen. Ebenso erlauben nur Erkenntnisse der Linguistik eine korrekte Interpretation von Sprache und deren Bedeutung. Nach diesen theoretischen Grundlagen erfolgt in der n¨achsten Schicht die technische Umsetzung. Wenn ein System hinsichtlich der in den oberen drei ¨ Schichten angestellten Uberlegungen skizziert wird, muss als n¨achstes dessen technische Struktur bzw. der Systemaufbau definiert werden. F¨ ur dieses Thema sind die Grundlagen der Informatik und Ingenieurswissenschaften von Bedeutung, um aus verschiedenen Einzelkomponenten ein funktionierendes Dialogsystem erstellen zu k¨ onnen. Nach dem Systemaufbau folgt auf der untersten Schicht die softwaretechnische Umsetzung der in den h¨ oheren Schichten erstellten Konzepte in einen maschinenlesbaren Dialogablauf. F¨ ur den Sprachdialog bedeutet dies die Umsetzung dieser Konzepte in eine Programmier- oder Beschreibungssprache.

6

1 Einleitung

Grunds¨ atzlich gilt, dass die dargestellten Themengebiete bei jeder Modellierung von Sprachdialogsystemen beteiligt sind, unabh¨angig davon, ob ein solches System manuell oder semiautomatisch, f¨ ur die Benutzung am Telefon oder im Automobil konzipiert wird. Allerdings werden die genannten Bereiche nicht f¨ ur jede Konzeption in ihrer vollen Bandbreite ben¨otigt. F¨ ur das vorliegende Werk gilt daher, dass die beschriebenen Schichten lediglich in der Bandbreite bekannt sein m¨ ussen, wie sie zur Erstellung kommunikativ und kognitiv sinnvoller Dialoge im Automobil ben¨ otigt werden. Entsprechend werden daher die jeweiligen Themengebiete im Verlaufe des Buches eingegrenzt. Die Besonderheit dieses Werkes ist dabei, dass sich der vorgeschlagene Modellierungsweg nicht nur auf eine oder wenige der beteiligten Schichten konzentriert, sondern alle Ebenen ber¨ uhrt.

1.4 Motivation und Zielsetzung des Buches Wie in den vorherigen Abschnitten beschrieben wurde, erfordert die Modellierung eines Sprachdialogsystems die detaillierte Kenntnis verschiedener Methoden und Forschungsgebiete. Es wurde auch dargestellt, dass sich die Forschung auf dem Gebiet der Dialogsysteme immer weiter spezialisiert hat, dabei ist die Spezialisierung aktuell f¨ ur so unterschiedliche Themen wie unter anderem Erkennung von Emotionen [Boufaden und Dumouchel 2008], Sprechererkennung [Shriberg und Stolcke 2008], Sprachsynthese [Ding et al. 2008], Bandbreitenextrapolation [Iser et al. 2008], Dialogannotation [Colman et al. 2008] oder automatisches Zusammenfassen [Liu und Liu 2008] erfolgt. Diese einzelnen Themen finden alle ihre Anwendung in einem Dialogsystem, ben¨otigen zu ihrer Integration in ein solch komplexes System allerdings einen fundierten Gesamt¨ uberblick u ¨ber die Methoden der jeweiligen Fachgebiete aus dem Schichtenmodell. Das erforderliche Methodenwissen aus dem Schichtenmodell und der einzelnen Spezialdisziplinen der Dialogsystemforschung ist allerdings so vielf¨altig, dass die sichere intellektuelle Beherrschung durch eine Person nicht mehr gew¨ ahrleistet ist. Dieses Problem der Beherrschbarkeit stellt sich grunds¨atzlich immer ¨ ofter bei modernen komplexen Softwaresystemen und auch f¨ ur den Bereich der Sprachdialogsysteme. Bei der Entwicklung entsprechender Dialogsysteme kann daher in der Praxis der aktuelle Kenntnisstand aus der Wissenschaft nicht immer umgesetzt werden oder es kann zu mangelhaften Systementw¨ urfen kommen. Bei Teaml¨ osungen entsteht außerdem ein hoher Kommunikationsaufwand, welcher zu mangelnder Passgenauigkeit der L¨osungen sowie unverh¨ altnism¨ aßig großen Entwicklungszeiten f¨ uhren kann. Da Sprachdialoge f¨ ur den Anwendungsbereich im Automobil besondere Anforderungen hinsichtlich der ergonomischen Beschaffenheit, der Ressourcennutzung und der Integration stellen und zudem in der wissenschaftlichen Dikussion eher eine Randerscheinung sind, wurden automobile Dialogsysteme als Betrachtungsgegenstand des vorliegenden Werkes ausgew¨ahlt.

1.5 Sprachdialogsysteme im Automobil

7

F¨ ur diesen definierten Anwendungsbereich soll im vorliegenden Buch eine L¨ osung der skizzierten Problematik der Beherrschbarkeit der wissenschaftlichen Grundlagen gefunden werden. Es ist daher das Ziel des vorliegenden Werkes, die Methoden der in unterschiedlichen Ebenen des dargestellten Schichtenmodells repr¨asentierten Disziplinen zusammenzuf¨ uhren, um die Erstellung von benutzerfreundlichen und kommunikativ sinnvollen Dialogsystemen in einem einheitlichen Design- und Entwicklungsprozess zu erm¨ oglichen. Dabei sollen die verschiedenen Ans¨atze von speech und language genauso zusammengef¨ uhrt werden, wie die unterschiedlichen Methoden und Erkenntnisse von Informatik, Ingenieurswissenschaften, Linguistik und Ergonomie. Zur Erm¨oglichung eines solchen integrierten Entwurfs werden in diesem Buch zuerst die Grundlagen f¨ ur die Entwicklung automobiler Sprachdialogsysteme dargestellt und darauf aufbauend die Implementierung eines umfassenden Entwicklungswerkzeugs geleistet. Als Vorbild f¨ ur dieses Werkzeug dient die klassische Softwareentwicklung, in der immer mehr integrierte Entwicklungsumgebungen eingesetzt werden. Das aus diesem Buch resultierende Werkzeug soll dabei die Erstellung von benutzerfreundlichen und kommunikativ sinnvollen Sprachdialogen auf innovative Art und Weise unterst¨ utzen. Die Erforschung, Planung, Implementierung und experimentelle Validierung einer solchen Umgebung, welche die im Schichtenmodell repr¨asentierten Methoden vereint, stellt einen erheblichen wissenschaftlichen Fortschritt dar, der außerdem in seiner Anwendung einen effizienten Vorteil bieten kann.

1.5 Sprachdialogsysteme im Automobil Sprachdialogsysteme im Automobil unterscheiden sich in vielf¨altiger Hinsicht von den etablierten und bekannten serverbasierten Anwendungen. Ein wesentlicher Unterschied ist dabei die Modellierungsart f¨ ur das Dialogmodell. Grunds¨ atzlich enth¨ alt ein Dialogmodell Antwort- bzw. Aktionsbeschreibungen f¨ ur von der Erkennung und Analyse gelieferte semantische Konzepte. Diese Abbildung von semantischen Konzepten auf Antworten ben¨otigt außerdem noch Wissen u ¨ber den gesamten Dialogablauf und die Dialogdom¨ane. Dialogmodelle k¨ onnen konzeptuell auf sehr unterschiedliche Arten modelliert werden. Der klassische Ansatz ist die Modellierung mittels deterministischer endlicher Automaten [Hopcroft und Ullman 1979] und wird zustandsbasierte Dialogmodellierung genannt. Dieser Ansatz f¨ uhrt u ¨blicherweise zu sehr statischen Dialogen. Die explizite Modellierung aller Transitionen bietet jedoch den Vorteil, dass eine genaue Spezifikation und Testbarkeit des Dialogflusses m¨ oglich ist. Daneben k¨ onnen Dialogmodelle auch als Regeln [Peckham 1993] formuliert werden, der Ansatz wird regelbasierte Dialogmodellierung genannt. Diese Modellierungsart erm¨oglicht flexiblere Dialoge und kompaktere Modelle, da Transitionen nicht explizit modelliert werden m¨ ussen.

8

1 Einleitung

Allerdings sind entsprechende Modelle nur schwer komplett spezifizier- und testbar. Aus der k¨ unstlichen Intelligenz stammt die Idee, Dialoge planen zu k¨onnen [Cohen et al. 1990]. Die planbasierte Dialogmodellierung f¨ uhrt teilweise zu nicht vorhersagbarem Dialogverhalten, was f¨ ur die Spezifizier- und Testbarkeit einen großen Nachteil darstellt. Es gibt außerdem noch die statistische Dialogmodellierung [Torres et al. 2005]. Dieser Ansatz kann zu unterschiedlichem Dialogverhalten bei identischer Ausgangsvoraussetzung f¨ uhren und ist ebenso nicht komplett spezifizier- und testbar. Da es f¨ ur die Modellierung von automobilen Sprachdialogen immanent wichtig ist, Dialoge komplett spezifizieren und testen zu k¨onnen, wird f¨ ur diese Dialogart immer noch auf die zustandsbasierte Dialogmodellierung zur¨ uckgegriffen. Dies stellt eine Besonderheit der automobilen Dialogsysteme dar, da telefonbasierte Systeme bereits seit einiger Zeit regel- oder planbasiert modelliert werden. Stochastische Systeme sind bereits in der Forschung weit verbreitet. Neben der Modellierung sind die Anforderungen an einen Sprachdialog im Automobil ganz andere als f¨ ur ein telefonisches Auskunftssystem. So ist der Funktionsumfang von automobilen Sprachbediensystemen sehr viel gr¨oßer als der eines Auskunftssystems. Erstere erlauben die Durchf¨ uhrung eines breiteren Aufgabenspektrums; so kann eine Telefonnummer gew¨ahlt werden, ein Ziel in das eingebaute Navigationssystem eingegeben oder auch nur ein anderer Radiosender eingestellt werden. Dagegen kann ein Auskunftssystem in der Regel nur eine Art von Aufgaben erledigen, wie beispielsweise die Auskunft u ¨ber Zugverbindungen. Im Gegensatz zum Aufgabenumfang ist allerdings die Aufgabentiefe bei Auskunftssystemen signifikant gr¨oßer. So m¨ ussen z.B. f¨ ur die Ermittlung einer Bahnverbindung mehrere vordefinierte Informationen vom Benutzer in beliebiger Reihenfolge mitgeteilt werden. Die Sprachsteuerung im Automobil erfordert in der Regel aber nur eine einzige Information, wie z.B. anrufen bei Sandra“ oder Frequenz 103,6“. ” ” Außerdem unterscheiden sich die Systeme im Automobil durch ihre Integration und die zur Verf¨ ugung stehenden Ressourcen von herk¨ommlichen serverbasierten Telefonsystemen [Hamerich 2005]. Dies bedingt weitere technische Unterschiede. So sind die Sprachdialoge fest ab Werk ins Fahrzeug integriert und k¨ onnen nicht einfach ge¨ andert oder ausgetauscht werden. Auch muss die, f¨ ur diese Systeme ben¨ otigte Hardware bei jeder Temperatur und Luftfeuchtigkeit rund um die Welt funktionieren. Dazu ist handels¨ ubliche Hardware, die beispielsweise im PC zu finden ist, nicht in der Lage. Schlussendlich darf ein Dialogsystem im Automobil niemals die komplette Aufmerksamkeit des Fahrers fordern, da dieser jederzeit in der Lage sein muss, das Automobil der Verkehrssituation und den Verkehrsregeln entsprechend zu f¨ uhren.

1.6 Das Werkzeug DiaGen

9

1.6 Das Werkzeug DiaGen Die im vorherigen Abschnitt genannten Faktoren beeinflussen in ganz besonderem Maße die Modellierung eines automobilen Sprachsystems. Bedingt durch diese Besonderheiten wiegt die in Abschnitt 1.3 dargestellte Problematik der unterschiedlichen Disziplinen und Methoden zur Entwickklung eines automobilen Sprachdialogs schwer. Insbesondere die Tatsache, dass ein Dialogsystem im Automobil nicht die komplette Aufmerksamkeit des Fahrers beanspruchen darf, zeigt die Bedeutung von ergonomischen Methoden bei der Modellierung von Sprachdialogen f¨ ur den automobilen Einsatz. Aus diesem Grund widmet sich das vorliegende Buch der Verkn¨ upfung der unterschiedlichen Methoden zur Modellierung eines Sprachdialogs, wie bereits in Abschnitt 1.4 dargelegt wurde. Im Detail wurde mit dem Blick auf automobile Systeme und deren Notwendigkeit ergonomischer Methoden entschieden, dass sich das vorliegende Werk ausschließlich der Modellierung von Sprachdialogen f¨ ur den Einsatz im Automobil widmen soll. Zur Modellierung von Sprachdialogen werden Entwicklungsumgebungen (vgl. Kapitel 6) eingesetzt. Diese erlauben zwar eine beschleunigte Erstellung von Dialogbeschreibungen, konzentrieren sich allerdings nur auf die softwaretechnische Umsetzung von Dialogmodellen und den Systemaufbau, u ¨berdecken daher nicht die komplexe und wissenschaftlich vieldimensionale Modellierung der Sprachdialoge f¨ ur den automobilen Einsatz. Um dieses offene Problem zu l¨ osen, wurde im vorliegenden Buch DiaGen4 entwickelt, ein Werkzeug f¨ ur die Modellierung spezieller Sprachdialoge im Automobil. Dieses Werkzeug vereinfacht und beschleunigt nicht nur die reine Codierung von Sprachdialogen f¨ ur die Dom¨ ane der Anwendung im Automobil, sondern unterst¨ utzt ebenfalls die Erstellung ergonomisch, kognitiv und kommunikativ sinnvoller, sowie korrekter und konsistenter Sprachdialoge im Automobil. Damit werden alle Schichten des vorgenannten Schichtenmodells von dem Werkzeug abgedeckt. Zus¨ atzlich lag das Augenmerk darauf, die Arbeit der eigentlichen Codierung zu minimieren und somit dem Dialogdesigner mehr M¨oglichkeit zu geben, sich um die grunds¨ atzlichen ergonomischen und kommunikativen Aspekte des Dialogdesigns zu k¨ ummern. Damit steigert eine Nutzung des Werkzeugs die Effektivit¨ at und Effizienz der Dialogentwickler erheblich. Die Entwicklung von DiaGen ist dabei nur mit Kenntnis der Grundlagen der bereits im Rahmen des Schichtenmodells erw¨ahnten Fachgebiete m¨oglich gewesen. Damit stellt das Modell nicht nur die Grundlage f¨ ur die Modellierung von Sprachdialogen dar, sondern auch die Basis f¨ ur die Entwicklung des Dialogentwicklungswerkzeugs DiaGen. Der Name DiaGen leitet sich von einem ebenfalls vom Verfasser dieses Werkes entwickelten Werkzeug ab, welches im Rahmen des EU-gef¨orderten Forschungsprojekts GEMINI entwickelt wurde (mehr dazu in Kapitel 6). Dieses Werkzeug war ein intelligenter Quellcodeeditor f¨ ur eine Dialogbeschreibungs4

Sprich /daI2|Ãen/.

10

1 Einleitung

sprache und hieß urspr¨ unglich DialogGenerator. Daraus wurde im Laufe der Zeit DiaGen. Da dieses Werkzeug immer nur ein Hilfswerkzeug war und kein offizieller Bestandteil der Werkzeugsammlung des Projekts GEMINI, wurde der Name f¨ ur das im Rahmen des vorliegenden Buches entwickelte Werkzeug u ¨bernommen. Dabei geht das im Rahmen dieses Werkes entwickelte System aber weit u ahigkeit seines namensgleichen Vorg¨angers hin¨ber die Leistungsf¨ aus. Die Leistungsf¨ ahigkeit und Funktionalit¨ at des f¨ ur die Modellierung von Sprachdialogen in der Automobildom¨ ane entwickelten Werkzeugs DiaGen konnten bereits kurz vor Fertigstellung des vorliegenden Buches erfolgreich pr¨ asentiert werden [Hamerich 2008]. Ein weiterer Nachweis der Leistungsf¨ahigkeit des Werkzeugs wurde mit der Modellierung und Evaluation einer Beispielapplikation erbracht, die kurz in Abschnitt 1.7 beschrieben wird. Da es f¨ ur die Anwendung des Werkzeugs DiaGen keine repr¨asentative Gruppe von entsprechend informierten Benutzern gab, welche die notwendigen Kenntnisse f¨ ur die Erstellung von Sprachdialogen im Automobil hatten und damit das Tool sinnvoll einsetzen konnten, war eine direkte Evaluation des Werkzeugs leider nicht m¨ oglich. Daf¨ ur wurde die mit DiaGen entwickelte und im n¨ achsten Abschnitt beschriebene Beispielapplikation einer Evaluation unterzogen, welche sogar neue Erkenntnisse f¨ ur die Arbeit an Sprachdialogen allgemein aufzeigte, wie in Kapitel 8 ausf¨ uhrlich dargelegt wird. Mit der Erstellung dieses Dialogs mit DiaGen konnte daher gleichzeitig die Zukunftssicherheit des Entwicklungswerkzeugs demonstriert werden.

1.7 Der proaktive TMC-Dialog Um die Leistungsf¨ ahigkeit des im Rahmen dieses Buches entwickelten Werkzeugs DiaGen zu validieren, wurde eine Beispielapplikation erstellt. Diese Applikation ist f¨ ur den Einsatz in einem Automobil mit Navigationssystem gedacht: Wenn bei laufender Navigation auf der eigenen Fahrtroute beispielsweise ein Unfall eine Umleitung n¨ otig macht, kann dies per Verkehrsfunk an die Verkehrsteilnehmer gemeldet werden. Mittels digitaler dynamischer Verkehrsmeldungen, die per Traffic Message Channel (TMC) von Radiosendern ausgestrahlt werden (vgl. Abschnitt 8.1.2), kann das Navigationssystem im Fahrzeug die Routenf¨ uhrung automatisch ¨ andern und die Unfallstelle umgehen. Aufgabe der Beispielapplikation ist dabei, eintreffende dynamische Verkehrsmeldungen vorzulesen und m¨ ogliche Umleitungsempfehlungen per Sprachdialog mit dem Fahrer zu kl¨ aren. Dabei wird der Dialog nicht vom Fahrer gestartet, sondern proaktiv vom Navigationsger¨at bei Vorliegen einer Verkehrsst¨ orung initiiert. Die Nutzung eines proaktiven Sprachdialogs f¨ ur dynamische Verkehrsmeldungen ist bisher weder in der Forschung noch im Produkt bekannt und in Teilen sogar vom Autor als Patent angemeldet worden. Proaktive Sprachdialoge sind bisher in der Forschung nicht erw¨ ahnt. Der Terminus proaktiver ”

1.8 Aufbau des Buches

11

Dialog“ wird dort bislang f¨ ur Dialogsysteme verwendet, die einem laufenden Gespr¨ ach folgen und sich beim richtigen Stichwort automatisch in dieses einschalten k¨ onnen [Minker et al. 2006] oder wie bei [Baudoin et al. 2005] beschrieben, automatisch bei mehreren Optionen die naheliegendste (basierend auf vorangegangenen Aktionen) vorschlagen. Der Grund f¨ ur die wissenschaftliche Nichtbeachtung mag in der geringen Bekanntheit von automobilen Dialogsystemen liegen: bei einem telefonischen Dialogsystem macht ein proaktives Verhalten keinen erkennbaren Sinn. In einigen neueren Kfz sind Systeme verbaut, die proaktiv einen Sprachdialog starten, wenn auf das angebundene Mobiltelefon ein Anruf erfolgt. Dabei wird der Fahrer gefragt, ob er das Gespr¨ ach annehmen m¨ochte. Da proaktive Dialoge bisher nicht systematisch evaluiert wurden, wird dies im vorliegenden Werk erstmals getan. Daher kann mit diesem Werk auch die grunds¨atzliche Frage der Akzeptanz von proaktiven Sprachdialogen im Automobil zumindest mit ersten Antworten hinterlegt werden. Des Weiteren sollen Antworten darauf gefunden werden, wie Autofahrer auf proaktive Sprachdialoge reagieren, ob diese Dialogform die Fahrsicherheit beeintr¨achtigt und ob eine entsprechende Funktionalit¨ at f¨ ur dynamische Verkehrsmeldungen als n¨ utzlich bzw. hilfreich angesehen wird.

1.8 Aufbau des Buches Zun¨ achst werden in Kapitel 2 die Grundlagen der Dialogtheorie gekl¨art. Dabei wird der Begriff Dialog“ definiert und weitere wichtige Begriffe, wie ” Dialogmodell, Dialogstrategie und Dialogdesign eingef¨ uhrt. Dieses Kapitel schafft damit das theoretische Fundament dieses Werkes und den Rahmen f¨ ur die im Schichtenmodell enthaltenen Ebenen drei und vier. Damit wird der Stand der Forschung auf der Dialogebene dargestellt. Im anschließenden Kapitel 3 werden auf Basis der Grundlagen detailliert Sprachdialogsysteme im Automobil behandelt. Dabei werden unter anderem die Gr¨ unde f¨ ur den Einsatz solcher Systeme er¨ortert, sowie ihre Anforderungen, Architektur, Integration und Funktionalit¨aten dargestellt. Des Weiteren wird der Begriff Sprachdialogsystem“ definiert und eine Gegen¨ uber” stellung mit Telefoniesystemen vorgenommen. Das Kapitel behandelt damit den Systemaufbau, also die zweite Ebene des Schichtenmodells. Hier wird der Stand der Forschung auf der technischen Systemebene und die speech-Sicht dargestellt. Aufbauend auf den theoretischen Grundlagen und dem Systemaufbau werden in Kapitel 4 benutzerfreundliche Dialoge im Automobil behandelt. Es wird er¨ ortert, was Benutzerfreundlichkeit bedeutet und was einen benutzerfreundlichen Sprachdialog ausmacht. In diesem Kapitel werden auch verschiedene Ans¨ atze f¨ ur benutzerfreundliche Sprachdialoge aus der aktuellen Forschung aufgegriffen und ihre Anwendbarkeit auf das automobile Umfeld

12

1 Einleitung

diskutiert. Auf das Schichtenmodell bezogen geht es dabei um die oberste und f¨ unfte Ebene. Nachdem in den vorherigen Kapiteln die Ebenen f¨ unf bis zwei behandelt wurden, wird in Kapitel 5 die Beschreibung von Sprachdialogen thematisiert. Konkret geht es um eine maschinenlesbare Beschreibung solcher Dialoge, wie sie in Sprachdialogsystemen verwendet werden. Es werden dabei verschiedene Ans¨ atze und Standards zur Beschreibung von Sprachdialogen vorgestellt. Ebenfalls werden auch kurz Formate und Formalismen von Grammatiken zur Spracherkennung vorgestellt. Aus Sicht des Ebenenmodells geht es bei dieser Thematik um die softwaretechnischen Grundlagen der Dialogerstellung (Ebene 1). Hier mischen sich auch bereits Dialog- und Signalsicht. Mit den bisherigen Kapiteln ist das Schichtenmodell komplett gef¨ ullt worden. Daher kann in Kapitel 6 die teilautomatisierte Modellierung von Dialogen besprochen werden. Konkret wird analysiert, inwieweit die vorhandenen Werkzeuge das Schichtenmodell abdecken und der Bedarf f¨ ur ein neues Werkzeug untersucht. Basierend auf der Bedarfsanalyse wird in Kapitel 7 das Entwicklungswerkzeug DiaGen vorgestellt, welches im Rahmen dieses Werkes entwickelt wurde. Das Werkzeug wird im Detail dargestellt und auf dessen Besonderheiten hingewiesen. Anschließend wird in Kapitel 8 der proaktive TMC-Dialog behandelt. Dabei wird der im Rahmen dieses Werkes und mit Hilfe des in Kapitel 7 vorgestellten Werkzeugs DiaGen entwickelte proaktive Navigationsdialog pr¨asentiert. Zus¨ atzlich werden auch die f¨ ur den Prototypen ben¨otigten Komponenten vorgestellt. Es folgt die Evaluation des Prototypen. Zuletzt erfolgen in Kapitel 9 die Zusammenfassung des Buches und ein Ausblick. Im Anhang wird ein Evaluationsprotokoll des Werkzeugs DiaGen vorgestellt, sowie ein ausf¨ uhrlicher Beispieldialog der beschriebenen TMC-Dialoganwendung. Außerdem wird der f¨ ur die Dialogevaluation verwendete Fragebogen pr¨asentiert.

2 Grundlagen der Dialogtheorie

In diesem Kapitel werden die theoretischen Grundlagen dieses Werkes gelegt. Dabei werden die grundlegenden Begriffe der Dialogtheorie, wie sie in diesem Buch Verwendung finden, definiert. Diese Definitionen dienen den nachfolgenden Kapiteln als Basis.

¨ 2.1 Dialog und Außerung Die Definition des Begriffs Dialog“ ist nicht einfach, da in der allgemeinen ” Linguistik mathematisch motivierte Definitionen kaum verwendet werden. In ¨ den folgenden Abs¨ atzen wird daher zuerst ein Uberblick u ¨ber die verschiedenen Verwendungen des Begriffs in den unterschiedlichen Disziplinen gegeben, um abschließend eine Definition zu erm¨ oglichen. In der allgemeinen Linguistik werden Dialoge als Sonderform des Gespr¨ achs angesehen und ihre Betrachtung somit als Gegenstand der Gespr¨achsanalyse verstanden [Linke et al. 1994]. Da alle im vorliegenden Werk behandelten Systeme jedoch ausschließlich Zwiegespr¨ ache erlauben, wird im Folgenden der Terminus Dialog“ als gleichberechtigt zum Gespr¨ach“ angesehen. ” ” Ein Dialog (engl. dialogue) ist laut [Drosdowski 1990] ein Gespr¨ ach, das zwischen zwei Gruppierungen gef¨ uhrt wird, um sich und die gegenseitigen Standpunkte kennenzulernen oder eine von zwei Personen abwechselnd gef¨ uhrte Rede und Gegenrede. [Lewandowski 1979] definiert einen Dialog als partnerbezogenes Zwiegespr¨ ach, eine Form der interaktionalen Kommunikation, bei ¨ der thematisch und/oder situativ bestimmte, intentional gesteuerte Außerungen an einen Partner gerichtet und beantwortet werden. Im vorliegenden Buch soll in Anlehnung an [M¨oller 1999] unter einem Dialog eine zielorientierte Interaktion zwischen zwei Partnern verstanden werden. Diese Interaktion muss nicht notwendigerweise rein sprachlicher Natur sein; in diesem Werk wird unter einem Dialog grunds¨atzlich eine sprachliche Interaktion verstanden. Dies wird in Definition 2.1 wiedergegeben:

14

2 Grundlagen der Dialogtheorie

Definition 2.1. Ein Dialog ist eine zielorientierte sprachliche Interaktion zwischen zwei Partnern. Eine solche sprachliche Interaktion basiert in einem gesprochen-sprach¨ lichen Dialog auf einer Menge von sprachlichen Außerungen zweier Partner. ¨ Der Begriff der Außerung“ wird in diesem Buch wie folgt definiert: ” ¨ Definition 2.2. Als Außerung wird der Beitrag eines Gespr¨ achsteilnehmers ¨ zu einem Dialog bezeichnet. Eine Außerung wird durch einen Sprecherwechsel begrenzt. Um Kommunikationszyklen in Dialogen beschreiben zu k¨onnen, wurde der englischsprachige Begriff Turn“ eingef¨ uhrt, dessen Definition hier folgt: ” Definition 2.3. Ein Turn bezeichnet einen Kommunikationszyklus zwischen ¨ zwei Dialogpartnern und besteht aus je einer Außerung der beiden Partner. F¨ ur Dialoge mit Dialogsystemen gilt, ein Turn besteht aus einer System- und einer Benutzer¨ außerung. ¨ Mehrere Außerungen k¨ onnen auch u ¨ber die Grenzen eines Turns hinweg zusammengefasst werden. In diesem Fall wird in zwischenmenschlichen Dialogen laut [Jekat-Rommel 1994] von Dialogsequenzen gesprochen. Um entsprechende semantisch zusammengeh¨ orende Einheiten in Dialogen mit einem Dialogsystem zu kennzeichnen, wurde in [Hamerich 2000] der Begriff des Dialogsegments genutzt, der auch in diesem Werk Verwendung findet.

2.2 Dialogregeln Um einen Dialog als zielorientierte Interaktion (vgl. Definition 2.1) ausf¨ uhren zu k¨ onnen, bedarf es einiger Regeln. Diese gelten als sehr wichtig f¨ ur die Kommunikation mit einem Partner (und als ein solcher sollte auch ein Dialogsystem m¨oglichst angesehen werden). Grice stellte in [Grice 1975] vier Maximen f¨ ur die kooperative Kommunikation auf, welche sich als Dialogregeln sehr gut eignen: •

die Maxime der Qualit¨ at besagt, dass nur wahre Informationen kommuniziert werden sollten. Sollte der Wahrheitsgehalt vom Sprecher nicht u uft werden k¨ onnen, muss er seine Zweifel entsprechend ausdr¨ ucken, ¨berpr¨ um den anderen Kommunikationsteilnehmer nicht zu verwirren. • die Maxime der Quantit¨ at definiert, dass Kommunikationsbeitr¨age so informativ wie n¨ otig sein sollten, aber auch nicht detaillierter als n¨otig. Es sollte also die richtige Menge an Informationen transportiert werden. • die Maxime der Relevanz regelt den Inhalt von Beitr¨agen. So sollten Kommunikationsbeitr¨ age inhaltlich zum aktuellen Thema des Dialogs passen und relevant sein.

2.3 Dialogakte

•

15

die Maxime der Modalit¨ at besagt, dass Unklarheiten oder Mehrdeutigkeiten in Kommunikationsbeitr¨ agen zu vermeiden sind. Außerdem sollten Beitr¨ age geordnet sein und nicht zu weit vom Thema wegf¨ uhren.

¨ Diese Maximen sollten in allen Außerungen von Dialogteilnehmern m¨oglichst immer beachtet werden, um eine Erreichung der Dialogziele zu gew¨ahrleisten. Vor allem aber f¨ ur die Kommunikation mit einem Dialogsystem sollten die Grice’schen Maximen gelten. Wenn Benutzer von Dialogsystemen immer ein kooperatives Verhalten zeigen und sich an diese vier Maximen orientieren, kann ein sinnvoller Dialog zur Erreichung eines Dialogziels gew¨ ahrleistet werden. Ebenso stellen diese Regeln eine Erwartung von Dialogteilnehmern an den jeweiligen Dialogpartner dar, dies gilt insbesondere f¨ ur Menschen im Dialog mit einem System. Wenn sich beide Partner (unabh¨ angig davon, ob sie Mensch oder Maschine sind) an diese Regeln halten, ist eine zielorientierte Interaktion im Sinne der Dialogdefinition durchf¨ uhrbar.

2.3 Dialogakte ¨ Wie bereits dargestellt, besteht ein Dialog aus Turns, die wiederum aus Auße1 ¨ onnen allerdings auch weiter unrungen bestehen. Einzelne Außerungen k¨ terteilt werden. Allgemein gibt es dabei neben der syntaktischen Ebene (in welcher die grammatische Struktur untersucht wird) und der Semantik (in welcher es um die Bedeutung des Gesagten, also den Inhalt, geht), noch die ¨ Pragmatik (besch¨ aftigt sich mit dem Sinn von Außerungen und den Absichten eines Sprechers). Seit [Austin 1962] und [Searle 1969] wird in der Linguistik ¨ auf der pragmatischen Ebene eine Außerung einem Sprechakt (engl. speech act) zugewiesen. Diese Theorie der Sprechakte beruht auf der Annahme, dass Aussagen nicht nur zur Beschreibung der Welt dienen k¨onnen, sondern auch zur Aus¨ ubung von kommunikativen Handlungen. Damit wurde der semanti¨ sche Wahrheitswert, auch Proposition genannt, einer Außerung um folgende zus¨ atzliche Ebenen erweitert: • die Lokution, die grammatische Wahrheit, zu deren Analyse die gramma¨ tische Struktur einer Außerung herangezogen wird; • die Illokution, welche die Absichten eines Sprechers beim T¨atigen einer ¨ Außerung ausdr¨ uckt und deren Bewertung vom Verst¨andnis des Dialogpartners abh¨ angig ist; • und die Perlokution, bei welcher die beabsichtigte Wirkung des Sprechers und deren Verst¨ andnis beim Dialogpartners beachtet wird.

1

Dar¨ uberhinaus gibt es in multimodalen Systemen bzw. Dialogen nat¨ urlich noch weitere Ausdrucksm¨ oglichkeiten, wie z.B. Gesten oder taktile Interaktionen, die allerdings f¨ ur dieses Buch nicht relevant sind.

16

2 Grundlagen der Dialogtheorie

F¨ ur Dialogsysteme ist der illokution¨ are Akt der wichtigste. Denn ein Dialogsystem sollte die Absichten eines Sprechers (also die Illokution) m¨oglichst perfekt verstehen und eine entsprechende passende Reaktion initiieren, also eine erfolgreiche Perlokution gew¨ ahrleisten. ¨ Da Sprechakte nur f¨ ur einzelne Außerungen existieren, wird f¨ ur Dialoge eine entsprechende Klassifikation ben¨ otigt. Diese sollte auch logische Paare ¨ von Außerungen zusammenfassen, wie eine erwiderte Begr¨ ußung oder eine beantwortete Frage. Diese Paare kann man in Dialogen zu Dialogakten kombinieren. Einfache Beispiele von Dialogakten sind ,Vorschlag‘, ,Akzeptanz‘ oder ,Ablehnung‘ (vgl. [Jekat et al. 1995]). Im Kontext einer speziellen Dialogdom¨ ane (vgl. Abschnitt 2.7) k¨ onnen so auch Dialogakte wie z.B. ,Abfrage einer Hausnummer‘, ,Best¨ atigung einer Telefonnummer‘ oder ,Eingabe eines Ziels‘ vorkommen. Damit stellen Dialogakte die Beziehung zwischen einzelnen Sprechakten dar, so kann nach einer Abfrage eine Eingabe erfolgen oder nach einem Vorschlag eine Ablehnung. Dialogakte sind von großer Wichtigkeit in der Designphase eines Dialogsystems, denn die Summe aller Dialogakte muss zum Dialogziel (siehe Abschnitt 2.8) f¨ uhren. Des Weiteren h¨ angt die Verwendung von Dialogakten in einem Dialogsystem von der Dialogstrategie (siehe Abschnitt 2.6) ab.

2.4 Dialogmodell Ein Dialogmodell dient der Beschreibung des Dialogflusses in einem Dialogsystem. Unter dem Dialogfluss wird dabei der gesamte m¨ogliche Dialogverlauf von Beginn des Dialogs bis zur Zielerreichung mit allen m¨oglichen Pfaden verstanden. Das Dialogmodell besteht aus Dialogsegmenten und Verkn¨ upfungen dieser Segmente. Es werden aber nicht alle denkbaren Segmente in Modell aufgenommen, sondern nur die, welche vom jeweiligen Entwickler als relevant angesehen werden. Meist sind das die Segmente, welche der Erreichung des Dialogziels (siehe Abschnitt 2.8) des jeweiligen Dialogsystems dienen.2 Im Interesse der Bedienbarkeit kann ein Dialogentwickler dem Modell noch zus¨atzliche Segmente hinzuf¨ ugen, etwa um Hilfestellungen bei auftretenden Fehlern zu geben. Grunds¨ atzlich kann damit festgestellt werden, dass das Dialogmodell die Wissensbasis der Dialogsteuerung in einem Dialogsystem darstellt. Die oben erw¨ ahnte Beschr¨ ankung der Dialogsegmente repr¨asentiert die Einschr¨ ankung der Dialogdom¨ ane, auf die noch in Abschnitt 2.7 eingegangen wird. Ein Dialogsegment im Dialogmodell wird einer Benutzer¨außerung basierend auf dessen illokution¨ aren Akt und der Semantik zugeordnet. Allgemein 2

Allerdings kann es vorkommen, dass bei der Entwicklung Segmente oder Verkn¨ upfungen vergessen werden, in diesem Fall liegt ein sogenannter Designfehler vor.

2.4 Dialogmodell

17

wird dieser zugeordnete illokution¨ are Akt zusammen mit der Semantik auch semantische Repr¨asentation oder auch semantisches Konzept genannt. Jedes Dialogsegment enth¨ alt je nach Modellierungsform und Dialogstrategie eine implizite oder explizite Zuordnung der Systemreaktion auf die Benutzereingabe. Folgt der Dialogablauf den Grice’schen Maximen, sollte dabei jede Benutzer¨ außerung zusammen mit der Systemreaktion ein Paar von zusammenpassenden Dialogakten ergeben (zumindest wenn die Systemreaktion auf der sprachlichen Ebene erfolgt). Wenn ein Dialogmodell implementiert wird, werden in aktuellen Dialogsystemen diese u ¨blicherweise in einer Dialogbeschreibungssprache beschrieben. Kapitel 5 widmet sich diesem Thema. Zur Dialogmodellierung existieren verschiedene Ans¨atze, die im Folgenden n¨aher beschrieben werden. 2.4.1 Zustandsbasierte Modellierung Bei der zustandsbasierten (engl. state-based ) Modellierung werden Dialoge mit Hilfe von deterministischen endlichen Automaten [Hopcroft und Ullman 1979] modelliert. Diese Herangehensweise ist die ¨ alteste und wird auch heute noch genutzt. Die Verwendung von Zustandsmodellen f¨ uhrt zu einem verh¨altnism¨aßig ¨ großen Entwicklungsaufwand, da alle Transitionen (also die Uberg¨ ange von einem Segment zum n¨ achsten) explizit modelliert werden m¨ ussen. Daher sind zustandsbasierte Dialoge im Ablauf h¨ aufig sehr statisch und wenig flexibel. Allerdings hat die explizite Modellierung auch Vorteile. So erlaubt diese Modellierungsart eine hundertprozentig genaue Spezifikation des Dialogablaufs. Auch kann diese sehr einfach nachvollzogen werden, da alle m¨oglichen Dialogpfade ausimplementiert werden. Zudem erlaubt diese Modellierung eine minimalistische Ausf¨ uhrung der Dialogsteuerung, da diese zur Ausf¨ uhrung von zustandsbasierten Dialogbeschreibungen keine zus¨atzliche interne Ablauflogik ben¨ otigt. 2.4.2 Regelbasierte Modellierung F¨ ur die regelbasierte (engl. rule-based ) Modellierung werden keine expliziten ¨ Uberg¨ ange des Zustandsgraphen definiert, sondern Vorbedingungen, Regeln und Ziele formuliert (siehe z.B. [Peckham 1993]). Teilweise wird diese Modellierungsform in der Literatur auch als frame-based bezeichnet [McTear 2004]. Dies bezeichnet eine Auspr¨agung von regelbasierten Dialogmodellen, f¨ ur die es im industriellen Umfeld einen Implementationsstandard gibt (vgl. Abschnitt 5.2.2). Mit diesem Ansatz sind viel flexiblere Dialoge m¨oglich, als mit der zustandsbasierten Modellierung. Die angesprochenen Bedingungen und Regeln werden zur Laufzeit eines Dialogs ausgewertet und k¨onnen je nach Ergebnis zu weiteren Unterdialogen verzweigen. Diese zus¨atzliche Flexibilit¨at kann eine

18

2 Grundlagen der Dialogtheorie

Minimierung des Entwicklungsaufwands bedeuten. Sie wird allerdings mit einer komplexeren Dialogsteuerung erkauft, da diese nun eine zus¨atzliche interne Ablauflogik ben¨ otigt. Da die Regeln in diesem Fall immer zur Dialoglaufzeit ausgewertet werden, kann die Spezifikation des Dialogablaufs komplex werden. In einfachen F¨allen, wenn das Dialogmodell explizit gehalten ist, ist die Spezifikation ¨ahnlich der eines zustandsbasierten Dialogs. Der Dialogablauf ist jedoch auch bei dieser Modellierungsart einfach nachzuvollziehen. Wenn die Anzahl der Regeln allerdings hoch ist, kann die Dialogmodellierung sehr un¨ ubersichtlich werden. Zus¨ atzlich kann auch die Wartung und das Debugging sehr schwierig werden, da bei einer durchgef¨ uhrten Dialogaktion die aktivierten Regeln nicht sofort erkenntlich sein k¨onnen. 2.4.3 Planbasierte Modellierung Bei der planbasierten (engl. plan-based ) Modellierung werden die Absichten eines Sprechers in einem Dialog modelliert, um im Dialogverlauf automatisch erkannt zu werden [Cohen et al. 1990]. Bei diesem Vorgehen ben¨ otigt die Dialogsteuerung neben einer komplexen Logik den Zugriff auf eine Planungskomponente, welche die einzelnen Pl¨ane ausarbeitet. Dabei ist ein Dialogablauf aus dem Modell sehr schwer herauszulesen. Die Spezifikation von solchen Dialogen ist komplexer, als von regelbasierten Modellen. Ein entscheidender Nachteil dieser Technik ist zudem, dass hierbei nicht gew¨ ahrleistet ist, dass bei semantisch identischen Benutzereingaben eine identische Dialogreaktion auftritt. So kann die Planungskomponente Pl¨ane unterschiedlich gewichten oder Absichten werden unterschiedlich interpretiert. Die Kontrolle des Dialogablaufs ist daher sehr schwierig. Daf¨ ur eignet sich dieser Ansatz f¨ ur hochkomplexe Aufgaben, bei denen einzelne Teildialoge miteinander konkurrieren oder viele Vorbedingungen f¨ ur eine Dialogreaktion erf¨ ullt werden m¨ ussen. Die Flexibilit¨ at des Ansatzes ist sehr hoch und die Dialoge werden von Benutzern als intelligent angesehen. Ein Beispiel f¨ ur ein planbasiertes Dialogsystem wird in [Ludwig 2004] vorgestellt. Eine Implementation von planbasierten Dialogen ist der information state approach, bei dem alle im Laufe eines Dialogs anfallenden Daten, sowohl von Ein- und Ausgaben, vom Dialogmanager, als auch vom Backend (also der Datenbank) in einen gemeinsamen Informationszustand geschrieben werden und aus diesem Pl¨ ane f¨ ur die n¨ achsten Dialogschritte abgeleitet werden. Mehr Informationen dar¨ uber sind zu finden bei [Traum und Larsson 2003]. 2.4.4 Statistische Modellierung Die statistische Modellierung beschreibt die Idee, Dialogmodelle aus Dialogdaten zu erlernen [Levin und Pieraccini 1997]. Das Vorgehen ¨ahnelt dem Prinzip der statistischen Spracherkennung. Bei diesem Ansatz werden sehr große Da¨ tenmengen gebraucht, um eine korrekte Klassifizierung von Außerungen f¨ ur

2.4 Dialogmodell

19

das jeweilige Dialogmodul zu erhalten. Genau diese Datenmengen sind aber auch das Problem des Ansatzes. Der Aufwand f¨ ur das Sammeln von entsprechenden Dialogkorpora ist sehr viel h¨ oher, als wenn ein Dialogmodell auf klassischem Wege erstellt und getestet wird. Dieser Ansatz wird daher vor allem f¨ ur Telefonsysteme eingesetzt, bei denen Daten gesammelt werden und das System immer wieder nachtrainiert werden kann. Ein telefonbasiertes statistisches Dialogsystem wird beispielsweise in [Torres et al. 2005] vorgestellt. Bei [M¨ oller 1999] wird ein Werkzeug zur Unterst¨ utzung der Erstellung von statistischen Dialogmodellen pr¨ asentiert. Der im Rahmen der Arbeit von M¨ oller verwendete Trainingskorpus basierte auf Daten aus dem Forschungsprojekt Verbmobil [Wahlster 2000]. Um den Aufwand der Datensammlung zu minimieren wurde in [Chung 2004] ein Dialogsystem basierend auf simulierten Daten erstellt. Um Dialogstrategien aus simulierten Daten lernen zu k¨onnen, wurde dieser Ansatz bei [Georgila et al. 2006] und [Rieser und Lemon 2006] auf unterschiedliche Arten weiterentwickelt. Durch die automatische Transkription von Daten soll der Aufwand f¨ ur die Erstellung eines statistischen Sprachdialogsystems weiter gesenkt werden. F¨ ur ein telefonbasiertes System wird ein solcher Ansatz bei [Syed und Williams 2008] vorgestellt. 2.4.5 Dialogmodellierung in automobilen Systemen Grunds¨ atzlich gelten f¨ ur kommerziell genutzte Dialogsysteme gewisse Besonderheiten f¨ ur die Dialogmodellierung. Dieses Charakteristikum wird von [Pieraccini und Huerta 2008] mit dem Begriff VUI Completeness 3 betitelt und bezeichnet die Notwendigkeit einer vollst¨ andigen und expliziten Spezifikation des Dialogverhaltens eines Dialogsystems in jeder m¨oglichen Situation eines Dialogverlaufs. Ziel dieser Anforderung ist der Ausschluss von ungewollten Endzust¨ anden oder Schleifen im Dialogverlauf, sogar bei komplett undenkbaren oder unsinnigen Eingaben. Es muss daher gegen¨ uber dem Auftraggeber garantiert werden, dass keine Eingabe zu einem undefinierten Systemzustand f¨ uhren kann. Um diese Vollst¨ andigkeit zu gew¨ ahrleisten, wird eine komplette ¨ Spezifikation aller m¨ oglichen Dialogzust¨ ande und der jeweiligen Uberg¨ ange gefordert, um damit den Nachweis zu erbringen, dass alle Dialogschritte zu einem definierten n¨ achsten Zustand f¨ uhren. Zus¨ atzlich zu dieser Spezifikation werden ausf¨ uhrliche Tests verlangt, die Vorlage der resultierenden Testprotokolle wird h¨ aufig ebenfalls erwartet. All dies begr¨ undet sich auch mit den sehr viel h¨ oheren Qualit¨ atsforderungen in der Automobilindustrie, welche aus der faktischen Unm¨ oglichkeit resultieren, nach Auslieferung eines Fahrzeugs mit eingebettetem Dialogsystem, dieses mittels Updates zu korrigieren. Grunds¨atzlich besteht zwar die M¨ oglichkeit des R¨ uckruf eines Automobils in die Werk¨ statt umd dabei Anderungen an ausgelieferten Fahrzeugen durchzuf¨ uhren. 3

Die Abk¨ urzung VUI steht dabei f¨ ur Voice User Interface.

20

2 Grundlagen der Dialogtheorie

Dies Vorgehen ist jedoch extrem teuer, aufw¨ andig und schadet zudem stark dem Image eines Herstellers. Aus diesem Grund erfolgt dies ausschließlich zur Behebung sicherheitskritischer M¨ angel. F¨ ur die im Fokus des vorliegenden Werkes liegenden automobilen Dialogsysteme (vgl. Kapitel 3), gilt die Forderung nach einer VUI Completeness erst recht. Denn schließlich stellen zum einen die Automobilhersteller als Auftraggeber der Systeme entsprechende Anforderungen an die Spezifikation und zum anderen muss das System von Autofahrern w¨ ahrend der Fahrt bedient werden. Das heißt, die Dialogsituationen und -¨ uberg¨ ange m¨ ussen f¨ ur einen Benutzer immer eindeutig sein, auch wenn die Konzentration zum großen Teil f¨ ur die Fahraufgabe ben¨ otigt wird. Eine weitere Einschr¨ankung bedeutet, dass Automobilhersteller zwar genaue Anforderungen an eine Sprachbedienung haben, Nutzerdaten aber u ugung stellen. Dies liegt zum ¨blicherweise nicht zur Verf¨ einen daran, dass echte Benutzerdaten aus Datenschutz- und Speichergr¨ unden nicht mitgeschnitten werden und zum anderen eine Datensammlung extrem aufw¨ andig und teuer ist. Die genannten Einschr¨ ankungen disqualifizieren damit einige der oben vorgestellten Dialogmodellierungsans¨ atze f¨ ur den Einsatz in automobilen Sprachbedienungen. Im Einzelnen bedeutet dies: •

Ohne initiale Nutzerdaten ist der Aufwand f¨ ur die Erstellung eines statistischen Dialogmodells nahezu unbezahlbar. Da zudem jeder Automobil¨ hersteller eine andere Bedienphilosophie vertritt, ist auch die Ubertragbarkeit von gewonnenen Daten nicht gew¨ahrleistet. Außerdem wird von einem Sprachbediensystem eine immer gleiche Systemreaktion erwartet, daher bietet auch der Mitschnitt von Nutzerdaten w¨ahrend des Betriebes keine Vorteile. Und noch dazu w¨ are eine Datensammlung aus Speicherplatzgr¨ unden gar nicht durchf¨ uhrbar, wie in Kapitel 3 ausf¨ uhrlich dargestellt wird. Daher scheidet die statistische Dialogmodellierung aus. • Da bei der Verwendung eines Dialogplaners eine exakte Spezifikation des Dialogflusses nicht m¨ oglich ist und außerdem identische Systemreaktionen nicht garantiert werden k¨ onnen, eignet sich auch der planbasierte Ansatz nicht zur Modellierung von Dialogsystemen im Automobil. • Eine regelbasierte Modellierung kann die verlangte Testbarkeit von Sprachdialogen erschweren. Zus¨ atzlich ist eine u ¨bersichtliche Spezifikation eines regelbasierten Ansatzes nur mit sehr hohem Aufwand zu erstellen. Damit ist der regelbasierte Ansatz zwar durchaus m¨oglich, wird allerdings in der Praxis ebenfalls nicht verwendet. • Die vom Auftraggeber erwartete lesbare Spezifikation des Dialogablaufs wird u ¨blicherweise als Ablaufdiagramm (engl. flowchart) geliefert. Um diese Spezifikation wirklich lesbar zu halten, ist eine zustandsbasierte Modellierung perfekt geeignet. Zudem ist diese Modellierungsform die einzige, die eine nachweisbare Testbarkeit des gesamten Ablaufs erlaubt. Damit spricht die Spezifizierbarkeit und Testbarkeit f¨ ur diese Modellierungsform,

2.5 Dialogsteuerung

21

obwohl der Implementierungsaufwand gegen¨ uber den anderen Formen sehr viel h¨ oher ist. Aus diesen Gr¨ unden werden Sprachbediensysteme im Automobil mittels Zust¨ anden modelliert. Es gibt sogar Werkzeuge f¨ ur die Spezifikation und Simulation von Sprachbediensystemen basierend auf Zustandsmodellen, wie in Abschnitt 6.1.4 dargestellt wird. Die Modellierung ist zwar – wie bereits dargestellt – aufw¨ andiger, daf¨ ur sprechen aber die lesbare Spezifikation, gute Testbarkeit und einfach zu implementierende Dialogausf¨ uhrung f¨ ur den Ansatz. Daher stellt die zustandsbasierte Modellierung das Mittel der Wahl in diesem Kontext und damit auch f¨ ur das vorliegende Buch dar.

2.5 Dialogsteuerung Wie bereits angesprochen, muss ein Dialogmodell auch ausgewertet und Aktionen initiiert werden. Diese Aufgabe u ¨bernimmt die Dialogsteuerung, die auch Dialogmanager oder Dialogkontrolle genannt wird. Sie ist die ausf¨ uhrende Komponente in einem Dialogsystem. Sie besteht aus dem Dialogmodell und den darauf fußenden Interpretationsvorschriften. In [Traum und Larsson 2003] werden die wichtigsten Funktionen f¨ ur eine Dialogsteuerung wie folgt definiert: • • • •

Aktualisierung des Dialogkontextes auf Basis des Dialogverlaufs; Zur Verf¨ ugungsstellung von kontextabh¨ angigen Dialogzust¨anden; Kommunikation mit weiteren Komponenten (z.B. Datenbank, Planer, zu steuerndes Ger¨ at); Entscheidung u ¨ber den weiteren Dialogfluss.

Folgende zus¨ atzliche Aufgaben nimmt die Dialogsteuerung außerdem noch wahr: • • •

Interpretation des Dialogmodells; Kommunikation mit Sprachein- und -ausgabeger¨aten (z.B. ASR, TTS); Aufruf von Unter- und Teildialogen.

Bei Verwendung einer Dialogbeschreibungssprache kann die Interpretation dieser Sprache in der Dialogsteuerung erfolgen, sie kann aber auch in eine weitere Komponente ausgelagert werden. In Sprachbediensystemen stellt der Dialogmanager die einzige aktive Komponente dar. Alle anderen Komponenten (Spracherkennung, Sprachausgabe, etc.) sind solange passiv, bis der Benutzer den Dialogstart durch Druck auf den entsprechenden Knopf oder Hebel ausf¨ uhrt. In diesem Fall leitet der Dialogmanager die Befehle weiter und sorgt f¨ ur die Abarbeitung der anstehenden Aufgaben.

22

2 Grundlagen der Dialogtheorie

2.6 Dialogstrategie Als Dialogstrategie wird die Strategie eines Dialogs bezeichnet, um das jeweilige Dialogziel (vgl. Abschnitt 2.8) zu erreichen. In der Literatur werden verschiedene Strategien unterschieden, im Folgenden werden die drei wichtigsten aufgef¨ uhrt. 2.6.1 Direktive Dialogstrategie Bei der direktiven Dialogstrategie ist das zugrundeliegende System rein passiv und wird nur durch einfache Kommandos gesteuert. Entsprechend heißen die Dialoge dieser Strategie auch Kommandodialoge (engl. command and control dialogues). Diese Dialoge zeichnen sich durch ein sehr kleines Vokabular aus und werden meist nur f¨ ur sehr stark eingegrenzte Dom¨anen eingesetzt. Das Dialogmodell von Kommandodialogen wird meist basierend auf endlichen Automaten in einem zustandsbasierten Dialogmodell (vgl. Abschnitt 2.4.1) formuliert. Ein Beispiel sind die ersten Programme zur sprachlichen Steuerung der Arbeitsfl¨ ache auf Computern. Als einzige Reaktion wurde dabei die gew¨ unschte Handlung ausgef¨ uhrt (wenn der Befehl korrekt erkannt wurde), eine andere R¨ uckmeldung gaben diese Systeme nicht. 2.6.2 Reaktive Dialogstrategie Eine Dialogstrategie heisst reaktiv, wenn auf jede Benutzeranfrage genau eine Antwort folgt. Im Unterschied zur direktiven Strategie ist das Vokabular eines solchen Systems sehr viel breiter angelegt. Dialoge dieser Strategie sind gesteuert und heißen daher systemgesteuert (engl. system driven dialogues). 4 ¨ Da diese Systeme meist nicht in der Lage sind, Uberbeantwortungen zu verarbeiten, werden u uebenen bis ¨blicherweise mehrere Dialogschritte bzw. Men¨ zur Erreichung des Dialogziels durchschritten. Auch in diesem Fall werden endliche Automaten zur Dialogmodellierung genutzt (vgl. 2.4.1). Ein klassisches Beispiel f¨ ur ein Dialogsystem mit einer reaktiven Dialogstrategie ist die automatische Fahrplanauskunft der Deutschen Bahn AG (vgl. Abschnitt 3.7.3). 2.6.3 Kooperative Dialogstrategie Dialoge dieser Strategie zeichnen sich durch eine Mischung von aktiven und passiven Phasen aus, beide Dialogpartner k¨ onnen also die Initiative u ¨bernehmen. Allerdings m¨ ussen in diesem Fall immer die Benutzerabsichten erkannt 4

¨ Uberbeantwortung heißt, dass mehr Informationen gegeben werden, als zu diesem Zeitpunkt verlangt wurden. Mehr dazu siehe in [Wahlster et al. 1983].

2.7 Dialogdom¨ ane

23

¨ werden, dazu ist tlw. auch Uberbeantwortung zul¨assig. Dialoge dieser Strategie heißen gemischt initiativ (engl. mixed initiative dialogues). F¨ ur diese Dialogstrategie werden regelbasierte (siehe Abschnitt 2.4.2), planbasierte (vgl. Abschnitt 2.4.3) oder auch statistische (siehe Abschnitt 2.4.4) Dialogmodelle verwendet. Die Philips Bahnauskunft (vgl. Abschnitt 3.7.3) ist eines der bekanntesten Beispiele f¨ ur ein Dialogsystem mit gemischter Initiative. 2.6.4 Mischformen Es ist durchaus u ur eine Dialoganwen¨blich, verschiedene Dialogstrategien f¨ dung zu nutzen. Die Auswahl einer konkreten Strategie kann dabei z.B. am Erfahrungsgrad des aktuellen Benutzers (Benutzermodellierung) oder vom aktuellen Dialogschritt abh¨ angen. So ist es u ¨blich, weniger erfahrene Benutzer mit einer reaktiven und z.T. sogar direktiven Dialogstrategie durch einen Dialog zu f¨ uhren, um ein Dialogziel schnell zu erreichen und ein Scheitern des Dialogs m¨oglichst zu verhindern. Erfahrene Benutzer, die bereits wissen, welche Angaben ein Dialogsystem ben¨ otigt, k¨ onnen dann einen Dialog mit gemischter Initiative vorfinden. In diesem Fall k¨ onnen Benutzer m¨ oglichst viele Angaben auf einmal machen und das System fragt eventuell fehlende Daten nach. Bei den meisten Sprachsteuerungen f¨ ur Kfz (vgl. Abschnitt 3.6.7) wird f¨ ur die reine Ansteuerung von Ger¨ aten, wie z.B. Audioger¨aten, auf eine direktive Strategie zur¨ uckgegriffen. Hauptgrund daf¨ ur ist, dass dies eine Verk¨ urzung des Dialogs erlaubt. Zudem wurde in internen Untersuchungen nachgewiesen, dass Benutzer bei der Steuerung von Audioger¨ aten kein zus¨atzliches akustisches Feedback des Sprachsystems h¨ oren m¨ ochten, ein Umschalten der Audioquelle ist ebenso klar h¨ orbar und reicht als Best¨ atigung daher meist aus. F¨ ur komplexere Aufgaben, wie z.B. die Eingabe einer Telefonnummer wird dagegen gerne eine kooperative Strategie eingesetzt. Dies hat den Grund, einem Benutzer bei der Eingabe einer Telefonnummer freie Wahl bei der Art der Eingabe zu lassen – so kann er entweder die komplette Nummer auf einmal oder aber blockweise eingeben.

2.7 Dialogdom¨ ane Eine wichtige Rolle bei jedem Dialogsystem spielt die zugrundeliegende Dom¨ane. Von ihr h¨ angt z.B. die Dialogstrategie und die dazu passende Dialogmodellierungsart ab. Beides hat direkte Auswirkungen auf das Vokabular des Dialogsystems, welches wiederum die Dom¨ ane abbildet. Dieses Vokabular ist im Gegensatz zum Vokabular der normalen zwischenmenschlichen Dialoge sehr eingeschr¨ ankt und kann daher auch als eine Fachsprache [von Hahn 1980] bezeichnet werden.

24

2 Grundlagen der Dialogtheorie

Diese Dom¨ anenbeschr¨ ankung ist der Grund, dass beispielsweise ein Fahrplaninformationssystem keine Wetterausk¨ unfte geben kann. Der Hintergrund f¨ ur Dom¨ anenbeschr¨ ankungen ist vor allem in der Spracherkennung zu finden. Denn je eingeschr¨ ankter das Vokabular eines Spracherkenners ist, desto gr¨oßer ist die Wahrscheinlichkeit einer guten Spracherkennrate. Dies gilt allerdings nur dann, wenn Benutzer auch nur das tats¨ achlich m¨ogliche Vokabular verwenden. Ansonsten treten sehr h¨ aufig sogenannte out of vocabulary Fehler auf. Um diesen Effekt zu minimieren, sollte daher beim Design eines Sprachdialoges (vgl. Abschnitt 2.10) dem Benutzer die Beschr¨ankung des Vokabulars m¨ oglichst gut vermittelt werden. Zudem sollten Benutzer immer kooperativ auftreten (vgl. Abschnitt 2.2), von einem im Grice’schen Sinne kooperativen Benutzer kann eine Einhaltung der Dialogdom¨ane erwartet werden.

2.8 Dialogziel Wie bereits in Definition 2.1 formuliert wurde, ist ein Dialog eine zielorientierte Interaktion, also wird jeder Dialog immer mit einem Ziel gef¨ uhrt. F¨ ur den zwischenmenschlichen Smalltalk trifft dies vielleicht nur indirekt zu, f¨ ur die Interaktion mit Sprachdialogsystemen aber ist dies durchweg zutreffend. Je nach Art des Systems ist das Ziel entweder die Erteilung einer Auskunft oder die Durchf¨ uhrung einer Aktion. Das Dialogziel ist grunds¨ atzlich unabh¨ angig von der verwendeten Dialogstrategie und sollte in einem Dialogsystem immer erreichbar sein.5 Daher m¨ ussen alle in einem Dialogsystem verwendeten Dialogakte zu diesem Ziel hinf¨ uhren.

2.9 Dialogparameter Um mit einem Dialogsystem das entsprechende Dialogziel zu erreichen, werden in der Regel Dialogparameter ben¨ otigt. Dies k¨ onnen Angaben vom Benutzer sein, wie z.B. ein Zielort in einem Navigationsdialog. Die Dialogparameter sind unabh¨ angig von der gew¨ahlten Dialogstrategie. Sie k¨ onnen allerdings je nach verwendeter Strategie mit unterschiedlichen Kombinationen von Dialogakten vom Benutzer angefordert werden. Damit kann jeder Dialogakt, der vom Benutzer ausgeht, ein Dialogparameter sein. Allerdings muss nicht jeder dieser Dialogparameter direkt zum Dialogziel f¨ uhren. Wenn z.B. der Benutzer die Wiederholung der letzten System¨außerung w¨ unscht, f¨ uhrt dies bei der Zielerreichung nicht zu einem Fortschritt. 5

Die Erreichbarkeit eines Dialogziels muss bei kommerziellen Systemen i.d.R. durch Testprotokolle nachgewiesen werden und wird mit dem Begriff VUI Completeness beschrieben. Vgl. 2.4.5.

2.10 Dialogdesign

25

2.10 Dialogdesign Unter Dialogdesign wird allgemein die Arbeit des Erstellens eines Sprachdialogs verstanden. Grunds¨ atzlich ist mit dem Dialogdesign daf¨ ur Sorge zu tragen, dass das resultierende Dialogsystem den Grice’schen Maximen, wie in Abschnitt 2.1 vorgestellt, so weit wie m¨ oglich gen¨ ugt. Des Weiteren existiert mit DIN EN ISO 9241 eine international anerkannte Industrienorm f¨ ur die Ergonomie der Mensch-System-Interaktion. Insbesondere Teil 110 (fr¨ uher Teil 10) ist hier erw¨ ahnenswert, da er die Grunds¨atze der Dialoggestaltung in diesem Bereich festschreibt. Die Norm bezieht sich zwar auf Dialoge mit graphischen Benutzeroberfl¨ achen, allerdings lassen sich die Inhalte auf die sprachliche Interaktion u ¨bertragen [Salmen 2002]. Das spezielle Augenmerk eines Dialogdesigners sollte auf dem Dialogfluss liegen. Schließlich soll ein Sprachdialog eine ergonomische Mensch-MaschineSchnittstelle mit einem einpr¨ agsamen und intuitiven Dialogverhalten darstellen. Im Dialogdesign werden daher sowohl die groben Linien eines Dialogs, wie die Dialogspezifikation, als auch die Details bearbeitet. Als entscheidende Details werden vor allem die Wortwahl (engl. wording) f¨ ur System¨außerungen, auch Prompts genannt, und die jeweiligen Gegenst¨ ucke im Sprachmodell bzw. der Grammatik angesehen. Eine sehr wichtige Bedingung f¨ ur das Dialogdesign ist dabei die Konsistenz. So sollten Begriffe, welche in den Prompts verwendet werden, auch von der Spracherkennung verstanden werden. Da Spracherkenner immer noch keine hundertprozentigen Erkennungsraten haben, ist es u.a. Aufgabe des Dialogdesigns, die Systemprompts entsprechend so zu gestalten, dass nur bestimmte Benutzer¨außerungen des Benutzers darauf folgen k¨ onnen und so die Grammatik an dieser Stelle m¨oglichst wenige Alternativen aufweist. So macht es z.B. einen großen Unterschied, ob der Eingangsprompt in einem Navigationsdialog der in Abbildung 2.1 dargestellten Version 1 oder der Version 2 entspricht.

(Version 1)

Wohin m¨ ochten sie navigieren?

(Version 2)

Bitte sprechen sie den Zielort.

Abbildung 2.1. Verschiedene Eingangsprompts f¨ ur einen Navigationsdialog

Bei Version 1 kann es z.B. auch Benutzer¨ außerungen wie nach Hamburg“ ”¨ oder sogar nach Ulm in die S¨ oflinger Straße“ geben. Beide Außerungen er” fordern eine entsprechend komplexe Grammatik, die potentiell zu vermehrten Erkennfehlern f¨ uhren kann. Version 2 hingegen fordert explizit nur zur Nennung eines Ortsnamens auf, Straßennamen und ¨ahnliches sollten hier nicht gesprochen werden. Die Verwendung solcher spezifischen Prompts ist bei kommerziellen Systemen g¨ angige Praxis (vgl. [Pieraccini und Huerta 2005]).

26

2 Grundlagen der Dialogtheorie

Da Fehlerkennungen trotzdem nicht ausgeschlossen werden k¨onnen, liegt ein weiterer Schwerpunkt des Dialogdesigns auf der Fehlerbehandlung. Dieses umfasst sowohl die Behandlung von Benutzerfehlern, als auch das Angebot einer Hilfestellung u onnen sogar h¨aufige Fehlerf¨alle spe¨ber Hilfedialoge. Es k¨ ziell modelliert werden, um eine entsprechende Behandlung zu erm¨oglichen [Wang et al. 2003]. Zusammengefasst ergeben sich folgende Punkte, die f¨ ur ein gutes Dialogdesign zu beachten sind (nach DIN EN ISO 9241-110 und [Salmen 2002]): • Dialoge sollten so gestaltet sein, dass sie einen Benutzer bei seiner Aufgabe unterst¨ utzen ohne zus¨ atzliche Belastung zu erzeugen (Aufgabenangemessenheit); • Dialoge sollten unmittelbar verst¨ andlich sein oder wenigstens eine Hilfefunktionalit¨at beinhalten, um den Benutzer zu f¨ uhren (Selbstbeschreibungsf¨ ahigkeit); • Dialoge sollten konsistent gestaltet werden, um den Ablauf f¨ ur Benutzer durchschaubar und vorhersehbar erscheinen zu lassen (Erwartungskonformit¨at); • Benutzerfehler und Fehlerkennungen der Spracherkennung sollten f¨ ur Benutzer erkennbar sein und mit m¨ oglichst wenig Aufwand behoben werden k¨ onnen (Fehlerrobustheit). F¨ ur weitere Informationen u ¨ber Dialogdesign sei an dieser Stelle auf folgende Literatur verwiesen [Bernsen et al. 1998, Suhm 2003, Boros 2004, Tomko und Rosenfeld 2004c].

2.11 Zusammenfassung In diesem Kapitel wurden die grundlegenden Begriffe der Dialogtheorie eingef¨ uhrt. Dabei wurde die spezielle Dom¨ ane der Sprachdialogsysteme im Automobil, welche die Grundlage dieses Werkes darstellen, beachtet. Da diese Anwendung einen absoluten Spezialfall darstellt und u ¨blicherweise in der klassischen Lehre oder Literatur nicht vertreten ist, wurde an allen wichtigen Stellen in diesem Kapitel auf die Besonderheit dieser Anwendungsform Bezug genommen. Die auf diese Art eingef¨ uhrten Begriffe werden in den folgenden Kapiteln wieder aufgegriffen und ggf. weiter ausgef¨ uhrt, um die Einzelheiten eines kompletten Dialogsystems darzustellen. Die in diesem Kapitel erw¨ahnten Begrifflichkeiten stellen die Basis f¨ ur die bereits in Abschnitt 1.3 erw¨ahnten Schichten der Kommunikation und Linguistik dar. Im n¨ achsten Abschnitt wird auf die erste technische Entwicklungsebene der Systemstruktur n¨aher eingegangen.

3 Sprachdialogsysteme im Automobil

Dieses Werk besch¨ aftigt sich mit Sprachdialogsystemen im Automobil, die (wie bereits in Abschnitt 2.4.5 erw¨ ahnt wurde) eine absolute Sonderform unter den Sprachdialogsystemen darstellen. Da Dialogsysteme im Kfz zudem in der Lehre und Literatur kaum betrachtet werden, wird in diesem Kapitel der Stand der Technik von Dialogsystemen im Automobil beschrieben. Damit schafft dieses Kapitel die technischen Grundlagen dieses Werkes. Zuerst wird im Folgenden auf die Frage eingegangen, warum Sprachsysteme u ¨berhaupt im Auto eingesetzt werden. Anschließend wird der Begriff des Dialogsystems, wie er in diesem Buch Verwendung findet, definiert. Im Anschluss werden die grunds¨ atzlichen Anforderungen an Sprachdialogsysteme im Automobil von Seiten der Kfz-Hersteller beschrieben. Anschließend wird die Architektur und Funktionsweise von Dialogsystemen im Automobil dargestellt. Dabei wird auch auf die einzelnen Komponenten eines solchen Systems im Detail eingegangen. Danach wird die Integration von Sprachdialogsystemen in ein Automobil beschrieben. Weiterhin werden die wichtigsten Funktionalit¨aten existierender Ger¨ ate dargestellt. Abschließend werden die eingebetteten Sprachdialogsysteme, wie sie in Automobilen vorkommen, den serverbasierten Dialogsysteme gegen¨ ubergestellt. Es werden die Gemeinsamkeiten und Unterschiede der beiden Systemarten diskutiert.

3.1 Warum Sprache im Automobil? Die Anzahl der Funktionen im Fahrzeug steigt seit Jahren stetig an [Hassel 2006]. Vor allem im Bereich der sogenannten Infotainmentsysteme 1 hat in den letzten Jahrzehnten ein großer Funktionszuwachs stattgefunden. Alles fing mit dem Radio an, welches 1922 erstmals in ein Automobil verbaut wurde und das heute in fast jedem Kfz zu finden ist [GFU 2006]. Hinzu kamen 1

Als Infotainmentsystem wird dabei die Summe aus Audio- und Navigationsger¨ aten zusammen mit einer Telefonsteuerung im Kfz angesehen.

28

3 Sprachdialogsysteme im Automobil

Audioabspielger¨ ate, wie Kassettenspieler und CD-Player, dann Autotelefone (urspr¨ unglich Festeinbauten, jetzt in der Regel per Freisprecheinrichtung angeschlossene Mobiltelefone) und schlussendlich seit Mitte der Neunziger Jahre des letzten Jahrhunderts Navigationsger¨ ate. Daneben gibt es inzwischen in fast jedem Automobil (zumindest optional) weitere Ger¨ate, wie Bremsassistent, Klimaanlage, Bordcomputer, Tempomat, Einparkhilfe, Abstandsradar, etc. Bei dieser Summe von Ger¨ aten gibt es Bef¨ urchtungen, dass es im Automobil zu einem u ¨berfrachteten Armaturenbrett kommen kann, welches ¨ mehr Ahnlichkeit mit dem Cockpit eines Flugzeugs habe als mit einem Kfz [Labiale 1997]. Dieses Szenario kann aber auch Vorteile haben: So ist es laut [Nielsen 1993] f¨ ur die optimale Bedienbarkeit wichtig, dass f¨ ur jede Funktion ein eigenes Bedienelement existiert.2 Allerdings verdeutlicht die leicht u ¨bertriebene Illustration in Abbildung 3.1, dass diese Ansicht f¨ ur den Einsatz im Automobil nicht tauglich ist. Schließlich soll der Fahrer sich vor allem um das Fahren k¨ ummern, die Augen auf die Straße vor sich und die H¨ande am Lenkrad haben. Denn im Vergleich zum Flugzeug gibt es im Kfz (noch) keinen Autopiloten, der den Fahrer von Routineaufgaben entlastet.

¨ Abbildung 3.1. Uberfrachtetes Armaturenbrett im Kfz. (Quelle: HBAS)

Neben dem Autopiloten werden in einem Flugzeug entsprechend viele Funktionen auch ben¨ otigt, um von A nach B zu gelangen. In einem Automobil dient dagegen ein Großteil der Zusatzfunktionen ausschließlich der Unterhaltung oder dem Komfort w¨ ahrend der Fahrt und nicht dem unmittelbaren Zweck der Fortbewegung. Daher waren die Automobilhersteller gezwungen, f¨ ur die immer neuen Funktionen eine neue Bedienphilosophie zu entwickeln, welche benutzerfreundlich, bedienbar und komfortabel war, aber nicht an ein Flugzeug erin2

Nat¨ urlich hat sich Nielsen bei dieser Aussage nicht auf automobile Ger¨ ate bezogen.

3.1 Warum Sprache im Automobil?

29

nerte. Die L¨ osung dieses Problems ist das Fahrerinformationssystem (FIS), in welchem die verschiedenen Komfort- und Infotainmentfunktionen geb¨ undelt wurden. Gemeinsam ist all diesen Systemen, dass sie die Anzahl der Kn¨opfe und Schalter f¨ ur nicht fahrrelevante Aufgaben minimieren, indem eine zentrale Anzeige- und Bedieneinheit verwendet wird. Diese erlaubt den Zugriff auf alle Funktionen u ustruktur. Da jedoch jeder Hersteller seine eigene ¨ber eine Men¨ Bedienphilosophie verfolgt, gibt es hier sehr unterschiedliche Ans¨atze. So variiert die Bedieneinheit stark je nach Automobilhersteller. Zur besseren Illustration werden in Abschnitt 3.5 die unterschiedlichen Infotainmentsysteme der deutschen Premiumhersteller beschrieben. Das Prinzip der Men¨ usteuerung, wie es in allen FIS zum Einsatz kommt, wurde von graphischen Benutzeroberfl¨ achen u ¨bernommen. Ebenso wie bei letzteren werden auch im Automobil Funktionen u ¨ber mehr oder weniger einfache Men¨ ustrukturen erreicht. Dazu wird neben einem grunds¨atzlichen Verst¨ andnis f¨ ur Men¨ ustrukturen auch ein visuelles Feedback ben¨otigt. Dies ist vor allem aus Gr¨ unden der Sicherheit ein klarer Nachteil. So wurde z.B. bei [Rockwell 1972] nachgewiesen, dass w¨ ahrend der Fahrt die r¨aumliche und visuelle Wahrnehmung extrem beansprucht werden. Wenn nun diese Modalit¨aten noch zus¨ atzlich durch die haptische Bedienung von Ger¨aten ausgelastet werden, kann sich dies nachteilig auf das Fahrverhalten auswirken. Nach der Theorie der multiplen Ressourcen von [Wickens und Hollands 1999] sollten daher besser die nicht mit der Hauptaufgabe besch¨aftigten Modalit¨aten f¨ ur fahrfremde Aufgaben, wie sie die Steuerung von Infotainment-Ger¨aten darstellt, genutzt werden. Es bleiben die sprachliche und auditive Modalit¨at, die w¨ ahrend der Fahrt kaum genutzt werden und sich daher gut zur Kontrolle von Infotainment-Ger¨ aten eignen [Akyol et al. 2001]. Auch [Merat 2003] hat nachgewiesen, dass eine auditive Zweitaufgabe w¨ahrend der Fahrt das Fahrverhalten nicht systematisch beeintr¨ achtigt. Dies wird von [Boer 2001] unterst¨ utzt, der das Lenkverhalten von Probanden untersucht hat. In dieser Studie wurde nachgewiesen, dass Aufgaben, welche r¨aumliche Ressourcen beanspruchen, zu einem 90 %igen Anstieg von unvorhersehbarem, ineffizientem Lenkverhalten beitragen, dagegen f¨ uhren Aufgaben mit Nutzung der sprachlichen Ressourcen nur zu einer Zunahme von 10%. Auch bei der Reaktionszeit gilt ¨ ahnliches: bei Nutzung der sprachlichen Ressourcen wird 26% mehr Reaktionszeit ben¨ otigt, bei r¨ aumlichen Ressourcen nimmt die Reaktionszeit um 74% zu. Das bedeutet zwar, dass auch eine Sprachbedienung die Reaktionszeit verl¨ angert, allerdings ist der Anstieg der Reaktionszeit bei der haptischen Bedienung sehr viel st¨ arker vorzufinden. Den Effekt der Belastung durch Sprechen erkl¨ art [Vollrath 2005] mit der emotionellen oder kognitiven Belastung von Gespr¨ achen. Normale sachliche Gespr¨ ache - wie sie mit einer Sprachbedienung u ¨blich sein sollten - wirken sich hier sehr viel weniger nachteilig aus. Das heißt, wenn eine Sprachbedienung einfach verst¨andlich ist, kann sie den Fahrer sinnvoll w¨ ahrend der Fahrt unterst¨ utzen und zur Sicherheit des Fahrers beitragen. Damit kann der Einsatz von Sprache im Automobil klar mit Sicherheitsaspekten begr¨ undet werden.

30

3 Sprachdialogsysteme im Automobil

Doch der Einsatz einer Sprachbedienung bietet noch weitere Vorteile. So erlaubt sie auch einen komfortablen und teilweise sogar schnelleren Zugriff auf einzelne Funktionen als eine haptische Bedienung. Dies gilt umso mehr, je problematischer einem Benutzer die Verwendung von Men¨ ustrukturen eines FIS f¨ allt. Zus¨ atzlich bieten auch sogenannte Shortcuts den gezielten direkten Zugriff auf h¨ aufig genutzte Funktionen der Sprachbedienung. Damit k¨onnen in sehr kurzer Zeit mehrere haptische Bedienschritte auf einmal erledigt werden. So kann beispielsweise die Eingabe eines Ziels im Navigationssystem per Sprache einfach und schnell erledigt werden, wie in Abschnitt 3.6.3 beschrieben. Haptisch m¨ ussen dagegen die Buchstaben eines Orts- oder Straßennamens einzeln mit dem Dreh-/Dr¨ ucksteller am Ger¨ at eingegeben werden. Ein sehr umst¨andlicher, zeitraubender und w¨ ahrend der Fahrt mitunter sogar gef¨ahrlicher Vorgang.3 Und schlussendlich ist eine Sprachbedienung immer noch ein innovatives Ausstattungsdetail, welches modern und auf dem neuesten Stand der Technik ist. Dies stellt f¨ ur viele K¨ aufer ein wichtiges Kriterium dar. Zusammengefasst heißt das, eine Sprachbedienung bietet eine sichere, komfortable und innovative M¨ oglichkeit, Infotainmentger¨ate w¨ahrend der Fahrt zu bedienen. Damit verbindet die Sprachsteuerung Sicherheit, Komfort und Innovation in einem Ger¨ at. Bleibt die Frage, ob ein Sprachdialogsystem im Automobil auch vom Fahrer genutzt wird. [Cameron 2000] stellte fest, dass Nutzer Spracheingabe sehr wahrscheinlich verwenden, wenn wenigstens eins der folgenden Kritieren zutrifft: • Der Nutzer hat keine andere Wahl. • Die Verwendung eines Sprachdialogsystems verletzt nicht die Privatsph¨are des Nutzers. • H¨ ande oder Augen sind mit anderen T¨ atigkeiten besch¨aftigt. • Das Sprachdialogsystem bietet eine schnellere Interaktion als jede andere Alternative. Der Einsatz einer Sprachbedienung im Auto macht demnach sehr viel Sinn. Denn bis auf das erste Kriterium sind alle Punkte hier zutreffend. In der Regel befinden sich die meisten Fahrer alleine in ihrem Automobil, die Privatsph¨are wird also bei der Nutzung eines Sprachsystems nicht verletzt. Daneben sollten beim Autofahren die H¨ ande am Steuer und die Augen auf die Straße gerichtet sein, wie auch bereits oben dargestellt wurde. Und schlussendlich ist die Verwendung von Sprachbefehlen in vielen F¨ allen durchaus schneller, als die Bet¨ atigung verschiedener haptischer Kontrollen. Damit kann Sprachbedienung im Kfz wirklich als eine Erfolgsgeschichte [Hanrieder 2004] bezeichnet werden: die Systeme bieten Sicherheit und Komfort, gelten gleichzeitig als hochgradig innovativ und werden zudem von den 3

Daher wird in einigen Fahrzeugen die haptische Bedienung des Navigationsger¨ ats w¨ ahrend der Fahrt deaktiviert.

3.2 Systemdefinition

31

Benutzern auch akzeptiert und gekauft. Dies f¨ uhrt dazu, dass Sprachbedienungen bei immer mehr Automobilherstellern verf¨ ugbar sind. Außerdem sind die Systeme nicht mehr ausschließlich auf die Oberklasse beschr¨ankt, auch in der Mittelklasse haben sich die Systeme bereits durchgesetzt. Und als sprachbediente Freisprecheinrichtung ist die Sprachsteuerung sogar optional f¨ ur Kleinwagen erh¨ altlich.

3.2 Systemdefinition Nachdem die Gr¨ unde f¨ ur den Einsatz einer Sprachbedienung im Automobil dargestellt wurden, werden in diesem Abschnitt die Begriffe Sprachdialogsystem und Sprachbediensystem definiert. 3.2.1 Sprachdialogsystem Dialogsysteme sind sprachverstehende Systeme, d.h. Systeme, welche eine nat¨ urlichsprachliche Eingabe erlauben. Letzteres bedeutet dabei, dass Eingaben entweder u ¨ber gesprochene oder geschriebene Sprache erfolgen k¨onnen. Da sich dieses Werk ausschließlich auf gesprochen-sprachliche Dialogsysteme konzentriert, wird der Begriff Dialogsystem“ synonym mit dem Begriff des ” gesprochen-sprachlichen Dialogsystems“ genutzt. ” Laut [Bußmann 2002] unterhalten sich nat¨ urlich-sprachliche Dialogsysteme mit einem Benutzer in einem erw¨ unschten Dialog, um dem Benutzer einen m¨oglichst nat¨ urlichen Zugang zu einem Softwaresystem anzubieten, z.B. einer Datenbank oder einem Expertensystem. Diese Systembenutzung m¨oglichst erfolgreich durchzuf¨ uhren, kann daher als das Ziel des gegenseitigen Dialogs (vgl. Definition 2.1) angesehen werden. Also muss ein Sprachdialogsystem (SDS) oder auch kurz Dialogsystem zun¨achst einmal ein sprachverste¨ hendes System sein, es muss also in der Lage sein, Außerungen eines Benutzers zu analysieren, zu verstehen und darauf zu reagieren. Da es sich bei aktuellen Dialogsystemen in der Regel um speziell f¨ ur eingeschr¨ankte Dom¨anen erstellte Systeme handelt (vgl. Abschnitt 2.7), sollte ein gutes Dialogsystem (allerdings auch der Benutzer) sich immer an die bereits in Abschnitt 2.1 eingef¨ uhrten Grice’schen Maximen halten. Diese Maximen k¨onnen somit als Grundregeln f¨ ur die Erstellung von Dialogsystemen gelten, da nur bei einem entsprechenden Verhalten der Dialogteilnehmer auch gew¨ ahrleistet werden kann, das gemeinsame Dialogziel auch wirklich zu erreichen. Allerdings sollte ein Dialogsystem auch Hilfemechanismen aufweisen, um auch unge¨ ubten Benutzern die Verwendung zu erm¨ oglichen. Zusammengefasst kann gesagt werden: Definition 3.1. Ein Sprachdialogsystem ist ein sprachverstehendes System, das dem Erreichen von Zielen im gegenseitigen kooperativen Dialog dient, daf¨ ur muss es Benutzer¨ außerungen ad¨ aquat verarbeiten und darauf sinnvoll reagieren k¨ onnen.

32

3 Sprachdialogsysteme im Automobil

3.2.2 Sprachbediensystem Sprachdialogsysteme im Automobil dienen aktuell ausschließlich der Steuerung von angeschlossenen Ger¨ aten, sie werden daher auch Sprachbediensysteme (SBS) genannt. Grunds¨ atzlich werden im Automobil keine sicherheitsrelevanten Funktionen sprachgesteuert. Die SBS stehen auch nicht im Zentrum der Aufmerksamkeit von Benutzern, vielmehr erm¨oglichen sie es ¨ dem Benutzer, mit knappen und kurzen Außerungen zum Ziel zu kommen. Auf Grund dieser Besonderheiten spielt nat¨ urlichsprachliches Sprachverstehen gegenw¨ artig keine (¨ ubergeordnete) Rolle f¨ ur solche Systeme, vgl. [Hamerich et al. 2005]. Grunds¨ atzlich gilt damit: Definition 3.2. Ein Sprachbediensystem ist ein Sprachdialogsystem, welches zur Steuerung von Ger¨ aten per Sprache genutzt wird. Eine Anwendungsdom¨ ane solcher Systeme ist die sprachliche Kontrolle von Ger¨ aten im Automobil, wie z.B. Telefon oder Navigationssysteme.

3.3 Systemanforderungen Wie bereits in Abschnitt 2.4.5 angemerkt, gibt es f¨ ur kommerzielle Dialogsysteme spezielle Anforderungen bez¨ uglich der Vollst¨andigkeit der Spezifikation. Doch neben diesen Anforderungen gibt es noch eine Reihe technischer Rahmenbedingungen, die automobile Systeme stark von anderen Sprachsystemen unterscheiden. In diesem Abschnitt werden alle Anforderungen an ein Sprachbediensystem im Automobil ausf¨ uhrlich dargestellt. Die Reihenfolge der Aufz¨ahlung erfolgt nach Priorit¨ aten f¨ ur die Entwicklungsphase eines SBS, beginnend mit den wichtigsten Punkten. 3.3.1 Hardwareanforderungen In der Automobilindustrie werden sehr hohe Anforderungen an die in einem Fahrzeug verwendete Hardware gestellt. Die in heutigen Automobilen eingesetzte Hardware ist daher nicht mit handels¨ ublichen Festplatten und Speicherbausteinen vergleichbar. Dies ist zum einen in den verschiedenen klimatischen Gegebenheiten auf der Welt, denen ein Automobil im Betrieb ausgesetzt ist, begr¨ undet. Zum anderen d¨ urfen Ersch¨ utterungen w¨ahrend der Fahrt die Elektronik und ihre Bausteine nicht besch¨ adigen. Daneben gibt es f¨ ur alle in einem Kfz eingesetzten Eleketronikkomponenten einevorgeschriebene ausfallsichere Mindestlebensdauer, die in MTBF (engl. mean time between failure) ausgedr¨ uckt wird und der Komponenten f¨ ur den Endverbraucher in der Regel nicht gen¨ ugen. Selbstverst¨ andlich muss auch in umfangreichen EMV-Tests

3.3 Systemanforderungen

33

(Elektromagnetische Vertr¨ aglichkeit) nachgewiesen werden, dass die zu verbauenden Komponenten keine St¨ orungen durch elektrische oder elektromagnetische Effekte verursachen k¨ onnen. Zuletzt muss ein Zulieferer von Elektronikkomponenten eine garantierte vorgeschriebene minimale Lieferf¨ahigkeit von identischen Teilen u ¨ber mindestens zehn bis zw¨olf Jahre garantieren. Aus diesen Gr¨ unden werden in Kfz keine Magnetspeicher, sondern relativ teure Flash-Bausteine eingesetzt. Die genannten Einschr¨ankungen f¨ uhren daher zu einer Beschr¨ ankung des Speicherplatzes in Automobilapplikationen. Dies ist im kurzlebigen Consumer-Gesch¨ aft ganz anders. Da Automobilhersteller ihre Produkte in großen St¨ uckzahlen fertigen und aus wirtschaftlichen Gr¨ unden h¨ aufig auf das Gleichteileprinzip zur¨ uckgreifen, stellen die Anschaffungskosten f¨ ur Speicherbausteine in der Summe erhebliche Geldbetr¨ age dar. Um hier finanzielle Mittel nicht zu verschwenden, ist daher ein sparsamer Umgang mit Speicherplatz eine der wichtigsten Forderungen u ¨berhaupt. Dieses Kriterium hat daher in der Regel oberste Priorit¨at und bei der Einf¨ uhrung von neuen Funktionen f¨ ur ein SBS ist deren Speicherbedarf eine entscheidende Gr¨ oße. Zuletzt sind die Geschwindigkeit und Leistungsaufnahme von Prozessoren ein wichtiges Kriterium. Strom steht in einem Kfz nicht unbegrenzt zur Verf¨ ugung, daher werden sehr sparsame Hardwarebausteine verwendet. Diese zeichnen sich meist durch hohe Lebensdauer und Ausfallsicherheit aus, k¨onnen aber von der Leistung nicht mit PC-Prozessoren mithalten. 3.3.2 Spezifikation Wie bereits in Abschnitt 2.4.5 dargstellt wurde, ist eine vollst¨andige Spezifikation des Dialogablaufs bei kommerziellen Dialogsystemen unerl¨asslich. Dies ist f¨ ur den Bereich von serverbasierten Dialogsystemen u.a. bei [Pieraccini und Huerta 2005] dargestellt und mit Begriff VUI Completeness bezeichnet worden. Gleiches gilt prinzipiell auch f¨ ur SDS im Automobil. Wie bereits in [Hamerich et al. 2005] beschrieben wurde, gibt es verschiedene Aspekte bei der Spezifikation eines SBS: •

Der wesentliche Aspekt ist die bereits angesprochene Vollst¨ andigkeit der Spezifikation. Dies ist umso wichtiger, da der Auftraggeber anhand der Spezifikation den kompletten Funktionsumfang eines SBS feststellen und außerdem seine Bedienphilosophie genau daraus ablesen k¨onnen sollte. Um den Dialogfluss m¨ oglichst gut verst¨ andlich darzustellen, haben sich Flussdiagramme zur Beschreibung durchgesetzt. Diese basieren auf endlichen Automaten, die auch zur Modellierung des Dialogablaufs verwendet werden, wie es bereits in Abschnitt 2.4.1 und 2.4.5 vorgestellt wurde. • Wichtig ist ferner die Konsistenz eines Dialogsystems, wie auch schon in Abschnitt 2.10 begr¨ undet wurde. Auch diese Eigenheit sollte bereits in der Spezifikation abgebildet sein, um sp¨ ater eine effiziente Implementierung zu erm¨ oglichen.

34

3 Sprachdialogsysteme im Automobil

• Zus¨ atzlich wird eine aussagekr¨ aftige Spezifikation auch als Grundlage f¨ ur ¨ die Uberpr¨ ufung des fertigen Systems verwendet. So m¨ ussen grunds¨atzlich alle Dialogabl¨ aufe durchgetestet und deren erfolgreiche Erledigung f¨ ur den Kunden protokolliert werden. Wenn eine Spezifikation all diese Punkte erf¨ ullt, kann die Entwicklung des SBS beginnen. 3.3.3 Integration in automobiles HMI Ein SBS im Automobil stellt heute nur eine alternative Bedienungsmodalit¨at dar. Das heißt s¨ amtliche Funktionen4 k¨ onnen auch haptisch ausgef¨ uhrt 5 werden. Bedingt dadurch orientiert sich die Sprachbedienung h¨aufig an der Logik und dem Design der haptischen Bedienung. Auch die Schnittstellen zu angeschlossenen Ger¨ aten wie z.B. einem Navigationssystem werden f¨ ur beide Modalit¨ aten ausgef¨ uhrt. Eventuell zus¨ atzlich f¨ ur die Sprache ben¨otigte Daten oder Funktionen m¨ ussen daher in den Entwicklungsprozess der haptischen Bedienung mit einfließen. Daher erfolgt die Definition und Entwicklung der beiden Bedienmodalit¨ aten zusammen in einem gemeinsamen Prozess, damit das finale HMI (engl. human machine interface) konsistent ist und zusammenpasst. Um dies zu gew¨ ahrleisten, erfolgt die bereits angesprochene Integration der Sprachbedienung in die graphisch-haptischen Schnittstellen und Systeme eines Automobils. Auf Grund dieser engen Verzahnung der Modalit¨aten werden automobile HMI-Systeme speziell f¨ ur einen Automobilhersteller und eine Fahrzeugreihe entwickelt. Diese Integration der Sprachbedienung bietet allerdings auch die M¨ oglichkeit, das HMI f¨ ur den Sprachdialog zu nutzen und damit eine multimodale Anwendung zu erstellen. Abh¨angig von der jeweiligen Bedienphilosophie des Automobilherstellers gibt es daher zum Beispiel die M¨ oglichkeit, m¨ ogliche Kommandos im aktuellen Systemzustand anzuzeigen oder eine erforderliche Disambiguierung durch die graphische Darstellung zu unterst¨ utzen. Bedingt durch den hohen Integrationsgrad von SBS und der Abh¨angigkeit von den r¨ aumlichen und technologischen Gegebenheiten im jeweiligen Automobil, ist eine enge Kooperation mit dem jeweiligen Fahrzeughersteller bei der Entwicklung von Spachbediensystemen notwendig. Außerdem kann eine solche Entwicklung nur von einem gr¨ oßeren Personenkreis geleistet werden, da verschiedene Spezialisten ben¨ otigt werden. So werden alleine f¨ ur die Erstellung 4

5

Als Funktion wird hier die Steuerung der angeschlossenen Ger¨ ate, wie beispielsweise Radio, Medienspieler, Navigationssystem und Telefonsteuerung bezeichnet. Mehr zum Funktionsumfang eines SBS weiter unten in Abschnitt 3.6. Es ist allerdings durchaus m¨ oglich, dass sprachlich mehrere haptische Bedienschritte auf einmal ausgef¨ uhrt werden k¨ onnen, in diesem Fall spricht man von einem shortcut der Bedienung. Nichtsdestotrotz sind (wenn auch manchmal sehr umst¨ andlich) alle sprachlichen Bedienungen auch haptisch nachvollziehbar.

3.4 Systemarchitektur

35

einer Bedienphilosophie in einem Automobil neben Ingenieuren und Technikern u ¨blicherweise immer auch Psychologen und Designer ben¨otigt. Der zeitliche Aufwand f¨ ur die Entwicklung eines kompletten neuen Systems wird u ¨blicherweise in mehreren Jahren gerechnet, dabei werden laufend Musterst¨ande erstellt, integriert und getestet. 3.3.4 Bedienbarkeit Neben den o.g. technischen Anforderungen soll eine Sprachbedienung nat¨ urlich auch von Nutzern bedient werden k¨ onnen. Daf¨ ur werden neue Technologien und Funktionalit¨aten regelm¨ aßig durch Benutzerbefragungen und -tests evaluiert, wie z.B. bei [Hamerich 2005] dargestellt. Daneben k¨onnen auch komplette Produktsysteme evaluiert werden. Ergebnisse von fr¨ uhen Designevaluationen k¨ onnen w¨ahrend der Spezifikati¨ onsphase eines neuen Systems zu wichtigen Anderungen f¨ uhren. Allerdings kann nicht ausgeschlossen werden, dass sich Auftraggeber bedingt durch ei¨ gene Uberzeugungen, Erfahrungen und/oder Bedienphilosophien nicht f¨ ur den – laut Evaluationsergebnissen – optimalen Weg entscheiden. In diesem Fall w¨ urde die Bedienbarkeit (engl. usability) den Einschr¨ankungen des Auftraggebers untergeordnet. Daher ist die Produktversion eines SBS immer ein Kompromiss zwischen optimaler Bedienbarkeit, m¨ oglichst niedrigen Hardwarekosten und den Designanforderungen des Kfz-Herstellers. Das Thema Bedienbarkeit wird in Kapitel 4 wieder aufgegriffen.

3.4 Systemarchitektur In diesem Abschnitt werden die wichtigsten Komponenten eines automobilen Dialogsystems dargestellt. Damit sollen die Grundlagen der den einzelnen Komponenten zugrundeliegenden Technologien und Ans¨atze erkl¨art werden, um anschließend das Zusammenspiel der Komponenten verstehen zu k¨onnen. ¨ Dieser Uberblick ist allgemein gehalten und nur als Einf¨ uhrung in die entsprechenden Bereiche zu verstehen. Um die Besonderheit der automobilen Systeme gegen¨ uber den bekannteren serverbasierten Sprachdialogsystemen auch vor dem Hintergrund der Systemarchitektur herauszustellen, sei bereits jetzt auf Abschnitt 3.7 hingewiesen, in dem Architektur und Merkmale von Serversystemen dargestellt werden. Die schematische Architektur eines Sprachbediensystems ist in Abbildung 3.2 dargestellt. Das eigentliche SBS besteht in einem Kfz nur aus dem Dialogmanager, der Spracherkennung (ASR) und dem Prompter. Alle anderen Ger¨ ate sind an das graphisch-haptische HMI gebunden und sind daher auch in einem Automobil vorzufinden, in dem kein SBS installiert ist. Zur besseren ¨ Ubersicht werden in den folgenden Abschnitten allerdings alle Komponenten, die f¨ ur ein funktionierendes SBS ben¨ otigt werden, beschrieben.

36

3 Sprachdialogsysteme im Automobil

Abbildung 3.2. Schematische Systemarchitektur eines SBS

3.4.1 Spracheingabe und akustische Vorverarbeitung Die Spracheingabe erfolgt bei gesprochen-sprachlichen Systemen grunds¨atzlich in ein Mikrofon. Dieses ist in Fahrzeugen meist im R¨ uckspiegel, der Dachbedieneinheit, im Dachhimmel oder der A-S¨aule eingebaut. Dabei k¨onnen sowohl einzelne Mikrofone verbaut werden, wie auch Mikrofonarrays zum Einsatz kommen. In letzterem Fall werden zwei bis vier Mikrofone nebeneinander installiert, um ein besseres akustisches Sprachsignal zu erhalten [Brandstein und Ward 2001]. Mikrofone geh¨oren nicht ausschließlich zum SBS, da sie ebenfalls f¨ ur die in einem Fahrzeug installierte Freisprecheinrichtung (FSE) genutzt werden, um damit die Spracheingabe f¨ ur das angeschlossene Mobiltelefon zu verarbeiten. ¨ Ublicherweise sind Dialogsysteme im Automobil nicht permanent aktiv, d.h. das Mikrofon muss gezielt aktiviert werden, um Fehlerkennungen und eine permanente Auslastung der Rechenleistung des FIS f¨ ur das SBS zu vermeiden. Daher muss ein Benutzer (dieser ist im Regelfall identisch mit dem Fahrer) das System aktivieren.6 Um das System zu starten, muss der sogenannte PTT-Knopf (engl. push to talk ) bet¨ atigt werden, der je nach Automobilhersteller und Modell entweder als Bedienhebel an der Lenks¨aule, Taste am Multifunktionslenkrad (MFL) oder Knopf in der Mittelkonsole ausgef¨ uhrt ist. Der PTT-Knopf ist damit der einzige haptische Bestandteil einer Sprachbedienung.7 Aus Gr¨ unden des Gleichteileprinzips wird der PTT in der Mittelkonsole oder auf dem MFL auch bei nicht installiertem SBS installiert, hat dann aber keine Funktion. 6

7

Ausgenommen proaktive Dialoge, wie z.B. die Ansage eines auf dem Mobiltelefon ankommenden Anrufs oder die im Rahmen dieses Werkes entwickelte Funktionalit¨ at f¨ ur Verkehrsnachrichten. In einigen Ausf¨ uhrungen, wie z.B. beim SBS in der aktuellen Mercedes C-Klasse (W204) gibt es auch einen separaten Abbruch-Knopf, welcher die Sprachbedienung abbricht.

3.4 Systemarchitektur

37

Bei gesprochen-sprachlichen Eingaben in ein Dialogsystem ist besonders auf die Akustik zu achten. So gibt es je nach r¨aumlicher Gegebenheit unterschiedliche Arten von Umgebungsger¨ auschen, die zur Erreichung einer besseren Spracherkennrate aus dem Sprachsignal gefiltert werden m¨ ussen. In Automobilen muss st¨ anding mit hohen St¨ orger¨ auschen von Wind, Regen, Scheibenwischern, unebener Fahrbahn etc. gerechnet werden. Zus¨atzlich k¨onnen ge¨offnete Fenster oder ein laufendes Gebl¨ ase weitere Ger¨ausche verursachen. Die Ger¨ ausche werden vor der eigentlichen Spracherkennung aus dem Signal gefiltert, um dessen Qualit¨ at zu verbessern. Die dabei angewandten Verfahren sind u.a. bei [H¨ ansler und Schmidt 2004] beschrieben. Sind mehrere Mikrofone verf¨ ugbar, werden neben der einkanaligen Echound St¨ orreduktion h¨ aufig beam former Verfahren eingesetzt, um die Qualit¨at des erkannten Sprachsignals weiter zu verbessern und auch in unterschiedlichen Sitzpositionen des Fahrers ein gutes Signal erkennen zu k¨onnen [Nordholm et al. 2001]. Im Gegensatz zu den bekannten PC-basierten Diktiersystemen m¨ ussen die Systeme im Kfz sofort von jedem bedienbar sein. Eine eigene Trainingsphase sollte allenfalls optional verf¨ ugbar, nicht jedoch erforderlich sein. Dar¨ uber hinaus k¨ onnen keine Nahbesprechungsmikrofone (Headsets) verwendet werden, da der Fahrer sich frei und ohne Kabel bewegen k¨onnen muss. Daher muss die akustische Vorverarbeitung auch die Entfernung des Fahrers vom Mikrofon mit beachten. Bereits bei den im Automobil vorfindbaren Abst¨anden kommen Effekte der Weitbereichsakustik ins Spiel, die zu einer zus¨atzlichen Kanalverzerrung f¨ uhren. Daher ist eine akustische Vorverarbeitung absolut notwendig f¨ ur ein automobiles SBS. ¨ Ublicherweise ist die akustische Vorverarbeitung im Mikrofon oder in der Spracherkennung integriert. Daher ist die Vorverarbeitung in der Architektur in Abbildung 3.2 auch nicht als eigene Komponente abgebildet worden. 3.4.2 Spracherkennung und Parsing Nachdem St¨ orger¨ ausche und Echos aus dem Signal gefiltert wurden, wird das gefilterte Sprachsignal an die Spracherkennung weitergegeben. Die automatische Spracherkennung (engl. automatic speech recognition) bildet das Sprachsignal auf eine Wortkette ab. Daf¨ ur wird das Sprachsignal abgetastet und aus diesem mittels der Fourier-Transformation Spektralparameter gewonnen. Aus letzteren werden Merkmalsvektoren errechnet, die mit Referenzmustern verglichen werden. Diese Muster sind Phonemfolgen, die sich zu Wortfolgen addieren. Die wahrscheinlichste Wortfolge stellt das Ergebnis der Spracherkennung dar. Die Grundlagen der Sprachsignalerkennung sind bei [Vary et al. 1998] ersch¨ opfend dargestellt. Detailliertes zur Spracherkennung kann bei [Jelinek 1998] gefunden werden. Die grunds¨ atzlichen Mechanismen der Spracherkennung, wie sie f¨ ur PCbasierte Systeme z.B. bei [Bahl et al. 1993] beschrieben werden, finden auch im Automobil Verwendung. Hervorzuheben ist aber der deutlich geringere

38

3 Sprachdialogsysteme im Automobil

Speicherverbrauch von automobilen Spracherkennern, der sich v.a. aus den in Abschnitt 3.3.1 beschriebenen Hardwareanforderungen erkl¨art. Daneben hat es sich wegen der bereits angesprochenen besonderen akustischen Bedingungen, welche im Auto herrschen, als sinnvoll herausgestellt, die f¨ ur das Training der Spracherkennung ben¨ otigten Daten auch in einem Kfz aufzunehmen. Damit sind akustische St¨ orungen und Umgebungsl¨arm im Trainingsmaterial ¨ ahnlich repr¨ asentiert wie es sp¨ ater im laufenden Betrieb der Fall sein wird. Da die Sammlung solcher Sprachdaten sehr teuer und aufw¨andig ist, wurden Daten zum Beispiel im Rahmen des Projekts SPEECON gesammelt [Iskra et al. 2002]. Daneben existieren weitere Bestrebungen zur Sammlung von Korpora in Automobilumgebungen, wie z.B. bei [Kato et al. 2008] beschrieben. Neueren Datums sind Untersuchungen, welche den besonderen Einfluss der kognitiven Belastung durch die Fahrt¨ atigkeit auf den Fahrer und die Erkennung seiner Sprache thematisieren, [Lindstr¨ om et al. 2008] haben dabei festgestellt, dass sich die Sprache des Fahrers unter unterschiedlichen Fahrbelastungen ¨ andern kann. Diese Studien werden Einfluss auf sp¨atere Generationen von Spracherkennern zum automobilen Einsatz haben. Um aus den Zeichenketten, die aus dem Spracherkennungsvorgang hervorgehen, eine Bedeutung herauszulesen, m¨ ussen die Wortfolgen interpretiert werden. Dies geschieht beim Parsing. Dort werden allgemein syntaktische Strukturen und semantische Beziehungen innerhalb der erkannten Wortfolge ¨ herausgearbeitet. Ublicherweise werden Grammatiken f¨ ur das Parsing verwendet, es gibt jedoch auch statistische Verfahren, die ohne eine Grammatik auskommen. In kommerziellen Systemen werden keine syntaktischen Analysen vom Parser ben¨ otigt, daher wird nur mit der semantischen Ebene gearbeitet.8 Der Parser weist in diesem Fall jeder Wortkette eine semantische Repr¨asentation zu. Synonymen k¨ onnen dabei die gleichen Repr¨asentationen zugewiesen werden. Dies funktioniert auch zwischen unterschiedlichen Sprachen. So werden die S¨ atze Ich m¨ ochte Gerhard anrufen“ und I would like to call Gerhard“ ” ” und Dial Gerhard“ alle auf die gleiche Repr¨ asentation abgebildet. F¨ ur den ” Dialog ist ausschließlich die Semantik essentiell, da nur bei Kenntnis der semantischen Repr¨ asentation eine Benutzer¨ außerung korrekt interpretiert und eine entsprechende Reaktion ausgel¨ ost werden kann. Konkrete Beispiele und weitere Informationen u ¨ber die verwendeten Grammatikalgorithmen werden in Abschnitt 5.3 dargestellt. F¨ ur Sprachdialogsysteme im Kfz ist der Parser in der Regel direkt in die Spracherkennungskomponente integriert, daher wurde er nicht als separate Komponente in der Systemarchitektur erw¨ ahnt.

8

Die semantische Ebene ist dabei in der Regel eine Kombination aus Semantik und einem Dialogakt, vgl. Abschnitt 2.3.

3.4 Systemarchitektur

39

3.4.3 Dialogmanager Die Kontrolle in einem Dialogsystem wird vom Dialogmanager (DM) ausge¨ ubt. Der DM ist die steuernde Komponente in einem Dialogsystem und f¨ uhrt die in Abschnitt 2.5 bezeichneten Funktionen der Dialogsteuerung aus. Wie bereits in Abschnitt 2.4.5 dargestellt wurde, eignet sich f¨ ur Sprachsysteme im Automobil vor allem die zustandsbasierte Dialogbeschreibung. Diese bietet auf der einen Seite die M¨ oglichkeit einer exakten Spezifikation und kommt zudem mit einem einfachen Dialogmanager aus, der wenig Funktionalit¨ at aufweisen muss und daher wenig Speicherplatz ben¨otigt.9 Aus diesen Gr¨ unden ist der verwendete DM in Automobilen analog zu einem endlichen Automaten aufgebaut, er arbeitet die Dialogbeschreibung ab und steuert entsprechend alle anderen Komponenten eines SDS. So ist die Dialogsteuerung z.B. daf¨ ur zust¨ andig, den Spracherkenner zu o¨ffnen, wenn der PTT-Knopf bet¨ atigt wurde. 3.4.4 Headunit Die Headunit ist prinzipiell ein eingebetteter Computer. Sie enth¨alt ein Motherboard mit Speicherbausteinen und Prozessor10 , daneben kann f¨ ur die Audioverarbeitung ein separater DSP (engl. digital signal processor ) genutzt werden, in einigen Systemen wird sogar f¨ ur das SBS ein eigener DSP verwendet. Aus den bereits erw¨ ahnten Hardwareanforderungen (Abschnitt 3.3.1) folgt, dass die Bausteine keine Consumer-Produkte sind, sondern explizit f¨ ur den Einsatz in eingebetteten Systemen spezifiziert und entwickelt wurden. Als Betriebssystem auf Headunits wird ein Echtzeitsystem wie beispielsweise QNX verwendet. Dialogsysteme im Automobil dienen ausschließlich zur Steuerung von anderen Ger¨ aten, wie z.B. CD-Player, CD-Wechsler, Radio, MP3-Player, Telefon, Adressbuch, Klimaanlage und Navigationssystem. Die Headunit u ¨bt u ¨ber diese Ger¨ ate die Systemkontrolle aus. Wenn das Display des Navigationssystems auf der Headunit montiert ist, wird die Headunit in die Mittelkonsole von Kfz integriert. In Abbildung 3.3 ist eine Headunit der Mercedes-Benz E-Klasse (W211) abgebildet. Um die Kontrolle u ¨ber alle angeschlossenen und verbauten Ger¨ate u ¨bernehmen zu k¨ onnen, sind die Infotainmentger¨ ate u ¨ber den Entertainment-Bus mit der Headunit verbunden. Dieser Bus wird u ¨blicherweise als MOST-Bus ausgef¨ uhrt. Dabei handelt es sich um ein serielles Bussystem, welches speziell ¨ f¨ ur die Ubertragung von Audio-, Video- und Sprachdaten entwickelt wurde. 9 10

Die Notwendigkeit von geringem Speicherverbrauch folgt den in Abschnitt 3.3.1 formulierten Hardwareanforderungen. In aktuellen Systemen von HBAS werden u ¨blicherweise SH4 Mikroprozessoren eingesetzt, 32-bit RISC-Prozessoren mit 200 bis 600 MHz der Firma Renesas Technology (Stand 2006/2007).

40

3 Sprachdialogsysteme im Automobil

Abbildung 3.3. Headunit der Mercedes-Benz E-Klasse (Ausstattungsvariante COMAND)

Der Bus wird im Automobil immer in einer Ringtopologie ausgef¨ uhrt und zur ¨ Ubertragung werden Lichtwellenleiter eingesetzt. Um beispielsweise das Navigationssystem mit Daten des Tachometers versorgen zu k¨ onnen, wird dieser ebenfalls an die Headunit angebunden. Daf¨ ur wird mit CAN oder D2B allerdings ein anderer Bus eingesetzt. Beide Systeme wurden fr¨ uher ebenfalls f¨ ur die Kommunikation mit den Multimediager¨aten eingesetzt, sind jedoch weniger leistungsf¨ ahig als der MOST-Bus. Wenn die Sprachbedienung als separates Hardwaremodul ausgef¨ uhrt ist, kommunizert sie ebenfalls u ¨ber den MOST-Bus mit der Headunit. Bei einer Softwareintegration residiert das SBS im Speicher der Headunit. 3.4.5 R¨ uckmeldungen des Systems Sprachliche R¨ uckmeldungen des Systems werden als Prompts bezeichnet. Die Ausgabe erfolgt dabei entweder per bereits vorab aufgenommener Audiodaten (engl. prerecorded speech) oder die Prompts werden in Textform an die Sprachsynthese (engl. text to speech) u ur bestm¨ogliche Sprachqualit¨at ¨bergeben. F¨ werden u ¨blicherweise ausschließlich aufgenommene Sprachprompts verwendet [Jeschke 2008]. Diese werden von professionellen Sprechern im Tonstudio aufgenommen und verf¨ ugen u ¨ber eine exzellente Sprachqualit¨at. Da Speicherplatz f¨ ur diese eingebetteten Systeme aber knapp ist, werden die Prompts komprimiert. Außerdem werden aus finanziellen Gr¨ unden und speicherplatzbedingt nur die wichtigsten Systemmeldungen aufgenommen. Weitere Texte, insbesondere Straßennamen oder Adressbucheintr¨ age sind allerdings viel zu zahlreich und dynamisch, um u ¨ber vorab aufgenommene Sprachprompts ausgegeben zu werden. Daher werden f¨ ur diese F¨ alle seit einiger Zeit Sprachsynthesen eingesetzt. In der aktuellen Mercedes C-Klasse (interne Bezeichnung W204) ist beispielsweise eine TTS im Einsatz, um TMC-Meldungen (siehe Abschnitt 8.1.2) vorzulesen.

3.5 Systemintegration

41

Wichtig ist die Auswahl der Stimme und auch die Qualit¨at der verwendeten TTS. Dies belegen auch Studien, in denen nachgewiesen wurde, dass die Auswahl der Stimme Auswirkungen auf das Fahrverhalten von Probanden hat [Harbluk und Lalande 2005, Jonsson et al. 2005]. In jedem Fall erfolgen Sprachausgaben des Systems u ¨ber die Bordlautsprecher des Fahrzeugs. Gleichzeitig laufende Audioausgaben werden je nach System von der jeweiligen Headunit w¨ ahrend der Promptausgabe leiser oder auch stumm geschaltet. Allerdings beschr¨ ankt sich ein SBS nicht ausschließlich auf akustische R¨ uckmeldungen. In einem vollintegrierten System werden je nach Dialogzustand auch die Displayanzeigen umgeschaltet und aktualisiert. Dies wird u.a. bei der sprachlichen Eingabe von Navigationszielen ben¨otigt, wie in Abschnitt 3.6.3 ausf¨ uhrlich dargelegt wird.

3.5 Systemintegration Die Besonderheit von Sprachbediensystemen ist ihre feste Integration in das Fahrerinformationssystem des Kfz ab Werk.11 Diese Systeme werden als Originalzubeh¨ or im Auftrag eines Automobilherstellers gefertigt und daher auch als OEM-Systeme (engl. original equipment manufacturer ) bezeichnet. Um ein System mit der im vorherigen Abschnitt beschriebenen Architektur in ein Kfz zu integrieren, ist ein erheblicher Aufwand notwendig. Zum einen existieren die bereits angesprochenen akustischen Bedingungen (vgl. Abschnitt 3.4.1), welchen durch Schallmessungen bereits in einem fr¨ uhen Stadium eines automobilen Prototypen Rechnung getragen wird, indem optimale Mikrofonpositionen ausgemessen werden. Zum anderen bestehen die bereits in Abschnitt 3.3.1 angesprochenen Hardwareanforderungen. Aus diesen Gr¨ unden werden SBS in Automobilen immer noch als eingebettete (engl. embedded ) Systeme ausgef¨ uhrt und entweder als separate Hardware oder als Software innerhalb von Infotainmentsystemen realisiert. Die Besonderheit bei diesen Systemen ist, dass ein Sprachbediensystem direkt auf die zu steuernden Ger¨ ate zugreift, also in direkter Kommunikation mit diesen steht. Dies bedeutet, dass in der Sprachsteuerung die Protokolle und Schnittstellen des gesamten Infotainmentsystems abgebildet werden m¨ ussen. Dies ist auch eine der Hauptschwierigkeiten der Integration von Sprachbedienungen in ein Kfz, da hier sehr hardwarenah und mit wenig Speicherplatz programmiert werden muss. Es gibt aktuell zwei M¨ oglichkeiten f¨ ur die Ausf¨ uhrung von Sprachbedienungen in einem Automobil. Die preisg¨ unstigere und weniger leistungsf¨ahige Alternative ist die Ausf¨ uhrung in Hardware. In diesem Fall sind die Anforderungen an den Speicher absolut minimal, der Spracherkenner wird auf 11

Es gibt allerdings auch Nachr¨ ustsysteme, die hier aber nicht thematisiert werden.

42

3 Sprachdialogsysteme im Automobil

einem Chip integriert und die gesamte Dialogapplikation muss mit maximal 128 KB Speicher auskommen. In Abbildung 3.4 ist ein exemplarisches Hardware-Modul einer solchen Sprachbedienung abgebildet. Wenn eine Hardware-Realisierung vorgenommen wird, muss das entsprechende Modul di¨ rekt an den Entertainment-Bus des Fahrzeugs angeschlossen werden.12 Uber diesen l¨ auft dann die gesamte Kommunikation mit der Headunit und den anderen Systemkomponenten. Das Sprachmodul wird in einem Fahrzeug u ¨blicherweise entweder unter der R¨ uckbank oder im Kofferraum montiert und dort an den Bus angeschlossen. Wenn eine Software-Integration vorgenommen werden soll, sind die einfache Portierbarkeit auf die verschiedenen genutzten Echtzeit-Betriebssysteme (v.a. QNX), sowie flexible Ger¨ ate-Schnittstellen f¨ ur die Kommunikation mit externen Komponenten die wichtigsten Faktoren. In diesem Fall werden Erkenner und Dialog in einen Flash-Speicher geschrieben. Aber auch in diesem Fall stehen u ur das komplette SDS nicht mehr als zwei bis vier ¨blicherweise f¨ MB zur Verf¨ ugung.13 Zwar weisen einige Speicher im Kfz schon erheblich gr¨ oßere Kapazit¨ aten auf, allerdings wird der Großteil des Speichers von der Navigation zur Routenberechnung ben¨ otigt.

Abbildung 3.4. Hardwaremodul eines SDS aus dem Audi A8

Die Ausf¨ uhrung eines SBS ist in einem Kfz ¨außerlich nicht zu erkennen. Grunds¨ atzlich ist das Vorhandensein einer Sprachsteuerung kaum auff¨allig. Die einzig sichtbaren Komponenten sind das Mikrofon und der PTT-Knopf. Einige Kfz-Hersteller haben in allen Modellen einer Baureihe aus Gr¨ unden des Gleichteileprinzips Mikrofone montiert, die tlw. auch zum Freisprechen verwendet werden. Auch der PTT-Knopf ist, wenn im Multifunktionslenkrad integriert, immer vorhanden. Da die Bedienphilosophien zwischen den 12 13

Dieser Bus ist separat vom Bus f¨ ur die Motoren und Steuerger¨ ate eines Automobils ausgef¨ uhrt. Zahlen und Gr¨ oßenangaben Stand 2006/2007.

3.5 Systemintegration

43

einzelnen Automobilherstellern stark differieren, gibt es sehr unterschiedliche Auspr¨ agungen der Headunit und des PTT-Knopfes. Im Folgenden werden drei sehr prominente Beispiele illustriert. Bei Mercedes-Benz in der aktuellen EKlasse (interne Bezeichung W211) ist das graphisch/haptische HMI in einem Ger¨ at geb¨ undelt, Display und Taster bilden eine Einheit, wie auf Abbildung 3.5 zu erkennen ist. Es gibt jedoch auch die M¨oglichkeit, das Display von den Tasten zu trennen, wie bei Audi im A8 (D3) zu finden (vgl. Abb. 3.6). Dagegen hat BMW mit dem iDrive nur einen zentralen Dreh-/Dr¨ ucksteller platziert und damit die Anzahl der Taster im Fahrzeugcockpit massiv reduziert. In Abbildung 3.7 ist das iDrive-System im BMW 7er (E65) dargestellt.

Abbildung 3.5. Headunit und PTT-Hebel (links, tlw. vom Lenkrad verdeckt) in der Mercedes-Benz E-Klasse. (Ausstattungsoption COMAND APS mit Linguatronic.)

Abbildung 3.6. Headunit im Audi A8 (aufgetrennt in Tasten und Display) mit PTT im Lenkrad. (Ausstattungsoption MMI mit Sprachdialogsystem.)

44

3 Sprachdialogsysteme im Automobil

Abbildung 3.7. Headunit im BMW 7er (mit zentralem Dreh-/Dr¨ ucksteller und Display) und PTT im Lenkrad. (Ausstattungsoption MMI mit iDrive und Sprachdialogsystem.)

3.6 Funktionalit¨ aten Nachfolgend werden die wichtigsten F¨ ahigkeiten eines automobilen Sprachbediensystems dargestellt. Dabei wird vor allem die Funktionalit¨at eines heute auf dem Markt als OEM-Ger¨ at erh¨ altlichen Systems illustriert. Die Beispieldialoge haben dabei nur exemplarischen Charakter, gegen¨ uber Seriensystemen kann es zum hier dargestellten Dialogablauf zu Abweichungen kommen, da f¨ ur jeden Automobilhersteller andere Varianten existieren. Diese unterscheiden sich typischerweise in den Systemausgaben (Prompts) und/oder den einzelnen Sprachbefehlen. Ein komplett einheitliches Vorgehen u ¨ber verschiedene Marken ist bisher nichtvorhanden und wird auch aus Gr¨ unden der unterschiedlichen Bedienphilosophien der Hersteller nicht angestrebt. Neben der Vorstellung der wichtigsten Funktionalit¨aten eines aktuellen Systems werden auch einige Ausblicke in die n¨ahere Zukunft gegeben. Abschließend wird am Beispiel der Linguatronic die Weiterentwicklung der SBS in den letzten zw¨ olf Jahren aufgezeigt. 3.6.1 Nummernwahl Die einfache Wahl einer Telefonnummer per Sprache ist eine der bekanntesten Funktionalit¨ aten eines SBS und in Abbildung 3.8 exemplarisch abgebildet. Dieser Dialog beginnt klassisch in systemgesteuerter (reaktiver) Dialogstrategie (vgl. Abschnitt 2.6.2). Die Eingabe der Nummer erfolgt dann in einer kooperativen Strategie (siehe Abschnitt 2.6.3), denn die Anzahl der Ziffern kann der Benutzer hier jeweils variieren. Das System fragt selbstt¨atig nach, ob weitere Ziffern hinzugef¨ ugt werden sollen. Der Dialog mag mit den Wiederholungen der Eingabe lang erscheinen, aber durch m¨ ogliche Spracherkennungsfehler und mangelndes Benutzervertrauen macht ein erneutes Vorlesen Sinn. Sollte ein Erkennfehler vorliegen

3.6 Funktionalit¨ aten (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys)

45

Nummer w¨ ahlen Bitte sprechen Sie die Nummer. 0-7-3-1 0 - 7 - 3 - 1 und weiter? 3-9-9-4-0 3 - 9 - 9 - 4 - 0 und weiter? W¨ ahlen Die Nummer wird gew¨ ahlt. <W¨ ahlton>

Abbildung 3.8. Nummerndialog eines aktuellen Sprachbediensystems

(oder sich der Benutzer versprochen haben) kann die Nummer per Sprachkommando korrigiert werden. Ansonsten kann auch jederzeit der Sprachdialog abgebrochen werden. Mit dem W¨ ahlen der Nummer ist der Sprachdialog zu Ende und die Freisprechfunktion des Telefons wird aktiviert. Wenn die Sprachbedienung erneut gestartet werden soll, muss wieder der PTT-Knopf bet¨atigt werden. Um das Telefonat zu beenden, kann das Dialogsystem nicht verwendet werden. In der Regel gibt es aber einen Knopf im Multifunktionslenkrad, der diese Funktionalit¨ at bietet. 3.6.2 Namenswahl Viele aktuelle SBS bieten bereits die M¨ oglichkeit, die Telefonbucheintr¨age auf der SIM-Karte oder im Speicher des Mobiltelefons als dynamisches Vokabular der Spracherkennung zur Verf¨ ugung zu stellen. Diese Technologie wird als G2P (engl. grapheme to phoneme) bezeichnet. Ein mit G2P ausgestattetes System kann damit auch die Namen aus dem mittels Bluetooth verbundenen Mobiltelefon erkennen. Damit wird der sprachliche Zugriff auf das Telefon stark vereinfacht und verk¨ urzt. Ein Beispieldialog f¨ ur diesen Fall ist in Abbildung 3.9 dargestellt.

(Ben) (Sys) (Ben) (Sys) (Ben) (Sys)

Namen w¨ ahlen Bitte sprechen Sie den Namen. Sandra Die Nummer von Sandra wird gew¨ ahlt <W¨ ahlton>

Abbildung 3.9. Namensdialog eines aktuellen Sprachbediensystems

46

3 Sprachdialogsysteme im Automobil

F¨ ur die Namenswahl gilt das gleiche, wie f¨ ur die Nummernwahl: ab dem W¨ahlzeitpunkt ist der Sprachdialog beendet. 3.6.3 Zieleingabe Mit dem Erscheinen der Mercedes-Benz E-Klasse (W211) 2003 war es erstmalig m¨ oglich, die 600 gr¨ oßten Orte eines Landes zur Navigation als Ganzwort zu sprechen, statt sie buchstabieren zu m¨ ussen. Der Honda Acura14 war 2005 das erste Modell, das eine komplette Ganzworteingabe in der Navigation auf Englisch erm¨ oglichte. Mit Erscheinen des neuen 5er BMW (E60) im September 2006 und wenig sp¨ ater der Mercedes C-Klasse (W204) 2007 ist diese Funktion auch in deutschen Automobilen m¨ oglich.15 Bei den meisten vorherigen Systemen m¨ ussen die Orts- und Straßennamen buchstabiert werden und nur die gr¨ oßten Ortsnamen sind direkt sprechbar. Die Problematik der Ganzwort¨ Navigation ist die Vielzahl der m¨ oglichen Außerungen und die große Anzahl an phonetisch ¨ ahnlichen Namen. So gibt es in Deutschland u ¨ber 68.000 verschiedene Orte und dabei z.B. 32 mal den Ort Neustadt. Um die Problematik von ahnlichen Ortsnamen und Verwechslungen in den Griff zu bekommen, pr¨asen¨ tiert das System dem Benutzer eine Liste der ¨ ahnlichsten Namen zur Auswahl. Ein exemplarischer Navigationsdialog ist in Abbildung 3.10 dargestellt. Weitere Beispieldialoge auch f¨ ur den Buchstabieransatz k¨onnen [Jeschke 2007] entnommen werden. ¨ Wenn das System eine Außerung nicht disambiguieren kann, fragt es zur¨ uck, ob die erste L¨ osung korrekt ist, gleichzeitig wird eine Liste der anderen m¨ oglichen Namen angezeigt (im Beispieldialog z.B. Hamburg und Hom¨ burg). Wenn eine Außerung eindeutig ist, wird der Name nur noch akustisch best¨ atigt, jedoch keine Nachfrage mehr angestoßen. Dieser Fall der Disambiguierungsliste ist ein klassisches Beispiel f¨ ur einen Fall, bei dem eine multimodale Ausgabe Sinn macht. Wenn das System ausschließlich per Sprache antworten w¨ urde, m¨ usste es entweder weitere Angaben des Benutzers erfragen, wie bei [Minker et al. 2004], oder aber die Liste komplett vorlesen. Letzteres w¨ are allerdings wenig komfortabel. Daher macht hier die Anzeige der Ergebnisse durchaus Sinn. Die Auswahl aus der Liste kann dann wieder per Sprache oder auch multimodal per haptischer Selektion geschehen. Letzterer Ansatz wird laut [Mischke et al. 2007] h¨ aufiger gew¨ ahlt. Wenn die Zielf¨ uhrung gestartet wird, endet der Sprachdialog und das Navigationssystem wird aktiviert. Dort wird die Routenberechnung erfolgen und die Zielf¨ uhrung gestartet. Letzteres bedeutet, dass auf dem Display der Headunit die Richtungs- oder Kartenanzeige (je nach aktueller Systemeinstellung) 14 15

Acura ist die Luxusmarke von Honda und wird nur in Nordamerika verkauft. In Europa wird der Acura seit Herbst 2006 als Honda Legend vermarktet. Es gibt inzwischen auch einige nachr¨ ustbare Navigationsger¨ ate, die per Spra¨ che bedient werden k¨ onnen, einen Uberblick u ¨ber deren Funktionsumfang bietet [Wiegand 2008].

3.6 Funktionalit¨ aten (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys)

47

Ziel eingeben Bitte sprechen Sie den Ortsnamen. Hamburg Ist Hamburg richtig? Ja Hamburg wurde eingestellt. M¨ ochten Sie einen Straßennamen eingeben? Ja Den Straßennamen bitte. Jungfernstieg Jungfernstieg wurde u ¨bernommen. M¨ ochten Sie eine Hausnummer eingeben? Nein M¨ ochten Sie die Zielf¨ uhrung starten? Ja Die Zielf¨ uhrung wird gestartet.

Abbildung 3.10. Navigationsdialog eines aktuellen Sprachbediensystems

aktiviert wird und die Ansagen der Navigation (z.B. Demn¨achst rechts ab” biegen.“) folgen. Eine zuk¨ unftige Erweiterung der Navigationszieleingabe wird die komfortable sprachliche Eingabe von Sonderzielen (wie Restaurants, Tankstellen etc.) sein, die in einem ersten Prototypen bei [M¨ uller und Hamerich 2007] vorgestellt wurde. ¨ Das Fernziel der Navigation w¨ are sicher ein System, das eine Außerung wie folgende verarbeiten k¨ onnte: Ich m¨ ochte zum Little Garden Restaurant, aber ” vorher bitte noch ein Zwischenstopp in meinem B¨ uro“. Das Demonstrationssystem CHAT von Bosch, der Uni Stanford und VW of America kann dies in der Dom¨ ane einer Stadt mit 50 Straßen bereits leisten [Weng et al. 2007]. Bis allerdings ein komplettes eingebettetes System mit einer Navigationsdatenbank von u adtenamen oder u ¨ber 68.000 deutschen St¨ ¨ber 200.000 Straßennamen alleine in Kalifornien eine solche Eingabe komplett verarbeiten kann, wird es noch einiger Jahre Forschung und billigerer Hardware bed¨ urfen. 3.6.4 Radiosteuerung Zur Steuerung des Radios k¨ onnen die folgenden Funktionen dieses Ger¨ats ebenfalls per Sprache gesteuert werden: • Senderwechsel ( N¨ achster/Vorheriger Sender“) ” • Frequenzeingabe ( Frequenz 103,6 Megahertz“) ” • Verkehrsfunk ( Verkehrsfunk an/aus“) ”

48

3 Sprachdialogsysteme im Automobil

• Direkte Senderwahl per VoiceTag ( Sender ’mein Lieblingssender’“) ” • Direkte Senderwahl per G2P der RDS-Sendernamen ( Sender SWR3“) ” Da die Funktionen wenig Interaktion bed¨ urfen, sind sie meist in direktiver oder reaktiver Dialogstrategie ausgef¨ uhrt. Da diese Dialoge entsprechend kurz und ¨ ahnlich verlaufen, wird auf eine exemplarische Darstellung verzichtet. 3.6.5 Steuerung des Medienspielers Aktuelle Kraftfahrzeuge haben neben dem Radio weitere Medienger¨ate an Bord. Dies k¨ onnen heute CD-Spieler, CD-Wechsler, DVD-Spieler und MP3Spieler sein. Hier gibt es ebenso Steuerkommandos, wie f¨ ur das Radio (z.B. N¨ achste CD“, N¨ achster/vorheriger Titel“, CD 2“). ” ” ” Noch ein Forschungsgegenstand ist die Sprachwahl von Musiktiteln. Mit den in aktuellen Kompressionsformaten (z.B. AAC, MP3, WMA) enthaltenen Metadaten, den sogenannten ID3-Tags, kann diese Funktionalit¨at bereitgestellt werden. Ein erster Forschungsansatz dazu wurde in [Wang et al. 2005] ¨ pr¨ asentiert. Die Idee dabei ist, direkt Außerungen wie Spiele Album ’Bad’ ” von Michael Jackson“ ausf¨ uhren zu k¨ onnen. Wie bei [Schulz und Donker 2006] nachgewiesen wurde, k¨ onnen Benutzer mit diesem Prototypen umgehen. Daher wird dieser Ansatz bei Harman/Becker zur Serienreife gebracht, eine ausf¨ uhrlichere Beschreibung ist bei [Wang und Hamerich 2008] zu finden. Der Nachteil dieses Ansatzes ist allerdings, dass Benutzer immer den Namen der entsprechenden Kategorie (Album, K¨ unstler, Titel) sprechen m¨ ussen. [Mann et al. 2007] haben daher einen Prototypen vorgestellt, der mit einer kategoriefreien Suche arbeitet. Alle Ans¨ atze ¨ahneln sich dahingehend, dass bei den großen Datenmengen (¨ ahnlich wie bei der Zieleingabe) h¨ aufig Disambiguierungslisten erscheinen k¨onnen. Bei [Schulz et al. 2007] wurde daher vorgeschlagen, zur Unterscheidung der verschiedenen Listentypen ein auditives Signal, ein earcon, zu spielen. 3.6.6 Internetzugriff Aktuell sind SBS ausschließlich geschlossene Systeme. Das Telefon kann zwar bedient werden, wenn eine Verbindung aber aufgebaut ist, wird der Sprachdialog beendet. In der Forschung befindet sich aktuell der sprachliche Zugriff auf Internet und E-Mails. Erste Prototypen wurden bereits vorgestellt [Berton et al. 2007, Fischer et al. 2007]. Neben der technischen Machbarkeit ist jedoch bei diesem Thema auch darauf hinzuweisen, dass durch eine intensive Besch¨aftigung mit Texten oder E-Mails die Fahrsicherheit leiden kann, wie es bei [Harbluk und Lalande 2005] nachgewiesen wurde.

3.7 Vergleich mit serverbasierten Dialogsystemen

49

3.6.7 Funktionszuw¨ achse am Beispiel Linguatronic Die Linguatronic ist die Sprachbedienung von Mercedes-Benz und war 1996 das weltweit erste Sprachbediensystem in einem Kfz u ¨berhaupt [Heisterkamp 2001]. Das System war das erste Produkt der Firma Temic SDS, die heute zu Harman/Becker geh¨ ort, und ist seit Erscheinen der neuen C-Klasse im Jahr 2007 (interne Bezeichnung W204) in der f¨ unften Generation erh¨ altlich. Im Folgenden werden die verschiedenen Features der einzelnen Generationen vorgestellt: 1. Generation erh¨ altlich ab 1996 ausschließlich in der S-Klasse (W140). Das System erlaubte die Sprachsteuerung des festeingebauten Autotelefons. Es verf¨ ugte u angige Erkennung und erlaubte eine ¨ber eine sprecherunabh¨ Zifferneingabe, sowie die Speicherung von h¨aufig gew¨ahlten Nummern in einem internen Adressbuch. 2. Generation erh¨ altlich ab 1998 mit Einf¨ uhrung der neuen S-Klasse (W220) und sp¨ ater f¨ ur fast alle Modellreihen von Mercedes-Benz, erlaubte zus¨atzlich zum Telefon die Sprachsteuerung von Radio, CD-Player und CDWechsler. 3. Generation erh¨ altlich ab 2002 f¨ ur die E-Klasse (W211) und nachfolgend f¨ ur die Baureihen der C-, CL-, M-, R-, SL-Klasse, den Maybach sowie die Modellpflege der S-Klasse (W220). Neue Funktionalit¨at war die sprachgesteuerte Zieleingabe von 800 Orten per Ganzwort, die restlichen Orte mussten anbuchstabiert werden (mehr dazu in [Hanrieder 2004]). Daneben kann das interne Adressbuch sprachgesteuert werden. 4. Generation erh¨ altlich seit 2005 mit Einf¨ uhrung der neuen S-Klasse (W221). Erlaubt zus¨ atzlich die erweiterte Steuerung des Medienspielers (MP3 und Speicherkarten). 5. Generation seit 2007 mit Vorstellung der neuen C-Klasse (W204) auf dem Markt. Dort k¨ onnen alle Ortsnamen per Ganzwort, also ohne Buchstabieren eingegeben werden. Daneben erlaubt G2P die Eingabe von Eintr¨agen aus dem Adressbuch ohne vorheriges Training. Außerdem ist erstmalig eine TTS verbaut, welche das Vorlesen von TMC-Meldungen erm¨oglicht. 6. Generation wird ab 2009 erh¨ altlich sein. ¨ Ein sehr ausf¨ uhrlicher Uberblick der Sprachbediensysteme bei BMW kann bei [Hassel 2006] gefunden werden.

3.7 Vergleich mit serverbasierten Dialogsystemen Sprachbediensysteme im Automobil gelten wegen der bereits beschriebenen Hardwareeinschr¨ ankungen als eingebettete Systeme. Im Gegensatz dazu stehen die serverbasierten Systeme, welche auf Servern mit nahezu unbeschr¨ankten Systemressourcen zum Einsatz kommen.

50

3 Sprachdialogsysteme im Automobil

In diesem Abschnitt werden automobile SDS mit weiteren Dialogsystemen verglichen. Dieser Vergleich gliedert sich in zwei Punkte (Anwendungsdom¨ane und Architektur), denen jeweils ein eigener Unterabschnitt gewidmet ist. Zur Illustration werden außerdem einige typische und bekannte Beispielsysteme vorgestellt. 3.7.1 Anwendungsdom¨ anen Je nach Anwendungsdom¨ ane werden unterschiedliche Arten von Dialogsystemen verwendet. Eingebettete Systeme Eingebettete Systeme sind nur als Bediensysteme ausgef¨ uhrt, diese geben dem jeweiligen Nutzer Kontrollm¨ oglichkeiten u ber angeschlossene Systeme. ¨ Ein im Rahmen dieses Buches sehr wichtiges Beispiel daf¨ ur sind Sprachbediensysteme im Auto. Diese Systeme erleichtern dem Fahrer die Bedienung z.B. des Telefons, der Audio- und Navigationsger¨ate w¨ahrend der Fahrt (siehe z.B. [Pieraccini et al. 2003, Hanrieder 2004, Hamerich et al. 2005]). Der a¨lteste Vertreter dieser Gattung ist das System Linguatronic, welches in Abschnitt 3.6.7 detailliert vorgestellt wurde. Doch es gibt auch Bediensysteme in Haushaltsger¨ aten, wie beispielsweise in einer Waschmaschine [Rieser 2003]. Telefonbasierte Systeme Telefonische Dialogsysteme haben in der Regel eine andere Zielsetzung. So k¨ onnen sie zum einen als Auskunftssysteme eingesetzt werden. Dabei ist eine typische Anwendungsform die der Fahrplanauskunft [Peckham 1993, Aust et al. 1995]. Zum anderen k¨ onnen Dialogsysteme aber auch f¨ ur andere Dom¨ anen Ausk¨ unfte erteilen, wie z.B. Wetterberichte [Zue et al. 2000], Verkehrsstaus (vgl. Abschnitt 3.7.3) oder Hotels [Mast et al. 2000]. Diese Systeme m¨ ussen auf großen leistungsf¨ ahigen Servern betrieben werden, da sie meist auf sehr große Datenmengen in Echtzeit zugreifen m¨ ussen. Wenn ein solches Auskunftssystem auch noch die Reservierung von z.B. Hotelbetten oder Fahrkarten zul¨ asst, wird es auch als Buchungssystem bezeichnet. Ebenfalls nur als telefonbasierte Systeme ausgef¨ uhrt sind Dialogsysteme, die zur Sprach¨ ubersetzung eingesetzt werden. Diese Systeme ben¨otigen beson¨ ders leistungsf¨ ahige Server, da die Ubersetzung – welche im Allgemeinen sehr aufw¨ andig ist – auch in Echtzeit durchgef¨ uhrt werden muss. Ein bekanntes Beispiel f¨ ur ein System dieser Kategorie ist Verbmobil [Wahlster 2000]. Eine ¨ Besonderheit solcher Systeme ist die Modellierung der Sprache. Da f¨ ur Ubersetzungen die Semantik einer Sprache sehr genau bekannt sein muss, erfordern ¨ Ubersetzungssysteme eine detaillierte Repr¨ asentation linguistischer Konzepte, die f¨ ur andere Zwecke in der Regel nicht gebraucht wird.

3.7 Vergleich mit serverbasierten Dialogsystemen

51

Weitere Arten von Dialogsystemen Des Weiteren k¨ onnen SDS auch zur reinen Unterhaltung dienen, wie diverse Weiterentwicklungen des ber¨ uhmten Systems Eliza (vgl. [Weizenbaum 1966]). Diese Systeme sind meist als Chatanwendungen im Internet zu finden und verarbeiten dort meist nur geschriebene Sprache. Es gibt allerdings auch unterhaltende Systeme, welche mit gesprochener Sprache arbeiten k¨onnen. Der Hauptzweck dieser Systeme ist dabei meist die Wissensvermittlung. Daher werden diese Systeme als Konversationsagenten bezeichnet. Solche Systeme, wie z.B. das ’Hans-Christian Andersen’-System [Bernsen und Dybkjær 2005] stehen in Museen oder auf Messen und sollen auf unterhaltende Art informieren. Die Systeme residieren meist auf handels¨ ublichen Computern, die in eine Stele integriert sind. Eine weitere Art der Dialogsysteme stellen die sogenannten Unterst¨ utzungsoder Handlungssysteme dar. Diese Systeme werden u blicherweise auf einem ¨ PC oder Server ausgef¨ uhrt, die Spracheingabe erfolgt dabei entweder per Tastatur oder Mikrofon. Da sehr komplexe Interaktionen von diesen Systemen zu bew¨ altigen sind, macht eine telefonische Bedienung hier auch keinen Sinn, da meist weitere Modalit¨ aten neben der sprachlichen gebraucht werden. Ein sehr fr¨ uhes Beispiel f¨ ur ein solches System war SHRDLU16 [Winograd 1972]. Das System bot eine nat¨ urlichsprachliche Schnittstelle zu einem simulierten Roboter in einer simulierten Kl¨ otzchenwelt. Mit Hilfe des Systems konnte ein Benutzer dem Roboter per Sprachkommando Gegenst¨ande aufheben oder umsetzen lassen. Es waren auch allgemeine Fragen zur simulierten Umwelt m¨oglich. Das bei [Peters 1999] vorgestellte Dialogsystem ist eine realistische Umsetzung und Weiterentwicklung von SHRDLU. In [Toptsis 2005] wurde dieses System wiederum weiterentwickelt und als eine multimodale Ansteuerung f¨ ur einen echten Roboter ausgef¨ uhrt. Damit handelte es sich schließlich um ein Robotersystem. Neben der Roboterdom¨ ane gibt es eine sehr komplexe Dom¨ane in dem Dialogsystem TRAINS. Dieses unterst¨ utzt einen Benutzer bei der Routenplanung einer amerikanischen Eisenbahngesellschaft [Allen et al. 1996]. 3.7.2 Systemarchitektur Im Gegensatz zu automobilen Sprachdialogsystemen sind Serversysteme nicht in ihre Umgebung eingebettet. Da telefonische Dialogsysteme sich von allgemeinen server-/PC-basierten Systemen kaum unterscheiden (einzige Ausnahme sind die Sprachausgabe und -eingabe u ¨ber ein Telefon anstatt PCLautsprecher bzw. Mikrofon), werden sie in diesem Abschnitt zusammen der Architektur eines SBS gegen¨ ubergestellt. Die schematische Systemarchitektur eines u ¨blichen serverbasierten Dialogsystems ist in Abbildung 3.11 dargestellt. 16

Der Name SHRDLU leitet sich von der H¨ aufigkeit des Auftretens der Buchstaben in der englischen Sprache ab, diese beginnt mit ETAOINSHRDLU.

52

3 Sprachdialogsysteme im Automobil

Abbildung 3.11. Schematische Systemarchitektur eines serverbasierten SDS

Im Folgenden werden die grundlegenden Architekturkomponenten eines serverbasierten Telefonsystems der Systemarchitektur eines automobilen Systems (wie bereits in 3.4 beschrieben) gegen¨ ubergestellt. Spracheingabe und akustische Vorverarbeitung Allen Systemarten gemein ist die Spracheingabe u ¨ber ein Mikrofon. Telefoniesysteme werden angerufen und ben¨ otigen daher keinen PTT-Knopf mehr. Bei ihnen ist die Spracherkennung entweder permanent aktiv (heutzutage die Regel) oder nur nach Ende eines Systemprompts. PC-basierte Systeme k¨onnen auch u ugen, meist werden sie jedoch per Schl¨ ussel¨ber einen PTT-Knopf verf¨ wort aktiviert. Umgebungsger¨ ausche k¨ onnen auch bei telefonischen Dialogsystemen auftreten. Da sich das eingebaute Mikrofon des Telefons in der Regel aber nahe am Mund befindet, ist der m¨ ogliche Einfluss solcher Umgebungsger¨ausche sehr viel kleiner als im Automobil. Der Aufwand der Signalerkennung ist f¨ ur Telefonsysteme insgesamt eher niedrig, daher reichen meist einfachere Algorithmen, welche in den Spracherkenner integriert werden. SDS auf einem PC k¨ onnen allgemeinen St¨ orger¨ auschen einer B¨ uroumgebung ausgesetzt sein. Daher wird hier meist ein einfaches Filterungsverfahren benutzt. Spracherkennung und Parsing Die Spracherkennung und das Parsing im Kfz unterscheiden sich prinzipiell u ¨berhaupt nicht von entsprechenden Komponenten auf Servern. Da aber auf Servern nicht so sehr auf Systemressourcen geachtet werden muss, wie in eingebetteten Systemen, kann die Spracherkennung hier sehr viel leistungsf¨ahiger sein und ausgefeiltere Algorithmen nutzen. Dialogmanager In telefonischen Dialogsystemen gibt es keine haptische Kontrolle u ¨ber das System. D.h. es entfallen sowohl der PTT-Knopf als auch die Displayausgaben, die auf dem Bildschirm der Headunit im Auto dargestellt werden k¨onnen. Daf¨ ur gibt es die Systemkontrolle, welche Telefonverbindungen erstellen und

3.7 Vergleich mit serverbasierten Dialogsystemen

53

beenden kann. Bei fr¨ uheren wenig komplexen Systemen u ¨bernahm diese Komponente auch die Aufgaben des Dialogmanagers und hieß daher IVR (engl. interactive voice response). Heute werden die Aufgaben der Telefoniekomponente vom Dialogmanager mit¨ ubernommen, da seine Aufgaben sehr viel komplexer geworden sind. Es gibt aber auch durchaus noch Architekturen mit einer Trennung zwischen Telefonsteuerung und Dialogmanager. Residiert ein Dialogsystem auf einem PC, entf¨allt die Verbindungskontrolle, die Dialogsteuerung ist also etwas einfacher. Daf¨ ur stehen h¨aufig ein Monitorbild oder andere zus¨ atzliche Ausgabemodalit¨aten zur Verf¨ ugung. Tlw. gibt es sogar die M¨ oglichkeit verschiedener Eingabemodalit¨aten. In beiden F¨allen kann ein Dialog von den zus¨ atzlichen M¨oglichkeiten profitieren, allerdings ist die Dialogkontrolle ungleich komplexer, da in diesem Fall Widerspr¨ uche vermieden werden m¨ ussen und eine Synchronisation der verschiedenen Modalit¨ aten durchgef¨ uhrt werden muss. Headunit / Backend Da es bei serverbasierten Systemen nicht um die Steuerung angeschlossener Ger¨ ate geht, ist auch keine Headunit vorhanden. Stattdessen werden telefonische Systeme zur Informationsabfrage eingesetzt. Dementsprechend sind sie entweder an eine einfache Datenbank, das Internet oder ein anderes System angeschlossen. Diese Systeme werden allgemein als Backend bezeichnet. In der Regel k¨ onnen diese Systeme auch ohne ein Sprachdialogsystem betrieben werden, der gr¨ oßte Aufwand f¨ ur die Anbindung eines solchen Systems stellt in diesem Fall die Datenaufbereitung f¨ ur die Modalit¨at Sprache dar. Diese Funktionalit¨ at wird in der Regel vom Backend u ¨bernommen. Es gibt aber bereits kommerzielle Dialogsystemplattformen, bei denen auch der Dialogmanager einzelne Aufbereitungen durchf¨ uhren kann. F¨ ur PC-gest¨ utzte Systeme gilt dies entsprechend. R¨ uckmeldungen des Systems R¨ uckmeldungen des Dialogsystems k¨ onnen bei Telefonsystemen nur u ¨ber die Modalit¨ at Sprache geschehen, andere Kan¨ ale stehen nicht zur Verf¨ ugung.17 Bedingt durch die Vielzahl von telefonischen Dialogsystemen, vor allem als Auskunftssysteme mit dynamischen Daten, wird meist eine Sprachsynthese f¨ ur die Systemr¨ uckmeldungen verwendet. Da auf einem Telefonieserver allerdings auch sehr große Systemressourcen zur Verf¨ ugung stehen, kommen hier sehr gute Synthesen zum Einsatz, die einen entsprechenden Ressourcenbedarf von u ¨ber 100 MB haben. Damit klingen auch Sprachprompts u ¨ber eine TTS sehr nat¨ urlich. 17

In Zukunft wird mit moderneren Telefonprotokollen auch eine gleichzeitige graphische Ausgabe auf einem Display im Endger¨ at m¨ oglich sein.

54

3 Sprachdialogsysteme im Automobil

3.7.3 Beispielsysteme In diesem Abschnitt werden einige typische Dialogsysteme exemplarisch vorgestellt, um einen Eindruck des Funktionsumfangs solcher Systeme zu geben. Stauinformation Um die Arbeits- und Funktionsweise eines telefonischen Dialogsystems besser zu illustrieren, wird in diesem Abschnitt das Stauinformationssystem ISA vorgestelllt, die IBM Stau Applikation. Dieses System ist vom Autor des vorliegenden Werkes im Rahmen eines Praktikums im Sommer 1999 bei der IBM entwickelt worden. Im Jahr 2000 wurde es in einer erweiterten Version erst¨ mals der Offentlichkeit pr¨ asentiert [G¨ unther et al. 2000].

Abbildung 3.12. Die Systemarchitektur von ISA

ISA l¨ auft auf einem handels¨ ublichen PC, der mit einer Telefoniekarte best¨ uckt ist. Das System wurde mit Entwicklungstools der IBM entwickelt, n¨ aheres bei [Hamerich 2000]. Bei dieser Systemarchitektur existiert ein Telefonie-Interface, welches auf der Telefoniekarte ankommende Sprachsignale direkt an den Spracherkenner weiterleitet. Die Systemarchitektur von ISA ist in Abbildung 3.12 dargestellt. Das System erm¨ oglicht eine Stauabfrage f¨ ur alle deutschen Autobahnen und ist daher ein typisches Auskunftssystem. Die Daten der jeweils aktuellen Verkehrssituationen werden dabei in regelm¨ aßigen Abst¨anden vom Backend aus dem Internet geladen und f¨ ur die Sprachausgabe aufbereitet. Neben den sprachlichen R¨ uckmeldungen bietet ISA zus¨ atzlich die M¨oglichkeit, die einzelnen Meldungen als SMS auf ein Mobiltelefon zu senden. Da zur Zeit der Implementation die Technologie f¨ ur Sprachsynthesen noch nicht ausgereift genug war, wurden statische Systemr¨ uckmeldungen von einem Sprecher aufgezeichnet, um eine m¨ oglichst gute Sprachqualit¨at zu gew¨ahrleisten. Zur Ausgabe der dynamischen Stauinformationen wird allerdings kom-

3.7 Vergleich mit serverbasierten Dialogsystemen (Sys) (Ben) (Sys)

(Ben)

55

Willkommen bei ISA dem Stauinformationssystem der IBM. Von welchem Bundesland oder welcher Autobahn m¨ ochten sie Staumeldungen? Gibt es Staus in Hamburg? ¨ Letzte Anderung: 15:33 Uhr, es gibt eine Meldung: A7 Flensburg in Richtung Hannover zwischen HH-Schnelsen-Nord und Elbtunnel 11 Kilometer Stau. Wor¨ uber m¨ ochten sie als n¨ achstes Staumeldungen h¨ oren? ... Abbildung 3.13. Beispieldialog mit ISA

plett auf TTS zur¨ uckgegriffen. Anders w¨ are eine Ausgabe der dynamischen Anteile auch nur mit unverh¨ altnism¨ aßigem Aufwand realisierbar gewesen. Das Dialogmodell von ISA ist zustandsbasiert und besteht aus einem einzigen Zustand. Dabei k¨ onnen allerdings mehrere Anfragen hintereinander an das System gestellt werden, die alle vollst¨ andig sein m¨ ussen. Nachfragen von Seiten des Systems sind nicht vorgesehen. Die Dialogstrategie des Systems ist reaktiv. Die Dialogsteuerung ist als IVR-System ausgef¨ uhrt, welche alle anderen Systemkomponenten steuert. Die Steuerung selbst besteht aus einem erweiterten Tcl-Interpreter. Die eingef¨ ugten Erweiterungen dienen der Kontrolle der Telefonschnittstelle und der Spracherkennung. Die Dialogbeschreibung besteht aus einem IVR Script, das in der Skriptsprache Tcl implementiert ist und von der Dialogsteuerung ausgef¨ uhrt wird. Weiteres dazu siehe bei [Davies et al. 1999, Papineni et al. 1999]. Ein kurzer Beispieldialog mit ISA ist in Abbildung 3.13 dargestellt. Bahnauskunft Es gibt ein offizielles Sprachdialogsystem der Deutschen Bahn AG, welches bereits seit 1998 besteht und in den letzten Jahren sogar beworben wurde. Das System wurde von Nortel Networks konzipiert, die eingesetzte Spracherkennung stammt von Temic SDS. Die Auskunft kann aus dem Festnetz kostenlos18 angerufen werden und gilt als das bekannteste Sprachdialogsystem in Deutschland. Die Dialoge erfolgen stark systemgetrieben, wie im Beispiel auf Abbildung 3.14 zu ersehen ist. Philips Speech Processing (jetzt zu Nuance geh¨orend) hat in Deutschland seit langer Zeit eine prototypische Bahnauskunft am Telefonnetz.19 Dieses System ist mit einer gemischten Initiative ausgestattet und erlaubt auch die Verarbeitung vollst¨ andiger Anfragen. Gleichzeitig wird eine implizite Verifikationsstrategie verwendet (im Gegensatz zur expliziten Verifikation bei der 18 19

Die Rufnummer ist die 0800 / 150 70 90. Dieses System ist unter 0241 / 60 40 20 zu erreichen.

56

3 Sprachdialogsysteme im Automobil

offiziellen Bahnauskunft). Das System wurde bereits 1995 vorgestellt und war damals bereits sehr revolution¨ ar [Aust et al. 1995]. Ein Beispieldialog, der die andere Dialog- und Verifikationsstrategie illustriert, ist in Abbildung 3.15 zu sehen. Es ist klar zu erkennen, dass f¨ ur erfahrene Benutzer diese Dialogstrategie ein schnelleres Erreichen des Dialogziels erlaubt. Allerdings ist es umstritten, ob Novizen mit dieser Strategie ebenfalls gut zurechtkommen. Aus diesem Grund werden kommerzielle Systeme sehr h¨ aufig mit dieser langwierigen Dialogstrategie entwickelt. Zur Abk¨ urzung der Dialoge kann barge-in verwendet werden. Diese Technologie erlaubt eine Unterbrechung der Systemausgaben durch den Nutzer, was sehr zur Beschleunigung eines Dialogdurchlaufs beitragen kann. 3.7.4 Bewertung Neben den Hardwarevoraussetzungen unterscheiden sich Telefonie- und Automobilsysteme vor allem in ihrer Anwendungsdom¨ane. W¨ahrend am Telefon Systeme u uhrung von ¨berwiegend zur Informationsgewinnung oder sogar Ausf¨ Aktionen eingesetzt werden, dienen automobile Systeme der Steuerung angeschlossener Ger¨ ate.

3.8 Dialogsysteme im Alltag Sprachdialogsysteme sind heutzutage immer noch mehrheitlich ein Gegenstand der Forschung. Durchgesetzt haben sich diese Systeme bisher eigentlich nur am Telefon (vor allem in den USA wurden in den letzten Jahren zahlreiche Callcenter und Telefonausk¨ unfte durch Dialogsysteme ersetzt) und im Automobil. Auf dem Telefonmarkt gibt es zahlreiche Firmen im internationalen Gesch¨ aft, die auf diesem Gebiet t¨ atig sind. Dabei gibt es nur noch sehr wenige Komplettanbieter, welche das gesamte Portfolio von der Spracherkennung u ¨ber die Synthese bis zur Dialogerstellung anbieten. Der mit Abstand gr¨oßte ist dabei wohl das US-Unternehmen Nuance. Andere Firmen beschr¨anken sich auf die Implementation von Sprachdialogen und kaufen die daf¨ ur n¨otige Technologie ein. In Deutschland ist der Trend zu telefonischen Dialogsystemen bisher nicht so stark zu beobachten. Es gibt die telefonische Bahnauskunft (siehe Abschnitt 3.7.3), Telefonbanking und einige weitere, vgl. z.B. [Haas et al. 2004]. Doch insgesamt werden Telefoniesysteme in Deutschland nicht sehr erfolgreich angenommen. Dies liegt vor allem an der Bedienbarkeit der Systeme, wie in [Peissner et al. 2004] berichtet wurde. Sprachbediensysteme im Auto haben sich seit 1996 stark durchgesetzt und sind inzwischen als Ausstattungsoption in fast jedem Fahrzeug der Ober- und Mittelklasse zu finden [Hanrieder 2004].

3.8 Dialogsysteme im Alltag (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys)

57

Herzlich willkommen beim Reiseservice der Deutschen Bahn. (...) Bitte nennen sie jetzt ihren Abfahrtsbahnhof. Wenn sie Hilfe zu unserem Service ben¨ otigen, sagen sie ’Anleitung’. Ulm M¨ ochten sie von Ulm Hauptbahnhof abfahren? Ja Wohin m¨ ochten sie fahren? Hamburg Die Hansestadt Hamburg, korrekt? Ja Bitte w¨ ahlen sie oder sagen sie ’Neueingabe’: Hamburg Hauptbahnhof, Altona, Dammtor, Harburg oder weitere Bahnh¨ ofe. Hauptbahnhof Sie m¨ ochten also nach Hamburg Hauptbahnhof fahren? Ja Bitte w¨ ahlen sie jetzt die Art der Verbindungssuche und sagen sie ’Ankunftszeit’ oder ’Abfahrtszeit’. Abfahrtszeit An welchem Tag m¨ ochten sie fahren? morgen Sie m¨ ochten also morgen am 15. April fahren? Ja Um welche Uhrzeit m¨ ochten sie fahren? Um acht Uhr Sie m¨ ochten also um acht Uhr morgens fahren? Ja Es gibt die folgende Verbindung: (...) Abbildung 3.14. Beispieldialog mit Bahnauskunft der DB AG

(Sys) (Ben) (Sys) (Ben) (Sys) (Ben) (Sys)

Guten Abend. Sie k¨ onnen Zugverbindungen zwischen 1.000 Bahnh¨ ofen in Deutschland erfragen. Von wo nach wo m¨ ochten sie fahren? Von Ulm nach Hamburg Wann m¨ ochten sie von Ulm Hauptbahnhof nach Hamburg Hauptbahnhof fahren? Morgen um Acht Sie m¨ ochten also morgen um acht Uhr morgens fahren? Ja Es gibt die folgende Verbindung: (...) Abbildung 3.15. Beispieldialog mit der Philips-Bahnauskunft

58

3 Sprachdialogsysteme im Automobil

Grunds¨ atzlich macht die Benutzung der Modalit¨at Sprache nur Sinn, wenn ihre Verwendung schneller ist, als andere Modalit¨aten oder andere Modalit¨ aten ausscheiden [Cameron 2000]. Dies spricht f¨ ur die Sprachbedienung im Auto. Grunds¨ atzlich wird es auch als Argument f¨ ur telefonische Auskunftssysteme ins Feld gef¨ uhrt. Allerdings wird dabei meist u ¨bersehen, dass hier durchaus bessere Alternativen existieren. Die Bahnauskunft, welche als eines der ¨ altesten Themenfelder f¨ ur Sprachdialogsysteme gilt (siehe z.B. [Mast 1993, Peckham 1993]) ist vom sprachlichen Umfang f¨ ur die Eingabe gesehen zwar hoch attraktiv, wenn es allerdings um die Auswahl einer Zugverbindung mit Umstiegsoptionen geht, ist eine visuelle Auflistung sehr viel aussagekr¨ aftiger, als eine vorgelesene Liste. Sprache als fl¨ uchtige Modalit¨at ist an dieser Stelle im Nachteil. Da außerdem bei vielen Benutzern eine gewisse Scheu vor diesen Systemen besteht und tlw. auch bereits schlechte Erfahrungen in der Vergangenheit gemacht wurden, werden sie von unerfahrenen Benutzern ungern benutzt. Eines der gr¨ oßten Probleme f¨ ur Sprachdialogsysteme ist daher ihre Akzeptanz beim Benutzer (wie auch schon mehrfach, z.B. in [Boros 2004] oder bei [Peissner et al. 2004] festgestellt wurde). Zwar sollte jeder Benutzer in der Lage sein zu sprechen, aber richtig mit einem System zu sprechen vermag leider nicht jeder. Dies kann an der Spracherkennung liegen (z.B. an ung unstigen Umgebungsbedingungen, Dialekten oder der Lautst¨arke des Sprechers), auch am schlechten Design der Applikation (vgl. Abschnitt 2.10), f¨ ur einen Benutzer ist es jedoch immer das gesamte System, welches versagt. Vielleicht hat auch die Erwartungshaltung vieler Benutzer damit zu tun, schließlich sind Systeme aus dem Kino, wie HAL oder der Bordcomputer vom Raumschiff Enterprise sehr vielen bekannt. Auch gibt es viele Benutzer, die gerne austesten, wieviel ein System versteht ohne eine sinnvolle Anfrage stellen zu wollen. Dies entspricht zwar nicht dem Verhalten eines kooperativen Benutzers, wie ihn Grice fordert (vgl. Abschnitt 2.2), aber daf¨ ur umso mehr der menschlichen Neugierde. Von daher wird noch viel Forschung in der Schaffung sprachlicher Benutzerschnittstellen und die Verbesserung der Spracherkennung n¨otig sein, um diese noch unrealistischen Fernziele auch erreichen zu k¨onnen.

3.9 Zusammenfassung Basierend auf den theoretischen Grundlagen in Kapitel 2 wurde in diesem Abschnitt die grundlegende Architektur und Funktionsweise eines automobilen Sprachdialogsystems eingef¨ uhrt. Außerdem wurde der Begriff des Sprachdialogsystems definitorisch gekl¨ art. Ferner wurde die Integration dieser Systeme in das Automobil thematisiert und die wichtigsten Funktionalit¨aten exemplarisch vorgestellt. Insbesondere die Notwendigkeit einer speicheroptimierten Dialogbeschreibung wurde in diesem Rahmen dargestellt. F¨ ur das allgemeine

3.9 Zusammenfassung

59

Verst¨ andnis wurden die automobilen Sprachsysteme den serverbasierten gegen¨ ubergestellt und miteinander verglichen. Mit diesem Kapitel ist damit die Basis f¨ ur die zweite Ebene des in Abschnitt 1.3 eingef¨ uhrten Schichtenmodells gelegt. In Kapitel 5 wird der Dialogmanager behandelt und die verschiedenen Alternativen zur Erstellung einer Dialogbeschreibung vorgestellt. Dabei wird auch darauf hingewiesen, wie bereits die Implementierung eines Sprachdialogs durch die Umgebungsbedingungen beeinflusst wird. Damit wird die unterste Ebene der softwaretechnischen Umsetzung des Schichtenmodells genauer illustriert. Aufbauend auf den grundlegenden Darstellungen dieses Kapitels wird allerdings zuerst im n¨ achsten Kapitel gekl¨ art, wie ein Sprachdialog im Automobil aussehen und funktionieren sollte. Damit wird die oberste Schicht des Schichtenmodells dargestellt.

4 Benutzerfreundliche Sprachdialoge im Automobil

Nachdem nun die theoretischen Grundlagen f¨ ur Sprachdialoge dargestellt sind und auch die technischen Rahmenbedingungen f¨ ur serverbasierte und eingebettete Dialogsysteme eingef¨ uhrt wurden, geht es in diesem Kapitel um die Benutzung dieser Systeme. Da Dialogsysteme als Mensch-Maschine-Schnittstelle gedacht sind, m¨ ussen sie auch von Menschen bedient werden k¨onnen. Es sollte also das Ziel sein, eine m¨ oglichst gut benutzbare Schnittstelle f¨ ur den Menschen zu schaffen, also eine hohe Benutzerfreundlichkeit zu erreichen. Da dieser Begriff allerdings sehr allgemein erscheint, wird in diesem Abschnitt zuerst eine genaue Definition des Begriffs f¨ ur die weitere Verwendung in diesem Buch vorgenommen. Anschließend werden verschiedene Ans¨atze f¨ ur benutzerfreundliche Dialoge diskutiert und deren Einsatzm¨oglichkeit im Feld der Sprachbedienung er¨ ortert. Abschließend werden verschiedene Maximen f¨ ur benutzerfreundliche Dialoge im Automobil definiert.

4.1 Benutzerfreundlichkeit Intuitiv hat jeder Mensch ein eigenes Verst¨ andnis des Begriffs benutzerfreundlich, daher wird im Folgenden eine Definition des Begriffs vorgenommen. Grunds¨ atzlich beschreibt der Begriff die Bedienbarkeit technischer Systeme1 durch menschliche Benutzer und nicht die Freundlichkeit oder Kooperativit¨ at des Benutzers oder des Systems. Neben dem Begriff Benutzerfreundlichkeit werden auch die Begriffe Nutzerfreundlichkeit, Bedienbarkeit oder Gebrauchstauglichkeit (engl. usability) verwendet. Im Prinzip beschreiben alle diese Begriffe dieselbe Eigenschaft eines technischen Systems, n¨amlich das Maß f¨ ur die Nutzungsqualit¨ at der Mensch-Maschine-Schnittstelle des betreffenden technischen Systems. 1

Um diesen Text m¨ oglichst allgemein zu halten, wird in diesem Abschnitt nur noch von Systemen gesprochen; gemeint sind damit jedoch technische Systeme, Produkte, Ger¨ ate oder Vorrichtungen allgemein, ohne R¨ ucksicht auf bestimmte Einsatzbereiche.

62

4 Benutzerfreundliche Sprachdialoge im Automobil

Laut [Nielsen 1993] gilt ein System als benutzerfreundlich, wenn es einfach zu erlernen, einpr¨ agsam, nicht fehlerintensiv, sowie angenehm und effizient zu bedienen ist. Die internationale Normenreihe ISO 9241, welche als europ¨aische Norm umgesetzt und auch vom DIN u ¨bernommen wurde (daher korrekt DIN EN ISO 9241 genannt), beschreibt die Ergonomie von Mensch-System-Interaktion.2 Teil 11 dieser Norm formuliert die Gebrauchstauglichkeit als das Ausmaß, in dem ein System durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen. In diesem Werk soll die Benutzerfreundlichkeit aus der Gebrauchstauglichkeit nach DIN EN ISO 9241-11 abgeleitet werden. Des Weiteren sollen die Begriffe Gebrauchstauglichkeit, Usability und Benutzerfreundlichkeit synonym verwendet werden. Es gilt Definition 4.1. Definition 4.1. Die Benutzerfreundlichkeit ist ein Maß, welches die Nutzungsqualit¨at eines technischen Systems durch einen (menschlichen) Benutzer beschreibt. Das Ausmaß der Benutzerfreundlichkeit wird bestimmt aus der Effektivit¨at, der Effizienz und der Zufriedenheit der Zielerreichung bei Benutzung des Systems. Unabh¨ angig von dieser Definition gilt f¨ ur die Auswertung der Benutzerfreundlichkeit, dass diese nur durch Tests und anschließende Befragungen erfolgen kann. Dabei werden subjektive Elemente in die Bewertung der einzelnen Benutzer unvermeidlich mit einfließen. Dies erschwert allerdings einen Vergleich von verschiedenen Systemen, umso mehr, wenn nicht gleiche Benutzergruppen ausgew¨ ahlt werden.

4.2 Benutzerfreundlichkeit von Sprachdialogen Die Auseinandersetzung mit der Benutzerfreundlichkeit von Sprachdialogen ist per se ein großer Hinweis auf den Reifegrad der Technologie und damit auch als ein Erfolg zu werten. Denn es geht aktuell bei Sprachdialogsystemen nicht darum, ob diese grunds¨ atzlich funktionieren, sondern um die Bedienbarkeit f¨ ur eine gr¨ oßere Zielgruppe. Allgemein gilt, wenn ein neues Produkt entwickelt wurde, welches einigen technologischen Fortschritt in sich vereint, wird dieses zuerst f¨ ur sogenannte fr¨ uhzeitige Anwender (engl. early adopters) vermarktet. Diese Zielgruppe ist vor allem an neuen Technologien bzw. Ger¨aten interessiert und nimmt auch unausgereifte Produkte gern in Kauf, wenn die Produkte nur interessant und/oder auff¨ allig genug sind. F¨ ur diese Zielgruppe ist die Benutzerfreundlichkeit eines Produkts daher unwichtig. Eine hohe Benutzerfreundlichkeit ist f¨ ur die breite Akzeptanz eines Produkts entscheidend, denn je mehr 2

Diese Norm enth¨ alt unter anderem einen Teil 110 (ersetzt den fr¨ uheren Teil 10), welcher die Grunds¨ atze der Dialoggestaltung behandelt (vgl. Abschnitt 2.10).

4.2 Benutzerfreundlichkeit von Sprachdialogen

63

durchschnittliche Benutzer ein Produkt bedienen k¨onnen, desto mehr Absatz kann es finden. Mit gutem Marketing kann nat¨ urlich ein Produkt auch aus anderen Gr¨ unden am Markt erfolgreich sein, dies ist im Rahmen dieses Werkes allerdings nicht wichtig. Aber die Tatsache, dass Sprachdialoge mit einem Automaten nicht mehr nur Science Fiction oder reine Forschungsthemen sind, sondern inzwischen mit dieser Technologie Geld verdient werden kann, bedeutet einen wichtigen Schritt zur weiteren Verbreitung der Technologie. Im Telefoniebereich ist Sprachtechnologie inzwischen allgemein verbreitet und auch akzeptiert (siehe u.a. [Matzer und Frisch 2003, Hottelet 2004]), Gartner hat bereits vor einiger Zeit der Spracherkennung f¨ ur Telefonie und Callcenter den Produktivit¨atsstatus zugewiesen [Rademacher 2004]. Zu guter Letzt ist auch die Verwendung von Sprachtechnologie in mobilen Anwendungen inzwischen recht verbreitet [Heim und Schw¨ ogler 2006]. Das heißt, insgesamt ist es f¨ ur das Feld der Sprachdialogsysteme ein großer Fortschritt, Benutzerakzeptanz und Benutzerfreundlichkeit in den Vordergrund zu stellen. Die Notwendigkeit dessen wurde bereits mehrfach betont, u.a. bei [Frisch 2004, Peissner et al. 2004]. Die Frage ist allerdings, wie man ein Sprachdialogsystem grunds¨ atzlich benutzerfreundlich machen kann. Was liegt an dieser Stelle n¨ aher, als sich einen m¨oglichst perfekten Dialog als Vorbild zu w¨ ahlen? Der denkbar benutzerfreundlichste Dialog ist der mit einem menschlichen Partner. Bei dieser Art von Dialogen treten u ¨blicherweise keine typischen Anwenderfehler auf, bei denen ein Partner entweder gar nicht spricht, keine Information u ¨ber sein Dialogziel liefert oder auf Fragen nicht antwortet. Diese Fehler sind laut [Heisterkamp 2003] beim Dialog mit einer Maschine sehr typisch. Menschliche Dialogpartner k¨onnen in diesen Situationen sehr viel besser reagieren, da die Aufl¨ osung von Missverst¨andnissen und eine inh¨ arente Fehlerkorrektur ein Teil der zwischenmenschlichen Kommunikation sind und teilweise sogar unbewusst ablaufen. Damit ist allerdings das Vorbild der zwischenmenschlichen Kommunkation sehr schwer zu erreichen. Dies gilt umso mehr, wenn f¨ ur die Implementierung eines Dialogsystems nur beschr¨ ankte Hardwareressourcen zur Verf¨ ugung stehen, wie z.B. im Automobil (vgl. Kapitel 3). Bis also der Mensch als Vorbild voll erreicht werden kann, sollte wenigstens eine inzwischen als sehr benutzerfreundlich bekannte Technologie als Vorbild dienen. Einen sehr guten Vorschlag macht hier [Heisterkamp 2003] mit seinem aufgestellten Vergleich des Lichtschalters. Wenn es bei Betreten eines Raumes dunkel ist, wird jeder Mensch intuitiv nach dem Lichtschalter suchen. Jedes Kind lernt heute die Bedeutung von Lichtschaltern, doch dies war nicht immer so. Heisterkamp zeigt in seinem Beitrag ein Schild vom Ende des 19. Jahrhunderts, welches besagt, dass der jeweilige Raum mit elektrischem Licht ausgestattet sei und zum Einschalten nur der Schalter bet¨atigt werden m¨ usse und kein Streichholz ben¨ otigt w¨ urde. Aus heutiger Sicht erscheint dieser Hinweis unn¨ otig und geradezu albern, aber als das Prinzip der elektrischen Beleuchtung noch neu war, war dieser Hinweis absolut notwendig.

64

4 Benutzerfreundliche Sprachdialoge im Automobil

Das Beispiel mit dem Lichtschalter zeigt eindrucksvoll, wie eine Technologie in den Alltag von Menschen eindringen und als nahezu selbstverst¨andlich angesehen werden kann. Ist diese Technologie damit auch als benutzerfreundlich zu bezeichnen? Nach Definition 4.1 ist eine Technologie nutzerfreundlich, wenn sie eine effektive, effiziente und zufriedenstellende Erreichung des Benutzerziels erm¨ oglicht. Im Allgemeinen ist die Bet¨atigung des Lichtschalters hochgradig effektiv, Ausnahmen sind eine defekte Gl¨ uhbirne oder nicht vorhandener Strom am Leuchtmittel. Auch ist der Vorgang des Lichteinschaltens sehr effizient, da nur ein Handgriff zum Einschalten getan werden muss. Zuletzt ist die Nutzung des Lichtschalters auch sehr zufriedenstellend, da in der Regel der vorher dunkle Raum sofort hell erleuchtet ist. Damit kann die Kom” munikation“ mit dem elektrischen Licht u ¨ber den Lichtschalter eindeutig als benutzerfreundlich bezeichnet werden. Mit dem Beispiel der Gl¨ uhbirne konnte illustriert werden, dass auch eine rein technische Kommunikation – in dem Fall die haptische Bet¨atigung eines Lichtschalters – sehr benutzerfreundlich sein und von jedem Menschen einfach durchgef¨ uhrt werden kann. Da nun die sprachliche Interaktion sehr viel nat¨ urlicher und in der Regel auch einfacher ist, als eine haptische, ist dies eine sehr gute Voraussetzung f¨ ur benutzerfreundliche Sprachdialoge. Problematisch ist hierbei lediglich die Erwartungshaltung vieler Benutzer, welche fast intuitiv die volle Leistungsf¨ ahigkeit eines Menschen hinter einem Dialogsystem vermuten. Welche Eigenschaften sollte also ein benutzerfreundliches SDS haben und was unterscheidet ein solches SDS von einem normalen“ SDS? Insbesondere ” Benutzerfehler sind ein Problem f¨ ur SDS, wie u.a. bei [Eckert et al. 1995, Bernsen et al. 1997] berichtet. Daneben kann es aber auch Fehler im SDS geben. Zusammengefasst k¨ onnen grunds¨ atzlich folgende drei Arten von Fehlern auftreten: Eingabefehler werden von Benutzern verursacht, die h¨aufigsten Fehler dabei sind: zu fr¨ uhes Sprechen beschreibt die Situation, dass der Benutzer spricht, bevor der Audiokanal f¨ ur den Spracherkenner ge¨offnet wird. In diesem Fall kann der Anfang des Sprachsignals nicht richtig verarbeitet werden, eine Fehlerkennung ist damit unvermeidlich. falsche Wortwahl auch als OOV-Fehler (engl. out of vocabulary) bezeichnet. In diesem Fall hat der Benutzer ein Wort benutzt, welches nicht im Vokabular des Spracherkenners vorhanden ist und deshalb in der Regel nicht erkannt werden kann. keine Eingabe – auch timeout genannt – liegt vor, wenn der Benutzer zu lange mit seiner Spracheingabe wartet. Da nach einem festgeschriebenen Zeitintervall der Spracherkenner den Audioeingang schließt, tritt in diesem Fall ein sogenannter Timeout-Fehler auf, um eine entsprechende Reaktion vom Dialogmanager ausl¨osen zu lassen.

4.2 Benutzerfreundlichkeit von Sprachdialogen

65

Interne Fehler k¨ onnen auftreten, wenn Benutzer¨außerungen intern falsch oder gar nicht weiterverarbeitet werden. Ersteres kann vor allem bei statisti¨ schen Grammatikformalismen auftreten. Wenn eine Außerung gar nicht weiterverarbeitet wird, liegt ein klassischer Designfehler vor, d.h. der Dialogdesigner hat f¨ ur einen Fall keine Reaktion vorgesehen. Ausgabefehler sind auf Fehler im Dialogskript zur¨ uckzuf¨ uhren. In diesem Fall wird auf eine richtig verarbeitete Eingabe mit einem falschen Konzept geantwortet. Ein benutzerfreundliches SDS sollte m¨ oglichst robust gegen diese Fehler sein. Daher ist es wichtig festzuhalten, in welchen der bereits in Abschnitt 3.4 vorgestellten Komponenten eine entsprechende Robustheit eingebaut werden sollte. Die meisten Benutzerfehler bereiten bereits bei der Spracheingabe Probleme. Hier ist vor allem die Spracherkennung betroffen. Timeout-Fehler und zu fr¨ uhes Sprechen k¨ onnen zumindest von den meisten u ¨blichen Spracherkennern identifiziert werden, so dass der Dialogmanager eine entsprechende Reaktion einleiten kann und die Anfrage leicht ver¨ andert wiederholt an den Benutzer stellt. Schwieriger ist Erkennung von OOV-Fehlern. Denn bedingt durch das Prinzip der statistischen Spracherkennung wird vom Erkennungsalgorithmus auch im Fall einer falschen Eingabe versucht, die Eingabe auf ein sinnvolles Ergebnis abzubilden. Allerdings gibt es auch f¨ ur dieses Problem verschiedene L¨ osungsvorschl¨ age, wie u.a. bei [Boros et al. 1997, Bazzi und Glass 2000, Scharenborg und Seneff 2005, Huang et al. 2006] dargestellt wird. Grunds¨atzlich ist jedoch die Gefahr von OOV-Fehlern bei den doch sehr beschr¨ankten Dialogdom¨ anen im Automobil eher gering und tritt haupts¨achlich bei dynamischem Vokabular ( anrufen bei Kartoffelsalat“) auf, mit den genannten ” L¨ osungsvorschl¨ agen kann dieses Problem aber entsch¨arft werden. Sehr viel gr¨ oßer ist die M¨ oglichkeit eines solchen Fehlers bei Serveranwendungen mit großen Vokabularien z.B. zur Suche in Datenbanken. Interne Fehler tauchen in der Regel im Zusammenspiel zwischen Spracherkennung, Parsing und Dialogmanager auf und sollten soweit wie m¨oglich durch intensives Testen und sorgf¨ altige Entwicklung vermieden werden. Wenn zudem eine handgeschriebene Grammatik verwendet wird, sind keine Fehler bei der Zuweisung von semantischen Konzepten an Worte zu erwarten. Ausgabefehler k¨ onnen bei zustandsbasierten Dialogmodellen nur durch Implementations- oder Designfehler auftreten. Hier ist eine sorgf¨altige und fachm¨ annische Dialogentwicklung umso wichtiger. Nachdem die internen und Ausgabefehler vor allem durch Entwicklungsfehler auftreten k¨ onnen, ist eine Fehlerbehandlung im laufenden System nur schwer m¨ oglich. Dagegen gibt es f¨ ur alle genannten Eingabefehler M¨oglichkeiten zur Behandlung innerhalb eines Dialogsystems. Das bedeutet, dass zumindest die Kommunikation mit dem System immer zum Dialogziel gef¨ uhrt werden kann. Es ist im Allgemeinen daher keine Frage der technischen Machbarkeit einer Fehlerbehandlung, sondern eher eine Frage des Aufwands f¨ ur atzlich ist der Aufwand zur Fehlerdie Umsetzung dieser Behandlung. Grunds¨

66

4 Benutzerfreundliche Sprachdialoge im Automobil

behandlung in einem Sprachdialogsystem n¨ amlich fast genauso groß, wie der Aufwand zur Entwicklung der eigentlichen funktionellen Applikation. Daher kann man am Vorhandensein und der Qualit¨ at einer Fehlerbehandlung auch die G¨ ute eines Dialogsystems erkennen. Wie dargestellt, werden die meisten dieser Fehler entweder im Dialogmanager bzw. Dialogskript verhindert oder dort zumindest gemeldet. Das heißt, dass an dieser Stelle fast alle der genannten Fehler abgearbeitet werden k¨onnen und vor allem diese Stelle elementar wichtig f¨ ur robuste und auch benutzerfreundliche Sprachdialoge ist. Was genau sollte also am Dialog beachtet werden? Wie bereits in Kapitel 2 definiert wurde, ist ein Dialog eine zielorientierte sprachliche Interaktion zwischen zwei Partnern. Im Umfeld von Dialogsystemen werden die Partner klar als menschlicher Benutzer und automatisiertes Dialogsystem gesehen. Weiter wurde bereits bei der allgemeinen Vorstellung des Dialogdesigns in Abschnitt 2.10 auf die grundlegenden Prinzipien hingewiesen, welche f¨ ur die Erstellung eines kooperativen Dialogs im Grice’schen Sinne (siehe Abschnitt 2.1) relevant sind. Das Dialogdesign ist damit der Schl¨ ussel zum benutzerfreundlichen Dialog. Ebenfalls in Abschnitt 2.10 wurde bereits auf Teil 110 der Norm DIN EN ISO 9241 eingegangen. Da dies ein sehr wichtiger Teil ist, wird er an dieser Stelle nochmal kurz wiedergegeben. Dieser Teil der Norm besch¨aftigt sich mit den Grunds¨ atzen der Dialoggestaltung. Zwar richtet sich die Norm grunds¨ atzlich eher an graphische Dialoge mit Bildschirmger¨aten, aber prinzipiell k¨ onnen die Anforderungen auch f¨ ur Sprachdialoge u ¨bernommen werden. Teil 110 der Norm beschreibt folgende Grunds¨atze f¨ ur die Gestaltung einer Mensch-Maschine-Schnittstelle: Aufgabenangemessenheit bedeutet, ein Dialog sollte eine geeignete Funktionalit¨ at f¨ ur den gew¨ unschten Zweck darstellen und unn¨otige Interaktionen minimeren. Selbstbeschreibungsf¨ ahigkeit steht f¨ ur eine hohe Verst¨andlichkeit des Systems durch R¨ uckmeldungen oder sogar Hilfen. Steuerbarkeit des Dialogs: der Benutzer sollte den Dialog steuern k¨onnen. Erwartungskonformit¨ at steht f¨ ur einen konsistenten und f¨ ur den Benutzer durchschaubaren Dialogablauf. Fehlerrobustheit – also eine Robustheit des Dialogs gegen¨ uber Benutzerfehlern – hier wird insbesondere eine fehlervermeidende Dialoggestaltung gefordert, ansonsten sollen erkannte Fehler nicht das Erreichen des Dialogziels verhindern. Individualisierbarkeit bedeutet die Anpassbarkeit an den Benutzer. Lernf¨ orderlichkeit steht f¨ ur eine minimale Erlernzeit der Anwendung. Wenn also ein Sprachdialog m¨ oglichst viele dieser Punkte m¨oglichst gut erf¨ ullt, dient dies ebenfalls der Benutzerfreundlichkeit. Denn ein der Aufgabe angemessener, verst¨ andlicher, konsistenter und fehlerrobuster Sprachdialog sollte die Effektivit¨ at, die Effizienz und auch die Zufriedenheit eines Benutzers

4.3 Evaluation von Sprachdialogen

67

steigern. Damit w¨ urde ein solcher Dialog im Sinne der Definition 4.1 als benutzerfreundlich gelten. Aus diesem Grunde sind die aufgef¨ uhrten Grunds¨atze der Gestaltung von Mensch-Maschine-Schnittstellen eine wichtige Grundlage f¨ ur eine erfolgreiche Dialogentwicklung. Der Punkt der Individualisierbarkeit ist in automobilen Sprachdialogen bisher im Produkt noch nicht umgesetzt worden. Es gibt jedoch Studien u ¨ber sogenannte adaptive Dialoge, wie z.B. die ausf¨ uhrliche Darstellung von [Hassel 2006].

4.3 Evaluation von Sprachdialogen Grunds¨ atzlich kann mit der Evaluation eines Dialogsystems sowohl dessen Leistungsf¨ ahigkeit gemessen werden, als auch die Akzeptanz des Systems bei Benutzern. W¨ ahrend sich die Performanzevaluation allerdings ausschließlich an messbaren objektiven Kriterien orientiert, basiert eine Benutzerevaluation bedingt durch den Einfluss menschlicher Nutzer auf subjektiven Kriterien. 4.3.1 Performanzevaluation Eine Performanzevaluation kann auf verschiedene Arten durchgef¨ uhrt werden. Die aufw¨ andigere Methode besteht darin, die einzelnen Komponenten eines Dialogsystems zu evaluieren. Dieses Evaluierungsverfahren wird auch glassbox evaluation genannt [Gibbon et al. 1997]. Grunds¨atzlich wird bei dieser Evaluationsmethode jede einzelne Komponente eines Dialogsystems evaluiert. Maßgeblich sind dabei die jeweils ein- und ausgehenden Daten. F¨ ur einige Komponenten ist es durchaus einfach m¨ oglich, deren einzelne Performanz zu messen, so gibt es f¨ ur die Spracherkennung mit der Erkennungsrate und der Wortkorrektheit sogar sehr etablierte Maße f¨ ur eine standardisierte Evaluation [Gibbon et al. 1997]. Eine andere Methode zur Performanzevaluation von Dialogsystemen ist, das System als Ganzes zu betrachten und zu evaluieren. In diesem Fall spricht man von der black-box evaluation [Gibbon et al. 1997, Hanrieder et al. 1998], dabei werden die Eingabedaten mit den Ausgaben verglichen und diese evaluiert. M¨ ogliche Messungen dieser Art von Evaluation k¨onnen z.B. die bei [Gibbon et al. 1997] definierten Maße sein: • • •

¨ Außerungsdauer – die durchschnittliche L¨ ange von Benutzer¨außerungen Dialogdauer – die durchschnittliche Dialogdauer in Sekunden Kontextuelle Angemessenheit – die Angemessenheit von Dialog¨außerungen in Anbetracht der vorhergehenden Benutzer¨außerungen • Transaktionserfolg (engl. task success) – gibt den Erfolg der Zielerreichung bei Dialognutzung an

68

4 Benutzerfreundliche Sprachdialoge im Automobil

4.3.2 Benutzerevaluation Die Benutzerevaluation fragt nach der Benutzerfreundlichkeit des Dialogsystems. In Abschnitt 4.1 wurde die Benutzerfreundlichkeit definiert als Maß, welches aus der Effektivit¨ at, der Effizienz und der Zufriedenheit bei der Zielerreichung der Systembenutzung bestimmt wird. Das bedeutet, dass f¨ ur die Benutzerevaluation genau diese drei Datenarten bestimmt bzw. erfragt werden m¨ ussen. Da diese Maße jedoch nicht einfach nur durch Beobachtung bestimmt werden k¨ onnen, ist die Befragung der Probanden hier unerl¨asslich [Nielsen 1993, Shneiderman 2002]. Die Befragung von Probanden bei der Untersuchung von Sprachdialogsystemen kann sich laut [Larsen 2003] allerdings nur zum Teil an vorhandenen Standardss f¨ ur die Messung der Benutzerfreundlichkeit von graphischen Dialogsystemen orientieren. Schließlich ist Sprache ein fl¨ uchtiges Medium, das Interface grunds¨ atzlich fehleranf¨ alliger als ein graphisches Pendant und außerdem ist das Vergessen von Kommandos [Hof et al. 2006] nur bei Sprachschnittstellen von so großer Bedeutung. Von daher ist die Auswahl der Fragen und deren Auswertung hochgradig abh¨ angig vom jeweilig zu evaluierenden System. 4.3.3 Vergleichende Evaluation Aus der obigen Darstellung folgt, dass die Vergleichbarkeit von Systemevaluationen nur sehr eingeschr¨ ankt m¨ oglich ist. Wenn die Frageb¨ogen systemabh¨ angig variiert werden, ist ein Vergleich der subjektiven Merkmale kaum m¨ oglich. Auch bei einer glass-box Evaluation kann ein Vergleich verschiedener Systeme ebenfalls nicht sinnvoll vorgenommen werden [Gibbon et al. 1997]. Allerdings liefert auch eine black-box Evaluation eine Reihe von verschiedenen Werten, die einzeln mit anderen Systemen vergleichbar und anwendbar sein m¨ ussen. Basierend auf dieser Problematik haben [Walker et al. 1997] mit PARADISE (PARAdigm for DIalogue System Evaluation) einen Ansatz entwickelt, objektive und subjektive Evaluationsfaktoren unter einer Funktion zusammenzufassen. Dies erlaubt nicht nur eine ganzheitliche Beurteilung der Systembedienbarkeit sondern zus¨ atzlich auch den Vergleich von unterschiedlichen Dialogstrategien und sogar unterschiedlichen Systemen. Allerdings hat dieser Ansatz auch einige Schwachstellen, die u.a. bei [Hassel 2006] aufgezeigt wurden. Ein wesentlicher Kritikpunkt ist dabei, dass bei Untersuchungen von Sprachbediensystemen im Automobil die Grundannahme von PARADISE u ¨ber einen Zusammenhang zwischen der Nutzerzufriedenheit auf der einen und Dialogkosten und Dialogerfolg auf der anderen Seite nicht best¨atigt werden konnte. Aus diesen Gr¨ unden wird f¨ ur die Dom¨ ane der Sprachbedienung im Automobil auch in diesem Buch ein Evaluationsergebnis aus mehreren Einzelergebnissen zusammengesetzt sein und nicht auf PARADISE zur¨ uckgegriffen.

4.4 Evaluationsm¨ oglichkeiten

69

4.4 Evaluationsm¨ oglichkeiten Bevor allerdings konkrete Ans¨ atze f¨ ur benutzerfreundliche Dialoge besprochen werden, muss gekl¨ art werden, wie unterschiedliche Ans¨atze evaluiert werden k¨onnen. Grunds¨ atzlich gibt es daf¨ ur verschiedene M¨oglichkeiten, die im folgenden kurz dargestellt werden. 4.4.1 Wizard of Oz Versuche Bevor u ur ein funktionsf¨ahiges System existiert, ¨berhaupt die Infrastruktur f¨ kann bereits in einer sehr fr¨ uhen Entwicklungsphase ein Wizard of Oz Versuch (WOZ) durchgef¨ uhrt werden. Diese Art von Versuchen hat sich insgesamt als brauchbar und sinnvoll durchgesetzt [Dahlb¨ ack et al. 1993]. Bei einem WOZ wird ein uninformierter Benutzer vor ein Ger¨ at gesetzt, welches er per Sprache bedienen soll. Dieses Ger¨ at wird allerdings von einem im Nebenraum sitzenden Menschen (dem Wizard ) gesteuert. Das bedeutet, weder der Dialogmanager noch der Spracherkenner sind echte Systeme, ihre Funktion wird vielmehr von einem Menschen u onnen auch sehr aufw¨andige oder ¨bernommen. Damit k¨ sogar noch nicht machbare Sprachdialoge simuliert und getestet werden. Auch f¨ ur die Erprobung von Sprachdialogen im Automobil haben sich WOZ Versuche durchgesetzt, wie unter anderem bei [Geutner et al. 2002, Cheng et al. 2004, Petrik et al. 2005] nachgelesen werden kann. Grunds¨ atzlich dient ein WOZ nicht nur der Evaluation, sondern bietet auch eine M¨ oglichkeit, Daten f¨ ur die Erstellung eines neuen Dialogdesigns zu liefern. Dies wurde z.B. bei [Schulz und Donker 2006] f¨ ur die Erstellung eines sprachbedienten MP3-Players genutzt. ¨ 4.4.2 Uberwachte Systembenutzung Wenn allerdings die Infrastruktur eines laufenden Dialogsystems bereits vorhanden ist, macht die Durchf¨ uhrung eines WOZ Versuchs keinen Sinn. Dieser ist in einer solchen Situation zu aufw¨ andig in der Konzeption und Durchf¨ uhrung, zudem ist die Qualit¨ at eines Dialogmanagers oder einer Spracherkennung mit einem WOZ nicht messbar. Wenn daher Dialogkomponenten von Benutzern getestet werden sollen, bleibt die Erstellung eines Prototypen, welcher dann von Benutzern evaluiert werden kann. In sp¨ ateren Entwicklungsschritten kann dieser Prototyp nach und nach verbessert und erneut evaluiert werden, so dass eine iterative Evaluation durchgef¨ uhrt wird. Gegen Ende der Entwicklungsphase wird daher der Prototyp u ¨blicherweise immer mehr zum finalen System. Bei ur einen sprachbedien[Schulz und Donker 2006] wurde ein solches Vorgehen f¨ ten MP3-Player im Automobil illustriert. Der Vorteil bei der u ur die Eva¨berwachten Systembenutzung ist, dass f¨ luation nur eine Betreuungsperson ausreicht, da der Wizard wegf¨allt. Zudem werden keine speziellen Komponenten f¨ ur eine Untersuchung verwendet, sondern der aktuelle Implementationsstand zur Evaluation herangezogen.

70

4 Benutzerfreundliche Sprachdialoge im Automobil

4.4.3 Simulierte Benutzertests Insbesondere bei der Verwendung von statistischen Dialogmodellen bietet sich auch die Durchf¨ uhrung von simulierten Benutzertests an. Voraussetzung daf¨ ur ist eine entsprechend große Menge an Daten, die nicht zum Training des Dialogmanagers verwendet wurde. Eine Beschreibung dieses Ansatzes kann z.B. bei [Georgila et al. 2006] gefunden werden. Wie bereits in Abschnitt 2.4.5 dargestellt wurde, kann eine statistische Dialogmodellierung nicht f¨ ur die Entwicklung von Sprachbediensystemen im Automobil herangezogen werden. Aus diesen Gr¨ unden liegen auch nicht gen¨ ugend Daten vor, eine datenbasierte Evaluation durchf¨ uhren zu k¨onnen. 4.4.4 Besonderheiten f¨ ur die Dom¨ ane der Sprachbedienung im Automobil Wie bereits ausf¨ uhrlich in Abschnitt 3.1 dargestellt wurde, sollen Sprachbediensysteme im Automobil grunds¨ atzlich auch immer w¨ahrend der Fahrt bedient werden k¨ onnen. Dies geht allerdings nur, wenn die Systeme vom Fahrer nicht zu viel Aufmerksamkeit fordern und entsprechend die kognitive Belastung gering halten. Um zu gew¨ ahrleisten, dass auch bei der Evaluation von neuen Dialogans¨ atzen der Benutzer nicht einer zu hohen kognitiven Belastung ausgesetzt wird und gleichzeitig auch das System bedienen kann, ohne st¨andig auf das System zu achten, m¨ ussen auch Evaluationen grunds¨atzlich anders angelegt werden, als f¨ ur serverbasierte Dialogsysteme. Es ist daher u ¨blich, den Benutzer auch w¨ ahrend einer Evaluation eines Sprachsystems einer der Fahraufgabe m¨ oglichst ¨ ahnlichen Belastung auszusetzen. Der nat¨ urliche Vorgang ist die Durchf¨ uhrung der kompletten Evaluation im fahrenden Automobil, wie z.B. bei [G¨artner et al. 2001], [Minker et al. 2004] und [Hassel und Hagen 2005] beschrieben. Diese Methode liefert sehr realistische Ergebnisse, allerdings darf die Sicherheit im Straßenverkehr unter den Versuchsbedingungen nicht leiden. In den oben zitierten Versuchen wurde daher sogar ein Automobil mit zwei Pedals¨atzen verwendet, um Unf¨ alle zu vermeiden.3 So realistisch die Evaluation in einem fahrenden Automobil auch ist, so groß ist allerdings auch der Aufwand zur Durchf¨ uhrung. Zuerst muss ein entsprechend geeignetes Fahrzeug zur Verf¨ ugung stehen. Dann muss das Dialogsystem in dieses funktionsf¨ ahig installiert werden und schließlich muss die Anbindung des Systems auch realistisch sein. Letzteres bedeutet, dass der Dialogstart durch den nachtr¨ aglichen Einbau eines entsprechenden PTT-Knopfes nicht zu aufw¨ andig oder unrealistisch sein sollte.

3

F¨ ur kleinere und seriennahe Evaluationen wird manchmal auch auf diese zus¨ atzliche Sicherheitsmaßnahme verzichtet.

4.5 Ans¨ atze f¨ ur benutzerfreundliche Sprachdialoge

71

Etwas einfacher ist daher die Durchf¨ uhrung entsprechender Versuche in einem Fahrsimulator. Die Sicherheitsprobleme des echten Straßenverkehrs werden ausgeblendet und zudem ist in der Regel die Messung von Fahrfehlern sehr viel einfacher. Auch die Integration eines Dialogsystems ist hier einfacher, da ein Simulator kein komplett realistisches Armaturenbrett verlangt. Zudem kann ein Dialog sogar einfach auf einem handels¨ ublichen PC laufen, station¨ are Stromversorgung ist hier kein Problem. Der gr¨oßte Nachteil einiger Fahrsimulatoren ist, dass Personen hier St¨ orungen des Gleichgewichtssinns erleiden k¨ onnen (¨ ahnlich der Seekrankheit) und als Probanden ausscheiden. Allerdings sind Fahrsimulatoren sehr teuer und aufw¨andig zu betreiben, daher gibt es Bestrebungen, eine billigere und einfachere Art der Simulation zu finden. Ein einfaches und probates Mittel ist die Erstellung eines Fahrsimulators am PC mittels eines f¨ ur Computerspiele entwickelten Lenkrads mit Pedalen. Handels¨ ubliche Computerspiele k¨onnen realistisch genug sein, hier als Ablenkungsaufgabe zu dienen. Bei [Cheng et al. 2004] wurde dieser Ansatz gew¨ ahlt. Allerdings eigenen sich Computerspiele weder zur genauen Analyse der durchgef¨ uhrten Fahrt noch ist ihre kognitive Belastung wirklich realistisch mit einer echten Fahraufgabe im Automobil zu vergleichen. Aus diesem Grund wurde bei Daimler mit der Software LCT (Lane Change Task) ein Werkzeug zur Bewertung der Fahrerablenkung entwickelt, welches nachgewiesener Maßen eine der echten Fahraufgabe ¨aquivalente kognitive Belastung darstellt [Mattes 2003, Harbluk et al. 2007]. Diese Software hat sich inzwischen zum Quasi-Industriestandard bei der Messung der Fahrablenkung etabliert und bietet die M¨ oglichkeit, realistische Tests s¨amtlicher Arten von Fahrerinformationssystemen im Automobil auch in einer einfachen B¨ uroumgebung durchf¨ uhren zu k¨ onnen.

4.5 Ans¨ atze fu ¨ r benutzerfreundliche Sprachdialoge Es gibt grunds¨ atzlich verschiedene Ans¨ atze einen Sprachdialog besonders benutzerfreundlich zu gestalten. Problematisch bei den meisten Ans¨atzen ist, neben der technischen Umsetzbarkeit in ein, mit den bereits in Kapitel 3 formulierten Einschr¨ ankungen versehenes eingebettetes Automobilsystem, auch die Akzeptanz bei Auftraggebern und Benutzern. Die wichtigsten und aktuellsten Vorschl¨ age und Ideen zu benutzerfreundlichen Sprachdialogen werden nachfolgend aufgegriffen und ihre Umsetzbarkeit beurteilt. 4.5.1 Nat¨ urliche Sprache als Problem? Laut Definition 4.1 gilt ein Dialog als benutzerfreundlich, wenn ein Benutzer sein jeweiliges Dialogziel besonders effektiv, effizient und zufrieden erreicht. Mathematisch gesprochen gilt also: U =P ◦E◦S

72

4 Benutzerfreundliche Sprachdialoge im Automobil

wobei U f¨ ur die Benutzerfreundlichkeit steht, P f¨ ur die Effektivit¨at, E f¨ ur die Effizienz und S f¨ ur die Zufriedenheit. Fraglich ist nun, ob die Maximierung einer der Parameter eine Maximierung von U bedeuten w¨ urde. Konkret geht es um die Idee, die Effizienz eines Dialogs zu maximieren, indem der menschliche Benutzer eine eingeschr¨ anktere Sprache verwendet. Diese Idee ist bereits vor l¨ angerer Zeit von [Shneiderman 1980] verfolgt worden. Die damaligen Gr¨ unde ¨ f¨ ur diesen Ansatz waren u.a. Angste, die fortschrittlichen Kommunikationsformen (gemeint war hiermit vor allem die haptische Kommunikation u ¨ber Maus oder Joystick) mit einem Computer w¨ urden nicht weiterentwickelt, die Computersysteme zur Analyse w¨ urden viel zu komplex werden. Diese Gr¨ unde sind heutzutage sicherlich u ¨berholt. Allerdings auch aus heutiger Sicht stichhaltig ist die Aussage, dass die nat¨ urlichsprachliche Kommunikation zu langwierig f¨ ur erfahrene Benutzer ist, die von einem Computer die Ausf¨ uhrung eines Kommandos in schnellstm¨ oglicher Zeit erwarten. An genau diesem Punkt kann man mit einer vereinfachten Sprache ansetzen, um eine h¨ ohere Effizienz und ein standardisiertes Sprachinterface zu erreichen [Tomko 2006]. Zudem kann man mit einer vereinfachten Sprache (Tomko spricht von Speech Graffiti, bei [Schiel et al. 2006] heißt der Ansatz Lingua Machinae) die Problematik von Fehlerkennungen stark minimieren. [Tomko und Rosenfeld 2004a] haben nachweisen k¨onnen, dass Benutzer die Grammatik einer vereinfachten Sprache schnell erlernen k¨onnen. In einem Vergleich von nat¨ urlichsprachlicher Spracheingabe und vereinfachter Spracheingabe konnte nachgewiesen werden, dass f¨ ur ein telefonisches Auskunftssystem eine Mehrheit der Benutzer die vereinfachte Eingabe pr¨aferierte [Tomko und Rosenfeld 2004b]. Zudem konnte gezeigt werden, dass Benutzer sogar nur mit minimaler Information und u ¨ber gezielte Prompts dazu gebracht werden k¨ onnen, ein Dialogsystem zur Datenabfrage lediglich mit vereinfachter Sprache zu bedienen (Tomko spricht von shaping) [Tomko und Rosenfeld 2004c]. ur ein Sprachdialogsystem Der Ansatz einer vereinfachten Anfragesprache f¨ ist daher sicherlich als erfolgreich zu bezeichnen. Aber wie steht es mit der ¨ Ubertragbarkeit f¨ ur den Automobilbereich? Grunds¨atzlich verbietet es sich, im Automobil den Benutzer vor Anwendung der Sprachbedienung umst¨andlich u ¨ber die zu verwendende Sprache zu informieren. Es ist das Ziel, eine Benutzung des Bediensystems ohne vorherige Schulung zu gew¨ahrleisten. Zudem gibt es in jeder Sprachbedienung gewisse identische Kommandow¨orter (z.B. Hilfe“, Abbruch“) die immer zur Verf¨ ugung stehen und dem Benutzer ” ” eine gewisse Orientierung sind. Damit ist ein St¨ uck der von [Schiel et al. 2006] geforderten Standardisierung bereits umgesetzt. Da aber die Dom¨ane der Sprachbedienung eine sehr viel engere und kleinere ist, als die Dom¨ane bei der Abfrage von Datenbanken, ist auch die Problematik von falschem oder außerhalb der Dom¨ ane liegendem Vokabular (also Eingabefehlern) sehr viel kleiner. Weil aber auch aktuelle Systeme keine vollst¨ andige Abdeckung der nat¨ urlichsprachlichen Anfragem¨ oglichkeiten aufweisen, muss der Benutzer sich auch an ein etwas eingeschr¨ ankteres Vokabular gew¨ ohnen. Mittels Hilfeprompts und

4.5 Ans¨ atze f¨ ur benutzerfreundliche Sprachdialoge

73

gezielt formulierten Prompts (vgl. Abschnitt 2.10) wird daher im Prinzip auch eine Art shaping im Tomko’schen Sinne betrieben. Bedingt durch die kleinere Dom¨ ane wirkt die resultierende Anfragesprache aber im Stil noch eher nat¨ urlichsprachlich, als einige Beispiele von speech graffiti. Aus der Sicht des Entwicklers ist hier bei der Wahl des Vokabulars zwischen Effizienz und Benutzerfreundlichkeit abzuw¨ agen. Im Zweifelsfall kann eine Einzelfallentscheidung dann nur durch eine Evaluation mit echten Benutzern gekl¨art werden. Dies bedeutet aber auch, dass eine Maximierung nur einer der Werte Effizienz, Effektivit¨ at oder Benutzerzufriedenheit nicht m¨oglich ist. Zusammenfassend kann gesagt werden, dass nat¨ urlichsprachliche Anfragen an Dialogsysteme im Automobil auch ein Problem darstellen k¨onnen, allerdings mit den vorhandenen Bordmitteln der Hilfedialoge durchaus ein l¨ osbares. 4.5.2 Adaptive Systeme Wie bereits in Abschnitt 4.2 beschrieben wurde, fordert DIN EN ISO 9241110 f¨ ur eine Mensch-Maschine Schnittstelle auch eine Individualisierbarkeit. Konkret heißt es dazu in der Norm: Ein Dialog ist individualisierbar, wenn ” das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe sowie an die individuellen F¨ ahigkeiten und Vorlieben des Benutzers zul¨asst“. Von vielen bildschirmbasierten Dialogen bekannt ist die Frage, ob eine Dialogbox beim n¨ achsten Mal wieder erscheinen soll oder die Einstellungen gespeichert werden sollen, wie zum Beispiel auf Abbildung 4.1 dargestellt. In diesen F¨allen adaptiert sich ein Softwaresystem an seinen Benutzer.

Abbildung 4.1. Dialogbox mit Individualisierungsm¨ oglichkeit

Auch im Automobil sind adaptive Systeme bekannt. Das bekannteste adaptive System ist das Autoradio mit geschwindigkeitsabh¨angiger Lautst¨arkeanpassung. Bei einem solchen System wird bei steigender Geschwindigkeit die Wiedergabelautst¨ arke angehoben, um vor dem Hintergrund von lauteren Fahr- und Motorenger¨ auschen subjektiv die Musik in gleicher Lautst¨arke h¨ oren zu k¨ onnen. Daneben sind auch bei FIS Adaptionen denkbar. So wird bei [Bachfischer et al. 2007] ein Prototyp eines adaptiven Navigationssystems

74

4 Benutzerfreundliche Sprachdialoge im Automobil

vorgestellt, welches z.B. bei vollem Tank keine Tankstellen als Sonderziel oder POI (engl. Point of Interest) anzeigt, bei leerem Tank allerdings ausschließlich M¨ oglichkeiten zum Tanken anzeigt. [Akyol et al. 2001] stellen ein multimodales FIS mit unterschiedlichen Adaptionsm¨ oglichkeiten vor. Bei [Hassel 2006] wird ein komplettes sprachbedientes FIS pr¨asentiert, welches sich an den Erfahrungsgrad eines Benutzers adaptiert. Wenn ein Benutzer in einer Applikation Experte ist, bekommt er im Sinne der gesteigerten Effizienz k¨ urzere Systemprompts zu h¨ oren als wenn er Anf¨anger ist. F¨ ur letzteren gibt es l¨ angere Prompts, um die verschiedenen M¨oglichkeiten aufzuzeigen. Hassel konnte zeigen, dass die Verwendung eines solchen adaptiven Systems schneller und effizienter gelang, als die Verwendung eines Referenzsystems. Allerdings konnte bei der Analyse nach dem PARADISE-Ansatz [Walker et al. 1997] (mehr dazu in Abschnitt 8.8) keine lineare Korrelation zwischen der Nutzerzufriedenheit und dem Erfolgsmaß gefunden werden. Basierend auf der Arbeit von Hassel hat [Hof 2007] diese um ein adaptives Hilfesystem erweitert. Dabei wurde auch eine Studie zum Vergessen von Sprachkommandos durchgef¨ uhrt [Hof et al. 2006]. Diese Studie erlaubte die adaptive Konfiguration des Hilfesystems; so wurden seltener verwendete Kommandos an den Anfang der Hilfetexte gesetzt, h¨aufiger verwendete an das Ende. Wie Hof berichtet, wurde dieses System von den Benutzern subjektiv besser bewertet als ein nicht adaptives System. Adaptive (also individualisierbare Systeme im Sinne von DIN EN ISO 9241-110) k¨ onnen damit insgesamt die Benutzerzufriedenheit st¨arken und sogar in vielen Situationen den Dialogfluss verk¨ urzen. Allerdings ben¨otigen adaptive Systeme Kenntniss des aktuellen Benutzers, um sein Profil korrekt zuordnen und den Sprachdialog entsprechend adaptieren zu k¨onnen. Genau diese Stelle ist aktuell der Schwachpunkt von adaptiven Systemen im Fahrzeug. Zuverl¨ assig ist eine Zuordnung bisher leider nicht m¨oglich. Zwar k¨onnen individualisierte Schl¨ ussel vergeben werden, aber ein Austausch innerhalb der Familie l¨ asst sich nicht vermeiden. Eine sprachliche Identifikation ist nur durch Zusatzaufwand des Fahrers m¨ oglich, was bisher von den Automobilherstellern abgelehnt wird. Bliebe die Identifikation u ¨ber Video oder das in der FSE eingesteckte Handy. Eine Stimmanalyse bei Verwendung des SBS w¨are zwar m¨ oglich, allerdings k¨ onnte hier die Adaption erst nach der ersten Verwendung greifen und zudem gibt es die Problematik von Stimmenver¨anderung durch z.B. Heiserkeit. Die Identifikation per Mobiltelefon w¨are zwar machbar, allerdings m¨ ussten mehrere Telefone pro Benutzer unterst¨ utzt werden und zudem ein Modellwechsel dem System vermittelt werden. Aus den genannten Gr¨ unden stellen adaptive Systeme daher durchaus einen Beitrag zu noch benutzerfreundlichen Systemen dar, allerdings sind diese Mechanismen f¨ ur Sprachsysteme immer noch ein Forschungsgegenstand.

4.5 Ans¨ atze f¨ ur benutzerfreundliche Sprachdialoge

75

4.5.3 Dialogstrategie Bereits in Abschnitt 2.6 wurde der Begriff der Dialogstrategie eingef¨ uhrt und verschiedene Strategien vorgestellt. Dort wurde auch beschrieben, dass f¨ ur ein Sprachbediensystem im Automobil vor allem direktive und nur in Einzelf¨allen eine kooperative Strategie verwendet wird. Diese Beschr¨ankung auf eine wenig aktive Dialogstrategie tr¨ agt zwar nicht zu einem linguistisch ausgefeilten Dialog bei, allerdings erlaubt diese Strategie einen effizienten und effektiven Dialogablauf, da das stark eingeschr¨ ankte Vokabular kaum Erkennfehler gestattet. Die Einschr¨ ankung des Vokabulars durch geschlossene Prompts (vgl. Abschnitt 2.10) dient sogar unmittelbar auch einer h¨oheren Verkehrssicherheit. So wurde z.B. bei [Kun et al. 2007] nachgewiesen, dass eine schlechte Erkennrate das Fahrverhalten negativ beeinflusst. Auch [Hof 2007] belegt, dass eine schlechte Erkennleistung des Spracherkenners zu einer stark erh¨ohten mentalen Belastung f¨ uhrt, was zu nachlassender Konzentration bei der Fahrt¨atigkeit f¨ uhren kann. Nun kann es aber sein, dass ein linguistisch eingeschr¨ankter Dialog zwar effizient und effektiv ist, aber vielleicht den Benutzer nicht zufriedenstellt. Aus diesem Grund haben [Ackermann und Libossek 2006] in einem WOZ untersucht, ob in einem Navigationsdialog ein freierer Dialog hilfreich und f¨ ur den Benutzer zufriedenstellend ist. Dabei kam heraus, dass es Benutzer im Automobil in der Tat sehr sch¨ atzen, explizit um eine konkrete Eingabe gebeten zu werden. Von daher kann der in Abschnitt 3.6.3 dargestellte Dialogablauf als sehr benutzerfreundlich gelten. Diese Punkte belegen die auch aus internen Versuchen bei Harman/Becker bekannte Tatsache, dass eine Sprachbedienung sehr konkrete und enge Sprachprompts ben¨ otigt, um den Fahrer m¨ oglichst wenig kognitiv zu belasten und die Fahrt¨ atigkeit nicht zu beeintr¨ achtigen. Damit sind also direktive und reaktive Dialogstrategien das Mittel der Wahl im Automobil, um eine sichere Fahrt und einen benutzerfreundlichen Dialog zu gew¨ahrleisten. Trotz dieser Erkenntnisse gibt es immer wieder Ans¨atze, komplett nat¨ urlichsprachliche und freie Dialoge auch im Automobil zu installieren. Ein solches System wurde z.B. bei [Weng et al. 2004] vorgestellt. Grunds¨atzlich gibt es entsprechende Ideen immer wieder. Dieser Ansatz ist ein wenig kontr¨ar zum oben formulierten Ansatz eingeschr¨ ankter Vokabularien. Solche gegens¨atzlichen Ans¨ atze gibt es vor allem im Prototypenstadium, wo es in der Regel nur auf die technische Machbarkeit ankommt, Fahrszenarien wurden beim zitierten System beispielsweise mit einem Computerspiel getestet (vgl. auch Abschnitt 4.4). Daneben spielen auch kulturelle Unterschiede eine große Rolle. Insbesondere in Japan sind zum Beispiel Systeme mit sehr ausf¨ uhrlichen Systemprompts sehr beliebt. Von daher kann die Aussage zu benutzerfreundlichen und effizienten Dialogen mit geschlossenen Systemprompts nur f¨ ur Europa wirklich fundiert belegt werden.

76

4 Benutzerfreundliche Sprachdialoge im Automobil

4.5.4 Pr¨ asentation von Ergebnislisten Sprache als fl¨ uchtiges Medium ist grunds¨ atzlich wenig dazu geeignet, Ergebnislisten von Anfragen aufzubereiten. Bereits [Miller 1956] hat in Studien herausgefunden, dass Menschen sich von einer Liste von Dingen im Schnitt sieben (plus/minus zwei) Dinge im Kurzzeitged¨ achtnis merken k¨onnen. Dies belegt die Fl¨ uchtigkeit der Sprache und das Problem, bei l¨angeren Listen einzelne Teile zu behalten. Das bedeutet, dass es beispielsweise bei einer sprachgesteuerten Restaurantsuche, wie mit dem bei [Weng et al. 2006] vorgestellten System m¨oglich, bei gr¨ oßeren St¨ adten schnell zu mehreren hundert Ergebnissen kommen kann. Diese kann man per Sprache und insbesondere im Automobil nicht erfassen, daher macht das Vorlesen hier keinen Sinn. F¨ ur diesen Fall hat eine Studie von [Pon-Barry et al. 2006] ergeben, bevorzugen Benutzer die konkrete Nennung von Einschr¨ ankungsm¨ oglichkeiten, um die Anzahl der Ergebnisse weiter zu reduzieren. Das bedeutet, f¨ ur die Benutzerfreundlichkeit sollten lange Listen von Eintr¨ agen oder Kommandos m¨ oglichst vermieden werden und stattdessen f¨ ur den Benutzer nachvollziehbar in entsprechende Unterkategorien sortiert und zugreifbar gemacht werden. 4.5.5 Sprachausgabe Wenn nicht ausschließlich eine direktive Dialogstrategie angewandt wird, gibt es sprachliche R¨ uckmeldungen des Systems. In einer Studie mit ¨alteren Fahrern (ab 55 Jahren) von [Jonsson et al. 2005] wurde dabei herausgefunden, dass die Stimme der Sprachausgabe einen Effekt auf die Geschwindigkeit und Unfallh¨ aufigkeit hat. So konnte nachgewiesen werden, dass eine h¨orbar junge Stimme die Fahrsicherheit und das subjektive Fahrgef¨ uhl deutlich verbessert. Dieser Test zeigt die Bedeutung der Qualit¨ at der Sprachausgabe sehr deutlich. Mit wachsendem Funktionsumfang der Sprachbediensysteme ist allerdings die reine Verwendung einer Studiostimme4 kaum noch m¨oglich. Schließlich sind in so vielen F¨ allen dynamische Antworten wichtig, wie zum Beispiel zur Best¨ atigung eines Ortsnamens, beim Vorlesen von Verkehrsmeldungen oder zur Aussprache eines Namens aus dem Adressbuch. Aus diesem Grund wird in zeitgem¨ aßen SBS nicht nur eine qualitativ hochwertige Stimme verwendet, sondern auch eine m¨ oglichst gute Sprachsynthese. Insbesondere bei der subjektiven Bewertung der Zufriedenheit mit einem Sprachsystem ist daher die Qualit¨ at der Sprachausgabe wichtig.

4

Die Sprachprompts werden offline in einem Studio aufgenommen und dann auf das Zielsystem portiert.

4.6 Zusammenfassung

77

4.6 Zusammenfassung In diesem Kapitel wurden benutzerfreundliche Sprachdialoge im Automobil behandelt. Dabei wurde zuerst der Begriff der Benutzerfreundlichkeit definiert und anschließend mit dem Vorbild des Lichtschalters ein sehr gutes Beispiel f¨ ur eine benutzerfreundliche Kommunikation zwischen Mensch und Technik vorgestellt. Noch ist die Technologie der Sprachbediensysteme allerdings nicht so weit entwickelt, dieses Idealziel zu erreichen. Um diesem Ziel aber m¨oglichst nah zu kommen, wurden die h¨ aufigsten Fehler bei der Benutzung von Sprachsystemen analysiert und deren Vermeidbarkeit diskutiert. Ferner wurden die wichtigsten Grunds¨ atze f¨ ur die Gestaltung einer Mensch-Maschine-Schnittstelle laut DIN EN ISO 9241-110 aufgef¨ uhrt. Basierend hierauf wurde dargestellt, wie Sprachdialoge evaluiert werden k¨ onnen und welche Maße dabei von Wichtigkeit sind. Es wurden die Begriffe Performanz- und Benutzerevaluation vorgestellt und deren jeweilige Ans¨atze diskutiert. Des Weiteren wurde auch die schwierige Vergleichbarkeit von Evaluationsergebnissen behandelt. Weiter wurde beschrieben, wie die Benutzerfreundlichkeit eines Dialogverfahrens evaluiert werden kann. Es wurde auch die Besonderheit der Integration in ein Automobil hervorgehoben. Anschließend wurden einige Ans¨ atze f¨ ur benutzerfreundliche Sprachdialoge vorgestellt. Dabei wurde auf die Problematik von freien nat¨ urlichsprachlichen Eingaben hingewiesen und die Chancen von adaptiven Systemen dargestellt. Außerdem wurden die optimale Dialogstrategie besprochen, die Fl¨ uchtigkeit von Sprache behandelt und die Wichtigkeit einer qualitativ guten Sprachausgabe illustriert. All diese Punkte werden sp¨ ater in diesem Werk wieder aufgegriffen, da sie eine Grundlage f¨ ur das Werkzeugsystem DiaGen bilden. Die in diesem Kapitel erw¨ ahnten Konzepte und Begriffe formen die oberste Ebene des bereits zu Beginn in Abschnitt 1.3 eingef¨ uhrten Schichtenmodells. Diese Ebene ist ebenso wichtig, wie die vorhergehende, um benutzerfreundliche Sprachdialoge zu entwickeln. Dabei spielt es keine Rolle, ob diese Entwicklung manuell oder teilautomatisiert geschieht. Bevor es allerdings im Detail mehr um das Entwicklungswerkzeug geht, wird im n¨ achsten Kapitel die technische Seite der Dialogbeschreibung n¨aher beschrieben. Dabei geht es darum, wie u ¨berhaupt ein Sprachdialog maschinenlesbar umgesetzt werden kann. Nach dem zitierten Schichtenmodell wird daher als n¨ achstes die unterste Ebene der softwaretechnischen Umsetzung illustriert.

5 Beschreibung von Sprachdialogen

Wie bereits in Abschnitt 2.4 erw¨ ahnt, wird der Ablauf eines Sprachdialogs in einem Dialogmodell festgehalten. Um aber Sprachdialoge mit einem Dialogsystem ablaufen zu lassen, muss dieses Dialogmodell in maschinenlesbarer ¨ Form vorliegen. Ublicherweise wird daher das Dialogmodell mittels einer Programmiersprache erstellt und dann von einem Interpreter oder Compiler interpretiert bzw. ausgef¨ uhrt. Urspr¨ unglich wurden f¨ ur Sprachdialoge normale, bereits vorhandene Sprachen verwendet, bevor auch hier eine Spezialisierung einsetzte und spezielle Dialogbeschreibungssprachen entwickelt wurden.1 In diesem Kapitel werden daher zuerst die wichtigsten allgemeinen Programmiersprachen, welche zur Programmierung von Sprachdialogen verwendet wurden, vorgestellt. Anschließend werden die sp¨ater entwickelten speziellen Dialogbeschreibungssprachen vorgestellt. Danach folgt eine Darstellung der wichtigsten Grammatikbeschreibungsformate, die zur Beschreibung von Grammatiken f¨ ur die Spracherkennung bei Sprachdialogsystemen verwendet werden.

5.1 Programmierung von Dialogen Die wesentliche allgemeine Programmiersprache, die zur Implementation von Sprachdialogen eingesetzt wurde, war PROLOG [Gazdar und Mellish 1989]. Das System Speedis, das basierend auf den Erkenntnissen aus dem EU gef¨ orderten Projekt SUNDIAL [Peckham 1993] aufgebaut wurde, arbeitet mit einem PROLOG-Dialekt f¨ ur die semantische Beschreibung des Dialogwissens [Heisterkamp und McGlashan 1996]. Da PROLOG als logische Programmiersprache aber sehr schwer zu erlernen 1

Grunds¨ atzlich wird - wie auch bereits einschr¨ ankend in Abschnitt 2.4.5 dargestellt - in diesem Werk von einer zustands- oder regelbasierten Modellierung von Sprachdialogen ausgegangen. F¨ ur planbasierte oder statistische Dialogmodelle m¨ ussen die hier get¨ atigten Angaben daher nicht gelten.

80

5 Beschreibung von Sprachdialogen

ist, erfordert seine Benutzung eine hohe Fachkenntniss. Daher wird die Sprache heute nur noch sehr selten f¨ ur die Beschreibung von Sprachdialogen verwendet. Zus¨ atzlich existieren verschiedene Ans¨ atze, Dialogabl¨aufe f¨ ur Experimente oder Prototypen auszuprogrammieren, so wurde beispielsweise bei der IBM f¨ ur diesen Zweck die Sprache Tcl mit einigen Erweiterungen verwendet [Papineni et al. 1999, Hamerich 2000]. Und auch f¨ ur die quelloffene Dialogumgebung von [Denecke 2002] werden mit C++ und JavaScript u ¨bliche Programmiersprachen verwendet. Als sehr verbreitete Programmiersprache wurde auch C sehr h¨aufig zur Programmierung von Sprachdialogen eingesetzt. F¨ ur eingebettete Umgebungen gilt dies bis heute, da C sehr geringe Anforderungen an seine Laufzeitumgebungen stellt. Grunds¨ atzlich kann jede beliebige Programmiersprache zur Erstellung eines Sprachdialogs verwendet werden, Voraussetzung ist lediglich eine Anbindung der ben¨ otigten Ein- und Ausgabekan¨ ale.

5.2 Dialogbeschreibungssprachen Ein Problem aller allgemeinen Programmiersprachen ist, dass diese f¨ ur die Beschreibung von Sprachdialogen besonderer Anpassungen bed¨ urfen. Die Ansteuerung der Schnittstellen von Spracherkennung und Sprachausgabe m¨ ussen daher von einem Anwender komplett selbst entwickelt werden, was als wenig komfortabel gilt [McTear 2004]. Da alle Elemente in diesem Fall auch hart“ ” kodiert werden m¨ ussen und nicht durch einen allgemeinen Ansatz beschrieben werden, sind Dialoge aus allgemeinen Programmiersprachen in der Regel auch nicht gut wartbar oder gar wiederverwendbar. Zu guter Letzt erfordert die Benutzung von allgemeinen Programmiersprachen eine gewisse Vorbildung, die sich nur in kleinsten Teilen f¨ ur die Entwicklung von Sprachdialogen nutzen l¨ asst. So ist es f¨ ur die Entwicklung von guten Sprachdialogen viel wichtiger, die Grundprinzipien des Dialogdesigns und die Ergonomie von Sprachdialogen zu verstehen (wie bereits in Abschnitt 2.10 dargestellt), als richtig mit Zeigern und Strukturen umgehen zu k¨ onnen. Aus diesen Gr¨ unden gab es bei vielen Firmen und Institutionen der Sprachverarbeitungsbranche Bestrebungen, f¨ ur die Beschreibung von Sprachdialogen einen allgemeinen Ansatz mittels einer eigenen Beschreibungssprache zu entwickeln. Diese neuen Dialogbeschreibungssprachen (engl. dialogue description languages (DDL)) bieten u.a. den Vorteil, dass Schnittstellen f¨ ur Ein- und Ausgabe bereits fest vorgesehen sind, die Programmierung kann damit auf einer h¨ oheren Ebene geschehen und der Entwickler bleibt von der low le” vel“ Programmierung verschont. Damit bieten DDLs einen Geschwindigkeitsvorteil bei der Implementation und ein Unterscheidungsmerkmal gegen¨ uber Konkurrenten. Außerdem erlauben sie auch einen flexibleren Personaleinsatz, da der Schulungsaufwand f¨ ur diese Sprachen durch den allgemeinen Ansatz

5.2 Dialogbeschreibungssprachen

81

gegen¨ uber den u ¨blichen Programmiersprachen sehr viel geringer ist. Insbesondere Markup-Sprachen (XML-Dialekte) haben sich dabei als sehr vorteilhaft herausgestellt, da sie besonders einfach und schnell zu erlernen sind. Im Folgenden wird zuerst GDML vorgestellt, eine Eigenentwicklung von Harman/Becker, die prim¨ ar f¨ ur den Einsatz der Dialogbeschreibung von automobilen Sprachsystemen entwickelt wurde. Diese Sprache wurde auch f¨ ur den im Rahmen des vorliegenden Werkes entwickelten Prototypen verwendet. Nachfolgend werden noch kurz weitere bedeutende Sprachen gew¨ urdigt, um die allgemeine Bedeutung von Dialogbeschreibungssprachen besser nachvollziehen zu k¨ onnen. 5.2.1 GDML GDML (Generic Dialog Modelling Language) ist die Dialogbeschreibungssprache von Harman/Becker Automotive Systems. Sie wurde bei der Temic Sprachverarbeitung entwickelt, welche 2002 von Harman/Becker u ¨bernommen wurde. Erste Konzepte von GDML wurden bei [Hennecke und Hanrieder 2000] vorgestellt. Der produktive Einsatz der Sprache wurde erstmals bei [Hamerich und Hanrieder 2004] beschrieben. Entwicklung Als Ende der Neunziger Jahre in der gesamten Sprachverarbeitungsbranche Bestrebungen f¨ ur Dialogbeschreibungssprachen einsetzten, wurden auch ¨ bei Daimler-Benz2 Uberlegungen in diese Richtung angestellt. In den beiden EU-gef¨ orderten Forschungsprojekten ACCeSS [Ehrlich et al. 1997] und IDAS [Lehtinen et al. 2000] wurden dabei erste Erfahrungen gesammelt. Basierend auf diesen verschiedenen Ans¨ atzen und Ideen definierten Andreas L¨ ow und Gerhard Hanrieder GDML. Der selbstentwickelte Dialogmanager GDM (Generic Dialog Manager) war urspr¨ unglich f¨ ur telefonische und automobile Dialogsysteme gedacht und beherrscht neben systemgetriebenen Dialogen auch bereits gemischt-initiative [Hanrieder 1998]. Wie bereits in Kapitel 3 angef¨ uhrt wurde, unterscheiden sich Sprachdialogsysteme im Automobil erheblich von telefonischen Systemen. Daher wird f¨ ur diese Systeme auch eine andere Dialogbeschreibung ben¨otigt. Als GDML definiert wurde, lag zwar bereits VoiceXML (vgl. Abschnitt 5.2.2) Version 0.9 vor, allerdings erwies es sich als ungeeignet, dessen Konzepte zu u ¨bernehmen. Daher wurde mit GDML eine komplett neue Dialogbeschreibungssprache erschaffen. Aber ebenso wie VoiceXML ist auch GDML ein XML-Dialekt. Wie bereits bekannt, besteht die prim¨ are Aufgabe von Dialogsystemen innerhalb eines Automobils aus der Steuerung von angeschlossenen Ger¨aten, welche 2

Die Wurzeln der Sprachverarbeitung in Ulm lagen bei der AEG-Telefunken, die von Daimler-Benz u aten wurden unter dem ¨bernommen wurde. Die Sprachaktivit¨ Dach von Daimler-Benz bei der Temic weitergef¨ uhrt und 2002 an Harman/Becker verkauft [Hamerich 2005].

82

5 Beschreibung von Sprachdialogen

keine dynamische Verbindung mit dem Internet ben¨otigen. Stattdessen ist es elementar, eine flexible und einfach zu nutzende Schnittstelle zwischen Dialog und angeschlossenen externen Ger¨ aten zu besitzen. Da Sprachdialogsysteme im Automobil immer als eingebettete Systeme ausgef¨ uhrt werden, war es f¨ ur GDML sehr wichtig, die verschiedenen Bus-Systeme der Automobilindustrie anzubinden und eine einfache Portierbarkeit auf die verschiedenen genutzten Echtzeit-Betriebssysteme3 zu gew¨ ahrleisten. Außerdem war es wichtig, dass GDML den bereits in Abschnitt 3.5 angesprochenen Hardwarebeschr¨ankungen gen¨ ugt. So wurde mit GDML schließlich eine Dialogbeschreibungssprache entwickelt, welche allen diesen Anspr¨ uchen gen¨ ugt und trotzdem flexible Dialogabl¨ aufe erm¨ oglicht. GDML war bereits 2001 so ausgereift, dass die Produktentwicklung bei der Temic begann. Konzepte Auf Grund der beschr¨ ankten Ressourcen in einem Automobil wurde GDML als kompilierte Sprache ausgef¨ uhrt. Aus dem gleichen Grund ist GDML im Gegensatz zu VoiceXML als getypte Sprache ausgef¨ uhrt. Um außerdem eine m¨ oglichst einfache Portierung eines Dialogs in andere nat¨ urliche Sprachen zu erlauben, werden Prompts im GDML-Dialog nur als Konzepte referenziert und die sprachliche Realisierung in einer separaten Datei verwaltet. Grammatiken m¨ ussen in GDML im JSGF-Format (vgl. Abschnitt 5.3.2) in einer eigenen Datei vorliegen. Der GDC (Generic Dialog Compiler) liest die GDML- und Prompt-Konzepte ein und erstellt daraus eine sprachunabh¨angige Bin¨ar-Datei f¨ ur den Dialog, sowie eine sprachabh¨ angige Datei f¨ ur die Sprachausgaben, welche beide sowohl auf dem PC als auch auf der Zielplattform ausgef¨ uhrt werden k¨ onnen. Grammatiken werden mit dem GDS (Grammar Development System) kompiliert. Der Spracherkenner ist bei Harman/Becker in das SSS (Speech Service System) zusammen mit dem Dialogmanager GDM und dem Prompter, der sowohl Audio-Dateien abspielen als auch vorgegebene Texte per TTS synthetisieren kann, integriert. W¨ ahrend der Entwicklung k¨onnen Dialoge mit dem DDS (Dialog Development Studio) getestet und debuggt werden. Die einzelnen Werkzeuge zur Entwicklung von GDML-Dialogen sind in schematischer Reihenfolge in Abbildung 5.1 wiedergegeben. Neben den beschriebenen Werkzeugen ist ein wichtiger Bestandteil dieses Pakets auch der Harman/Becker eigene Spracherkenner StarRec DSR. Dieser ist voll in die beschriebenen Werkzeuge integriert. Um eine bestm¨ogliche Erkennungsleistung bei beschr¨ ankten Ressourcen zu erlauben, wurden die akustischen Modelle im Erkenner mittels diskriminativen Trainings m¨oglichst kompakt trainiert [Willett 2004]. Zus¨ atzlich zu den selbstverst¨andlich sehr guten Erkennraten werden einem Dialogentwickler mit Konfidenz- und OOVMaßen (dazu mehr in Abschnitt 4.2) zahlreiche M¨oglichkeiten geboten, Be3

In der Automobilindustrie werden v.a. QNX und VxWorks eingesetzt.

5.2 Dialogbeschreibungssprachen

83

Abbildung 5.1. Werkzeuge zur Erstellung eines GDML-Dialogs

nutzeranfragen bestm¨ oglich zu verarbeiten. Die f¨ ur einige Anwendungen auch ben¨ otigten M¨ oglichkeiten der multilingualen Erkennung4 runden das Bild ab. Ein GDML-Dialog besteht aus mindestens zwei Dateien, der eigentlichen Dialogdatei und den Prompt-Konzepten. Es k¨ onnen jedoch beliebig mehr Dialogdateien sein. Da Produktdialoge sehr umfangreich sind, wird u ¨blicherweise f¨ ur jedes zu steuernde Ger¨ at eine eigene Datei angelegt. Funktionen werden ebenfalls gekapselt, so dass eine komplette Dialogbeschreibung u ¨blicherweise u ¨ber 50 GDML-Dateien umfasst. Wie bereits angesprochen, war es eine Anforderung an GDML, eine M¨ oglichkeit zur Steuerung von externen Ger¨ aten, wie z.B. Telefon oder Radio, zu bieten. Diese Schnittstelle wurde in GDML als eigenes Konzept ausgef¨ uhrt und Systemcall genannt. Diese Systemcalls passen sich komplett an die Syntax von GDML an, k¨ onnen Argumente aufnehmen und R¨ uckgabewerte liefern. Externe Ger¨ ate, welche mit dem Dialog u ¨ber Systemcalls verbunden werden sollen, ben¨ otigen ein Systemcall-Interface, welches den Call parst, bearbeitet und beantwortet. Die Ansteuerung des Spracherkenners erfolgt u ¨ber ein Interface, welches dem der Systemcalls sehr ¨ ahnlich ist. Damit wird dem Dialogdesigner eine sehr große Freiheit gegeben, weil beim Aufruf des Erkenners nicht nur die jeweilige Grammatik mit ihren Regeln aktiviert werden kann, sondern auch sehr genaue Einstellungen der verschiedenen timeout- und Konfidenzwerte vorgenommen werden k¨ onnen. Bedingt durch die Vielf¨ altigkeit der m¨ oglichen Konzepte ist GDML damit als sehr explizite Sprache ausgef¨ uhrt. Dies gilt vor allem, wenn Dialoge 4

Dabei kommt es vor allem darauf an, Eingaben von Nicht-Muttersprachlern gut erkennen zu k¨ onnen. Details dazu k¨ onnen bei [van Compernolle 2000, Gruhn et al. 2004] gefunden werden.

84

5 Beschreibung von Sprachdialogen

zustandsbasiert modelliert werden. Weiterhin erm¨oglicht GDML auch eine regelbasierte Dialogmodellierung, dies wird allerdings bisher nicht in Kundenprojekten eingesetzt, da es von den Kunden explizit nicht erw¨ unscht ist. Ein Dialog in GDML besteht in der Regel aus mehreren Teildialogen, die in GDML mit bezeichnet werden. Jeder dieser Dialoge enth¨alt dabei mindestens einen Dialogschritt, in GDML als <step> bezeichnet. Die Abarbeitung eines GDML-Dialogs beginnt grunds¨ atzlich im Dialog namens main“. ” Eine Besonderheit von GDML ist, dass s¨ amtliche Variablen und Konzepte vor ihrer Verwendung deklariert werden m¨ ussen. Variablen m¨ ussen außerdem einem der in GDML m¨ oglichen Typen zugewiesen werden. Beispiel Wie bereits dargestellt, wurde in GDML darauf geachtet, einen Dialog einfach in eine andere nat¨ urliche Sprache portieren zu k¨onnen. Dies wird durch die Verwendung der Promptkonzepte erm¨ oglicht. Um die Konzepte mit Inhalt zu f¨ ullen, gibt es eine separate Datei, welche die konkreten Prompttexte oder Verweise auf Audiodateien enth¨ alt. Abbildung 5.2 stellt eine solche Datei mit deutschen Prompttexten f¨ ur den abgebildeten Demodialog dar. In diesen Promptkonzepten k¨ onnen entweder Texte f¨ ur die TTS-Ausgabe oder Dateinamen angegeben werden, im vorliegenden Beispiel werden die Texte direkt an eine TTS zur Sprachsynthese u ¨bergeben. <prompt_body concept="start"> Willkommen zur Demo. Wollen Sie starten? <prompt_body concept="confirm_yes"> Das Programm wird gestartet. <prompt_body concept="confirm_no"> Schade, dann h¨ oren wir halt auf. <prompt_body concept="goodbye"> Bis dann. Abbildung 5.2. Definition der Promptkonzepte in GDML f¨ ur Demo-Dialog

5.2 Dialogbeschreibungssprachen

85

<def_prompt <def_prompt <def_prompt <def_prompt

concept="start"/> concept="confirm_yes"/> concept="confirm_no"/> concept="goodbye"/>

<def_enum name="recog_errors" elements="RECOG_OK, RECOG_ERROR"/>

<step name="test"> <prompt concept="start"/> <prompt concept="confirm_yes"/> <else> <prompt concept="confirm_no"/> <step name="start_again"> <prompt concept="goodbye"/> Abbildung 5.3. Demo-Dialog in GDML

In Abbildung 5.3 ist ein GDML-Beispieldialog zu sehen. Klar zu erkennen sind die beiden Dialogzust¨ ande, in GDML auch als <step> bezeichnet. Die expliziten Zustands¨ uberg¨ ange werden grunds¨ atzlich durch das Element definiert. Wie bereits gesagt, m¨ ussen Variablen in GDML deklariert und einem Typen zugewiesen werden. Es gibt in GDML dabei neben den u ¨blichen Standardtypen einer Programmierspache zwei besondere Typen:

86

5 Beschreibung von Sprachdialogen

•

recres list ist ein Typ, welcher die n-besten geparsten Erkennergebnisse aufnimmt • enum ist ein Aufz¨ ahlungstyp Aussichten GDML wird bei Harman/Becker bereits seit 2001 f¨ ur die Entwicklung von Kundenprojekten verwendet. Im Jahre 2003 kamen mit den Sprachdialogsystemen im Audi A8 (D3) und in der Mercedes-Benz E-Klasse (W211) die ersten Produkte basierend auf dieser Technologie auf den Markt. Seitdem wird GDML f¨ ur die Entwicklung s¨ amtlicher Dialogsysteme verwendet. Da die Sprache und s¨ amtliche zu ihrer Verarbeitung notwendigen Werkzeuge komplett selbst entwickelt wurden, k¨ onnen eventuell notwendige Erweiterungen der Sprache ohne große Absprachen mit externen Partnern vorgenommen werden. Dies wird vor allem dann der Fall sein, wenn neue Anwendungsf¨ alle entstehen oder die Ansteuerung des Spracherkenners ge¨andert wird. Eine - auch langfristige - Abl¨ osung von GDML durch andere Sprachen oder Konzepte ist aktuell nicht geplant, da keine andere Sprache den Erfordernissen des Marktes und der Kunden soweit entspricht wie GDML. Selbst multimodale Erweiterungen k¨onnen mit dem Konzept der Systemcalls umgesetzt werden, ¨ ohne große grundlegende Anderungen an der Sprache durchzuf¨ uhren. GDML gilt damit als absolut zukunftssicher, wenn auch kleinere Erweiterungen nicht ausgeschlossen werden k¨ onnen. 5.2.2 Weitere Sprachen Neben GDML existiert eine Vielzahl weiterer Dialogbeschreibungssprachen, von denen im Folgenden die wichtigsten kurz dargestellt werden. VoiceXML VoiceXML steht f¨ ur Voice Extensible Markup Language. Es ist eine DDL, welche f¨ ur die einfache Umsetzung von Sprachdialogen im Telefoniebereich geschaffen wurde. Entwicklung Die Sprache geht zur¨ uck auf gemeinsame Bestrebungen der Firmen AT&T, IBM, Lucent und Motorola, die sich 1999 im VoiceXML-Forum zusammentaten, um eine standardisierte DDL zu entwickeln. Alle Partner hatten vorher bereits eigene DDLs spezifiziert, erkannten jedoch die Notwendigkeit eines Standards, um der Sprachtechnologie zu einem Durchbruch zu verhelfen. Daher wurde noch 1999 VoiceXML Version 0.9 ver¨offentlicht. [Sharma und Kunins 2002]

5.2 Dialogbeschreibungssprachen

87

Im Interesse einer komplett u ¨bergreifenden und herstellerunabh¨angigen Standardisierung wurden die Rechte an VoiceXML im Jahre 2000 vom VoiceXML-Forum an das World Wide Web Consortium (W3C) u ¨bertragen.5 [Maracke 2003] Die derzeit neueste Version von VoiceXML ist Version 2.1 [Oshry et al. 2007], welche eine minimale Weiterentwicklung von Version 2.0 [McGlashan et al. 2004] darstellt. Es wird auch an einer Version 3.0 gearbeitet, die bislang allerdings nicht ver¨ offentlicht wurde. Konzepte Da HTML die Definition von VoiceXML maßgeblich mit beeinflusst hat, wurde VoiceXML ebenfalls als Interpretersprache angelegt. Dabei besitzt VoiceXML, ebenso wie HTML, keine eigenen Konstrollstrukturen, stattdessen wird ECMA-Script6 verwendet. Variablen in VoiceXML sind grunds¨atzlich ungetypt. Ferner wird als Schnittstelle nach außen immer das HTTP verwendet. Zur Anbindung externer Informationsquellen, wie z.B. Datenbanken werden CGI-Skripte benutzt. Grammatiken k¨ onnen in VoiceXML vielf¨ altig in ein Dialogskript eingebunden werden. Sie d¨ urfen in JSGF (vgl. Abschnitt 5.3.2) und SRGS (siehe Abschnitt 5.3.4) vorliegen, sowie alternativ auch in einfacher BNF (vgl. Abschnitt 5.3.1) im VoiceXML-Skript selbst enthalten sein. Desweiteren bieten alle VoiceXML-Plattformen auch fest eingebaute vordefinierte Grammatiken. Ein VoiceXML-Skript wird vom VoiceXML-Interpreter (VXI) interpretiert und ausgef¨ uhrt. Die gr¨ oßte konzeptionelle Einheit in einem solchen Skript ist ein Formular, das in VoiceXML als bezeichnet wird. Es k¨onnen sich mehrere Forms in einem Skript befinden, das oberste Form wird dabei als erstes ausgef¨ uhrt. Die Ausf¨ uhrung der einzelnen Konzepte in einem Form ist im Form Interpretation Algorithm (FIA) geregelt. Dieser FIA bestimmt die Ausf¨ uhrungsreihenfolge der einzelnen Elemente in einem VoiceXML-Skript und stellt damit quasi den Dialogmanager in der VoiceXML-Architektur dar. VoiceXML unterst¨ utzt grunds¨ atzlich die zustandsbasierte und regelbasierte Dialogmodellierung. In der Literatur wird die VoiceXML Ausf¨ uhrung des regelbasierten Ansatzes auch als frame-based bezeichnet [McTear 2004]. Da VoiceXML bewusst als einfach zu erlernende Sprache angelegt ist, wurden komplexe Funktionalit¨ aten in einfachen Konzepten gekapselt. Dies gilt vor allem f¨ ur die Aufrufe des Spracherkenners und die Reaktion auf Spracheingaben. Grunds¨ atzlich wird in VoiceXML ein Sprachdialog als ein Formular betrachtet, das zu f¨ ullende Felder und Beschreibungen zu diesen enth¨alt. Die 5

6

Dieses Gremium ist vor allem durch Empfehlungen f¨ ur die Gestaltung und Implementation von Standards im Umfeld des World Wide Web bekannt geworden. Es ist ein regierungs- und unternehmensunabh¨ angiges Gremium, bei dem bereits sehr viele Unternehmen, Universit¨ aten und Institutionen Mitglied sind. ECMA-Script ging aus JavaScript von Netscape und JScript von Microsoft hervor. Es ist auch als ECMA-Standard 262 bekannt ([ECMA 1999]).

88

5 Beschreibung von Sprachdialogen

Beschreibungen stellen die System¨ außerungen (prompts) dar, ein Feld ist mit Eingaben des Benutzers zu f¨ ullen. Aus dieser Betrachtung ergibt sich, dass Benutzereingaben in einem verwaltet werden. Die Vorgehensweise des FIA ist die, dass zuerst ein Feld in einem Form ausgew¨ahlt wird7 , anschließend wird der jeweilige Prompt vorgelesen und dann automatisch der Spracherkenner mit der angegebenen Grammatik ge¨offnet. Nachdem eine pas¨ sende Außerung vom FIA erkannt und geparst wurde, gilt ein Feld als gef¨ ullt. Um schließlich Reaktionen auf erfolgte Benutzereingaben vorzunehmen, wird der Anweisungsblock ausgef¨ uhrt, der mit dem Tag bezeichnet ist. Dieser Ansatz erlaubt eine effiziente Implementation und einfache Darstellung auch l¨ angerer und komplexer Dialoge. Beispiel Im Rahmen der Gegen¨ uberstellung von GDML und VoiceXML wird weiter unten in Abschnitt 5.2.3 ein VoiceXML Beispieldialog gezeigt. N¨aheres ist dort beschrieben. Aussichten VoiceXML ist bereits sehr verbreitet und hat sich vor allem f¨ ur kommerzielle Telefonieanwendungen zu einem echten Standard f¨ ur Dialogbeschreibungen entwickelt. In den USA gibt es bereits mehrere sogenannte Sprachportale, die auf VoiceXML beruhen [Sharma und Kunins 2002]. Doch auch Universit¨ aten und Forschungsprojekte besch¨ aftigen sich inzwischen mit VoiceXML, siehe z.B. [Bennett et al. 2002, Alton-Schneidl 2003, de C´ ordoba et al. 2004, Kim et al. 2004]. Wie von [Hamerich et al. 2003] bereits beschrieben, ist VoiceXML nicht geeignet f¨ ur die Modellierung von gr¨ oßeren komplexen Applikationen. Daher hat es sich bei industriellen Telefonieanwendungen durchgesetzt, die komplette Modellierung in anderen Sprachen (z.B. SCXML [Barnett et al. 2008]) zu erledigen. VoiceXML wird in diesem Fall nur noch f¨ ur jeweils eine Systemausgabe mit Aufruf des Spracherkenners verwendet. Diese VoiceXML-Skripte werden in Echtzeit aus der gesamten Modellierung generiert. Nach erfolgter Erkennung werden die Ergebnisse dann zur¨ uckgeliefert und außerhalb von VoiceXML weiter verarbeitet. Da dieses Problem allgemein bekannt ist, wird gerade an VoiceXML 3.0 gearbeitet, welches SCXML als Skriptsprache beinhalten und damit auch eine einfachere Metamodellierung erlauben soll. Wie bereits dargestellt wird VoiceXML momentan vor allem f¨ ur Telefonieapplikationen verwendet. Dies liegt vor allem am Ressourcenbedarf des VXI. In [B¨ uhler und Hamerich 2004, B¨ uhler und Hamerich 2005] wird ein in ECMA-Script kompilierter VXI dargestellt, der auch auf eingebetteten Ger¨ aten verwendet werden k¨ onnte. 7

In einem systemgetriebenen Dialog werden die Felder automatisch von oben nach unten ausgew¨ ahlt, in einem Dialog mit gemischter Initiative wird das oberste noch ungef¨ ullte Feld im aktuellen Form ausgew¨ ahlt.

5.2 Dialogbeschreibungssprachen

89

X+V, SALT und EMMA Bereits seit einiger Zeit sind auch multimodale Dialogbeschreibungen im Gespr¨ ach. Einen u ¨bergreifenden und von allen akzeptierten Standard gibt es bisher nicht. Aber es existieren drei sehr detaillierte und sich widersprechende Konzepte, die in diesem Abschnitt kurz beschrieben werden. IBM, Motorola und Opera haben mit XHTML + VoiceXML (kurz X+V genannt) eine M¨ oglichkeit geschaffen, VoiceXML-Codeelemente in XHTMLCode einzubinden und damit eine multimodale Verkn¨ upfung von zwei Standards vorgesehen [Axelsson et al. 2004]. SALT (Speech and Application Language Tags) stellte eine Erweiterung f¨ ur verschiedene existierende Markupsprachen, wie z.B. HTML, XHTML, WML, um neue Konzepte zur Sprachsteuerung dar. Diese Erweiterung ging allerdings nicht konform mit VoiceXML, sondern definierte eigene Konzepte. Nachdem Microsoft als gr¨ oßter Partner des Forums allerdings im Jahr 2007 TellMe gekauft hat, welches massiv in VoiceXML und existierende Standards investiert hatte, brach die Unterst¨ utzung f¨ ur SALT weg. Aktuell gibt es keine Unternehmen mehr, die SALT propagieren. EMMA (Extensible Multi-Modal Annotations) ist vom W3C als Austauschformat f¨ ur die Schnittstelle zwischen Eingabe und Interaktionsmanagement gedacht. Die Sprache soll Eingaben von Spracherkennern, Handschrifterkennern und auch Tastaturen verarbeiten und an eine Dialogmanagerkomponente weitergeben k¨ onnen. Der aktuelle Umfang von EMMA ist bei [Baggia et al. 2007] spezifiziert. Bisher ist lediglich zu berichten, dass SALT nach anf¨anglich großen Werbemaßnahmen inzwischen faktisch tot ist. Wie lange allerdings EMMA und X+V weiterbestehen, kann aktuell nicht gesagt werden. GDialogXML GDialogXML ist die Kurzform f¨ ur GEMINI Dialog XML. Es handelt sich dabei um eine objekt-orientierte und multimodale Dialogbeschreibungs- und -modellierungssprache, die im Rahmen des EU gef¨orderten Projekts GEMINI (vgl. Abschnitt 6.2.1) entwickelt wurde. GDialogXML wurde prim¨ar f¨ ur die Modellierung automatisch generierter Dialoge entwickelt. In die Sprache flossen Erkenntnisse aus GDML , VoiceXML , HTML und RDF ein. Eine erste Vorstellung der Sprache erfolgte in [Hamerich et al. 2003], ihre besondere multimodale Fehlerbehandlung wurde von [Wang et al. 2003] beschrieben. GDialogXML wurde erfolgreich f¨ ur zwei Demo-Anwendungen im Rahmen des GEMINI Projekts eingesetzt [Hamerich et al. 2004b]. GDialogXML wird im GEMINI-Projekt als Meta-Sprache eingesetzt, um daraus VoiceXML zu generieren. Die Besonderheit der Sprache ist, dass sie nicht nur f¨ ur die Modellierung von Dialogen verschiedener Modalit¨aten eingesetzt werden kann, sondern gleichzeitig auch zur Modellierung von Datenbasen und -klassen.

90

5 Beschreibung von Sprachdialogen

Nach dem Ende des GEMINI-Projekts kann GDialogXML auch ohne die im Rahmen des Projekts entwickelten Werkzeuge weiterverwendet werden. Konzepte der Sprache wurden im Rahmen des Standardisierungsprozesses einer Dialogmetasprache einem gr¨ oßeren Kreis vorgestellt. Der letzte Stand der Sprache mit ihren grunds¨ atzlichen M¨oglichkeiten wurde von [Schubert und Hamerich 2005] dokumentiert. HDDL HDDL wurde von Harald Aust im Rahmen seiner Dissertation [Aust 1998] f¨ ur Philips entwickelt. Diese Sprache war eine der ersten Dialogbeschreibungssprachen, die bereits eine Vielzahl von wegweisenden Konzepten enthielt. Soweit bekannt ist, gibt es in HDDL zum Beispiel spezielle Konstrukte f¨ ur die Verifikation von Erkennergebnissen. Leider d¨ urfen Details der Sprache nicht ver¨offentlicht werden, daher kann hier auch nicht mehr dar¨ uber gesagt werden. xHMI Die Firma Nuance8 hat vor einiger Zeit eine eigene Metabeschreibungssprache f¨ ur Sprachdialogsysteme namens xHMI vorgestellt. Detaillierte Ausk¨ unfte u ¨ber diese Sprache wurden jedoch bisher nicht erteilt. Es gibt lediglich ein publiziertes White Paper [ScanSoft 2004], welches dar¨ uber informiert, dass xHMI auf XML basiert und einen generischen Ansatz zur Beschreibung von Sprachdialogen bietet. Generisch heisst in diesem Sinne, dass xHMI M¨oglichkeiten bieten soll, Dialogbeschreibungen u.a. f¨ ur VoiceXML und SALT zu erstellen. Laut internen Aussagen soll xHMI grunds¨atzlich SCXML ¨ahneln, einer abstrakten Beschreibungssprache f¨ ur zustandsbasierte Sprachapplikationen, die wie VoiceXML vom W3C spezifiziert wird. 5.2.3 Vergleich GDML und VoiceXML Nachdem nun GDML als zentrale Dialogbeschreibungssprache des vorliegenden Werkes vorgestellt wurde und auch VoiceXML als Industriestandard bekannt ist, werden in diesem Abschnitt die wesentlichen Unterschiede und Gemeinsamkeiten der beiden Sprachen gegen¨ ubergestellt. ¨ Ahnlichkeiten beider Sprachen sind teilweise durchaus beabsichtigt, da zum Zeitpunkt der Definition von GDML bereits VoiceXML 0.9 verabschiedet war. Auf Grund der bereits in Kapitel 3 beschriebenen Besonderheiten von automobilen Sprachsystemen war VoiceXML jedoch f¨ ur den Automobilmarkt ungeeignet. 8

¨ Die Firma war vor der Ubernahme des ehemaligen Wettbewerbers Nuance als ScanSoft bekannt, die vorher bereits Lernout & Hauspie, Philips Speech Processing und Speechworks u ¨bernommen hat.

5.2 Dialogbeschreibungssprachen

91

Codeelemente Ein Vergleich der grundlegenden Codeelemente beider Sprachen ist in Tabelle 5.1 dargestellt. Genauere Beschreibungen der in den Fußnoten beschriebenen Unterschiede sind in diesem Abschnitt zu finden. ¨ VoiceXML-Element Aquivalent in GDML <step>1 <step> <prompt>2 <prompt>3 –4 <exit> 1

mit enthaltenem expliziten Erkenneraufruf anschließend konkretes Wording oder Referenz auf Audio-Datei 3 anschließend Referenz auf Konzept, das Wording oder Referenz auf Audio-Datei enth¨ alt 4 ¨ muss explizit ausformuliert werden, kein direktes Aquivalent vorhanden 2

Tabelle 5.1. Vergleich der wichtigsten Codeelemente von VoiceXML und GDML

Externe Schnittstellen Wie bereits dargestellt, muss eine Sprachbedienung direkt auf die zu kontrollierenden Ger¨ ate im Automobil zugreifen k¨onnen. Daf¨ ur wurde in GDML das Konzept der Systemcalls als eigenes Codeelement geschaffen, um diesen direkten Zugriff aus dem Dialog heraus zu erm¨oglichen. In VoiceXML ist der Zugriff auf externe Ressourcen außerhalb des Dialogmodells nur u ¨ber CGI Skripte oder ECMA Skript m¨oglich. Beide Alternativen bedingen die Existenz zus¨ atzlicher Softwarekomponenten neben dem VoiceXML Interpreter, n¨ amlich einen HTTP-Server oder einen zus¨atzlichen ECMA-Script Interpreter. Da der Speicherplatz in Automobilanwendungen aber stark begrenzt und teuer ist, bietet sich der VoiceXML Ansatz nicht als Alternative zu GDML an. Schnittstelle zum Spracherkenner In VoiceXML ist die Schnittstelle zur Spracherkennung im Interpretations Algorithmus (FIA) des Interpreters enthalten und nur durch das Codeelement zu erkennen. Der Vorteil dieser L¨ osung ist ein u ¨bersichtlicher Dialogcode und dadurch eine schnelle Erlernbarkeit der Sprache f¨ ur Einsteiger. In GDML dagegen sind die Erkenneraufrufe explizit als eigene Codeelemente ausgef¨ uhrt, wie auf Abbildung 5.3 zu erkennen ist. Dieses Konzept l¨asst

92

5 Beschreibung von Sprachdialogen <prompt bargein="false"> Herzlich willkommen bei meiner Demo <prompt> Wollen Sie das Programm starten? <prompt> Schade dann h¨ oren wir halt auf <exit/> <elseif cond="answer == true"/> <prompt> Das Programm wird gestartet <prompt> Bis dann <exit/> Abbildung 5.4. Demo-Dialog in VoiceXML

die Dialogmodellierung zwar sperrig erscheinen, bietet aber daf¨ ur dem Dialogdesigner jeden Freiraum bei der Implementation. So k¨onnen individuell, basierend auf der aktuellen Dialogsituation, nicht nur verschiedene Grammatikregeln aktiviert werden, es k¨ onnen auch unterschiedliche Timeoutwerte gesetzt werden. Zus¨ atzlich bietet das Interface einen einfachen Zugriff auf dynamisches Vokabular u ¨ber sogenannte Enrollments. Eine Funktionalit¨at, die VoiceXML u ur die Sprachbedienung von ¨berhaupt nicht vorsieht, die aber f¨ Adressb¨ uchern oder Navigationsdatenbanken essentiell ist.

5.2 Dialogbeschreibungssprachen

93

Dialogprompts In Tabelle 5.1 ist f¨ ur die Sprachausgabe des Dialogs in beiden Sprachen das identische Codeelement <prompt> notiert. Doch trotz dieser Gemeinsamkeit ist das grunds¨ atzliche Konzept von Sprachausgaben in VoiceXML und GDML v¨ ollig unterschiedlich. In VoiceXML m¨ ussen die Inhalte der Sprachausgabe (entweder als Wave-Dateinamen oder als TTS-Texte) explizit an der Stelle im Code spezifiziert werden, an der sie auch verwendet werden. Dies mag in kleineren Anwendungen u ¨bersichtlich und sinnvoll erscheinen, aber schon bei der mehrfachen Verwendung identischer Ansagen in unterschiedlichen Kontexten muss entweder der Prompt redundant erneut geschrieben werden oder ein eigener Dialogschritt f¨ ur die Sprachausgabe erstellt werden. Sehr viel schwieriger wird es bei VoiceXML, wenn Dialoganwendungen internationalisiert werden sollen, sprich eine fertige Anwendung in eine andere Sprache u ¨bertragen werden soll. In diesem Fall muss der Dialog ge¨ andert werden. In GDML wurde aus diesen Gr¨ unden die Idee eines Promptkonzepts erschaffen. Promptkonzepte m¨ ussen wie Variablen auch deklariert werden. Daneben muss f¨ ur jedes Konzept ein Inhalt (sogenannter Prompt Body) angegeben werden, der wie bei VoiceXML auch aus Dateinamen oder Texten (Wording) bestehen darf. Nun kann an jeder beliebigen Stelle des Dialogs das Promptkonzept referenziert und damit verwendet werden. Wieder ist GDML hier sehr viel expliziter und verlangt mehr Schreibarbeit, aber daf¨ ur ist die Wiederverwendung von Ansagen einfach machbar, die Texte k¨ onnen einfach und unabh¨ angig vom Dialogablauf verwaltet werden und schlussendlich ist eine Portierung in andere nat¨ urliche Sprachen mit dem einfachen Austauschen der Promptinhalte erledigt. Letzteres bietet den zus¨ atzlichen Vorteil, dass bei der Spezifikation und Implementation eines Dialogs in GDML keine R¨ ucksicht auf sprachliche Besonderheiten bei den Sprachausgaben f¨ ur verschiedene Sprachen genommen werden muss, da diese separat vom Dialogablauf spezifiziert und definiert werden. Damit kann also die Dialogentwicklung in GDML sprachunabh¨ angig vor sich gehen. Programmierkonzepte GDML bietet nahezu den vollen Funktionsumfang einer Programmiersprache, so gibt es verschiedene Schleifentypen, Variablentypen, Listen etc. Daneben bietet es sogar eigene logische Konstruktoren f¨ ur die verschiedenen Typen. Es fehlen allerdings Klassen oder Objekte, damit ist GDML keine objektorientierte Sprache. Im Gegensatz dazu bietet VoiceXML lediglich ein rudiment¨ares Set von eigenen Beschreibungsformen. Weitergehende Konzepte werden zwar angeboten, erfordern aber ECMA Script oder sogar CGI Skripte. Dies ist eine Folge der Abstammung von HTML, welches ebenfalls CGI Skripte oder JavaScript ben¨ otigt, um komplexere Operationen ablaufen zu lassen. Doch die Verwandtschaft mit HTML hat noch andere Nachteile: die Elemente von VoiceXML

94

5 Beschreibung von Sprachdialogen

d¨ urfen nicht an beliebigen Stellen verwendet werden, sondern nur in einem eng definierten Rahmen, der von der Document Type Definition (DTD) vorgegeben wird.9 Die DTD gestattet beispielsweise den Aufruf eines Unterdialogs (engl. subdialogue) nicht nach jedem VoiceXML Element. Dies macht die Implementation von verschachtelten Dialogen mit VoiceXML sehr schwer. Zus¨ atzlich gibt es in VoiceXML keine getypten Variablen, was einen sehr komplexen, un¨ ubersichtlichen und damit fehleranf¨alligen Code zur Folge haben kann. Ausf¨ uhrung Wie bereits dargestellt, sind Sprachbediensysteme im Automobil als geschlossene Systeme ausgef¨ uhrt. S¨ amtliche Daten sind bereits in der Entwicklungsphase des Dialogs bekannt. Sogar die m¨ oglichen Datenquellen sind eindeutig bekannt: Navigationsdatenbank (f¨ ur Orts- und Straßennamen), Adressbuch (f¨ ur Firmen- und Personennamen), Radio (Namen von Radiosendern) und die Grammatik. Weitere Datenquellen k¨ onnen nicht vorkommen. Die Kenntnis der kompletten Datenquellen gestattet die Kompilierung des Sprachdialogs, da kein dynamisches Verhalten ben¨otigt wird. Dies spart Speicherplatz und erlaubt einen einfachen und kleinen Dialogmanager. Im Gegensatz dazu kann in VoiceXML Dialogen der Datenraum unbekannt sein. Daher werden u ¨blicherweise dynamische Dialoge verwendet, die mittels CGI Skripten implementiert werden. Daneben wird nat¨ urlich ein komplexerer Dialogmanager ben¨ otigt, der auch die dynamische Interpretation von Dialogskripten leisten muss. Konvertierung von GDML in VoiceXML Bei [Hamerich und B¨ uhler 2005] wird ein ausf¨ uhrlicher Vergleich der beiden Sprachen vorgenommen. Ferner wird basierend auf [MegatTajuddin 2005] gezeigt, dass GDML Dialoge inklusive Prompts und Grammatiken komplett und automatisch in funktionsf¨ ahige VoiceXML Dialoge umgewandelt werden k¨onnen. Wie bereits in den bisherigen Beschreibungen angedeutet, ist der resultierende VoiceXML Code allerdings sehr umfangreich und umst¨andlich. Bewertung Dieser Vergleich hat noch einmal gezeigt, dass VoiceXML f¨ ur den Einsatz in eingebetteten Systemen im Automobil ungeeignet ist. GDML ist zwar umst¨ andlicher zu handhaben und produziert daher auch l¨angeren Quellcode, l¨ asst sich aber speichersparend kompilieren. Damit ist GDML f¨ ur den Einsatz in eingebetteten Systemen die Beschreibungssprache der Wahl. 9

Die DTD beschreibt die Syntax einer XML Sprache.

5.3 Grammatikbeschreibungen

95

Wie dargestellt wurde, ist VoiceXML f¨ ur Anf¨anger besser geeignet, da kleinere bis mittlere Dialogmodelle sich in k¨ urzerem und einfacherem Code darstellen lassen. Um dies zu illustrieren wird auf Abbildung 5.4 die VoiceXML Version des GDML Beispieldialogs von Abbildung 5.3 dargestellt. Wie schon bei einem so kleinen Dialog zu erkennen, sind VoiceXML Dialoge etwas k¨ urzer ¨ als ihr Aquivalent in GDML. Dies liegt v.a. an der Explizitheit von GDML und dem ben¨ otigten Deklarationsblock. Die manuelle Entwicklung eines solchen expliziten und umfangreichen Codes ist allerdings sehr aufw¨ andig und fehleranf¨ allig. Daher wurde im Rahmen dieses Werkes das Programmierwerkzeug DiaGen entwickelt. Auf diesen Punkt und das resultierende Werkzeug wird in Kapitel 7 ausf¨ uhrlich eingegangen.

5.3 Grammatikbeschreibungen Nachdem mit der Dialogbeschreibung die Dialogebene bekannt ist, wird in diesem Abschnitt die Signalebene (speech) betrachtet. So m¨ ussen f¨ ur Sprachdialoge neben dem Dialogfluss und den Systemausgaben auch die m¨oglichen Eingaben, ergo die Dialogparameter (vgl. Abschnitt 2.9) genau vorgegeben werden. Dies liegt begr¨ undet im Prinzip der statistischen Spracherkennung (siehe Abschnitt 3.4.2). Dieser Teil der Beschreibungsformen wird u ¨blicherweise nicht im Dialogablauf beschrieben sondern in einer separaten Form. Daher wird die Beschreibung der m¨ oglichen bzw. akzeptierten Spracheingaben auch nicht in einer Dialogbeschreibungssprache kodiert, sondern in Form von Grammatiken. Grunds¨ atzlich gibt es zwei verschiedene Alternativen, m¨ogliche Spracheingaben f¨ ur ein Dialogsystem zu beschreiben. Der ¨altere Weg ist die Verwendung von Grammatiken, die in verschiedenen Formaten vorliegen k¨onnen. Die zweite M¨ oglichkeit ist die Verwendung von statistischen Sprachmodellen. Bei ¨ diesem Ansatz wird aus einer m¨ oglichst großen Zahl von Außerungen ein Korpus erstellt, u uhrt wird. Beispielsweise ¨ber dem die Spracherkennung ausgef¨ arbeitet das in [Hamerich 2000] vorgestellte System nach diesem Prinzip. Grunds¨ atzlich arbeiten sowohl GDML als auch VoiceXML mit Grammatiken. ¨ Mit minimalen Anderungen an den Beschreibungssprachen k¨onnten jedoch auch statistische Sprachmodelle verwendet werden, allerdings w¨aren daf¨ ur umfangreiche Arbeiten v.a. an der Spracherkennung n¨otig. Daher werden im Rahmen dieses Buches nur Grammatiken betrachtet. In diesem Abschnitt werden die wichtigsten und bekanntesten Grammatikbeschreibungen f¨ ur Dialogsysteme vorgestellt. Zuerst wird allerdings kurz auf die Unterschiede einer Dialoggrammatik und einer Verstehensgrammatik eingegangen. F¨ ur Auskunfts-, Unterst¨ utzungs- und Bediensysteme (vgl. Abschnitt 3.7.1) reicht es in der Regel aus, die semantische Repr¨ asentation einer Benutzer¨außerung zu erkennen. Denn f¨ ur die Steuerung eines Telefons im Automobil ist es irrelevant, ob ein Benutzer sagt Anrufen bei Gerhard“, Verbinde mich ” ” mit Gerhard“ oder Ich m¨ ochte bei Gerhard anrufen“. Die wichtige Informa”

96

5 Beschreibung von Sprachdialogen

tion f¨ ur das System ist, dass der Benutzer das Telefon verwenden m¨ochte, um die Nummer f¨ ur den Eintrag ’Gerhard’ zu w¨ahlen. Eine entsprechende semantische Repr¨ asentation wird daher als Erkennergebnis an den Dialog geliefert. Diese Repr¨ asentation ist sprachenunabh¨angig und enth¨alt keine Information u ¨ber den exakten Wortlaut des Benutzers, einzig seine Intention wird repr¨ asentiert. Wie bei [Hamerich et al. 2005] dargestellt, geht es bei solchen Systemen nicht um Sprachverstehen.10 Daher spielen syntaktische Unterschiede gar keine Rolle und semantische Unterschiede nur soweit, wie sie konkret in einer Dom¨ ane auftauchen k¨ onnen. Komplexere Grammatiken im ¨ linguistischen Sinne sind zur Zeit nur f¨ ur Ubersetzungssysteme n¨otig, da dort sehr genaues Wissen auch u orter wichtig ist. ¨ber einzelne W¨ Die wichtigsten Grammatiknotationen f¨ ur Dialogsysteme werden im Folgenden beschrieben. 5.3.1 BNF Die allgemeinste Beschreibung von Grammatiken f¨ ur Sprachdialogsysteme stellt die Backus-Naur-Form (BNF) dar. Die BNF, auch als Backus-Normalform bezeichnet, ist eine kompakte formale Metasyntax, die benutzt wird, um kontextfreie Grammatiken darzustellen. Urspr¨ unglich war sie nach John Backus benannt, sp¨ater wurde sie (auf Anregung von Donald Knuth) auch nach Peter Naur benannt. Durch die BNF wurde es erstmals m¨ oglich, die Syntax einer Programmiersprache (damals ALGOL 60) formal exakt darzustellen, vgl. [Naur et al. 1960]. Ein Beispiel f¨ ur eine einfache BNF-Grammatik ist in Abbildung 5.5 zu sehen. yes = ja [gerne | nat¨ urlich | bitte] | jawohl | sicher no = ( nein | nee | n¨ o ) [danke] Abbildung 5.5. Ja/Nein-Grammatik in BNF-Notation

5.3.2 JSGF Um Sprachgrammatiken im praktischen Einsatz zu standardisieren wurde das Java Speech Grammar Format (JSGF) von Sun Microsystems entwickelt [Sun 1998a]. Laut [K¨ olzer 2002] waren folgende Partner bei der Entwicklung beteiligt: Apple, Novell, AT&T, Dragon, IBM, Philips und TI. JSGF wurde mittlerweile auch vom W3C als Standard zur Beschreibung von Grammatiken 10

Nat¨ urlich gibt es Arbeiten, die sich auch mit dem Sprachverstehen im klassischen akademischen Sinne besch¨ aftigen, mehr dazu bei [Pieraccini und Huerta 2005].

5.3 Grammatikbeschreibungen

97

anerkannt [Hunt 2000]. Mit Hilfe von JSGF k¨ onnen regul¨are Grammatiken in einer BNF-¨ ahnlichen Notation erfasst werden. Um auch sprachen- und wortunabh¨ angig zu sein, k¨onnen einzelne Wortgruppen mit einem semantischen Bezeichner versehen werden. Diese Kategorien entsprechen den Dialogparametern des Benutzers, also den benutzerseitigen Dialogakten. F¨ ur die Notation dieser semantischen Konzepte gibt es inzwischen einen Standard vom W3C namens SISR [van Tichelen und Burke 2007]. Vorher gab es keine eindeutige Syntax f¨ ur diese Notation. Sun hat zwar einige Vorschl¨ age in dieser Richtung gemacht (vgl. [Sun 1998b]), diese waren aber nicht sehr konkret. Daher haben die meisten Nutzer von JSGF eigene propriet¨ are Versionen der semantischen Notation erstellt. In GDML und VoiceXML sind diese z.B. leicht unterschiedlich. In Abbildung 5.6 ist die JSGFForm des obigen Beispiels in Harman/Becker-Notation dargestellt, in den geschweiften Klammern stehen die Wertpaare f¨ ur die semantische Repr¨asentation, auch Tags genannt. Der erste Wert cmd bezeichnet das GrammatikFeature. Es k¨ onnen beliebige Features erstellt werden. Ein Feature stellt praktisch die Klassifikation der Dialogparameter f¨ ur den Dialog dar. Im Dialog wird ein Feature an eine interne Variable gebunden, der Wert des Features stellt die erkannte Benutzerintention f¨ ur das jeweilige Feature dar. Im Beispiel gibt es die m¨ oglichen Intentionen yes f¨ ur positive Antworten und no f¨ ur ablehnende. = (ja [gerne | nat¨ urlich | bitte] |jawohl | sicher) {cmd=yes}; <no> = ((nein | nee | n¨ o) [danke]) {cmd=no}; Abbildung 5.6. Ja/Nein-Grammatik in JSGF-Notation

Das Dialogmodell muss die m¨ oglichen verschiedenen Werte verarbeiten k¨onnen und sollte f¨ ur jeden Fall eine eigene Behandlung vorsehen. Nat¨ urlich k¨ onnen auch Werte gleich verarbeitet werden. Wichtig ist nur, dass jeder m¨ ogliche Dialogparameter auch im Dialogmodell verarbeitet wird. Ist dies nicht der Fall, entsteht ein undefinierter Zustand. 5.3.3 GSL Die Grammar Specification Language (GSL) der Firma Nuance hat sich bei den telefonischen Sprachdialogsystemen zu einem wichtigen Standard entwickelt. Neben JSGF ist dies die meistgebrauchte Grammatikbeschreibungssprache f¨ ur Dialogsysteme. Allerdings ist GSL propriet¨ar und detaillierte Informationen u ¨ber das Format werden nur an registrierte Kunden weitergegeben und d¨ urfen auch nicht ver¨ offentlicht werden.

98

5 Beschreibung von Sprachdialogen

5.3.4 SRGS Nachdem inzwischen alle wichtigen Beschreibungssprachen auf XML basieren, wurde im W3C eine XML-basierte Grammatikbeschreibung spezifiziert [Hunt und McGlashan 2004]. Das Resultat wurde als Speech Recognition Grammar Specification (SRGS) bezeichnet und ist prinzipiell die Portierung von JSGF nach XML. Aus diesem Grund wird diese Grammatikbeschreibung auch als Grammar XML (GRXML) bezeichnet. Es gibt grunds¨ atzlich zwei Darstellungsformen, die erste ist eine ABNFForm, die sich sehr stark an der VoiceXML-Version von JSGF orientiert. Die zweite Darstellungsart ist eine XML-Version, welche im Folgenden n¨aher betrachtet wird. F¨ ur das menschliche Auge wirkt die XML-Notierung der kleinen Ja/Nein-Grammatik auf Abbildung 5.7 sehr unleserlich. Daf¨ ur ist es f¨ ur Computerprogramme sehr viel einfacher, Grammatiken in dieser Notation zu erstellen und zu verarbeiten. ja gerne nat¨ urlich bitte jawohl sicher $.cmd="yes" nein nee n¨ o danke $.cmd="no" Abbildung 5.7. Ja/Nein-Grammatik in SRGS-Notation

5.4 Zusammenfassung

99

5.4 Zusammenfassung In diesem Kapitel wurden zuerst die Hintergr¨ unde und Notwendigkeiten der Entwicklung von Dialogbeschreibungssprachen dargestellt. Anschließend wurde GDML als zentrale Dialogbeschreibung des vorliegenden Werkes detailliert vorgestellt. Zur besseren Einordnung wurden kurz andere wichtige Sprachen beschrieben, vor allem VoiceXML . Letztere wurde GDML in einem Vergleich gegen¨ ubergestellt und die Vor- und Nachteile der Sprachen insbesondere vor dem Hintergrund des Einsatzes in einer eingebetteten Umgebung diskutiert. Dabei ist bereits auf die Problematik des ausf¨ uhrlichen Quellcodes von GDML Dialogen hingewiesen worden. Ein Problem, das mit dem im Rahmen dieses Werkes entwickelten DiaGen Werkzeug gel¨ost werden soll. Da die Dialogbeschreibungssprachen ausschließlich der Beschreibung des Dialogablaufs im Dialogmodell dienen, m¨ ussen die m¨oglichen Benutzer¨außerungen anderweitig implementiert werden. Daher wurden ebenfalls die Grammatikbeschreibungen f¨ ur Dialogsysteme vorgestellt. Dabei wurde darauf hingewiesen, dass diese Grammatiken keinen linguistischen Anspr¨ uchen gen¨ ugen, da es bei den meisten Dialogsystemen ausschließlich um die Erkennung von Benutzerintentionen geht, welche zur Erreichung des Dialogziels f¨ uhren sollen. Das heißt, Sprachverstehen kann mit diesen Grammatiken nicht erfolgen. Die vorgestellte Beschreibung JSGF ist f¨ ur das weitere Werk von Bedeutung, da dieses Format von GDML genutzt wird. Mit der Darstellung der softwaretechnischen Umsetzung bei der Erstellung von Dialogsystemen sind mit Ende dieses Kapitels alle f¨ unf Schichten des in Abschnitt 1.3 eingef¨ uhrten Schichtenmodells bekannt. Das bedeutet, dass die Kapitel 2 bis 5 die Grundlage f¨ ur die Entwicklung eines Werkzeugs zur Unterst¨ utzung der Dialogentwicklung f¨ ur automobile Sprachbediensysteme darstellen. Wie diesem Kapitel bereits entnommen werden konnte, ist alleine die Implementierung von Sprachdialogen auch mit Dialogbeschreibungssprachen immer noch sehr aufw¨ andig. Auch die Spezifikation und Vollst¨andigkeit eines Dialogs in zustandsbasierter Modellierung muss umst¨andlich und langwierig erledigt bzw. gepr¨ uft werden. Daher gibt es bereits Werkzeuge, die bei einigen dieser Schritte Unterst¨ utzung geben sollen. Diese werden im nachfolgenden Kapitel vorgestellt.

6 Teilautomatisierte Modellierung von Dialogen

Wie bereits in der Einleitung dargestellt wurde, ist es das Ziel dieses Werkes, die Methoden der verschiedenen in den vorangegangenen Kapiteln beschriebenen Ebenen des Schichtenmodells in ein Werkzeug zu vereinen. Auch die Vereinigung von Dialogsicht (Dialogmodell) und Erkennungssicht (Grammatik) ist dabei angestrebt. In diesem Abschnitt soll der Bedarf f¨ ur ein solches neues Werkzeug aufgezeigt werden. Im vorherigen Kapitel wurde die Dialogbeschreibungssprache GDML vorgestellt. Dabei konnten in dem Beispieldialog von Abb. 5.3 bereits die in Abschnitt 2.4.1 angek¨ undigten, ausmodellierten expliziten Transitionen gesehen werden. Diese begr¨ unden den bereits erw¨ahnten verh¨ altnism¨ aßig großen Entwicklungsaufwand. Trotz dieses Nachteils eignet sich solch eine zustandsbasierte Beschreibungssprache hervorragend f¨ ur den industriellen Einsatz, wie bereits in Abschnitt 3.3 diskutiert wurde. So kann mit zustandsbasierten Modellen eine eindeutige und vollst¨ andige Spezifikation recht einfach erstellt werden, wie sie f¨ ur Auftraggeber essentiell ist. Um aber den gegen¨ uber anderen Ans¨ atzen gr¨oßeren Entwicklungsaufwand, welcher durch diese explizite Beschreibung entsteht, handhabbar zu machen, sollte die Codeentwicklung so weit wie m¨ oglich automatisch unterst¨ utzt werden. Die Verwendung eines Entwicklungswerkzeugs bietet sich dabei an. Dies ist eine Bestrebung, die nicht nur f¨ ur die Entwicklung von Sprachdialogsystemen gilt, sondern sich allgemein in der informatischen Anwendungsentwicklung wiederfindet. So wird heutzutage insbesondere die Softwareentwicklung in C, C++ oder Java nur noch selten ohne eine integrierte Entwicklungsumgebung (IDE) durchgef¨ uhrt. Inzwischen haben sich sogar neben den bekannten propriet¨ aren IDEs von Borland, IBM oder Microsoft auch frei verf¨ ugbare wie Eclipse oder KDevelop durchgesetzt. Auch f¨ ur Sprachdialoge gibt es grunds¨ atzliche Bestrebungen, den Entwicklungsaufwand durch den Einsatz von Werkzeugen zu verringern. Insbesondere f¨ ur die Dialogbeschreibungssprache VoiceXML existieren bereits verschiedenste freie und kommerzielle Entwicklungsumgebungen.

102

6 Teilautomatisierte Modellierung von Dialogen

Neben der einfachen Codierung von Hand gibt es grunds¨atzlich zwei unterschiedliche automatisierte Herangehensweisen f¨ ur die Entwicklung von Sprachapplikationen, die sich zum Teil auch u ¨berschneiden k¨onnen. Das ist zum einen der graphische Ansatz, bei dem mittels Ablauf- oder Zustandsdiagrammen ein Dialogverlauf erstellt und daraus Code generiert wird. Zum anderen existiert der textuelle Ansatz, welcher auf vorhandenen generischen Dialogmodulen mit semiautomatischer Unterst¨ utzung aufbaut. Beide Ans¨atze werden in den folgenden Unterkapiteln dargestellt und einige exemplarische Vertreter der jeweiligen Kategorie genauer betrachtet. Ziel dieses Kapitels ist es, aus den vorgestellten Werkzeugen Ideen und Ans¨ atze f¨ ur die Entwicklung eines eigenen Werkzeugs – welches im nachfolgenden Kapitel 7 im Detail vorgestellt wird – zu generieren. Des Weiteren soll der Bedarf f¨ ur das neue Werkzeug belegt werden.

6.1 Graphischer Ansatz Dialogabl¨ aufe – insbesondere zustandsbasierte – lassen sich graphisch sehr gut mit Zustands- oder Flussdiagrammen (engl. state / flow charts) abbilden. Diese Abbildung wird dann als Spezifikation und Grundlage f¨ ur die sp¨atere Erstellung des Codes genutzt. An dieser Stelle ist eine weitgehend automatische Generierung des Codes erstrebenswert. Da Dialogbeschreibungen aber fast beliebig komplex werden k¨ onnen, wird h¨ aufig nur f¨ ur die einfachsten Zust¨ande Code automatisch generiert. F¨ ur komplexere Schritte kann ein semiautomatischer Ansatz oder sogar eine komplett manuelle Entwicklung n¨otig sein. Die Wahl der schlussendlich zur Codeerzeugung eingesetzten Methode h¨angt von der Leistungsf¨ ahigkeit des jeweiligen Werkzeugs und der Komplexit¨at der zu erstellenden Dialogbeschreibungen ab. Grunds¨ atzlich ist die Verwendung von Flussdiagrammen insbesondere f¨ ur industrielle Anwendungen im Telefoniebereich ein sehr g¨angiges Verfahren [Pieraccini und Huerta 2005]. Auch f¨ ur die Spezifikation von Sprachdialogen f¨ ur den automobilen Einsatz wird ein solches Verfahren eingesetzt [Hamerich et al. 2005]. In letzterem Fall werden die resultierenden Diagramme, welche je nach Funktionsumfang des entsprechenden Dialogs mehrere hundert Seiten umfassen k¨ onnen, allerdings nur als Grundlage f¨ ur die manuelle Implementation verwendet. Einige Schnittstellen werden automatisch generiert, der Großteil der Codeentwicklung erfolgt allerdings - vor allem bedingt durch die Komplexit¨ at - noch manuell. Im Anschluss werden einige existierende Werkzeuge zur Modellierung von Sprachdialogen, welche auf einer graphischen Repr¨asentation des Dialogflusses beruhen, vorgestellt. 6.1.1 CSLU-Toolkit Das CSLU-Toolkit des Center for Spoken Language Understanding der Oregon Health & Science University ist ein frei verf¨ ugbares Werkzeug, welches f¨ ur

6.1 Graphischer Ansatz

103

die Erstellung einfacher Informationsdialoge f¨ ur Telefonsysteme erstellt wurde ur Forschung und Lehre gedacht [McTear 1998].1 Das Toolkit ist vor allem f¨ und soll prim¨ ar von Anf¨ angern im Gebiet der Sprachdialogsysteme zur simplen und schnellen Erstellung von einfachen Telefondialogen genutzt werden. Bestandteile dieses Toolkits sind mehrere verschiedene Werkzeuge, unter anderem Werkzeuge zur Synchronisierung von Sprachausgaben mit animierten Avartaren, Betrachtung von Waveforms und der Rapid Application Developer (RAD), welcher hier im Vordergrund steht. Mit dem RAD k¨ onnen einfache Zustands¨ uberg¨ange erstellt werden. Der Benutzer kann mittels drag & drop verschiedene Zust¨ande in eine Abfolge bringen. Allerdings erlaubt die Darstellung keine Unterscheidung von Spracheinund -ausgaben. Wie aus Abbildung 6.1 ersichtlich ist, sind die erstellten Ab¨ laufdiagramme nur hilfreich, um einen groben Uberblick zu bekommen. Detaillierte Informationen u ¨ber verwendete Variablen, Prompts oder Grammatiken m¨ ussen von den Icons umst¨ andlich einzeln abgefragt werden.

Abbildung 6.1. Beispieldialog im RAD des CSLU-Toolkits

Grunds¨ atzlich eignet sich das CSLU-Toolkit f¨ ur Anf¨anger auf dem Gebiet der Sprachdialogsysteme, um erste Erfahrungen zu sammeln. Eine Erstellung gr¨ oßerer und komplexer Applikationen macht mit diesem Werkzeug jedoch keinen Sinn. Da außerdem der Fokus klar auf Telefonieapplikationen liegt, kann es f¨ ur die Dom¨ ane der Sprachbedienung nicht eingesetzt werden. Das Werkzeug widmet sich ausschließlich der untersten Ebene des Schichtenmodells, der softwaretechnischen Grundlage. Es bietet somit auch keine Zusammenf¨ uhrung der verschiedenen Ebenen an.

1

Dieses Toolkit kann im Internet unter http://www.cslu.ogi.edu/toolkit/ bezogen werden.

104

6 Teilautomatisierte Modellierung von Dialogen

6.1.2 REWARD-Projekt Im Rahmen des f¨ ur drei Jahre von der EU gef¨orderten Forschungsprojekts REWARD (Real World Application of Robust Dialogs) wurde ein Entwicklungswerkzeug f¨ ur die Erstellung von telefonbasierten Dialogen erstellt, welches auch von unge¨ ubten Benutzern verwendet werden konnte [Failenschmid und Thornton 1998]. Das resultierende Werkzeug wurde als Benutzerumgebung zur Dialogerstellung von systemgetriebenen Dialogen erstellt und detailliert bei [Brøndsted et al. 1998] vorgestellt. Neben der Wiederverwendbarkeit von Dialogelementen stand vor allem die graphische Modellierung von Grammatiken und Dialogfluss im Vordergrund. Mit einem Dialogflusseditor wurden Flussdiagramme gezeichnet, welche in einer Skriptsprache gespeichert wurden. Im Editor k¨ onnen in das Flussdiagramm verschiedene Aktionen, wie Wiedergabe von Prompts, Zugriff auf eine Datenbank, Evaluierung einer Benutzereingabe, etc. integriert werden. Die in der Skriptsprache gespeicherte Beschreibung kann kompiliert und anschließend an eine, auch im Rahmen des Projekts entwickelte, Ablaufumgebung weitergegeben werden, in welcher die erstellten Dialoge ausgef¨ uhrt werden k¨ onnen. Die Werkzeugentwicklung im Rahmen des REWARD-Projekts wurde am Ende als aufw¨ andig und teuer bezeichnet [K¨ olzer 2002]. Trotz des hohen Aufwands, sind die resultierenden Werkzeuge nicht f¨ ur komplexe Dialoge mit gemischter Initiative zu verwenden. Zudem ist auch dieses Werkzeug f¨ ur die Verwendung von telefonbasierten Dialogen entwickelt worden. Eine Verwendung f¨ ur Sprachbediensysteme scheidet daher aus. REWARD hat zwar die Dialog- und Signalebenen zusammen in einem Tool realisiert, aber eine echte Zusammenf¨ uhrung ist nicht gelungen. Eine Integration von linguistischen oder ergonomischen Aspekten der Dialogentwicklung ist nicht erfolgt. 6.1.3 DiaMod In [K¨ olzer 2002] wurde DiaMod vorgestellt, ein Tool zur Erstellung von Sprachdialogen basierend auf sogenannten Dialog-Statecharts. Die wesentli¨ che Motivation f¨ ur die Entwicklung von DiaMod war die Uberzeugung der Autorin, dass visuelle Beschreibungen f¨ ur unerfahrene Entwickler sehr viele Vorteile bieten. Die beschriebenen Dialog-Statecharts basieren auf den allgemeineren Statecharts, welche auf [Harel 1987] zur¨ uckgehen. Statecharts erlauben die Darstellung von Nebenl¨ aufigkeiten, u ¨bergeordneten Zust¨anden und Aktionen und werden u.a. f¨ ur die Modellierung dynamischer Aspekte in UML eingesetzt [Booch et al. 2005]. Bei Verwendung zur Beschreibung von Sprachdialogmodellen wurden die Statecharts bei [K¨ olzer 2002] als Dialog-Statecharts bezeichnet und gewisse Konventionen f¨ ur die Konzepte der Dialogmodellierung eingef¨ uhrt, um Statecharts zur Beschreibung von Dialogmodellen optimal einsetzen zu k¨onnen.

6.1 Graphischer Ansatz

105

Es war das Ziel der Entwicklung von DiaMod, mit einem universellen Werkzeug in verschiedenenen Dialogbeschreibungssprachen modellieren zu k¨ onnen. Wie bei [K¨ olzer 2002] beschrieben, ist das Konzept der DialogStatecharts m¨ achtig genug, um Dialogbeschreibungen in Speedis-Prolog (vgl. Abschnitt 5.1), GDML (vgl. Abschnitt 5.2.1) und VoiceXML (vgl. Abschnitt 5.2.2) abzudecken. Damit ist mit DiaMod die Beschreibung von komplexen Dialogen auch zur Sprachbedienung m¨ oglich. Allerdings erlaubt dieses Werkzeug lediglich eine graphische Codeentwicklung, welche bisher weder eine vollst¨andige noch eine f¨ ur die Zielplattformen optimale Codeerzeugung gestattet. Zudem erfordert auch der graphische Ansatz eine große Eingew¨ohnung. Letzteres bedeutet f¨ ur uninformierte Nutzer sicherlich nur einen kleinen Nachteil. Nur ist die Annahme, Sprachdialoge von uninformierten Entwicklern erstellen zu lassen, v¨ ollig falsch. Da das Design von Sprachdialogen eine sehr komplexe Angelegenheit ist (siehe Abschnitt 2.10), sollte die Erstellung von Sprachdialogsystemen m¨oglichst nicht uninformierten Personen, sondern speziell ausgebildeten Designern u ¨berlassen werden. Bei diesen kann davon ausgegangen werden, dass die Elemente einer Dialogbeschreibungssprache (hier: GDML) bekannt sind. Wichtiger als ein einfach zu nutzendes Werkzeug ist daher die Schnelligkeit der Entwicklung, die das Werkzeug erlaubt. Auch DiaMod bietet keine Unterst¨ utzung u ¨ber alle Ebenen des Schichtenmodells, sondern konzentriert sich auf die unterste Ebene der softwaretechnischen Umsetzung. Eine M¨ oglichkeit zur Bearbeitung oder Konsistenz¨ uberpr¨ ufung von Spracherkennungsgrammatiken ist in DiaMod leider nicht vorhanden. 6.1.4 GUIDE Die Firma Elektrobit Automotive2 entwickelte das Werkzeug GUIDE (GUI Designer). Das Werkzeug ist urspr¨ unglich ausschließlich f¨ ur die Spezifikation, Konzeption, Erstellung und Demonstration von graphischen Bedienelementen f¨ ur Automobile entwickelt worden. Neben diesen M¨oglichkeiten bietet GUIDE auch eine automatische Codegenerierung. [Goronzy und Beringer 2005] haben eine Erweiterung des Werkzeugs um die sprachliche Modalit¨ at pr¨ asentiert. Mit dieser kann zu jedem graphischen Zustand auch ein Dialogzustand im Sprachdialogsystem verkn¨ upft werden. Wie dargestellt wurde, basiert das gesamte Modell und auch der resultierten Code von GUIDE auf Zust¨ anden. Der Vorteil bei der Nutzung von GUIDE ist der, dass die Konsistenz zwischen den verschiedenen Modalit¨aten automatisch sichergestellt ist, da eine gemeinsame Datenbasis f¨ ur Sprachprompts und Texte verwendet wird. Des Weiteren kann mit GUIDE ein voll multimodales System simuliert werden. 2

Fr¨ uher als 3Soft bekannt.

106

6 Teilautomatisierte Modellierung von Dialogen

Wie außerdem bei [Goronzy et al. 2006] dargestellt wurde, erlaubt die Spracherweiterung von GUIDE auch die Unterscheidung unterschiedlicher Benutzertypen. Auch k¨ onnen mit dem Werkzeug Usability-Tests durchgef¨ uhrt werden. Das Werkzeug GUIDE ist ein industrielles Werkzeug, welches auch bei einigen Automobilherstellern zur Spezifikation und Simulation von graphischen Bedienphilosophien eingesetzt wird. Die Spracherweiterung bietet bisher nur eine Schnittstelle zu Standardspracherkennern, welche nicht u ¨ber die erweiterten M¨ oglichkeiten des StarRec DSR verf¨ ugen. Des Weiteren ist eine Entwicklung separater Sprachdialogzust¨ ande ohne korrespondierende GUI-Zust¨ande, wie sie beispielsweise bei der Verwendung von sprachlichen Shortcuts auftreten k¨ onnen, nicht m¨ oglich. Zus¨ atzlich ist unklar, ob die rein graphische ¨ Entwicklungsumgebung ausreicht, um kleinste Anderungen am Dialogablauf durchzuf¨ uhren. Auch GUIDE bietet keine Abdeckung der oberen Ebenen des Schichtenmodells. Eine Konsistenzpr¨ ufung von Grammatik und Dialog ist nicht bekannt, daf¨ ur bietet das Werkzeug eine automatische Konsistenzpr¨ ufung f¨ ur das Vokabular des Sprachdialogs und die verwendeten GUI-Texte. 6.1.5 VoiceObjects Die Firma VoiceObjects bietet seit mehreren Jahren ein gleichnamiges Werk¨ zeug als Entwicklungsumgebung zum Erstellen, Testen, Betreiben und Uber3 wachen von sprachgesteuerten Telefonanwendungen an. Wie in Abbildung 6.2 gesehen werden kann, wird auch hier der Dialogablauf graphisch zusammengestellt. Die Besonderheit bei VoiceObjects ist, dass als Basis zwar VoiceXML verwendet wird, jedoch von der Plattform w¨ ahrend der Laufzeit nur das jeweilig aktuelle Modul in VoiceXML generiert wird. Das gesamte Handling des Modulaufrufs und der interne Ablauf zwischen den einzelnen Modulen wird ohne VoiceXML in einer propriet¨ aren Laufzeitumgebung abgewickelt. Mit diesen Maßnahmen k¨ onnen die Nachteile von VoiceXML, wie sie in Abschnitt 5.2.3 dargestellt wurden, ausgeglichen werden. Somit erlaubt VoiceObjects ein sehr flexibles Dialogverhalten bei geringem Erstellungsaufwand. Die Bedienung der Software soll laut Eigenwerbung ohne technische Programmierkenntnisse m¨ oglich sein. Dies mag grunds¨atzlich sicher zutreffen, es erscheint jedoch fraglich, ob ohne Kenntnis des Variablenkonzepts wirklich eine solche Sprachapplikation sinnvoll und benutzerfreundlich erstellt werden kann. Die von VoiceObjects exportierte XML-Notation einer Anwendung ist jedenfalls ohne Programmierkenntnisse nur sehr schwer zu verstehen. Die Software bietet jedoch mit der automatisch erzeugten Dokumentation des Dialogablaufs und der M¨ oglichkeit, alle verwendeten Prompts automatisch in eine Excel-Datei zu exportieren, auch echten Mehrwert. 3

Eine Demoversion als Plugin f¨ ur Eclipse kann im Download Center bei www.voiceobjects.de heruntergeladen werden.

6.2 Textueller Ansatz

107

Abbildung 6.2. Beispieldialog in VoiceObjects

VoiceObjects selber ist allerdings komplett auf den Einsatz f¨ ur Telefonsysteme ausgelegt. Mit der Konzentration auf VoiceXML und der wirtschaftlich sicher profitablen Notwendigkeit, das Werkzeug auch als Laufzeitumgebung aktiv einsetzen zu m¨ ussen, ist dieses Werkzeug nicht f¨ ur den Einsatz im Automobil geeignet. Ob zudem die rein graphische Erstellung eines Dialogablaufs auch f¨ ur komplexe Automobilanwendungen sinnvoll ist, erscheint nach einem ersten Test zumindest zweifelhaft. Eine Abdeckung der oberen Ebenen des Schichtenmodells bietet auch VoiceObjects nicht. Auch eine Konsistenz¨ uberpr¨ ufung zwischen Spracherkennungsgrammatik und Sprachdialog wird nicht angeboten.

6.2 Textueller Ansatz Beim hier vorgestellten textuellen Ansatz geht es nicht um eine komplette manuelle Codeerstellung, sondern um eine werkzeugunterst¨ utzte semiautomatische Entwicklung, welche daf¨ ur sorgt, dass die Dialogmodellierung nur zum Teil von Hand erfolgt, wesentliche Teile werden aber mehr oder weniger automatisch modelliert. Dies sorgt zum einen f¨ ur eine erhebliche Beschleunigung der Codeentwicklung. Weiterhin erlaubt die systematische Nutzung dieses Ansatzes auch die Nutzung von Codebibliotheken, was auch wieder zur Beschleunigung der Codeentwicklung beitragen kann. Daneben erlaubt

108

6 Teilautomatisierte Modellierung von Dialogen

die Wiederverwendung von Codeteilen auch eine Minimierung des Test- und Spezifikationsaufwands. Bei allen im vorherigen Abschnitt vorgestellten Werkzeugen erfolgte die komplette graphische Modellierung von Hand, lediglich die Erstellung des dahinterliegenden Programmcodes wurde tlw. automatisiert. Beim textuellen semiautomatischen Ansatz dagegen wird direkt bei der Entwicklung der Applikation ein gewisses Maß an Automatisierung eingesetzt. Dabei kann hier auch auf eine graphische Repr¨ asentation der Dialogmodelle verzichtet werden. 6.2.1 GEMINI-Projekt Das f¨ ur zwei Jahre von 2002 bis 2004 gef¨ orderte EU-Projekt GEMINI (Generic Environment for Multilingual Interactive Natural Interfaces) zielte auf die Erstellung einer Plattform zur semiautomatischen Erstellung von Sprachdialogen zur Abfrage von Datenbanken ab [Hamerich et al. 2004a]. Die resultierende Plattform wurde Application Generation Platform (AGP) genannt und war in der Lage, semiautomatisch aus der Beschreibung einer Datenbank multilinguale und multimodale Sprachdialoge zur Abfrage zu erstellen [D’Haro et al. 2006]. Eingesetzt wurde die AGP zur Erstellung einer B¨ urgerabfrage mittels eines Lebenslagenkonzepts und einer Bankinganwendung [Hamerich et al. 2004b]. Als Basis der AGP wurde die Dialogbeschreibungs- und Modellierungssprache GDialogXML (vgl. Abschnitt 5.2.2) verwendet, die im Rahmen des GEMINI-Projekts entwickelt wurde. In dieser Sprache k¨onnen Dialogmodelle f¨ ur multiple Modalit¨ aten, sowie Datenbeschreibungen modelliert werden. Eine Besonderheit der Sprache ist, dass sie nicht zur manuellen Codeentwicklung konzipiert worden war, da bei der Entwicklung der Sprache prim¨ar eine m¨ oglichst einfache maschinelle Verarbeitung im Fokus stand. Aus diesem Grund verf¨ ugt GDialogXML auch nicht u ¨ber eine klare Syntaxbeschreibung wie beispielsweise C oder GDML , sondern wird komplett durch Objekte und ihre Beziehungen beschrieben [Schubert und Hamerich 2005]. Die Anwendungsentwicklung mit der AGP erfolgte in mehreren Schichten. In der ersten Schicht, dem Framework Layer, wurde die grundlegene Funktionalit¨ at der Anwendung beschrieben, indem die wesentlichen Ein- und Ausgabeparameter benannt und deren Reihenfolge festgeschrieben wurden. Daneben wurde das Datenmodell beschrieben, welches sich mit einem graphischen Editor recht einfach erstellen ließ. Zum Schluss wurden in allgemeiner Form die grundlegenden Aufrufe an die Datenbank (als API-Beschreibungen ohne jegliche Funktionalit¨ at) spezifiziert. Alle drei resultierenden Modelle griffen auf eine identische Datenbasis zu und erlaubten daher bereits in einem sehr fr¨ uhen Stadium der Anwendungsentwicklung eine Zusammenf¨ uhrung dieser unterschiedlichen Modelle. Auf Grundlage dieser ersten Modelle wurde schließlich aus der allgemeinen Anwendungsbeschreibung mittels Zuordnung der Datenbankaufrufe und der

6.3 Zusammenfassung

109

Datenmodelle ein erstes abstraktes – d.h. sprachen- und modalit¨atsunabh¨angiges – Dialogmodell. Im Mittelpunkt dieser Schicht, dem Retrievals Layer, stand die Verkn¨ upfung der bereits in der vorherigen Schicht definierten Datenbankabfragen mit den Ein- und Ausgabeparametern. Erst in der dritten und letzten Schicht, genannt Dialogues Layer, wurde der abstrakten Dialogbeschreibung entsprechende Erweiterungen f¨ ur die jeweilig ben¨ otigte Modalit¨ at und Zielsprache hinzugef¨ ugt. F¨ ur die Entwicklung von sprachunabh¨ angigen Dialoganwendungen stand GDML Pate, welches ebenfalls u ugt. ¨ber dieses Feature verf¨ Schlussendlich wurde von der AGP je nach ausgew¨ahlter Modalit¨at eine komplette Dialogbeschreibung in VoiceXML oder HTML generiert. Eine detaillierte Beschreibung der verschiedenen Schichten und ihrer jeweiligen Werkzeuge ist bei [Hamerich et al. 2004c] zu finden. Die Generierung von VoiceXML-Anwendungen durch die AGP war recht aufw¨ andig, da VoiceXML einer sehr strikten Syntax unterliegt, welche eine Umsetzung der sehr freien Syntax von GDialogXML nur sehr umst¨andlich erlaubte [Hamerich et al. 2003]. Doch am Ende gelang die Erzeugung von lauff¨ ahigen VoiceXML-Dialogen auf quelloffenen Umgebungen. Die Integration einer solchen Umgebung und die Anwendungsentwicklung daf¨ ur beschrieben [de C´ ordoba et al. 2004]. Das GEMINI-Projekt kam zu einem sehr erfolgreichen Abschluss: die mit der AGP generierte Bankinganwendung wurde sogar kommerziell von einer griechischen Bank eingesetzt. Wie beschrieben war auch dieses Projekt f¨ ur telefonische Dialoganwendungen konzipiert worden. Zudem war die gesamte AGP ausschließlich auf Dialoge zur Abfrage von Datenbanken ausgerichtet. Wie bereits in Kapitel 3 ausf¨ uhrlich dargestellt wurde, sind Sprachdialoge im Automobil nicht mit solchen Anwendungen zu vergleichen. Daf¨ ur sind einige grundlegende Ans¨ atze der Anwendungsentwicklung aus dem GEMINI-Projekt sehr interessant und sollen zum Teil als Ans¨ atze f¨ ur das im Rahmen des vorliegenden Werkes entwickelte Werkzeug dienen. Im GEMINI-Projekt ging es vor allem um die semiautomatische Erstellung einer Dialogbeschreibung. Unterst¨ utzung f¨ ur ergonomische oder linguistische Aspekte wurde dem Nutzer nicht gew¨ ahrt. Damit bleiben die oberen Ebenen des Schichtenmodells auch von der GEMINI AGP unber¨ uhrt. Die AGP verf¨ ugt u ¨ber ein eigenes Grammatikwerkzeug, das einige M¨oglichkeiten bietet [Georgila et al. 2004]. Ein Konsistenztest zwischen Grammatik und Dialog ist allerdings nicht verf¨ ugbar.

6.3 Zusammenfassung Keines der vorgestellten Werkzeuge bietet eine Abdeckung aller Ebenen des Schichtenmodells. Auch eine Zusammenf¨ uhrung von Spracherkennungsgrammatik und Dialog wird nur in Teilen geboten. Damit kann festgestellt werden, dass ein Werkzeug, welches die Methoden aller Ebenen des Schichtenmo-

110

6 Teilautomatisierte Modellierung von Dialogen

dells zur Erstellung benutzerfreundlicher, kommunikativ sinnvoller, konsistenter und korrekter Sprachdialoge f¨ ur den Einsatz im Automobil bisher nicht existiert. Die in diesem Kapitel vorgestellten Werkzeuge wurden alle f¨ ur die Dom¨ane der Telefonsysteme entwickelt. Zwar erlaubt DiaMod (vgl. Abschnitt 6.1.3) eine Codeentwicklung in VoiceXML und GDML, welches f¨ ur die Beschreibung von Sprachdialogen zur Sprachbedienung im Automobil eingesetzt wird, allerdings wird DiaMod den Erfordernissen der Automobilindustrie nur bedingt gerecht. Dies gilt vor allem, da kein optimierter Code erzeugt werden kann und auch keine komplette Abdeckung der Sprache GDML gegeben ist; zudem ist DiaMod f¨ ur Laien konzipiert worden, welche in der Realit¨at gar nicht f¨ ur die Entwicklung von Sprachbediensystemen im Automobil eingesetzt werden. Daher wird f¨ ur die Entwicklung von Sprachdialogen mit GDML ein entsprechendes Modellierungswerkzeug ben¨ otigt, welches den Nachteil der bereits beschriebenen zustandsbasierten Modellierung aufhebt und die Ebenen des Schichtenmodells s¨ amtlichst mit einbezieht. Das resultierende Werkzeug wird im n¨ achsten Kapitel vorgestellt. Aus diesem Kapitel werden insbesondere einige wesentliche Ideen der GEMINI-AGP u ¨bernommen. Des Weiteren wurde die Schlussfolgerung gezogen, dass eine graphische Repr¨ asentation von Dialogabl¨aufen zwar m¨oglich ist, f¨ ur die Erstellung von komplexen Dialogen allerdings entweder nicht aus¨ reicht oder aber nur auf Kosten der Ubersichtlichkeit oder Kontrolle geht. Da aber insbesondere bei Sprachbediensystemen die Kontrolle u ¨ber den Code und seinen Speicherbedarf extrem wichtig ist (vgl. Kapitel 3), kann dies nicht in Kauf genommen werden. Von daher wurde bei der Entwicklung eines eigenen Werkzeugs f¨ ur die Entwicklung von SDS im Automobil nicht auf eine graphische sondern auf eine textuelle Eingabeform gesetzt.

7 Das Entwicklungswerkzeug DiaGen

Wie bereits im vorherigen Kapitel festgestellt wurde, gibt es kein Werkzeug, welches alle Ebenen des Schichtenmodells in sich vereint. Daher wurde im Rahmen des vorliegenden Werkes ein eigenes Werkzeug konzipiert und entwickelt, welches nicht nur eine einfachere und schnellere Codierung erlaubt, sondern auch durch die Vermeidung von grunds¨ atzlichen Designfehlern auf der kommunikativen und sprachlichen Ebene eine Hilfestellung f¨ ur den Entwickler ist. Der Name DiaGen (sprich /daI2|Ãen/) f¨ ur das Werkzeug wurde in Anlehnung an ein gleichnamiges Werkzeug aus dem EU-Projekt GEMINI (vgl. Abschnitt 6.2.1) gew¨ ahlt. Auch dieses Werkzeug wurde vom Verfasser erstellt. Das GEMINI DiaGen war ein Quellcodeeditor f¨ ur die Entwicklung von Dialogmodellen mittels GDialogXML. Da die AGP mit all ihren einzelnen Assistenten von verschiedenen Konsortiumsmitgliedern entwickelt wurde, gab es erst sehr sp¨ at ein f¨ ur alle Projektpartner verf¨ ugbares Entwicklungswerkzeug. Um hier Abhilfe zu schaffen, wurde ein Quellcodeeditor f¨ ur GDialogXML gebaut. DiaGen stand damals f¨ ur Dialog Generator. Das im Rahmen des vorliegenden Werkes entwickelte DiaGen hat in vielerlei Hinsicht von den Erfahrungen aus dem GEMINI Projekt profitiert. Ferner wurden auch f¨ ur das Werkzeug selber viele Ideen vom GEMINI DiaGen u ¨ber¨ nommen. Da beide Werkzeuge schlussendlich eine Ahnlichkeit aufwiesen und zudem das GEMINI-Werkzeug ein rein internes Werkzeug blieb (das heißt in keiner Publikation erw¨ ahnt wurde), entschied sich der Verfasser, auch das GDML-Werkzeug DiaGen zu nennen. Mit vollem Namen m¨ usste es nat¨ urlich DiaGen2 genannt werden, der Zusatz 2 ist aber im Laufe der Arbeit mit dem GDML-Tool entfallen. Das in diesem Kapitel vorgestellte Werkzeug wurde erstmals bei [Hamerich 2008] pr¨ asentiert. In diesem Kapitel wird das Werkzeug noch detaillierter dargestellt. Dabei werden zuerst die Anforderungen an das System genannt, im Anschluss wird das Werkzeug in allen Einzelheiten vorgestellt, abschließend erfolgt die Funktionsbeschreibung in Form eines Benutzerprotokolls.

112

7 Das Entwicklungswerkzeug DiaGen

7.1 Anforderungen Hintergrund f¨ ur die Entwicklung eines eigenen Werkzeugs im Rahmen dieses Werkes ist die bereits mehrfach angesprochene Problematik der unterschiedlichen ben¨ otigten Methoden bei der Entwicklung eines automobilen Dialogsystems. Wie bereits in Abschnitt 2.4.5 begr¨ undet wurde, werden f¨ ur solche Systeme zustandsbasierte Dialogmodelle verwendet. Entsprechende Beschreibungssprachen wurden in Kapitel 5 vorgestellt. Der Nachteil der etwas aufw¨andigeren Codierung mit solchen Sprachen kann durch Einsatz eines entsprechenden Werkzeugs ausgeglichen werden. Die Anforderungen an dieses Werkzeug werden in den folgenden Abschnitte dargestellt. 7.1.1 Betriebssystem und Programmiersprache Die gesamte Dialogentwicklung von Harman/Becker findet ausnahmslos unter MS Windows statt. Daher macht es absolut Sinn, auch ein neues Dialogwerkzeug f¨ ur diese Plattform zu entwickeln. Da ein Großteil der verwendeten Werkzeuge in C oder C++ entwickelt wurden, gibt es f¨ ur diese Sprachen gen¨ ugend geschultes Personal, um sp¨atere Wartungs- oder Erweiterungsaufgaben durchzuf¨ uhren. Von daher soll auch DiaGen in diesen Sprachen geschrieben werden. 7.1.2 Zielgruppe DiaGen soll nicht f¨ ur Anf¨ anger im Dialogdesign konzipiert werden. Vielmehr soll es von Experten verwendet werden, welche die Grunds¨atze des Dialogdesigns kennen und bei ihrer Arbeit unterst¨ utzt werden sollen. Dabei geht es prim¨ ar um die Erleichterung der Dialogcodierung, um mehr Zeit und Konzentration auf die grundlegenden Schritte der allgemeinen Gestaltung der Mensch-Maschine-Schnittstelle, der sprachlichen Ebene und der grunds¨atzlichen Funktionalit¨ at verwenden zu k¨ onnen. Das bedeutet aber auch, dass eine umfassende Kenntnis der Dialogbeschreibungssprache GDML vorausgesetzt werden kann. Ebenso sollten die grundlegenden Prinzipien der Gestaltung von Sprachdialogen bekannt sein. Damit braucht f¨ ur die Entwicklung von DiaGen auch nicht auf umfangreiche Hilfefunktionalit¨ aten f¨ ur Anf¨ anger geachtet zu werden. Vielmehr kann gezielt ein Expertenmodus entwickelt werden. 7.1.3 Einsatzszenario DiaGen soll nicht als Spezifikationswerkzeug dienen, f¨ ur diesen Einsatz existieren bereits mehrere Werkzeuge. DiaGen soll vielmehr im Anschluss an die Spezifikationsphase bei der Umsetzung und Codierung einer Spezifikation

7.1 Anforderungen

113

verwendet werden. Dabei ist es wichtig, dass auch automatisch aus der Spezifikation erstellte Dialogteile einfach in die Arbeit mit DiaGen integriert werden k¨onnen. DiaGen muss dabei sowohl mit den f¨ ur den Produkteinsatz gedachten Anwendungen kompatibel sein, als auch alleine im Rahmen der Vorentwicklung nutzbar sein. Wichtig ist in beiden F¨ allen eine beschleunigte und effizientere Entwicklung von neuen Applikationen. 7.1.4 Dialogbeschreibung Wie bereits ausf¨ uhrlich dargestellt, ist GDML zur Beschreibung von Sprachdialogen aktuell ohne Alternative f¨ ur Harman/Becker. Daher soll GDML auch als Dialogbeschreibungssprache von DiaGen eingesetzt werden. 7.1.5 Dialogmodellierungsart Wie dargestellt wurde, k¨ onnen mit GDML sowohl zustandsbasierte als auch regelbasierte Dialoge modelliert werden. Da letztere allerdings momentan weder in der Produktentwicklung noch in der Vorentwicklung genutzt werden, muss zumindest die zustandsbasierte Dialogmodellierung mit DiaGen m¨oglich sein. 7.1.6 Editierbarer Dialogquellcode W¨ ahrend der Entwicklung eines Sprachbediensystems kann es auch noch in sehr sp¨ aten Phasen erforderlich sein, Details am Code ¨andern zu m¨ ussen. Ursachen daf¨ ur k¨ onnen sowohl Entwicklungs- oder Codierfehler sein, wie auch Schnittstellen¨ anderungen oder neue Kundenanforderungen. Um in solchen ¨ F¨allen auch tats¨ achlich Anderungen vornehmen zu k¨onnen, ist eine direkte Kontrolle des Quellcodes (in diesem Falle also des GDML-Codes) dringend erforderlich. Auch im GEMINI-Projekt (vgl. Abschnitt 6.2.1) wurde die Er¨ fahrung gemacht, dass in diesen F¨ allen eine manuelle Anderung des Ablaufcodes erforderlich sein kann. Allerdings wurde dabei auch festgestellt, dass es ¨ nahezu unm¨ oglich ist, Anderungen im Ablaufcode (in diesem Fall VoiceXML) auch in die Modellierungssprache (GDialogXML) zu u ¨bernehmen. Die Generierung einer Ablaufsprache aus einer Modellierungssprache ist bereits ein sehr aufw¨ andiger und komplexer Vorgang. Diesen Prozess aber auch r¨ uckw¨arts durchf¨ uhren zu k¨ onnen, ist mehr als die doppelte Arbeit, schließlich wird vom Entwickler erwartet, dass marginale Code¨anderungen auch nur in ent¨ sprechend kleinen Anderungen am Entwicklungsmodell resultieren. Dies ist allerdings ein betr¨ achtlicher Aufwand. Andererseits ist dieser Schritt dringend n¨ otig, da ansonsten die Gefahr besteht, dass abgelieferter Ablaufcode ¨ nicht konsistent mit den Entwicklungsmodellen ist. Bei sp¨ateren Anderungen uhrte w¨ are außerdem nicht sichergestellt, dass ehemals am Quellcode durchgef¨ ¨ Anderungen auch nach erneuter Quellcodegenerierung noch vorhanden w¨aren.

114

7 Das Entwicklungswerkzeug DiaGen

Um den Aufwand bei der Erstellung des Entwicklungswerkzeugs gering zu halten und trotzdem immer konsistenten Quellcode zu erm¨oglichen, ist eine zentrale Forderung an DiaGen gewesen, direkt mit GDML im Stile eines Quellcodeeditors umgehen zu k¨ onnen. Dies w¨ urde nebenbei auch den Schulungsaufwand f¨ ur weitere Benutzer reduzieren, da die Kenntnis von GDML f¨ ur die Entwicklung von Sprachdialogen f¨ ur jeden Dialogdesigner verpflichtend ist. 7.1.7 Beschleunigung der Dialogerstellung Wenn allerdings von einem neuen Werkzeug die Modellierung in der Zielsprache gefordert wird, m¨ ussen andere Unterst¨ utzungsformen f¨ ur Entwickler bereitgestellt werden, um die Erstellung von Dialogapplikationen zu beschleunigen. Insbesondere die Erstellung und Verwaltung von Variablen bietet sich in diesem Fall an. Da in GDML bedingt durch das Typsystem Deklarationen verpflichtend sind und dadurch (insbesondere im Vergleich zu VoiceXML) sehr viel Codierungsaufwand ben¨ otigt wird, sollte dieser Nachteil durch DiaGen ausger¨ aumt werden und eine einfachere und schnellere Programmierung erm¨ oglichen. Da zudem in GDML viele Abl¨aufe u ¨ber unterschiedliche Aufz¨ ahlungsvariablen geregelt werden, sollen auch diese einfacher zugreifbar und wartbar werden. 7.1.8 Schnelles Aufsetzen von neuen Projekten Um einen neuen GDML-Dialog aufzusetzen, wird neben dem Dialogcode selber ein passender Compiler f¨ ur den Dialogablauf (GDC), ein Compiler f¨ ur die zugrundeliegende Sprachgrammatik (GDS) und ein zu beiden Compilern kompatibler Spracherkenner (DSR) mit ebenfalls kompatiblem Laufzeitsystem (SSS) ben¨ otigt. Diese Werkzeuge sind bereits ausf¨ uhrlich in Abschnitt 5.2.1 dargestellt worden. Sehr wichtig ist, bei dieser Vielzahl von Werkzeugen allerdings, dass alle Komponenten immer miteinander kompatibel sein m¨ ussen. Wenn allerdings insbesondere f¨ ur eine spontane Demonstration oder einen Prototypen ein neuer Ansatz verwendet werden muss, ist der Aufbau eines komplett neuen Systems immer aufw¨ andig, da die gegenseitigen Abh¨angigkeiten beachtet werden m¨ ussen. Alternativ kann ein fertiges System als Grundlage verwendet werden, dieses muss jedoch erst umst¨andlich von Hand auf ein sinnvolles Minimum an Funktionalit¨ at reduziert werden. Aus diesen Gr¨ unden war es eine wesentliche Forderung an DiaGen, sehr schnell ein lauff¨ ahiges und kompatibles Minimalsystem zur Verf¨ ugung zu stellen, um neue Dialoge darauf aufbauend erstellen zu k¨onnen. 7.1.9 Unterst¨ utzung von Codebibliotheken Ein weiterer wichtiger Punkt ist die Verwendung von Codebibliotheken. Auch wenn Sprachbediensysteme f¨ ur jeden Hersteller individuell entwickelt werden,

7.1 Anforderungen

115

gibt es gewisse Funktionalit¨ aten, die allen Systemen gemein sind. Aus softwaretechnischer Sicht und auch aus Effizienzgr¨ unden w¨are es allerdings falsch, diese Codeteile immer wieder neu zu entwickeln. Daher werden diese Codeteile in Modulen verwaltet und sind in s¨ amtlichen Anwendungen vorhanden. Auch zuk¨ unftig mit DiaGen erstellte Anwendungen sollen nat¨ urlich einfach vorhandene Codebibliotheken integrieren k¨ onnen. Daher ist es eine wesentliche Anforderung an DiaGen, den Code grunds¨atzlich so modular wie m¨oglich zu verwalten und an m¨ oglichst vielen Stellen die Wiederverwendung von bereits entwickelten Modulen zu gestatten. 7.1.10 Einfachere Integration von neuen Schnittstellen Ein wichtiges Merkmal von GDML ist die Integration der Schnittstellen in den Dialogcode mittels Systemcalls. Aus Gr¨ unden einfacherer Wartung und Modularit¨ at werden die Definitionen der Systemcalls in separaten Dateien gehalten. Zum Zwecke der leichteren Eingrenzbarkeit von Fehlern oder zur Vereinfachung des Codes kann es allerdings vorkommen, dass die Schnittstellen im Dialog nicht exakt identisch verwendet werden, wie sie definiert wurden. Aus diesem Grunde werden in der Regel Wrapper verwendet. Das sind eigene Module, die quasi als H¨ ullenklasse den lokal verwendeten Aufruf von der globalen Definition kapseln. Diese Vorgehensweise macht aus Gr¨ unden der Wartbarkeit zwar Sinn, erfordert aber nat¨ urlich mehrfachen Aufwand bei der Erstellung, da nahezu identische Codeteile doppelt entwickelt werden m¨ ussen. Es ist daher eine Anforderung an DiaGen, diesen Aufwand weitestgehend zu minimieren. 7.1.11 Einbindung von Compiler und Ablaufumgebung Wie bereits in Abschnitt 5.2.1 dargestellt, existiert f¨ ur die Kompilierung und das Testen von GDML-Dialogen bereits eine Reihe von Werkzeugen. Wenn nun ein weiteres Werkzeug dazu kommt, muss dieses nat¨ urlich zu den anderen passen. Sehr vorteilhaft w¨ are es, wenn sogar eine einfache Interaktion zwischen den Werkzeugen m¨ oglich w¨ are. Daher ist es eine Anforderung an DiaGen, Kompiliervorg¨ ange direkt aus dem Werkzeug heraus starten zu k¨onnen, eine direkte R¨ uckmeldung u ¨ber den Kompiliervorgang zu erhalten und anschließend ebenfalls direkt aus DiaGen heraus den Dialog starten zu k¨onnen. 7.1.12 Konsistenz zwischen Grammatik und Dialog Ein h¨ aufig auftretendes Problem bei der Entwicklung von Sprachdialogen ist eine Inkonsistenz zwischen den im Dialog verwendeten Grammatikfeatures (Dialogsegmenten) und den in der Grammatik definierten Features (Dialogparametern). Wenn diese nicht identisch sind, k¨onnen undefinierte Dialogzust¨ ande auftreten oder andere Fehler passieren. Auch wenn solche Fehler

116

7 Das Entwicklungswerkzeug DiaGen

meist durch simple Tippfehler zu Stande kommen, werden sie nicht bei der syntaktischen Codepr¨ ufung oder beim Kompilieren entdeckt. Bestenfalls werden solche Fehler bei ausf¨ uhrlichen Dialogtests entdeckt. Daher handelt es sich bei dieser Fehlerklasse um klassische Designfehler, welche direkt die Kommunikation zwischen Anwender und System betreffen. Wenn die Dialogentwicklung durch ein Werkzeug unterst¨ utzt wird, sollen daher auch solche Fehler soweit als m¨ oglich vermieden werden. Damit w¨ urde DiaGen auch Fehler der oberen drei Ebenen des bereits in der Einleitung aufgef¨ uhrten Schichtenmodells abfangen. Es ist ein wesentliches Ziel dieses Werkes, die unterschiedlichen Methoden und Ans¨ atze der Dialog- und der Signalebene zusammenzuf¨ uhren. Mit einer entsprechenden Funktionalit¨ at zur Sicherstellung der Konsistenz zwischen Grammatik und Dialog wird daher diese Forderung zum einen erf¨ ullt und zum anderen ein wichtiges Unterscheidungsmerkmal zu anderen Systemen (vgl. Kapitel 6) gegeben. 7.1.13 Zukunftssicherheit Schlussendlich muss DiaGen zukunftssicher sein. Dies betrifft insbesondere den Einsatz neuer Codierrichtlinien, neuer Codekonstrukte, neuer Schnittstellen oder neuer weiterer Entwicklungswerkzeuge. All dies soll m¨oglichst einfach ge¨andert werden k¨ onnen, ohne wesentliche Teile von DiaGen anpassen oder gar neu implementieren zu m¨ ussen. 7.1.14 Softwarequalit¨ at Selbstverst¨ andlich gilt auch f¨ ur die Entwicklung von DiaGen, dass die Grundregeln guter Softwareentwicklung beachtet werden m¨ ussen. Das bedeutet im Einzelnen, dass der Quellcode gut strukturiert und dokumentiert sein sollte, sowie m¨ oglichst modular gehalten sein sollte, um zuk¨ unftige Erweiterungen m¨ oglichst einfach zu gestatten. Des Weiteren sollte das gesamte Werkzeug m¨ oglichst gut benutzbar im Sinne der Definition dieses Buches sein.

7.2 Entwicklung von DiaGen Wie bereits gesagt, gab es keine Wahl f¨ ur das Betriebssystem, DiaGen wird unter Windows eingesetzt und muss darunter laufen. Da aktuell keine weiteren Entwicklungsplattformen existieren, wird auch keine Kompatibilit¨at f¨ ur eine Zweitplattform ben¨ otigt. Die Wahl der Programmiersprache fiel auf C++. Dies ist die Standardentwicklungssprache f¨ ur Werkzeuge bei HBAS und es gibt einen großen Pool an Entwicklern f¨ ur die Sprache. Da es sich bei DiaGen allerdings um ein Werkzeug mit gr¨ oßtenteils graphischen Oberfl¨achen handelt, wird zus¨atzlich

7.3 Eigenschaften von DiaGen

117

auf den plattformunabh¨ angigen Klassenaufsatz von Trolltech Qt zur¨ uckgegriffen. Dies erlaubt eine komfortable und einfache Erstellung von graphischen Oberfl¨ achen. Zus¨ atzlich bietet Qt eine Reihe von sinnvollen weiteren Klassen an, welche insbesondere beim Parsing von XML-Dateien sehr vorteilhaft sind. DiaGen wurde daher vom Verfasser unter Windows XP mittels Visual Studio 6.0 und Qt 4.3 entwickelt.

7.3 Eigenschaften von DiaGen In diesem Abschnitt werden die Eigenschaften des fertigen Entwicklungswerkzeugs DiaGen vorgestellt. Dabei wird auf die oben formulierten Anforderungen Bezug genommen, um die Erf¨ ullung der Anforderungen zu dokumentieren. Da einige Anforderungen in mehrfacher Hinsicht erf¨ ullt werden, k¨onnen einige Anforderungen auch mehrfach referenziert werden. 7.3.1 Systemanforderungen DiaGen kann auf jedem System mit XP oder Vista laufen. Es werden lediglich einige frei verf¨ ugbare dynamische Bibliotheken (DLLs) von Qt ben¨otigt. Zus¨ atzlich wird f¨ ur die Nutzung des Funktionsumfangs von DiaGen eine funktionsf¨ ahige GDML Entwicklungsumgebung mit g¨ ultiger Lizenz ben¨otigt. 7.3.2 Wartung und Erweiterbarkeit Der Quellcode von DiaGen ist modular aufgebaut und gut dokumentiert. Eine Erweiterbarkeit der Funktionalit¨ aten ist einfach m¨oglich. 7.3.3 Nutzung Die Benutzeroberfl¨ ache von DiaGen ist an m¨ oglichst vielen Stellen mit Hinweisen (sogenannte tool tips) oder kleinen Hilfetexten versehen, um die Benutzung von DiaGen so einfach wie m¨ oglich zu machen. Ein Beispiel daf¨ ur ist in Abbildung 7.1 zu sehen. 7.3.4 Quellcodeeditor Bedingt durch die Forderung, dass in DiaGen der GDML-Code editierbar sein muss (vgl. Abschnitt 7.1.6), ist DiaGen als Quellcodeeditor ausgef¨ uhrt worden. Vor allem aus den Erfahrungen im Projekt GEMINI ist auf den Einsatz einer Modellierungssprache und anschließender Generierung der Zielsprache verzichtet worden. Eine Modellierungssprache h¨atte zwar eine klarere, bessere strukturierte und einfachere Modellierung erlaubt, die Generierung von GDML-Dialogen w¨ are allerdings aufw¨ andig gewesen. Da letztere allerdings

118

7 Das Entwicklungswerkzeug DiaGen

Abbildung 7.1. Tooltip bei der Projekterstellung mit DiaGen

auch noch in sp¨ ateren Entwicklungszeitpunkten editierbar sein m¨ ussen, muss die Generierung der Zielsprache auch umgekehrt in die Modellierungssprache erfolgen. Ansonsten w¨ aren Code¨ anderungen nicht in die Modellierung eingeflossen. Da der Aufwand f¨ ur eine solche L¨ osung jedoch sehr hoch ist, die angepeilte Zielgruppe allerdings GDML-Erfahrungen hat, wurde DiaGen komplett als Quellcodeeditor ausgef¨ uhrt. Dies bietet vor allem den Vorteil, dass s¨ amtliche Konstrukte von GDML auch ohne die Hilfe von DiaGen manuell eingesetzt werden k¨onnen. Selbst die nicht von DiaGen unterst¨ utzten regelbasierten Dialoge k¨onnen damit umgesetzt werden. ¨ Um allerdings die Ubersicht u ¨ber den Code zu erleichtern, bietet DiaGen neben der M¨ oglichkeit der Syntaxhervorhebung ein Fenster an, welches die Navigation innerhalb einer GDML-Datei erleichert. In Abbildung 7.2 ist dieses Fenster am linken Rand des Quellcodefensters zu erkennen. Die dort ausgew¨ ahlte Einheit ist im Quellcode markiert. Ebenfalls ist in der Abbildung die Syntaxhervorhebung gut zu erkennen. Auch der generelle Editor-Charakter der Anwendung ist zu sehen. Wird eine Aktion mit DiaGen ausgef¨ uhrt, wird automatisch zuerst die Wohlgeformtheit des Codes mittels des XML-Parsers von Qt gepr¨ uft. Etwaige Fehler werden sofort angezeigt und die weitere Ausf¨ uhrung der Aktion abgebrochen. Durch diese erste automatische Syntaxpr¨ ufung ist DiaGen mehr als ein simpler Codeeditor. In DiaGen wurde bewusst auf eine graphische Darstellung des Dialogablaufs verzichtet. F¨ ur kleinere Dialoge ist eine visuelle Repr¨asentation zwar

7.3 Eigenschaften von DiaGen

119

Abbildung 7.2. DiaGen mit Navigationsfenster

sehr hilfreich, bei den f¨ ur die Produktentwicklung u ¨blichen Umf¨angen w¨are diese Repr¨ asentation allerdings unlesbar. Mit der in der Produktentwicklung verwendeten graphischen Spezifikation ist außerdem die Erfahrung gemacht worden, dass die erforderliche Granularit¨ at in einer graphischen Repr¨asentation u ¨ber eine komplette Anwendung nicht darstellbar ist. Von daher ist DiaGen bewusst als Quellcodeeditor angelegt worden, der in ¨ mehrfacher Hinsicht die Navigation erleichtert. Wenn ein allgemeiner Uberblick u otigt wird, kann das graphische Spezifi¨ber eine Dialoganwendung ben¨ kationsformat verwendet werden. 7.3.5 Kontextmen¨ u DiaGen erlaubt auch eine Beschleunigung der Dialogerstellung. Dabei ist ein wesentliches Merkmal des Werkzeugs sein Kontextmen¨ u. Neben den u ¨blichen Aktionen wie Kopieren und Einf¨ ugen bietet das Men¨ u in Abh¨angigkeit des gerade aktuellen Kontexts unterschiedliche Codeelemente an, die syntaktisch korrekt an der aktuellen Cursorposition eingef¨ ugt werden k¨onnen. Damit entf¨ allt l¨ astige Tipparbeit. Insbesondere bei XML-Dialekten mit den vielf¨altigen spitzen Klammern ist dies sehr wichtig. Auf Abbildung 7.3 ist das Kontextmen¨ u innerhalb eines <step> Elements abgebildet. Zu erkennen sind die M¨ oglichkeiten, an der aktuellen Position einen Dialog oder eine Funktion zu referenzieren, einen Prompt aufzurufen, auf einen weiteren Dialogschritt zu verweisen, auf ein Event zu warten, eine Verzweigung zu erstellen, eine Aufz¨ ahlungsvariable zuzuweisen, eine Verzweigung

120

7 Das Entwicklungswerkzeug DiaGen

Abbildung 7.3. Kontextmen¨ u von DiaGen innerhalb eines GDML <step>

basierend auf einem Grammatik-Feature zu erstellen oder eine neue Variable hinzuzuf¨ ugen. Bei der Auswahl eines der genannten Punkte wird der Anwender anschließend gebeten, f¨ ur ein neu zu erstellendes Element einen Namen einzugeben bzw. f¨ ur den Aufruf einen Namen aus einer Liste auszuw¨ahlen. Anschließend wird das entsprechende Codeelement syntaktisch korrekt an der gew¨ ahlten Position dem Quellcode hinzugef¨ ugt. Bei jeder Option ist immer sichergestellt, dass der gesamte Dialog immer lauff¨ahig bleibt und der XMLCode immer wohlgeformt ist. Das heißt, wird ein neues GDML-Element eingef¨ ugt, wird automatisch ein passendes schließendes Element hinzugef¨ ugt. 7.3.6 Projektbearbeitung Eine typische GDML-Anwendung besteht u ¨blicherweise aus mehreren einzelnen Dateien, wobei bis zu f¨ unfzig oder mehr Dateien zusammenkommen k¨onnen. Diese zu einer Anwendung geh¨ orenden Dateien k¨onnen in DiaGen als ein Projekt zusammen gespeichert werden. Dabei werden nicht nur die GDML Dateien erfasst, sondern auch die Grammatik, Compilereinstellungen und die Startskripte. Zus¨ atzlich erlaubt die Projektspeicherung auch die globale Verwaltung von Variablennamen und -werten. Damit ist dies eine wesentliche Voraussetzung f¨ ur die M¨ oglichkeiten des oben beschriebenen Kontextmen¨ us. Neben der Speicherung von mehreren Dateien in einem Projekt ist es mit DiaGen auch ohne weiteres m¨ oglich, existierende GDML-Dateien in ein vorhandenes Projekt zu integrieren. Damit k¨ onnen Codebibliotheken effizient und einfach genutzt werden. Dies beschleunigt nicht nur die Erstellung von neuen Anwendungen, sondern erlaubt auch die einfache Wiederverwendung von Modulen.

7.3 Eigenschaften von DiaGen

121

Um auch den Start mit einer neuen GDML Anwendung zu vereinfachen, bietet DiaGen die M¨ oglichkeit, mit einem kleinen Beispielprojekt zu starten. Dabei m¨ ussen nur die wesentlichen Informationen u ¨ber Compilerorte, Sprache und Projektname eingegeben werden, wie auf Abbildung 7.4 zu sehen ist. Das Resultat ist ein neues lauff¨ ahiges Projekt mit einem kleinen Ja/NeinDialog. Dieses kann dann als Startpunkt f¨ ur ein neues Projekt verwendet werden. Eine wichtige Basis dieses Beispielprojekts ist dabei die Nutzung des auch bei Produktdialogen verwendeten Dialogframeworks, welches quasi die Basisklassen in einer Dialogimplementation mit GDML darstellt.

Abbildung 7.4. Erstellung eines neuen Projekts mit DiaGen

Fast alle im gezeigten Dialogfenster abgefragten Namen k¨onnen sogar in der Registrierung gespeichert werden, einzig der Name des neuen Projekts muss vom Anwender jedes mal neu eingegeben werden. Damit kann nicht nur der Start eines neuen Projekts schnell erfolgen, die Nutzung der Daten aus der Systemregistrierung gestattet auch eine noch schnellere und einfachere Vorgehensweise mit jeder weiteren Benutzung von DiaGen. Die Verwendung einer Beispielapplikation als Startpunkt einer DiaGenEntwicklung entspricht nicht dem Vorgehen der GEMINI-AGP. Dort wurde nach der Definition des verwendeten Datenmodells ein erster grober Dialogablauf skizziert, der im Anschluss weiter ausgef¨ uhrt wurde. Allerdings basierte dieser Ablauf auf dem vorher definierten Datenmodell, schließlich war GE-

122

7 Das Entwicklungswerkzeug DiaGen

MINI f¨ ur Dialoge zur Datenabfrage konzipiert. Da es bei Sprachbediensystemen nicht um die Abfrage von Daten, sondern die Steuerung von Ger¨aten geht und zudem eine eigene Modellierungssprache nicht f¨ ur DiaGen verwendet wurde, w¨ are eine grobe Dialogbeschreibung nur in der Spezifikationsphase m¨ oglich. Diese soll jedoch explizit kein Einsatzszenario von DiaGen darstellen. Aus diesem Grund macht der Start mittels einer funktionierenden Beispielapplikation Sinn. Dies trifft umso mehr zu, als die grunds¨atzliche Struktur aller SBS immer sehr ¨ ahnlich ist. Dadurch und durch die Verwendung des Dialogframeworks innerhalb von DiaGen enth¨ alt jede mit DiaGen erstellte Anwendung die grundlegenden wichtigen Codeteile, die auch in einer Produktanwendung ben¨ otigt werden. Dies ist damit ein Baustein f¨ ur die Sicherstellung der Entwickklung von kommunikativ sinnvollen Dialogen mit DiaGen. 7.3.7 Schnittstellenerweiterung Mittels des Projektimports ist es kein Problem, auch neue Schnittstellendefinitionen (also Definitionen von Systemcalls) zu einem Projekt hinzuzuf¨ ugen. Zus¨ atzlich bietet DiaGen allerdings auch die M¨oglichkeit, automatisiert eine H¨ ullenklasse um eine solche Definition herum zu erstellen. Ausgehend von diesem automatisiert erstellten Kapselungsmodul k¨onnen dann dialogspezifische ¨ Anpassungen oder Anderungen durchgef¨ uhrt werden. Diese Funktionalit¨at erspart viel manuelle Codierungsarbeit und r¨ aumt potentielle Fehlerf¨alle aus. 7.3.8 Dialoge kompilieren und testen Mittels der Projektdefinition sind DiaGen bereits die Pfade zu den Compilern bekannt. Zus¨ atzlich werden f¨ ur jedes Projekt auch die korrekten Einstellungen f¨ ur die Compiler gespeichert. Zus¨ atzlich sind die Compileraufrufe komplett in DiaGen integriert. Da die entsprechenden Programme jedoch lediglich referenziert werden, ist auch ein einfacher Austausch (z.B. durch neuere Versionen) der Compiler ohne Probleme m¨ oglich. Wie bereits dargestellt, u uft DiaGen selbst den Dialogcode auf eine ¨berpr¨ korrekte XML-Notation. Weitere Fehler, die beim Kompilieren auftreten, k¨onnen direkt im Kompilierungsfenster selektiert werden. Die Codeansicht wird in diesem Fall automatisch die betreffende Datei und Zeile ¨offnen und selektieren, wie in Abbildung 7.5 dargestellt. Zus¨ atzlich kann auch jedes mit DiaGen erstellte oder geladene Projekt direkt vom Werkzeug aus gestartet werden. Die erforderlichen Einstellungen und Pfade sind ebenfalls bereits in der Projektbeschreibung gespeichert. Damit bietet DiaGen die komplette Unterst¨ utzung einer integrierten Entwicklungsumgebung an. Es erlaubt sowohl die Editierung des Programmcodes, bietet Unterst¨ utzung bei der Codeerstellung, erlaubt die direkte Ausf¨ uhrung der Kompilierung und bietet ebenfalls die M¨ oglichkeit, fertige Applikationen direkt auszuf¨ uhren.

7.3 Eigenschaften von DiaGen

123

Abbildung 7.5. Fehlgeschlagene Kompilierung mit selektierter Fehlerstelle

7.3.9 Konsistenz zwischen Grammatik und Dialog Um angemessen auf Spracheingaben des Benutzers reagieren zu k¨onnen, muss im Dialog auf die von der Spracherkennung gelieferten Werte eine korrekte Reaktion erfolgen. Wie bereits in Abschnitt 5.3.2 dargestellt, kommt es dabei auf die Werte der entsprechenden Tags in der Grammatik an. Wenn diese allerdings im Sprachdialog nicht korrekt referenziert werden, liegt ein Designfehler vor, da in diesem Fall auf eine erlaubte und korrekte Eingabe keine korrekte Systemreaktion erfolgt. Wie bereits oben beschrieben, sind diese Fehler nicht einfach auf syntaktischer Ebene auszuschließen. Aus diesem Grund war es eine wichtige Anforderung an DiaGen, hier eine automatische Konsistenz sicherzustellen. Um dies zu gew¨ ahrleisten, bietet DiaGen auch eine Grammatikansicht an, wie sie in Abbildung 7.6 zu sehen ist. In dieser Ansicht werden die ¨ offentlichen (also direkt vom Dialog aus aufrufbaren) Grammatikregeln oben angezeigt. Darunter werden die jeweiligen Subregeln angezeigt. Im dritten Fenster werden alle in der markierten Regel enthaltenen Grammatik-Tags (oder Features) aufgelistet. Wird eines davon markiert, werden in der vierten Liste alle m¨ oglichen Werte f¨ ur das entsprechende Tag dargestellt. Da in der ersten Liste auch mehrere Regeln markiert werden k¨ onnen, kann so mit einem Blick die komplette Liste aller m¨oglichen Features und ihrer Werte erfasst werden. Wird nun im Kontextmen¨ u der entsprechende Eintrag f¨ ur eine Verzweigung basierend auf einem Grammatik-Feature ausgew¨ahlt (oder alternativ der entsprechende Eintrag in der Featureliste doppelt angeklickt), wird der An-

124

7 Das Entwicklungswerkzeug DiaGen

Abbildung 7.6. Grammatikfenster von DiaGen

wender nach einer Variablen gefragt, welche die entsprechenden Werte von der Erkennung zugewiesen bekommen hat. Anschließend wird automatisch an der aktiven Cursorposition die Verzweigung mit allen m¨oglichen Alternativen eingef¨ ugt. Auf diese Weise muss der Anwender nicht die einzelnen Werte aus der Grammatik kopieren oder abtippen, er kann sich voll auf die Funktionalit¨at des Dialogs konzentrieren und die Dialogkommunikation entsprechend der gew¨ unschten Alternative sicherstellen. In Abbildung 7.7 ist das entsprechende Resultat f¨ ur die Grammatik aus Abbildung 7.6 dargestellt. Wie zu erkennen ist, sind f¨ ur einzelne Alternativen ausschließlich Kommentare aufgef¨ uhrt. Die korrekte Zuordnung zu weiteren Aktionen muss der Anwender von Hand erledigen. Selbstverst¨ andlich k¨onnte auf der Basis von bekannten Ausdr¨ ucken bereits eine fest zugeordnete Aktion verkn¨ upft werden. Allerdings wurde in diesem Fall mehr auf die Zukunftssicherheit von DiaGen geachtet. Denn je mehr Aktionen in DiaGen fest verankert werden, desto schwerer kann DiaGen erweitert werden. Aus diesem Grund geht DiaGen in s¨amtlichen Aktionen nur von GDML-Codeelementen aus, eine Wertpr¨ ufung wird grunds¨ atzlich nicht durchgef¨ uhrt. Ebenfalls aus Gr¨ unden der Zukunftssicherheit und Erweiterbarkeit wird bei der automatischen Erstellung einer Verzweigung aufgrund von Erkenn-

7.3 Eigenschaften von DiaGen

125

Abbildung 7.7. Automatisch eingef¨ ugte Verzweigung f¨ ur ein Grammatik-Tag

ergebnissen ein Default verwendet. Dieser ist zwar im Augenblick der Generierung u ussig und redundant, da die Aufz¨ahlung der Alternativen ¨berfl¨ vollst¨ andig ist, jedoch bei einer sp¨ ateren Erweiterung der Grammatik w¨are der Sprachdialog korrekt, ohne dass letzterer nochmal angepasst werden m¨ usste. Mit dieser Funktionalit¨ at ist daher eine Zusammenf¨ uhrung der Spracherkennungs- und der Dialogebene in einem Dialogentwicklungswerkzeug gelungen. Dies ist umso wichtiger, als eine entsprechende Funktionalit¨at bisher in keinem bekannten Werkzeug existiert. Damit stellt diese Funktionalit¨at eine echte Innovation dar. 7.3.10 Erstellung benutzerfreundlicher Dialoge Basierend auf den Erkenntnissen aus Kapitel 4 unterst¨ utzt DiaGen den Entwickler bewusst bei der Erstellung benutzerfreundlicher Dialoge. Dies geschieht zum einen durch die bereits vorgenannten Eigenschaften, welche die M¨oglichkeit von internen Dialogfehlern (wie in Abschnitt 4.2 beschrieben) minimieren. Daneben gibt es in DiaGen explizite Warnungen, wenn ein Entwickler gegen Prinzipien von benutzerfreundlchen Dialogen, wie zum Beispiel die in Abschnitt 4.5.4 dargestellten Prinzipien zur Ergebnislisten, verstoßen will. Dies geschieht zum Beispiel, wenn Variablenlisten als Parameter an einen Sprachprompt u ¨bergeben werden und zus¨atzlich noch weitere Parameter gew¨ unscht sind. In diesem Fall wird der Entwickler explizit gewarnt, den Benutzer nicht zu sehr abzulenken. Die Warnung ist in Abbildung 7.8 dargestellt. Die Warnung kann allerdings ignoriert werden, damit verhindert DiaGen keine Entwicklungsvarianten, sondern warnt lediglich vor ung¨ unstigen Designs.

126

7 Das Entwicklungswerkzeug DiaGen

¨ Abbildung 7.8. Warnung bei der Ubergabe von Listen als Promptparameter

Eine weitere Warnung gibt DiaGen aus, wenn mehr als vier Variablen als Promptparameter definiert werden. Die entsprechende Warnung kann Abbildung 7.9 entnommen werden. Die Codestruktur von DiaGen erlaubt eine einfache Erg¨ anzung dieser Warnungen, um zuk¨ unftig beispielsweise einen Entwickler vor zu langen Hilfetexten oder anderen m¨oglichen Problemstellen zu warnen.

¨ Abbildung 7.9. Warnung bei der Ubergabe von mehr als vier Promptparametern

Zu guter Letzt ist in die Projekte von DiaGen eine qualitativ sehr gute Sprachsynthese f¨ ur verschiedene Sprachen integriert, welche auch in gleicher Qualit¨ at bereits erfolgreich in Sprachbediensystemen am Markt enthalten ist. Mit diesen Punkten hat DiaGen unter Beweis gestellt, dass es mehr ist, als ein einfacher Quellcodeeditor. Vielmehr stellt es auch eine Unterst¨ utzung f¨ ur die Entwicklung benutzerfreundlicher Dialoge dar.

7.4 Evaluation von DiaGen DiaGen ist ein Werkzeug f¨ ur Dialogentwickler, welche Sprachdialoge f¨ ur den automobilen Einsatz in GDML entwickeln und u ¨ber die Grunds¨atze des Dialogdesigns informiert sind. F¨ ur diese Klientel bietet DiaGen eine neue Qualit¨at und ein neues Tempo der Dialogentwicklung. Da f¨ ur eine korrekte Evaluation allerdings keine entsprechend informierte, aber trotzdem unvorbereitete Kontrollgruppe zur Verf¨ ugung stand, erfolgte

7.5 Zusammenfassung

127

keine Evaluation des Werkzeugs. Stattdessen wird in Anhang A ein Benutzerprotokoll vorgestellt. Des Weiteren wird in Kapitel 8 ein mit DiaGen erzeugtes Dialogsystem vorgestellt und dessen Evaluation beschrieben. Mit dieser Evaluation kann somit auch indirekt die Leistungsf¨ahigkeit von DiaGen unter Beweis gestellt werden. Wie bei der Erstellung von Entwicklungswerkzeugen u ¨blich, ist das Werkzeug im Rahmen der Benutzung (zur Erzeugung des erw¨ahnten Dialogsystems) nach und nach verbessert und erweitert worden. Das angesprochene Benutzerprotkoll und auch die in diesem Abschnitt beschriebenen Funktionen beruhen aber selbstverst¨ andlich auf der aktuellsten Version von DiaGen.

7.5 Zusammenfassung In diesem Kapitel wurde das Entwicklungswerkzeug DiaGen vorgestellt. Das System wurde entwickelt, um zu zeigen, dass es m¨oglich ist, die Methoden der unterschiedlichen Disziplinen aus dem Schichtenmodell in einem Werkzeug zusammenzuf¨ uhren. Ebenso konnte gezeigt werden, dass es m¨oglich ist, automatisiert die Konsistenz von speech und language in einem Dialog sicherzustellen. Des Weiteren bietet das Werkzeug auch konkrete Unterst¨ utzung bei der Erstellung von Sprachdialogen f¨ ur die Dom¨ ane der Sprachsteuerung im Automobil. Wie gezeigt wurde, besteht diese Unterst¨ utzung nicht nur aus einer reinen Programmierhilfe, da auch Designfehler verhindert werden k¨onnen, die sich nicht auf die reine Codierungsarbeit beziehen. Die am Anfang dieses Kapitels erw¨ ahnten Anforderungen werden von der endg¨ ultigen Version des Werkzeugs DiaGen voll erf¨ ullt. Damit ist mit DiaGen ein sinnvolles, funktionsf¨ahiges, zukunftssicheres und gut zu bedienendes Werkzeug erstellt worden, welches auf Produktstandards bei der Erstellung von Sprachdialogen in der Automobildom¨ane basiert und dort ohne Einschr¨ ankungen eingesetzt werden kann.

8 Proaktiver TMC-Dialog

In diesem Kapitel wird der mit Hilfe des Werkzeugs DiaGen erstellte proaktive TMC-Dialog vorgestellt. Da diese Art von Dialogen bisher nicht im Produkt zu finden ist, wird nach der Erkl¨ arung der technischen Grundlagen der Stand der Technik aus aktuellen Kraftfahrzeugen behandelt. Anschließend werden die grundlegenden Ideen f¨ ur den neuen Dialogansatz vorgestellt. Danach werden die f¨ ur die Erstellung und Simulation notwendigen zus¨atzlichen Komponenten illustriert. Dann wird die Vorgehensweise zur Erstellung des Dialogs mittels DiaGen behandelt. Im Anschluss wird die Grundlage f¨ ur die Evaluation dieser Dialoge gelegt, um danach die durchgef¨ uhrte Evaluation mit ihren Ergebnissen zu beschreiben.

8.1 Grundlagen In diesem Abschnitt wird der Begriff des proaktiven Dialogs eingef¨ uhrt und definiert. Des Weiteren wird erkl¨ art, was die Abk¨ urzung TMC bedeutet. 8.1.1 Proaktiver Dialog Wie bereits in Abschnitt 3.4.1 dargestellt wurde, erfolgt der Start eines SBS mit der Bet¨ atigung des PTT-Knopfes. Dies ist u ¨blicherweise das Signal an den Dialogmanager, eine Systemausgabe zu versenden und den Spracherkenner mit der aktuell zum Kontext passenden Grammatik zu initialisieren. Wird ein Dialog allerdings nicht aktiv vom Benutzer gestartet, sondern von einem anderen internen Ereignis, heißt der Dialog proaktiv. In der Literatur ist der Begriff proaktiver Dialog bereits etwas anders belegt. So definieren [Baudoin et al. 2005] einen proaktiven Dialog mit einem Dialogagenten als eine kommunikative Aktion, die zu einem Nachfolger des ” vom Benutzer antizipierten Zustandes f¨ uhrt“. Das bedeutet, der Dialogagent antizipiert die Benutzeraktionen auf der Basis der vorangegangenen Aktionen. Wenn also der Benutzer in einer Situation eine Wahl zwischen mehreren

130

8 Proaktiver TMC-Dialog

Alternativen hat, kann das System basierend auf dem Benutzermodell eine M¨ oglichkeit vorschlagen. Im Kontext von Dialogsystemen wird ein solches System als adaptiv bezeichnet. Wichtig f¨ ur dieses Buch festzustellen ist, dass in dem beschriebenen Fall eine Reaktion des Systems erwartet wird und dies sogar vom Benutzer initiiert wird. Das heißt diese Definition von Baudoin ist kontr¨ ar zu der diesem Werk. Auf der anderen Seite sprechen [Minker et al. 2006] und [Strauß 2006] von Proaktivit¨ at als der F¨ ahigkeit eines Dialogsystems zu einem Gespr¨ach von mehreren menschlichen Partnern beizutragen, ohne explizit angesprochen zu sein. Das bedeutet, in diesem Fall steht proaktives Verhalten f¨ ur die F¨ahigkeit eines Dialogsystems, die Initiative in einem Gespr¨ach automatisch zu u ¨bernehmen. Abh¨ angig vom Kontext kann dies erwartet oder unerwartet sein. Da die Begrifflichkeit eines proaktiven Dialogs daher unklar ist, erfolgt eine konkrete Definition f¨ ur diesen Begriff: Definition 8.1. Ein Dialog mit einem Dialogsystem heißt proaktiv, wenn er ohne Handlung oder Anweisung des Benutzers automatisch gestartet wird. Ein typisches Beispiel f¨ ur einen proaktiven Dialog im Automobil ist ein ankommender Anruf auf das dem System bekannte Mobiltelefon. In diesem Fall kann das System dem Benutzer mitteilen Sandra ruft an. M¨ochten Sie ” das Gespr¨ ach annehmen?“. Der Name des Anrufers ist dabei nat¨ urlich nur bekannt, wenn er auch auf dem Telefon angezeigt wird. Der proaktive Dialog spart in diesem Moment Zeit f¨ ur den Benutzer – die umst¨andliche Suche nach dem Telefon zur direkten haptischen Gespr¨achsannahme entf¨allt – da ein einfaches Ja“ reicht, um das Telefonat entgegenzunehmen. ” 8.1.2 TMC Der TMC (Traffic Message Channel) ist ein digitaler Radiodienst, der u ¨ber RDS ausgestrahlt wird und in den meisten europ¨aischen L¨andern und auch den USA verf¨ ugbar ist.1 TMC-Nachrichten werden von einem Radiosender2 verschickt, sowie eine von Polizei oder Verkehrssteuerungsanlagen gemeldete Verkehrsbeeintr¨ achtigung vorliegt, dabei wird pro Meldung eine separate TMC-Nachricht versandt. Prinzipiell soll eine TMC-Meldung unmittelbar 1 2

Details sind unter http://www.tmcforum.com zu finden. In Deutschland werden TMC-Meldungen von fast jedem Sender der ARD, sowie vom Deutschlandfunk ausgestrahlt. Es gibt auch verschiedene private Sender, welche TMC-Meldungen f¨ ur ihren jeweiligen Sendebereich ausstrahlen. Neben dem kostenlosen TMC existiert auch noch die kostenpflichtige Variante TMCpro, welche ausschließlich von privaten Radiosendern ausgestrahlt wird. Bei TMCpro werden die Daten automatisch von Datensensoren an Autobahnbr¨ ucken oder in die Fahrbahn integrierten Sensorschleifen gesammelt und von einer TelekomTochter aufbereitet. Mehr zu den Unterschieden von TMC und TMCpro kann bei [R¨ obke-Doerr 2006] gefunden werden.

8.2 Stand der Technik

131

nach Eintreffen in der Verkehrszentrale eines Radiosenders ausgestrahlt werden. Damit sollen Autofahrer nahezu in Echtzeit u ¨ber Verkehrsbehinderungen informiert werden. Die Daten einer solchen Meldung werden von einem TMC-f¨ahigen Radioger¨ at unh¨ orbar empfangen und an ein Navigationsger¨at weitergeleitet. Dieses kann auf Grund der aktuellen Routenplanung und den Informationen aus der TMC-Nachricht automatisch eine neue Route berechnen und damit die Behinderung umgehen. Dieses Prinzip wird als dynamische Zielf¨ uhrung bezeichnet. Eine TMC-Meldung besteht aus einem Ereigniscode, einem Ortscode, einer zeitlichen Beschr¨ ankung und einem Umfahrungshinweis. Dabei sind alle Bestandteile der Meldung in einem sprachunabh¨ angigen Bin¨arformat codiert. Die ¨ Ubersetzung in nat¨ urliche Sprache nimmt das jeweilig ausgebende Endger¨at, im Normalfall das Navigationsger¨ at, vor. Der Ereigniscode ist international g¨ ultig und sieht u ¨ber 1000 unterschiedliche Ereignisse vor (u.a. stockender Verkehr, Staus in verschiedenen L¨ angen, Unfall, Baustelle, Nebel etc.). Der Ortscode ist zwar auch sprachunabh¨ angig, wird aber spezifisch f¨ ur jedes Land in der Location Code List (LCL) festgehalten. In der LCL sind s¨amtliche Namen von wichtigen Punkten im Bundesfernstraßennetz (dies sind vor allem die Ausfahrten der Autobahnen) codiert, die f¨ ur die TMC-Meldungen genutzt werden sollen. Da das Straßennetz laufend w¨ achst und sich auch die Verkehrsstr¨ ome ver¨ andern, wird auch die LCL laufend aktualisiert. In Deutschland wird die LCL von der Bundesanstalt f¨ ur Straßenwesen (BASt) erstellt. In der aktuellen Version f¨ ur Deutschland sind u ¨ber 32.000 Eintr¨age im LCL enthalten. [BASt 2005]

8.2 Stand der Technik In heute erh¨ altlichen Automobilen wird bei aktivierter Zielf¨ uhrung eine automatische Neuberechnung der Route durchgef¨ uhrt, wenn eine entsprechend lautende TMC-Meldung eintrifft und die dynamische Routenberechnung am Ger¨ at aktiviert ist. Der Fahrer wird dar¨ uber in der Regel mit einer kurzen Mitteilung ( Die Route wird auf Grund aktueller Verkehrsmeldungen neu berech” net.“) darauf hingewiesen. Es ist mittlerweise Standard, dass die empfangenen TMC-Meldungen in einem Men¨ u des Navigationssystems angezeigt werden k¨ onnen. In der aktuellen Mercedes C-Klasse (W204) ist es auch m¨oglich, sich mittels einer eingebauten TTS TMC-Meldungen vorlesen zu lassen. Allerdings werden hier nur alle aktuell vorliegenden Nachrichten vorgelesen. Das bedeutet, aktuell gibt es außer der reinen Vorlesefunktionalit¨at keine Sprachdialoge zum Thema TMC im Kfz. Wird durch eine eintreffende Meldung die Route neu berechnet, erfolgt bestenfalls eine kurze Information u ¨ber die Tatsache der Neuberechnung, in einigen Systemen wird die St¨orung auch auf dem Display angezeigt. Eine konkrete sprachliche Information erfolgt in aktuellen Systemen allerdings nicht.

132

8 Proaktiver TMC-Dialog

8.3 Idee fu ¨ r proaktive TMC-Dialoge Wie bereits dargestellt wurde, wird der Fahrer in aktuellen Systemen nicht per Sprache u ur eine Neuberechnung informiert. Wenn ¨ber den konkreten Anlass f¨ ein Navigationssystem auf dynamische Routenberechnung eingestellt ist, werden daher alle die aktuelle Route betreffenden TMC-Meldungen ber¨ ucksichtigt und f¨ ur jede eintreffende Meldung wird eine neue Route berechnet. Grunds¨ atzlich ist diese dynamische Routenberechnung auch durchaus sinnvoll, kann doch auf diese Weise ein Stau oder sogar eine Sperrung einfach umfahren werden und somit Zeit gespart und sogar die Umwelt geschont werden. Allerdings sind TMC-Meldungen nicht immer korrekt, k¨onnen sogar veraltet sein oder auch falsch. Zus¨ atzlich ist es sogar m¨oglich, dass in Abh¨ angigkeit der aktuellen Geschwindigkeit und des TMC-Empf¨angers eine Meldung mit bis zu f¨ unfzehn Minuten Versp¨ atung im Empfangsger¨at verarbeitet wird [ADAC 2004]. In dieser Zeit kann sich ein Verkehrsstau schnell wieder aufl¨ osen oder eine Umleitungsstrecke ist u ullt. Auch ist es im Falle ¨berf¨ einer n¨ otigen Umfahrung m¨ oglich, dass mehrere Alternativrouten existieren, zwischen denen der Fahrer ausw¨ ahlen k¨ onnen will. Aus diesen Gr¨ unden ist es nicht immer sinnvoll, das Navigationssystem eine automatische Neuberechnung durchf¨ uhren zu lassen. ¨ Problematisch ist der Automatismus der Ubernahme jeder beliebigen Meldung zur Routenneuberechnung. Zus¨ atzlich weiß ein Fahrer nicht, warum genau eine Neuberechnung durchgef¨ uhrt wird. Es macht daher Sinn, im Falle einer eintreffenden TMC-Meldung dem Fahrer diese kurz vorzutragen und anschließend zu fragen, ob er die Meldung beachten und z.B. eine Umleitung w¨ ahlen wolle. Sollte es dabei mehrere M¨ oglichkeiten geben, m¨ usste nach einer konkreten Route gefragt werden. So ist es denkbar, dass neben einer schnellen Strecke eine andere mit sch¨ oner Landschaft existiert. Dieses Szenario w¨ urde dann zu proaktiven Dialogen f¨ uhren, wie es auch in [Hamerich 2007] vorgestellt wurde. Der Vorteil dieser L¨ osung w¨ are nicht nur ein Informationsgewinn f¨ ur den Fahrer, sondern auch die einfache M¨ oglichkeit, als Ortskundiger eigene Routen zu fahren oder trotz Warnung einer staugef¨ ahrdeten Strecke zu folgen, da die Umfahrung nicht schneller w¨ are.

8.4 Ziele Der Entwicklung eines proaktiven TMC-Dialogs liegen folgende Ziele zugrunde: • •

Nachweis, dass DiaGen einfach und schnell funktionierende Dialoganwendungen f¨ ur den Einsatz im Automobil erstellen kann; Demonstration der Machbarkeit einer benutzerfreundlichen und besseren Handhabung von TMC-Meldungen im Automobil (wie im vorangegangenen Abschnitt ausf¨ uhrlich beschrieben);

8.6 Architektur

•

133

M¨ oglichkeit der allerersten systematischen Evaluation eines proaktiven Sprachdialogs im Automobil.

Im n¨ achsten Abschnitt wird dabei das Szenario zum Einsatz des resultierenden Systems und der Evaluation beschrieben.

8.5 Szenario Wie aus den oben formulierten Zielen bereits hervorgeht, ist die Entwicklung des Dialogprototypen nicht nur reiner Selbstzweck, sondern dieser soll auch noch einer Evaluation unterzogen werden. Die Entwicklung des Prototypen mit Hilfe von DiaGen stellt dabei die Evaluation des Werkzeugs dar. Die Ergebnisse sind detailliert im Anhang zu finden. Zur Evaluation des Dialogs soll dieser in ein Versuchsfahrzeug integriert werden. Daf¨ ur wird aber neben dem Sprachdialog eine TMC-Komponente, die weiter unten in Abschnitt 8.7.3 ausf¨ uhrlich beschrieben wird, ben¨otigt. Diese TMC-Komponente soll als Simulationskomponente vom Versuchsleiter gesteuert werden und dabei auf Knopfdruck einen proaktiven Dialog starten, welchen die Versuchsperson dann zu Ende f¨ uhrt. Die Simulation soll dabei so weit wie m¨ oglich realistisch ausgef¨ uhrt sein, um auch entsprechend wirklichkeitsnahe und verwertbare Evaluationsergebnisse zu gew¨ahrleisten. Die genaue Architektur des erstellten Dialogsystems wird im folgenden Abschnitt beschrieben.

8.6 Architektur Grunds¨ atzlich entspricht die Architektur des Dialogsystems der bereits in Abschnitt 3.4 vorgestellten Architetkur f¨ ur Sprachbediensysteme. Die Bestandteile des eigentlichen Systems mit Dialogmanager, Prompter und Spracherkenner k¨ onnen sogar alle unver¨ andert auch f¨ ur den Produkteinsatz verwendet werden. F¨ ur die Evaluation l¨ auft die gesamte Software auf einem im Kofferraum des Versuchsfahrzeugs befindlichen PC. Bei der im Versuchsfahrzeug montierten Headunit handelt es sich lediglich um eine leere H¨ ulle mit einem Display und VGA-Anschluss. Dieses Display stellt die multimodalen graphischen Dialogteile dar. Als einziges externes Ger¨at wird eine TMC-Simulation angebunden. Der PTT-Knopf befindet sich an der Headunit, Mikrofon und Lautsprecher sind im Auto vorhanden und k¨ onnen ebenfalls auch f¨ ur Produktsysteme verwendet werden. Eine ausf¨ uhrliche Beschreibung der Architektur des Versuchssystems ist im Abschnitt 8.8.1 zu finden.

134

8 Proaktiver TMC-Dialog

8.7 Konstruktion des Systems Um das System funktionsf¨ ahig im Fahrzeug einsetzen zu k¨onnen, sind einige Arbeiten n¨ otig, die in diesem Abschnitt beschrieben werden. 8.7.1 Spezifikation Der proaktive TMC-Dialog muss zuerst den Fahrer u ¨ber ein neues Vorkommnis informieren. Dies ist n¨ otig, um dem Benutzer die M¨oglichkeit zu geben, den Dialog abzubrechen. Letzteres kann sinnvoll sein, wenn sich der Nutzer z.B. gerade in einer besonders anspruchsvollen Verkehrssituation oder aber in einem wichtigen Gespr¨ ach mit dem Beifahrer befindet. Best¨atigt der Fahrer, weitere Informationen h¨ oren zu wollen, soll ihm der Inhalt der TMC-Meldung vorgelesen werden. Anschließend wird der Benutzer gefragt, ob er einer Umleitung folgen will und die m¨ oglichen Alternativen werden vorgeschlagen. Hier kann der Benutzer eine Alternative w¨ ahlen, um dann automatisch eine Routenneuberechnung des Navigationssystems zu veranlassen. Schematisch ist dieser Dialogablauf auf Abbildung 8.1 zu sehen.

Abbildung 8.1. Schematischer Dialogablauf im TMC-Dialog

8.7 Konstruktion des Systems

135

Von der linguistischen Perspektive ist dieser Dialog wenig anspruchsvoll, die meisten Abfragen k¨ onnen einfach mit Ja“ oder Nein“ beantwortet wer” ” den. Einzig die Auswahl der Umleitungsalternative erm¨oglicht einen etwas komplexeren Dialog. 8.7.2 Dialogerstellung mit DiaGen Die Erstellung des spezifizierten Dialogablaufs mit DiaGen konnte schnell und einfach erledigt werden. Die Erstellung dieser Anwendung war der Pr¨ ufstein f¨ ur die Entwicklung von DiaGen und bei der Anwendungsentwicklung hat auch DiaGen an einigen Stellen noch Verbesserungen erfahren. Die wichtigsten Schritte zur Dialogerstellung mit DiaGen sind im Anhang A dargestellt. Dabei kann grunds¨ atzlich gesagt werden, dass die Unterst¨ utzung von DiaGen bei der Dialogentwicklung sehr hilfreich und zeitsparend war. 8.7.3 TMC-Service Komponente Um einen entsprechend der beschriebenen Idee folgenden Prototypen umzusetzen, bedarf es einer Komponente f¨ ur die Generierung der TMC-Meldungen. Dieser Komponente w¨ urde neben der m¨ oglichst einfachen Generierung der Texte auch die Aufgabe obliegen, diese Texte in den Dialog zu kommunizieren und dort ein Startereignis f¨ ur den proaktiven Dialog auszul¨osen. Im Produktfahrzeug w¨ urden diese Aufgaben vom Tuner und der Navigationsapplikation u ¨bernommen werden, allerdings ist eine Anbindung existierender Produktger¨ ate f¨ ur einen Prototypen mit zu viel Integrationsaufwand verbunden. Daher wurde beschlossen, die TMC-Erstellung ausschließlich zu simulieren. Im Interesse m¨ oglichst guter Evaluationsergebnisse wurde eine vom Versuchsleiter steuerbare Simulationsumgebung konzipiert. Die Meldungen k¨onnen dort wie in einem guten WOZ-System einfach per Maus zusammengeklickt werden. Auf Knopfdruck wird dann die Kommunikation mit dem Sprachdialog aufgenommen. Diese Kommunikation ist mit dem Konzept der Systemcalls einfach auch u oglich. Bei der Spezifikation die¨ber verteilte Systeme hinweg m¨ ser Calls wurde auf eine m¨ oglichst realistische Umsetzung Wert gelegt, um eine produktnahe Implementation zu gew¨ ahrleisten. In Abbildung 8.2 ist die graphische Benutzeroberfl¨ache des TMC-Service dargestellt. Wie auch in der Realit¨ at erfolgt die Umsetzung des TMC-Texts in nat¨ urliche Sprache bereits im TMC-Modul. Wird der Knopf Send“ bet¨atigt, ” wird ein Event an den Dialog u ur den ¨bertragen, welches dort als Startsignal f¨ proaktiven Dialog dient. Anschließend u agt der Dialog die aktuelle Sy¨bertr¨ stemsprache an den TMC-Service, welcher daraufhin in Echtzeit den Klartext aus den im GUI angew¨ ahlten Angaben generiert und diesen an den Dialog zur¨ uckschickt. Die auf der Benutzeroberfl¨ ache abgebildeten Klartexte sind also eine reine Vorschau und zeigen nicht die Systemsprache an.

136

8 Proaktiver TMC-Dialog

Abbildung 8.2. Graphische Benutzerober߬ ache des TMC-Service

Hinter der GUI liegt eine komplette Liste aller 135 Autobahnausfahrten der BAB 7, welche von D¨ anemark kommend u ¨ber Flensburg, Hamburg, Hannover, G¨ ottingen, Kassel, W¨ urzburg, Ulm, und F¨ ussen bis nach Reutte in ¨ Osterreich verl¨ auft und mit 948 km Gesamtl¨ ange die l¨angste Autobahn in Deutschland darstellt. Beim Start des TMC-Service muss eine mit entsprechend korrekt formatierten Daten versehene Datei angegeben werden, welche anschließend geladen und auf der Benutzeroberfl¨ ache angezeigt wird. Durch diese Auslagerung der Daten ist es ohne weiteres m¨ oglich, auch andere Autobahnen aus Deutschland oder sogar anderen L¨ andern in dem Service zu verwenden. Die verwendeten Funktionen, um die Ergebnisse der Auswahl an den Sprachdialog zu senden, wurden in u ¨blichen GDML Definitionsdateien hinterlegt. Damit kann

8.8 Evaluation des Sprachdialogs

137

¨ der TMC-Service auch f¨ ur weitere Aufgaben ohne Anderungen einfach u ¨bernommen werden. 8.7.4 Konstruktionsaufwand Der Vorteil bei der Benutzung der Entwicklungsumgebung von Harman/Becker war, dass sehr viele Systemkomponenten ohne Aufwand einfach u ¨bernommen werden konnten. Zu diesen Komponenten geh¨oren die Spracherkennung, die TTS, der Dialogmanager und die gesamte Ablaufumgebung. Eine reine Eigenentwicklung war das Dialogskript. Wie in mehreren Selbsttests best¨ atigt wurde, konnte mit der Verwendung von DiaGen der Zeitaufwand f¨ ur die Erstellung einer funktionsf¨ ahigen, konsistenten und benutzerfreundlichen Dialogapplikation mehr als halbiert werden. In einigen Versuchen konnte der Erstellungsaufwand durch den Einsatz des Werkzeugs sogar um bis zu zwei Drittel reduziert werden. Damit kann belegt werden, dass bedingt durch die Nutzung von DiaGen Dialogskripte sehr viel schneller und auch konsistenter entwickelt werden konnten, als dies bei komplett manueller Erstellung der Fall ist. Die Integration des TMC-Dialogs in eine komplette Demonstrationsumgebung war aufw¨ andiger. Dies war allerdings n¨ otig, um in der Evaluation auch normale Funktionalit¨ aten wie eine Navigationszieleingabe testen zu k¨onnen. Ein reiner Test des proaktiven Dialogs w¨ are zu schnell und unvorbereitet gewesen. Sehr viel gr¨ oßer war der Aufwand zur Erstellung des TMC-Services. Hier war zwar schnell ein erster Prototyp lauff¨ ahig, der eine Kommunikation mit dem Dialog erlaubte, aber die Umsetzung der Details der Verkehrsmeldung ¨ auf das GUI und deren korrekte und effiziente Ubergabe an den Dialog waren recht aufw¨ andig. Am meisten Aufwand kostete die Testphase der Simulation. Diese erforderte noch einige Umbauten und Code¨ anderungen, bevor ein performanter Dialogablauf mit der TMC-Komponente m¨ oglich war.

8.8 Evaluation des Sprachdialogs In diesem Abschnitt wird die Evaluation des TMC-Dialogs beschrieben. Dabei wird auf die bereits in Abschnitt 4.3 eingef¨ uhrten Begrifflichkeiten zur¨ uckgegriffen. Zuerst wird der f¨ ur die Evaluation des TMC-Dialogs verwendete Versuchsaufbau vorgestellt. Danach erfolgt die Beschreibung der Evaluation der Dialoge und die Darstellung der Ergebnisse. Abschließend erfolgt eine Bewertung der Ergebnisse. 8.8.1 Versuchsaufbau Wesentlich f¨ ur die sinnvolle Evaluation eines automobilen Dialogsystems ist eine realistische Testumgebung [Bernsen und Dybkjær 2001]. M¨ogliche Auf-

138

8 Proaktiver TMC-Dialog

bauten und Konzepte f¨ ur eine solche Testumgebung wurden bereits in Abschnitt 4.4 diskutiert. F¨ ur die Evaluation des TMC-Dialogs wurde ein bei Harman/Becker vorhandenes Versuchsfahrzeug verwendet. Es handelt sich dabei um eine Mercedes-Benz S-Klasse (W220), bei welcher die Headunit entfernt und durch eine umgebaute Headunit der E-Klasse (W211) ersetzt wurde, die außer einem Display keine eigene Funktionalit¨ at aufweist. Der Einbau dieser DummyHeadunit in das Fahrzeug ist auf Abbildung 8.3 dargestellt. Mittels eines VGA-Kabels wird das Display der Headunit mit einem im Kofferraum befind¨ lichen PC verbunden. Uber ein serielles Kabel wird ein Knopf der Headunit ebenfalls mit dem PC verbunden und funktioniert damit als PTT-Ersatz. Die im Fahrzeug verbauten Lautsprecher und Mikrofone dienen auch dem SBS zur Sprachein- und -ausgabe.

Abbildung 8.3. Dummy-Headunit in Demofahrzeug

Da der TMC-Dialog selber sehr kurz und zudem als einziger Evaluationsgegenstand zu klein ist, wurde er in einen Testdialog zur Zieleingabe integriert. Dabei wurde lediglich das vom TMC-Service verschickte Event als zus¨atzliches Start-Event definiert, welches dann den komplett isolierten TMC-Dialog startet, wie er auch im Rahmen dieses Werkes vorgestellt worden ist. Der TMC-Service wurde auf einem Notebook installiert und dieses mit dem PC im Kofferraum verbunden. Damit konnte der Versuchsleiter den TMCService kontrollieren und gleichzeitig in elektronischer Form Notizen u ¨ber den Testverlauf anfertigen. 8.8.2 Evaluation des TMC-Dialogs Bei der Evaluation des TMC-Dialogs stand die Beantwortung folgender Fragen im Vordergrund:

8.8 Evaluation des Sprachdialogs

139

• • • •

Akzeptieren Benutzer proaktive Dialoge f¨ ur Verkehrsmeldungen? Beintr¨ achtigen proaktive Dialoge die Fahrsicherheit? Ist der im Rahmen dieses Werkes entwickelte Dialog benutzerfreundlich? Werden die vom Dialog zur Verf¨ ugung gestellten Informationen als n¨ utzlich und hilfreich angesehen? • Wird die M¨ oglichkeit, Alternativen f¨ ur Umleitungen w¨ahlen zu k¨onnen akzeptiert?

Wie bereits dargestellt wurde, ist der TMC-Dialog selber extrem kurz, daher ist die Wahrscheinlichkeit auftretender Dialogfehler (vgl. Abschnitt 4.2) sehr gering. Zudem kann bedingt durch die Untersuchung des proaktiven Charakters des Dialogs jeder Proband nur einmal komplett unvorbereitet den Dialog durchf¨ uhren. Da außerdem der eingesetzte Spracherkenner auch f¨ ur Serienprodukte von Harman/Becker eingesetzt wird und zus¨atzlich das Vokabular des Dialogs minimalistisch ausfiel, wurde von einer sehr geringen Fehlerrate bei der Spracherkennung ausgegangen. Aus diesen Gr¨ unden wurde auf eine systematische Performanzevaluation verzichtet. Dies erlaubte eine kompaktere Versuchsauswertung. Zudem war mit neuen Erkenntnissen aus einer Performanzevaluation des TMC-Dialogs nicht zu rechnen. Trotzdem wurde entschieden, eventuell auftretende Fehler zu notieren, um die hier aufgestellte Behauptung ggf. zu untermauern und eine eventuell auftretende große Benutzerunzufriedenheit erkl¨ aren zu k¨ onnen. Aus diesen Darstellungen folgt, dass das Hauptaugenmerk der Evaluation der Benutzerevaluation und damit der Benutzerzufriedenheit galt. Bei einer ersten Probeevaluation gab es bereits das klare Ergebnis, dass die Abfrage nach Umleitungsalternativen u ussig sei. Die Probanden schlugen ¨berfl¨ vor, diese Abfrage zu sparen und stattdessen eine entsprechende Einstellung in der Navigation vorzusehen. Da dieses Ergebnis so eindeutig war, wurde in der echten Evaluationsrunde ein Szenario verwendet, welches keine weiteren M¨ oglichkeiten außer der schnellsten Strecke vorsah. Die Ergebnisse dieser Evaluation sind im n¨ achsten Abschnitt zu finden. 8.8.3 Ergebnisse Die Untersuchung wurde von einem Fragebogen begleitet. Dieser ist komplett im Anhang C abgebildet. Insgesamt nahmen sieben Probanden an dem Versuch teil, die allesamt Kollegen von Harman/Becker waren. Die statistischen Daten der Probanden sind in Tabelle 8.1 zusammengestellt. Die Anzahl der Versuchspersonen ist zwar relativ klein, allerdings kann laut [Rubin 1994] bereits eine Untersuchung mit vier Probanden die gr¨obsten Benutzerprobleme aufzeigen. Da zudem auf eine Streuung von Experten und Novizen geachtet wurde, kann auch laut [Nielsen 1993] die Benutzergruppe zumindest f¨ ur einen ersten Test als ausreichend angesehen werden.

140

8 Proaktiver TMC-Dialog Geschlecht 5 m¨ annlich, 2 weiblich Alter 1 Person: 20 – 30, 6 Personen: 30 – 40 Studiengang 2 Computerlinguistik, 3 Informatik, 2 Ingenieure Technisches Interesse 5 sehr hoch, 2 hoch Tabelle 8.1. Statistische Daten der Probanden

Um die Erfahrung der Probanden mit der dynamischen Zielf¨ uhrung einsch¨ atzen zu k¨ onnen, wurde als n¨ achstes nach einem eigenen Navigationsger¨at und den Erfahrungen mit TMC-Meldungen gefragt. Vier von sieben Personen besitzen ein eigenes Navigationsger¨ at, allesamt Nachr¨ ustger¨ate (f¨ ur Details siehe Tabelle 8.2). Die Antworten ergaben zwar bei zwei Personen Erfahrungen mit der dynamischen Zielf¨ uhrung, diese hatten aber nichts st¨orendes an den Empfehlungen auszusetzen. Besitzen ein Navigationsger¨ at 4 ja, 3 nein Art des Systems 3 PNA, 1 Radio-Nachr¨ ustger¨ at Steuerung 3 Touchscreen, 1 Sprache TMC-Empf¨ anger 4 ja Nutzen dynamische Zielf¨ uhrung 2 ja, 2 nein Folgen der Fahrempfehlung 1 h¨ aufig, 1 teils/teils St¨ orend an Empfehlungen 2 nichts Tabelle 8.2. Antworten auf die Frage nach einem eigenen Navigationssystem

Als n¨ achstes wurde nach der Vorerfahrung mit Sprachsystemen gefragt. Dies erm¨ oglicht eine Unterscheidung der Probanden nach Erfahrungsgrad und kann im besten Fall eine Aussage u ¨ber die Benutzerfreundlichkeit des Systems f¨ ur verschiedene Benutzergruppen liefern. Obwohl alle Probanden im Kollegenkreis bei HBAS rekrutiert wurden, gab es Personen ohne Erfahrung mit Sprachdialogsystemen. Dies erkl¨ art sich durch die Besch¨aftigung mit speziellen Detailfragen oder administrativen T¨ atigkeiten. Insgesamt kannten f¨ unf Probanden die Systeme von Harman/Becker entweder im Produktstadium oder aus der Vorentwicklung, zwei Probanden hatten noch nie entsprechende Systeme benutzt, waren also als Novizen einzusch¨atzen. Nach diesen einleitenden Fragen wurden die Probanden kurz instruiert, wie das Sprachsystem zu bedienen sei. Als vordergr¨ undiges Untersuchungsobjekt diente dabei ein Dialog zur Zieleingabe, wie er bereits in Abschnitt 3.6.3 vorgestellt wurde. Dies war n¨ otig, da die Benutzer den proaktiven Dialog unvorbereitet ohne vorherige Informationen zu dem Thema erleben sollten. Nach diesen Instruktionen wurden die Probanden gebeten, ein auf Karteik¨artchen

8.8 Evaluation des Sprachdialogs

141

notiertes Ziel einzugeben. Dies gelang insgesamt allen Probanden erfolgreich, wenn es auch zu vereinzelten Fehlern kam.3 Nach der Eingabe wurde die simulierte Zielf¨ uhrung gestartet. Kurz danach wurde vom Versuchsleiter – ohne Vorwarnung – ein Event mit dem TMCService abgeschickt und die Benutzer mit dem proaktiven Dialog konfrontiert. Die Reaktion der Benutzer wurde genauestens beobachtet und erfreulicherweise kam es in keinem Fall zu Verst¨ orung. Ebenso erfreulich war, dass alle Benutzer den TMC-Dialog ohne Probleme zu Ende f¨ uhrten. Dies erkl¨art die bereits im vorherigen Abschnitt angedeutete Konzentration der Evaluation auf die Benutzerevaluation. Die Performanzevaluation gibt f¨ ur die Bewertung des Ansatzes von TMC-Dialogen damit keine Hilfe, außer vielleicht der, dass die Benutzer bei der anschließenden Befragung sich nicht auf die Fehler konzentrieren, sondern f¨ ur allgemeinere weiterf¨ uhrende Fragen offen sind. Nachdem die Probanden erfolgreich den TMC-Dialog zu Ende gef¨ uhrt hatten, wurde die erste Runde der Nachbefragung durchgef¨ uhrt.4 Im Mittelpunkt stand dabei die Frage, ob Benutzer proaktive Sprachdialoge f¨ ur Verkehrsmeldungen im Automobil akzeptieren und ob der mit DiaGen entwickelte Dialog benutzerfreundlich ist. Es folgte zuerst eine unstrukturierte und allgemeine Nachfrage nach den Eindr¨ ucken des Tests.5 Erfreulicherweise – vielleicht auch bedingt durch die sehr hohe Erfolgsrate des Dialogs – kamen viele positive Reaktionen. Die Idee des proaktiven Dialogs wurde von fast allen Probanden gelobt, einer hielt diese Funktionalit¨ at sogar bereits f¨ ur ein fertiges Produkt. Lediglich eine Person st¨ orte sich am Dialog und war der Meinung, dass neue Meldungen einfach ohne Nachfrage automatisch vorgelesen werden sollten. Nach dieser ersten Frage, wurden die Probanden gezielt befragt, was ihnen an dem erlebten Dialog besonders gut und besonders schlecht gefallen hat. Die teilweise widerspr¨ uchlichen Antworten sind in Tabelle 8.3 zusammengefasst. Insgesamt f¨ allt bereits bei diesem Feedback auf, dass die Kritik sich nicht an den Ansatz grunds¨ atzlich richtet, sondern lediglich Details betrifft. Dagegen sind die positiven R¨ uckmeldungen auch auf den Ansatz allgemein zu beziehen. Dies ergibt bereits eine sehr positive Grundaussage. Allerdings waren noch viele Fragen offen, daher gab es weitere detaillierte und strukturierte Fragen. Auf die Frage nach dem selbst¨ andigen Dialogstart des TMC-Dialogs folgte von den Probanden fast ausschließlich positives Feedback (viermal sehr gut, 3

4 5

Obwohl dies nicht zum eigentlichen Untersuchungsgegenstand geh¨ ort, wurde es trotzdem der Vollst¨ andigkeit halber notiert. Hintergrund f¨ ur die Fehler waren OOV-Fehler in der Kommandoeingabe und Erkennungsfehler auf dem 70.000 verschiedene St¨ adtenamen umfassenden Vokabular. Es haben aber alle Probanden diesen Dialog erfolgreich zu Ende f¨ uhren k¨ onnen. Erst an dieser Stelle wurde der proaktive Dialog thematisiert, vorher wurde dieser weder erw¨ ahnt noch wussten die Probanden von diesem. Erfahrung bei HBAS hat gezeigt, dass dieses unmittelbare allgemeine Feedback sehr wertvoll ist und zudem von Probanden gerne f¨ ur R¨ uckmeldungen genutzt wird.

142

8 Proaktiver TMC-Dialog Gut

L¨ ange der Sprachansagen graphische Darstellung immer klar, was man sagen kann hat sehr gut funktioniert guter kurzer Dialog Schlecht Sprachprompts sind zu schnell Qualit¨ at der Sprachsynthese nichts zu lange Sprachansagen umst¨ andliche Formulierungen der Ansagen Tabelle 8.3. Zusammenfassung der Erlebnisse w¨ ahrend des Tests

zweimal gut). Die eine Ausnahme betrifft die bereits oben erw¨ahnte Meinung einer Versuchsperson, dass sie die Meldungen gerne ohne Nachfrage des Systems vorgelesen bekommen h¨ atte. Die Frage, ob der Dialog eine Unterst¨ utzung angeboten habe oder nervig sei, wurde durchweg positiv beantwortet (f¨ unfmal sehr hilfreich, zweimal hilfreich). Bis auf einen Probanden erkl¨arten sogar alle, dass sie das System sehr gerne selber in ihrem eigenen Auto nutzen w¨ urden. Information im Voraus

Nur ausgew¨ ahlte Meldungen Welche

Jede Meldung vorlesen Hohes Aufkommen

so fr¨ uh wie m¨ oglich maximal 30 Minuten vorher min. 5 Minuten vorher 10 - 50 km vorher so sp¨ at wie m¨ oglich 7 ja nicht f¨ ur Wetterverh¨ altnisse, nur f¨ ur Ansagen die sinnvolle Alternative bieten nur wenn Autobahn verlassen werden muss nur unmittelb. betreffende Meldungen (Stau, o.¨ a.) 5 ja, 2 nein nur wichtige und nahe Meldungen Konfiguration der Meldungsart von Hand nur die jeweils nahegelegenste Meldung

Tabelle 8.4. Antworten der ersten Nachbefragung

Bereits bei der Systementwicklung und bei Gespr¨achen mit Kollegen im Vorfeld zeichneten sich allerdings Fragen ab, die grunds¨atzlich vom Systemdesign unabh¨ angig sind, allerdings vor der Einf¨ uhrung eines entsprechenden Systems in einem Produkt sehr relevant sind. Bei diesen Fragen ging es vor allem darum, wann welche Information dem Benutzer wie vorgelesen werden ¨ soll. Hintergrund dieses Fragenblocks war die Uberlegung, dass eine zu sp¨at gelesene Meldung keine sinnvollen Reaktionen mehr erlaubt, eine zu fr¨ uh kom-

8.8 Evaluation des Sprachdialogs

143

munizierte Meldung allerdings zu u ussigen Umwegen f¨ uhren k¨onnte. ¨berfl¨ Aus diesen Gr¨ unden wurden die Probanden unter anderem gefragt, wie weit im voraus sie es f¨ ur sinnvoll halten w¨ urden, Kenntnis einer TMC-Meldung zu erlangen. Bedingt durch die bereits in Abschnitt 8.1.2 erw¨ahnte Vielzahl von m¨ oglichen Ereignissen kann eventuell eine Filterung der vorzulesenden Meldungsarten Sinn machen. Zus¨ atzlich wurde gefragt, ob grunds¨atzlich jede eintreffende Meldung vorgelesen und wie bei einem hohen Aufkommen von Meldungen beispielsweise im Ruhrgebiet verfahren werden solle. Die Antworten waren allerdings auch hier teilweise widerspr¨ uchlich, wie aus Tabelle 8.4 ersehen werden kann. Da die f¨ ur die Tests verwendete Headunit auch u ¨ber eine Anzeigem¨oglichkeit verf¨ ugte, wurde auch f¨ ur die eintreffende simulierte TMC-Meldung in der Evaluation eine Anzeige entworfen (vgl. Abbildung 8.4). Nachdem die Benutzer diese gesehen hatten, wurden sie auch befragt, ob dies sinnvoll sei. Sechs von sieben Probanden bejahten diese Anfrage.

Abbildung 8.4. Graphische Anzeige bei eintreffender TMC-Meldung

Anschließend wurden die Versuchspersonen gebeten, dem System eine Schulnote zu geben. Die Durchschnittsnote der Probanden f¨ ur das System fiel mit 1,8 erfreulich gut aus. Um eine Bewertung des TMC-Dialogs vornehmen zu k¨onnen, wurden die Probanden nach Alternativen im Umgang mit empfangenen TMC-Meldungen befragt. Die Bewertung des TMC-Dialogs schnitt dabei am positivsten ab, wie Tabelle 8.5 entnommen werden kann. Ber¨ ucksichtigt man die kognitive Fahrbelastung im Auto ist allerdings eine sehr wichtige Frage die, ob die Inhalte einer vorgelesenen Verkehrsmeldung u ¨berhaupt memoriert werden. Zudem wurde davon ausgegangen, dass eine ge¨ anderte Reihenfolge der Textbausteine oder auch nur eine andere Wortwahl die Aufnahme des Nachrichteninhalts beeinflussen k¨onnte. Aus diesem Grund wurde nach dieser ersten Runde der Nachbefragung nochmals eine TMC-Meldung abgespielt (mit anderem Inhalt als die erste). Ohne die Be-

144

8 Proaktiver TMC-Dialog Neuberechnung mit Hinweis 3 gut, 3 schlecht, 1 sehr schlecht Neuberechnung ohne Hinweis 1 schlecht, 6 sehr schlecht Mit proaktivem Dialog 5 sehr gut, 2 gut Andere M¨ oglichkeit 1 haptisch, 1 nicht rein haptisch, 5 keine Tabelle 8.5. Alternativen zum Umgang mit TMC-Meldungen

nutzer dar¨ uber im Vorfeld informiert zu haben, wurden sie nach dem Abspielen der Meldung befragt, welche Informationen in der Meldung enthalten waren. Die vorgespielte Meldung sah dabei wie folgt aus (die entsprechende Displaydarstellung ist auf Abbildung 8.4 dargestellt): In 10 km Vollsperrung der A7 zwischen den Ausfahrten 118 Niederstotzingen und 117 Giengen/Herbrechtingen. Im Ergebnis konnten sich die meisten Probanden an die Art der berichteten St¨ orung erinnern, ein Großteil konnte auch die erste Autobahnausfahrt korrekt wiedergeben, ab der die St¨ orung berichtet wurde. Obwohl allerdings die Entfernung zur St¨ orung als erste Information in der Meldung vorgelesen und angezeigt wurde, erinnerten sich nur die wenigstens Probanden an diese korrekt. Dabei ist diese Entfernung bei nicht vorhandener Ortskenntnis sehr wichtig, um die Relevanz der entsprechenden Meldung f¨ ur die augenblickliche Fahrt einordnen zu k¨ onnen. Die gesammelten Ergebnisse des Memorierungstests sind in Tabelle 8.6 zusammengefasst. Art der St¨ orung 6 korrekt, 1 weiß nicht Ort der St¨ orung 1 alles korrekt, 4 erste Ausfahrt korrekt, 2 weiß nicht Entfernung bis zur St¨ orung 3 korrekt, 4 weiß nicht Tabelle 8.6. Zusammenfassung des Memorierungstests

Bereits bei der Entwicklung des TMC-Dialogs wurde die M¨oglichkeit der einfachen Wahl einer Umleitungsalternative als ein wichtiger Vorteil des Dialogansatzes angesehen. Dies ist auch so in [Hamerich 2007] berichtet worden. Wie bereits im vorangegangen Abschnitt erw¨ ahnt wurde, ist die M¨oglichkeit der Wahl einer Umleitungsalternative allerdings bereits bei den Probeevaluationen klar durchgefallen. In der finalen Evaluation ist daher dieses Szenario abgeschaltet worden. Um aber trotzdem eine R¨ uckmeldung zu dieser Idee zu erhalten, wurden die Probanden zum Schluss nochmals befragt, wie sie die andere Routenempfehlungen des Systems bewerten w¨ urden. Zur Auswahl standen dabei die Option einer landschaftlich sch¨onen Strecke, einer Route zu einer wichtigen nahen Sehensw¨ urdigkeit oder auch Routen zu Restaurants in der N¨ ahe. S¨ amtliche Probanden lehnten die M¨oglichkeit ab, diese Optionen automatisch bei Empfang einer umleitungsrelevanten TMC-Meldung anzubie-

8.8 Evaluation des Sprachdialogs

145

ten. Selbst die M¨ oglichkeit einer w¨ ahlbaren Voreinstellung wurde nur von einer Person f¨ ur den Fall einer landschaftlich sch¨ onen Strecke gew¨ unscht. Ansonsten wurde diese Funktionalit¨ at nicht im Umfang eines Sprachdialogs gesehen, wie aus der Zusammenstellung der Antworten zu dieser Frage in Tabelle 8.7 entnommen werden kann. Die entsprechenden Funktionalit¨atsumf¨ange wurden allesamt im Navigationssystem gesehen, jedoch nicht f¨ ur wichtig genug gehalten, sie per Sprache zugreifbar zu machen. Einzig die M¨oglichkeit, die entsprechende Anfrage explizit per Sprache an das Navigationssystem zu stellen, wurde im Interview als positiv bewertet. Allerdings wurde dies als optionaler Bestandteil der Zieleingabe in der Navigation gesehen. Landschaftlich sch¨ one Strecke 1 nur nach Voreinstellung, 6 nie Sehensw¨ urdigkeiten 7 nie Restaurants 7 nie Sonstiges 6 nichts, 1 sehr weitr¨ aumige Umfahrung Tabelle 8.7. Zusammenfassung zur Frage nach Umleitungsalternativen

Zum Abschluss wurden die Probanden nach anderen m¨oglichen Einsatzm¨ oglichkeiten f¨ ur proaktive Dialoge befragt. Daraufhin wurden die folgenden M¨ oglichkeiten genannt: • w¨ ahrend Nachtfahrten als Schutz vor M¨ udigkeit • bei weiter entfernten Zielorten sollten Temperatur und Wetter am Ziel genannt werden 8.8.4 Bewertung der Ergebnisse Die im vorherigen Abschnitt dargestellten Ergebnisse werden in diesem Abschnitt bewertet, um daraus Antworten auf die in Abschnitt 8.8.2 formulierten Fragen zu generieren. Grunds¨ atzlich muss allerdings vorweg gesagt werden, dass auf Grund der geringen Anzahl von Evaluationsteilnehmern das Ergebnis nur bedingt repr¨ asentativ sein kann. Die Frage nach der Akzeptanz der proaktiven Dialoge f¨ ur Verkehrsmeldungen kann uneingeschr¨ ankt positiv beantwortet werden. Die proaktive Vermittlung von Verkehrsinformationen wurde von f¨ unf Probanden als sehr hilfreich und von zwei Probanden als hilfreich angesehen. Ferner wurde der proaktive Dialog von vier Personen als sehr gut und von zwei Personen als gut bewertet6 . Dies wird zus¨ atzlich unterstrichen durch die positive Bewertung mit der Schulnote 1,8 und die guten R¨ uckmeldungen direkt nach dem Versuch. Damit kann der grunds¨ atzliche Ansatz, TMC-Meldungen per proaktivem Sprachdialog dem Fahrer zu kommunizieren, als akzeptiert angesehen werden. 6

Eine Person st¨ orte sich an den Nachfragen und bewertete daher schlechter.

146

8 Proaktiver TMC-Dialog

Eine Beeintr¨ achtigung der Fahrsicherheit konnte nicht festgestellt werden. Dies mag allerdings auch daran liegen, dass die Tests ausschließlich im stehenden Fahrzeug stattfanden. Beobachtungen und Interviews gaben aber keinen Grund zu der Besorgnis, dass der proaktive Dialog die Fahrsicherheit mehr ¨ gef¨ ahrdet, als ein regul¨ ar gestarteter Dialog. Ein negativer Uberraschungseffekt konnte nicht festgestellt werden. Damit k¨ onnen keine Anhaltspunkte gefunden werden, dass proaktive Sprachdialoge die Fahrsicherheit beeintr¨achtigen. Wie bereits in Kapitel 4 dargestellt, ist die Benutzerfreundlichkeit kein einfach zu messender Wert, sondern wird nach Definition 4.1 aus der Effektivit¨ at, Effizienz und der Zufriedenheit der Systembenutzung abgeleitet. Da die proaktiven Dialoge vom Benutzer nicht initiiert wurden, ist es schwer die Effektivit¨ at zu bewerten. Da aber der Dialog mit der Frage nach dem Vorlesen einer Verkehrsmeldung beginnt und alle Evaluationsteilnehmer die Frage bejaht haben und immer korrekt verstanden wurden, wird die Effektivit¨ at als erf¨ ullt angesehen. Die Effizienz der TMC-Dialoge kann auf Grund der positiven Bewertung des Ansatzes und der sehr viel schlechteren Bewertung anderer M¨ oglichkeiten zur Kommunikation von Routen¨anderungen durch TMC-Meldungen ebenfalls als erf¨ ullt angesehen werden. Die Zufriedenheit der Benutzer ist durch die positiven Aussagen des Interviews belegt. Damit kann in Summe der TMC-Dialog als benutzerfreundlich angesehen werden. Die Frage, ob die vom Dialog zur Verf¨ ugung gestellten Informationen als n¨ utzlich und hilfreich angesehen wurde, ist von den Benutzern im Rahmen der Nachbefragung zustimmend beantwortet worden. Die Frage nach Umleitungsalternativen ist allerdings als eine der Kernpunkte des Dialogs durchweg von den Benutzern abgelehnt worden. Da der Widerspruch zu dieser Funktion bereits im Vorfeld so klar war, wurde er in der Evaluation nur noch als theoretische Option im Fragebogen mit einbezogen und ist dort von fast allen Probanden komplett abgelehnt worden. Allerdings wirft die Evaluation auch noch einige Fragen f¨ ur die weitere Zukunft auf. Zum einen besagen der Memorierungstest und auch die initialen R¨ uckmeldungen, dass die Sprachausgabe inhaltlich auf alle F¨alle noch verbessert werden kann. Zum anderen zeigen die widerspr¨ uchlichen Aussagen zum Informationszeitpunkt, dass auch diese Frage noch systematisch weiter untersucht werden muss. Eventuell ist in dieser Frage auch keine perfekte L¨osung zu erreichen und die Vorlaufzeit f¨ ur das Vorlesen einer Meldung muss vom Endbenutzer selbst in den Men¨ ueinstellungen konfiguriert werden. Eine weitere ungel¨ oste Frage ist der Umgang mit einem hohen Aufkommen von TMCMeldungen. Die Befragung der Probanden ergab lediglich, dass sich ein Großteil der Problematik zwar bewusst ist, aber auch keine naheliegende L¨osung kennt. Von daher wird ohne eine vergleichende Langzeitstudie keine belastbare Aussage u ¨ber die beste Konfiguration und Filterung der vorzulesenden TMC-Meldungen zu t¨ atigen sein. Erfreulich ist aber, dass der im Rahmen dieses Werkes erstmals vorgestellte Ansatz, TMC-Meldungen proaktiv per Sprachdialog dem Fahrer zug¨anglich

8.9 Zusammenfassung

147

zu machen, grunds¨ atzlich akzeptiert und machbar ist. Gleichwohl sind vor dem Einbau der entsprechenden Funktionalit¨ at in echte Produktsysteme noch viele Fragen zu beantworten. Zusammenfassend kann damit die Evaluation des Prototypen insgesamt als Erfolg angesehen werden und damit auch der Nachweis erbracht werden, dass DiaGen die schnelle Erstellung von funktionsf¨ ahigen und benutzerfreundlichen Sprachdialogen erm¨ oglicht.

8.9 Zusammenfassung In diesem Kapitel ist der mit der Hilfe von DiaGen entwickelte Prototyp eines proaktiven TMC-Dialogs vorgestellt worden. Dabei wurde der Begriff des proaktiven Dialogs definiert und die Grundlagen des Traffic Message Channel beschrieben. Außerdem wurde dargestellt, wie in aktuellen Systemen der Inhalt von TMC-Meldungen an den Fahrer weitergegeben wird und darauf aufbauend der Grundstein f¨ ur den entwickelten TMC-Dialog gelegt. Mit der Entwicklung und Evaluation des TMC-Dialogs ist erfolgreich der Nachweis erbracht worden, dass die Verwendung von DiaGen es gestattet, einfach und schnell funktionierende und benutzerfreundliche Dialoganwendungen f¨ ur den Einsatz im Automobil zu erstellen. Insgesamt ist ein Weg aufgezeigt worden, wie eine benutzerfreundlichere Handhabung von TMC-Meldungen gelingen kann. Außerdem ist eine systematische Evaluation eines proaktiven Sprachdialogs durchgef¨ uhrt worden.

9 Zusammenfassung und Ausblick

Im vorliegenden Werk wurde nachgewiesen, dass die verschiedenen Methoden der im Schichtenmodell aus Abschnitt 1.3 enthaltenen Disziplinen in einem Entwicklungswerkzeug vereinigt werden k¨ onnen. Eine Zusammenfassung der Erkenntnisse dieses Werkes erfolgt im nachfolgenden Abschnitt. Anschließend wird ein Ausblick auf zuk¨ unftig zu kl¨ arende Fragen sowie neue Entwicklungen gegeben.

9.1 Zusammenfassung Die Forschung im Bereich der Sprachdialogsysteme hat sich in den letzten Jahren immer weiter diversifiziert, am bedeutensten und grundlegensten erscheint hierbei die Unterteilung in Signalebene (speech) und Dialogebene (language). Da allerdings f¨ ur die Modellierung intelligenter Dialogsysteme beide Ebenen von Bedeutung sind und ein u ¨bergreifender Ansatz zur Modellierung von Sprachdialogen bisher nicht gefunden wurde, ist im Rahmen des vorliegenden Buches ein Schichtenmodell entwickelt worden. Dieses Modell bildet die f¨ ur die Modellierung von Sprachdialogen n¨ otige Interdisziplinarit¨at in strukturierter Form ab. Des Weiteren wurden mittels dieses Modells die notwendigen Methoden zur Erstellung eines Sprachdialogsystems benannt. Das Modell ber¨ ucksichtigt dabei die Ergonomie der Mensch-Maschine-Schnittstelle, die Regeln der Kommunikation und der Linguistik, als auch die ingenieursm¨aßigen Grundlagen des Systemaufbaus und die softwaretechnischen Grundlagen solcher Systeme. Um die verschiedenen Methoden der in den Ebenen des Schichtenmodells repr¨ asentierten Schichten zusammenzuf¨ uhren wurde das Werkzeug DiaGen entwickelt. Da Sprachdialogsysteme im Automobil mehr Herausforderungen an Dialogdesign, Integration und Ergonomie stellen und außerdem in Forschung und Lehre weniger bekannt sind, wurden diese als Anwendungsgrundlage f¨ ur das Werkzeug DiaGen bestimmt. So wurde die dort sehr verbreitete

150

9 Zusammenfassung und Ausblick

Form der zustandsbasierten Dialogmodellierung beachtet. Da Sprachdialogsysteme im Automobil grunds¨ atzlich der Kontrolle und Steuerung angeschlossener Ger¨ ate, wie zum Beispiel von Navigationssystemen oder Mobiltelefonen dienen, wurde auch eine einfache Integration externer zu steuernder Komponenten in DiaGen vorgesehen. Auch die kognitive Belastung des Fahrers, der neben der haupts¨ achlichen Fahrt¨ atigkeit der einzige Benutzer eines automobilen Sprachsystems ist, spielt f¨ ur solche Systeme eine besondere Rolle. Aus diesem Grund wurde auch auf ergonomische Grunds¨atze bei der Verwendung von DiaGen geachtet. Daneben wurde auch eine Unterst¨ utzung bei der Entwicklung komplexer Dialogabl¨ aufe vorgesehen. Dies ist f¨ ur automobile Systeme umso wichtiger, da im Dialogablauf solcher Systeme die Ger¨atesteuerung im Vordergrund steht und daher zwar nur eine u ¨berschaubare Dialogdom¨ane abgedeckt wird, diese allerdings mehrere Ebenen in die Tiefe gehen kann. DiaGen erlaubt die Erstellung von benutzerfreundlichen, kommunikativ sinnvollen Sprachdialogen. Des Weiteren k¨ onnen mit der Verwendung von DiaGen Dialogmodelle f¨ ur automobile Systeme in weniger als der H¨alfte der Zeit entwickelt werden, die f¨ ur die klassische manuelle Softwareentwicklung ben¨ otigt wird. Neben der allgemeinen Zeitersparnis ist es vor allem bemerkenswert, dass mit DiaGen erstmals ein Dialogentwicklungswerkzeug vorgestellt wird, welches die Konsistenz von Grammatik und Sprachdialog sicherstellt. Damit k¨ onnen elementare Fehler verhindert werden, deren Entdeckung sehr aufw¨ andig und teuer ist. Außerdem bietet DiaGen dem Benutzer eine große Unterst¨ utzung bei der Entwicklung benutzerfreundlicher Sprachdialoge. Als Nachweis f¨ ur die Leistungsf¨ ahigkeit des Werkzeugs wurde ein prototypischer proaktiver TMC-Dialog konzipiert und umgesetzt. Dieser Dialog ist einer Benutzerevaluation unterzogen worden, deren Ergebnisse nicht nur zeigen, dass der entstandene Dialog benutzerfreundlich ist, vielmehr k¨onnen sie auch als Startpunkt f¨ ur die Entwicklung einer neuen Funktion in zuk¨ unftigen Sprachbediensystemen im Automobil dienen. Das Werkzeug DiaGen konnte mit der insgesamt erfolgreichen Evaluation des TMC-Dialogs nicht nur zeigen, dass es zur Entwicklung und Erstellung benutzerfreundlicher Dialoge im Automobil herangezogen werden kann. Es wurde zus¨ atzlich auch festgestellt, dass mit DiaGen und dem zustandsbasierten Ansatz sogar die Entwicklung von zukunftsf¨ahigen und innovativen Sprachdialogen m¨ oglich ist. Die Evaluation hat weiterhin gezeigt, dass der Ansatz proaktiver Dialoge im Automobil akzeptiert ist und hat die T¨ ur aufgestoßen f¨ ur eine Vielzahl neuer Dialoganwendungen. Aus wissenschaftlicher Sicht ist mit der Vereinigung der Methoden aus dem Schichtenmodell ein wichtiger Schritt in Richtung von besseren Sprachsystemen gelungen. Erstmals konnten die verschiedenen Methoden der Sprachdialogmodellierung zusammengef¨ uhrt und damit ein Beitrag zum wissenschaftlichen Forschritt geleistet werden. So wurden die grundlegenden Ideen, die zu DiaGen gef¨ uhrt haben, vom Publikum im Rahmen der Pr¨asentation von [Hamerich 2008] mit sehr großem Interesse aufgenommen. Insbesondere die

9.2 Ausblick

151

Idee der Zusammenf¨ uhrung der bisher getrennt angesehenen Dialogmodellierung und Grammatikentwicklung wurde sehr interessiert aufgenommen.

9.2 Ausblick Mit der Entwicklung von DiaGen konnte gezeigt werden, dass mit einer Kombination von informatischen, linguistischen und ingenieurstechnischen Methoden ein geeignetes Werkzeug zur schnellen Erstellung konsistenter, fehlerfreier, benutzerfreundlicher und kommunikativ sinnvoller Sprachdialoge f¨ ur die Dom¨ ane der Sprachsteuerung entstehen konnte. Damit hat DiaGen seine erste Bew¨ ahrungsprobe bestanden. Ein m¨oglicher produktiver Einsatz des Werkzeugs in der Vor- und/oder Produktentwicklung von automobilen Sprachdialogen bei Harman/Becker wird noch evaluiert. Sollte diese Evaluation grunds¨ atzlich positiv ausfallen, wird es sicherlich einige Erweiterungen an DiaGen geben. M¨ ogliche sinnvolle Erweiterungen sind die Anbindung an die verwendete Promptdatenbank, eine Anbindung an die verwendeten Spezifikationswerkzeuge oder auch eine Integration einer komplexeren Beispielanwendung als Startpunkt zuk¨ unftiger Entwicklungen. All diese Schritte wurden bei der Erstellung von DiaGen bereits bedacht und die Schnittstellen daher so offen wie m¨ oglich ausgef¨ uhrt. Neben dem Werkzeug DiaGen konnte mit der Entwicklung des proaktiven TMC-Dialogs erste Schritte in Richtung benutzerfreundlicher sprachgesteuerter Kontrolle der dynamischen Zielf¨ uhrung gegangen werden. Allerdings hat die Evaluation des Dialogs noch einige Fragen aufgeworfen, die noch zu kl¨aren sind. So ist zum Beispiel der bestm¨ ogliche Abstand zwischen Vorlesen einer Meldung und Zeit bis zum Eintreffen am Ort der St¨orung nicht einfach zu bestimmen. Auch ist noch unklar, wie bei geh¨ auftem Auftreten solcher Meldungen verfahren werden soll. Mit Einf¨ uhrung des TMC-Nachfolgers TPEG (Transport Protocol Experts Group), der von der Europ¨ aischen Rundfunkunion propagiert wird, k¨onnen noch mehr Informationen im Radio eines Kfz empfangen werden. So wird neben Verkehrsinformationen auch dar¨ uber nachgedacht, mit TPEG Informationen von Parkleitsystemen, Flugh¨ afen und Bahnh¨ofen zu transportieren. Damit nimmt zuk¨ unftig die Frage, wie diese Daten dem Fahrer im Kfz m¨oglichst einfach und wenig ablenkend pr¨ asentiert werden, einen wichtigen Raum ein. Die Modalit¨ at Sprache bietet sich dort an. Im vorliegenden Buch wurde gezeigt, dass dies schon f¨ ur TMC-Meldungen eine praktikable L¨osung darstellt. Neben zus¨ atzlichen Informationen u ¨ber die Radiokan¨ale werden in absehbarer Zeit auch Informationen aus dem Internet im Automobil zur Verf¨ ugung stehen. Insbesondere diese Mengen von unstrukturierten Informationen m¨ ussen f¨ ur den Fahrer mit m¨ oglichst wenig Ablenkung aufbereitet werden und zugreifbar sein. Auch hier bietet sich die Modalit¨at Sprache an. Seitdem 1996 das erste sprachbediente Autotelefon auf den Markt kam, ist die Funktionsvielfalt von Sprachbediensystemen immer weiter gewachsen.

152

9 Zusammenfassung und Ausblick

Zeitgleich hat sich auch die Nachfrage nach solchen Systemen immer weiter gesteigert. Daher scheint es nur noch eine Frage der Zeit zu sein, bis wirklich in allen Fahrzeugen eine Sprachbedienung zur Verf¨ ugung steht und damit hoffentlich die sprachliche Bedienung von Ger¨ aten so leicht ist, wie es in der Science-Fiction bereits heute m¨ oglich ist. Da der grunds¨ atzliche Ansatz von DiaGen auch unabh¨angig von der Dom¨ ane der automobilen Sprachdialogsysteme eingesetzt werden kann, wird er sicher wieder aufgegriffen und weiterentwickelt werden. Eine denkbare Weiterentwicklung der Vereinigung von Signalebene und Dialog, wie sie in DiaGen vorgenommen wurde, k¨ onnte die automatische Sicherstellung von passenden Systemfragen zu vorgegebenen Sprachausgaben sein. Das heißt, der Wortschatz eines Systems sollte nicht wie bisher u ¨ber zwei verschiedene Kan¨ale bestimmt, sondern nur noch u urde es ¨ber einen Weg definiert werden. Damit w¨ in Zukunft noch einfacher m¨ oglich sein, die wichtigen Erkenntisse der verschiedenen Forschungsgebiete im Bereich sprachliche Mensch-Maschine-Interaktion zusammen zu f¨ uhren und zu einem Gesamtsystem zu kombinieren.

A DiaGen Benutzerprotokoll

Das Benutzerprotokoll soll einen Einblick in die Leistungsf¨ahigkeit des Werkzeugs DiaGen geben. Daher werden in diesem Abschnitt die wichtigsten Schritte bei der Erstellung des in Kapitel 8 beschriebenen proaktiven TMCDialogs vorgestellt. Grunds¨ atzlich stellen die angegebenen Namen von Variablen, Routinen und Dateien nur Beispiele dar und k¨onnen nach Belieben des Entwicklers oder Codekonventionen auch anders benannt werden. Neues Projekt erstellen Mit dem Shortcut Ctrl+P oder u u File - New GDML Project kann ¨ber das Men¨ ein neues GDML Projekt angelegt werden. F¨ ur den TMC-Dialog wurden die folgenden Einstellungen in der erscheinenden Dialogbox vorgenommen: Dieses Projekt enth¨ alt bereits einen lauff¨ ahigen Ja/Nein-Dialog, der mittels Ctrl+F7 oder Compile/Run - Compile all kompiliert werden kann. Soll der Dialog getestet werden, gen¨ ugt Ctrl+F5 oder Compile/Run - Run project um den Dialog zu starten. Neue Dialogzust¨ ande definieren und verkn¨ upfen Bevor an dieser Stelle weitere Funktionalit¨ at hinzugef¨ ugt werden kann, muss die globale Zustandsvariable um einige weitere Zust¨ande f¨ ur den TMC-Dialog erweitert werden. Daher sollte jetzt die Datei global defines.gdml angezeigt werden (Window - global defines.gdml) und dort die Variable Dialog State enum gesucht werden. Die Aufz¨ahlungsvariable sollte aktuell nur mit einem Wert wie folgt definiert sein: <def_enum elements="Dialog_State_Main" name="Dialog_State_enum" /> Das bedeutet, es gibt aktuell nur einen Hauptzustand im Dialog. F¨ ur die Erstellung des TMC-Dialogs werden allerdings noch weitere Zust¨ande

154

A DiaGen Benutzerprotokoll

Abbildung A.1. Dialogbox in DiaGen zur Erstellung eines neuen Projekts

ben¨ otigt: ein Zustand f¨ ur die erste Abfrage, ob der Fahrer die neue Nachricht anh¨ oren m¨ ochte, der Zustand f¨ ur die Beantwortung der Frage, ob eine Umleitung gefahren werden soll, und dann drei Zust¨ande f¨ ur die m¨oglichen Umleitungen (schnellste Strecke, sch¨ one Strecke, Sehensw¨ urdigkeit). Daher sollte die oben gezeigt Definition von Hand ge¨andert werden, um wie folgt auszusehen: <def_enum elements="Dialog_State_Main, Dialog_State_YesNo, Dialog_State_YesNo_TMC, Dialog_State_YesNo_Detour, Dialog_State_Detour_Scenic, Dialog_State_Detour_Sight, Dialog_State_Detour_Sight_Scenic" name="Dialog_State_enum" /> Diese Dialogzust¨ ande m¨ ussen auch mit verschiedenen Grammatikregeln kombiniert werden, um in jedem Zustand eine Spracherkennung durchf¨ uhren zu k¨ onnen. Dazu muss die Projektdatei namens mod recog.gdml angezeigt werden. Diese Datei enth¨ alt s¨ amtliche projektrelevanten Funktionen f¨ ur die Spracherkennung. Da neue Dialogzust¨ ande hinzugef¨ ugt wurden, m¨ ussen diese in der Funktion fn recog prepare bekannt gemacht werden. Dies kann ganz einfach nach den Variablendefinitionen in dieser Funktion durchgef¨ uhrt werden. Dazu muss per Rechtsklick die Methode Add Switch Statement ausgew¨ahlt werden. Als Switch-Element soll gleich die erste angezeigte Variable dienen:

A DiaGen Benutzerprotokoll

155

in dialogState:Dialog State enum. Der Hauptzustand und der default waren bereits in dieser Routine gesetzt, deren Daten k¨onnen u ¨bernommen und die alte Switch-Anweisung gel¨ oscht werden. Alle neuen Zust¨ande mit YesNo im Namen bekommen exakt die gleichen Werte wie der Hauptzustand. Die u ussen auf folgende Werte gesetzt werden: ¨brigen drei Werte m¨ Grammatik erweitern Die drei hier erw¨ahnten Grammatikregeln m¨ ussen jetzt noch mit der Grammatik verkn¨ upft werden, indem in der sprachunabh¨angigen Hauptgrammatik folgendes eingef¨ ugt wird: public = ( {$label} | {$label} | {$label} | {$label} ) {menu=cfv_choice; group=cfv_decide; $label}; public = ( {$label} | {$label} | {$label} ) {menu=cfv_choice; group=cfv_decide; $label}; public = ( {$label} | {$label} | {$label} ) {menu=cfv_choice; group=cfv_decide; $label}; =

156

A DiaGen Benutzerprotokoll

( [] [] ) {cmd=cfv_detour}; = ( [] [] ) {cmd=cfv_sight}; = ( [] [] ) {cmd=cfv_scenic}; = ( [] [] ) {cmd=cfv_none}; Diese Regeln erlauben dem Benutzer bei Auswahl der Art der Umleitungsstrecke, eine der M¨ oglichkeiten oder auch gar keine zu w¨ahlen. Die filler stehen f¨ ur sprachliche F¨ ullw¨ orter wie z.B. bitte“, m¨ochte“ etc. ” ” Anschließend m¨ ussen die sprachunabh¨ angigen Regeln mit einer sprachlichen Realisierung in der Datei phrases.jsgf versehen werden. Dazu m¨ ussen die folgenden Regeln hinzugef¨ ugt werden: public ( | | );

= schnellste Strecke schnelle Strecke Umleitung

public = ( [nahe] Sehensw¨ urdigkeit ); public = ( ( sch¨ one | sch¨ onere | sch¨ onste ) Strecke ); public = ( ( [gar] nichts [von dem]) ); Mit der Integration dieser Regeln ist der Dialog wieder vollst¨andig, da alle im Dialog aktivierbaren Grammatikregeln nun auch existieren.

A DiaGen Benutzerprotokoll

157

Ja/Nein Dialog hinzuf¨ ugen Um die Ja/Nein-Fragen abzuhandeln, wird ein reiner Ja/Nein Dialog ben¨otigt. Dieser wird mit Ctrl+D oder File - New GDML Dialog zum Projekt hinzugef¨ ugt. Der entsprechend ben¨ otigte graphische Dialog ist auf Abbildung A.2 abgebildet.

Abbildung A.2. Dialogbox zur Integration eines neuen GDML-Dialogs ins Projekt

Die resultierende GDML-Datei soll dlg yesno.gdml genannt werden. In dieser Datei soll jetzt ein parametrierter Ja/Nein-Dialog entstehen. Dazu muss in der Datei per Rechtsklick zuerst ein Dialog mit Namen dlg yesno definiert werden. Dieser Dialog erh¨ alt als Parameter wie auf Abbildung A.3 dargestellt die Variable dialogState vom Typ Dialog State Enum.

Abbildung A.3. Dialogbox zur Parameter¨ ubergabe bei Dialogen

158

A DiaGen Benutzerprotokoll

Das Resultat des Ja/Nein-Dialogs ist eine boolsche Variable, die ebenfalls per einfacher Dialogbox hinzugef¨ ugt werden kann, wie auf Abbildung A.4 zu sehen ist.

Abbildung A.4. Dialogbox zur Eingabe des Dialogresultats

Um die Durchl¨ aufe innerhalb des Dialogs zu z¨ahlen und dem Benutzer bei wiederholter Eingabe eine Hilfestellung geben zu k¨onnen, wird eine Z¨ahlvariable ben¨ otigt. Diese wird innerhalb des Dialogs per Rechtsklick lokal definiert, wie Abbildung A.5 zeigt.

Abbildung A.5. Dialogbox zur Definition einer lokalen Variable

Im ersten Dialogschritt wird zuerst die Vorbereitung der Spracherkennung angestoßen, daf¨ ur wird per Rechtsklick ein Funktionsaufruf eingesetzt und ahlt. Als Parameter wird DialogState selektiert. fn Recog Prepare ausgew¨ Nach diesem Aufruf wird per Rechtsklick ein Switch u ¨ber die m¨oglichen Dialogzust¨ ande eingef¨ ugt. Nun m¨ ussen f¨ ur die einzelnen Zust¨ande Prompts vergeben werden. Dies kann mit DiaGen ebenfalls sehr einfach u ¨ber das Kon-

A DiaGen Benutzerprotokoll

159

textmen¨ u erledigt werden. Um den Benutzer bei eventuellen Eingabefehlern zu unterst¨ utzen, sollten in Abh¨ angigkeit der Z¨ahlvariablen unterschiedliche Prompts vergeben werden. Die entsprechende Abfrage kann auch einfach u ¨ber das Kontextmen¨ u mit dem Punkt Add Switch Statement erzeugt werden. Bei Auswahl der Integervariablen werden sogar automatisch die ersten drei Werte vorgegeben. F¨ ur den Zustand Dialog State YesNo TMC k¨onnen jetzt beispielsweise verschiedene Prompts in Abh¨ angigkeit der Z¨ahlvariablen aufgerufen werden. Um einen Prompt zu setzen kann auch wieder einfach das Kontextmen¨ u aktiviert werden, jetzt sollte der Punkt Add Prompt Call ausgew¨ ahlt werden. In der erscheinenden Dialogbox sollte die Option Add new prompt gew¨ ahlt werden. Nun kann der Name, wie auf Abbildung A.6 gezeigt, eingegeben werden. Der Prompt wird automatisch in der Promptdefinitionsda¨ tei eingetragen und definiert, ein Promptbody f¨ ur die Außerung wird ebenfalls automatisch erzeugt. Wenn der Name f¨ ur das Konzept best¨atigt wird, kann in der folgenden Dialogbox der Prompttext eingegeben werden. Im aktuellen Fall sollte f¨ ur den ersten Prompt z.B. folgendes eingegeben werden: Neue Verkehrsmeldung verf¨ ugbar. M¨ ochten Sie die Nachricht anh¨ oren? F¨ ur den Fall der erneuten Erkennung, wird nach dem selben Schema ein erneuter Prompt erstellt, der Prompttext k¨ onnte hier lauten: Sagen Sie "ja" um die Verkehrsmeldung zu h¨ oren, sonst sagen Sie "nein".

Abbildung A.6. Dialogbox zur Eingabe eines neuen Promptnamens

F¨ ur die restlichen m¨ oglichen Zust¨ ande k¨ onnen auf die gleiche komfortable Weise wieder entsprechende Prompts definiert und erstellt werden. Anschließend muss die Erkennung durchgef¨ uhrt werden. Daf¨ ur muss ein neuer Dialogschritt erstellt werden, zu dem nach Erledigung des ersten auch verwiesen werden muss. Auch f¨ ur diese Aktion stehen einfache Kontextmen¨ ueintr¨age zur Verf¨ ugung.

160

A DiaGen Benutzerprotokoll

In diesem Schritt sollte die Z¨ ahlvariable automatisch erh¨oht werden, dies muss manuell durch Eingabe folgender Zeile geschehen: Nun kann die eigentliche Spracherkennung stattfinden. Daf¨ ur muss lediglich die entsprechend bereits im Dialogframework vorhandene Funktion aufgerufen werden. Dies geht wieder u ueintrag Add Function ¨ber den Kontextmen¨ Call Reference. In der erscheinenden Combo-Box sollte fn Recog Speech selektiert werden. Es erscheint eine Dialogbox welche den Benutzer automatisch darauf hinweist, dass diese Funktion einen R¨ uckgabewert liefert. Nun muss aus den im aktuellen Namensraum bekannten Variablen eine passende Variable zur Aufnahme der R¨ uckgabe ausgew¨ ahlt werden. Alternativ kann auch an dieser Stelle eine neue Variable erstellt werden. Letzteres ist in diesem Falle sinnvoll, da die Variable bisher lediglich global vorhanden ist, an dieser Stelle aber lokal ben¨ otigt wird. Wenn der Name eingegeben ist, wird die Variable automatisch syntaktisch korrekt definiert und verkn¨ upft mit dem R¨ uckgabewert der gerufenen Funktion zur Spracherkennung. Wieder muss eine Abfrage der Variable mittels Switch erzeugt werden, dabei darf nur der Gut-Fall weiterverarbeitet werden. Sollte es bei der Erkennung zu Fehlern gekommen sein, sollte hier wieder zur¨ uck zum vorherigen Schritt gesprungen werden. In diesem Fall soll dann der Prompt f¨ ur die erneute Nachfrage gespielt werden. Wenn die Spracherkennung ohne Fehler funktioniert hat, sollte in den n¨ achsten Dialogschritt gesprungen werden. In diesem wird jetzt das FeatureValue (vgl. Abschnitt 5.3.2) automatisch abgefragt. Dazu muss lediglich die Grammatikansicht von DiaGen ge¨ offnet werden u ¨ber Ctrl+M oder GDML Assistance - Open Grammar File. Anschließend muss die verwendete Grammatikregel markiert und ein Grammatik-Feature mit Doppelklick ausgew¨ahlt werden, nun muss noch eine Variable gew¨ ahlt werden, in welcher das Ergebnis gespeichert wird. Wird z.B. cmd ausgew¨ ahlt, muss die Variable wie auf Abbildung A.7 dargestellt selektiert werden.

Abbildung A.7. Dialogbox zur Auswahl einer Variable f¨ ur Erkennergebnisse

Wird die Variable ausgew¨ ahlt wird automatisch eine Switch-Case Anweisung f¨ ur alle in der Grammatik vorhandenen Alternativen erstellt. Dies ist sehr komfortabel und spart dem Entwickler den Aufwand, den Dialog st¨andig mit

A DiaGen Benutzerprotokoll

161

der Grammatik vergleichen zu m¨ ussen. Gleichzeitig kann durch diese Maßnahme verhindert werden, interne Fehler im Dialog zu erzeugen, wie sie in Abschnitt 4.2 beschrieben wurden. Da es sich bei dem vorliegenden Dialog um einen Ja/Nein Dialog handelt, muss noch je nach Abh¨ angigkeit des Wertes die boolsche R¨ uckgabevariable auf true bzw. false gesetzt werden und der Ja/Nein Dialog ist fertig. TMC-Service einbinden Wie bereits in Kapitel 8 dargestellt wurde, ist zur Simulation der TMCMeldungen der TMC-Service erstellt worden. Dieser ist f¨ ur die gesamte Funktionalit¨ at einer ankommenden Meldung und deren Inhalt verantwortlich. Um die Funktionalit¨ at nun in den Dialog einfließen zu lassen, werden die bereits in Abschnitt 5.2.1 eingef¨ uhrten Systemcalls verwendet. Um die f¨ ur den TMC-Service ben¨ otigten Methoden zu definieren, bietet DiaGen die M¨oglichkeit, schnell und einfach eine Systemcall-Definition zu erstellen. Dies geschieht u ¨ber die bereits bekannte Methode, eine neue GDML Datei anzulegen mittels Ctrl+D bzw. File - New GDML Dialog. In der erscheinenden Dialogbox wird dann eine Systemcall-Definition gew¨ ahlt, wie auf Abbildung A.8 zu sehen ist. Ist die Definitionsdatei bereits in einem anderen Projekt vorhanden, bietet DiaGen auch die M¨ oglichkeit, diese mit der Funktion des Datei-Imports per Ctrl+I oder File - Import GDML File in das aktuelle Projekt einzubinden.

Abbildung A.8. Dialogbox zur Erstellung einer neuen Systemcall-Datei

In der neuen Datei muss zuerst per Kontextmen¨ u das neue Event f¨ ur den proaktiven Dialogstart definiert werden. Anschließend wird eine Aufz¨ahlungsvariable ben¨ otigt, um die m¨ oglichen Umleitungsalternativen der TMC-Mel-

162

A DiaGen Benutzerprotokoll

dung aufzunehmen. Als Umleitungsalternativen exitieren folgende vier M¨oglichkeiten: • lediglich eine Umleitung u ¨ber die schnellste Strecke • die Wahl zwischen sch¨ oner Strecke und schnellster Strecke • die Wahl zwischen einer nahen Sehensw¨ urdigkeit und schnellster Strecke • die Auswahl zwischen allen drei M¨ oglichkeiten Die entsprechende Variable kann ganz einfach u u und ¨ber das Kontextmen¨ die Auswahl von Add New Enum gesetzt werden. Abbildung A.9 illustriert die Eingabe f¨ ur die neue Variable.

Abbildung A.9. Dialogbox zur Erstellung einer neuen Aufz¨ ahlungsvariable

Sollte eine Sehensw¨ urdigkeit als Alternative zur Verf¨ ugung stehen, wird zu ihrer Klassifikation eine weitere Aufz¨ ahlungsvariable ben¨otigt. Diese sollte u ¨ber den gleichen Weg als Variable mit Namen TMC SightType enum mit folgenden Elementen definiert werden: TMC_Sight_None,TMC_Sight_Church,TMC_Sight_City, TMC_Sight_Historic,TMC_Sight_Landscape,TMC_Sight_Museum, TMC_Sight_Park Nach der Deklaration der n¨ otigen Variablen folgen nun die beiden TMCFunktionen. Dabei k¨ onnen die eben deklarierten Variablen ggf. einfach referenziert werden, ein großer Vorteil der Nutzung von DiaGen. Per Kontextmen¨ u und Auswahl des Punkts Add New GDML System Call (welcher nur in Systemcall-Definitions Dateien zur Verf¨ ugung steht) kann der Name des neuen Calls eingegeben werden, wie es in Abbildung A.10 dargestellt ist. Wird diese Box mit Ok best¨ atigt fragt DiaGen sofort die Parameter des Calls ab. In diesem Fall soll die Sprachenkennung (z.B. de_DE f¨ ur Deutsch) als Parameter an den Service u ¨bergeben werden, um den Text ohne Probleme im Dialog nutzen zu k¨ onnen. Der Parameter wird also wie in Abbildung A.11 dargestellt definiert.

A DiaGen Benutzerprotokoll

163

Abbildung A.10. Dialogbox zur Namenseingabe eines neuen Systemcalls

Abbildung A.11. Dialogbox zur Eingabe der Systemcall Parameter

Als n¨ achstes wird der R¨ uckgabewert definiert, welcher in diesem Fall die TMC-Nachricht in Textform als String enth¨ alt. Die Eingabe der Variablen geschieht dabei u ¨ber eine Dialogbox analog der in Abbildung A.4 dargestellten. Damit ist der erste von zwei Systemcalls erfolgreich definiert worden. Der n¨ achste wird analog des obigen Verfahrens erstellt. Dieser Call wird TMC GetOptions genannt, erh¨ alt als Parameter ebenfalls die Spracheninformation und liefert gleich drei Resultate zur¨ uck: zum einen die Umleitungsalternativen des zuvor deklarierten Typs TMC Options enum, dann mit urdigkeiten und schlussendlich TMC SightType enum den Typ der Sehensw¨ noch den Namen der Sehensw¨ urdigkeit. Damit ist die Definition der Schnittstelle zum TMC-Service abgeschlossen. Um die definierten Funktionen einfach im Dialog nutzen zu k¨onnen, gleichzeitig unabh¨ angig von eventuellen Schnittstellen¨anderungen zu sein und außerdem einfaches Debugging der Schnittstellen nach außen zu erlauben, macht es Sinn, eine Kapselung dieser Definitionen vorzunehmen. Dies ist mit DiaGen sehr einfach m¨ oglich, da einfach nur Ctrl+L oder GDML Assistance - Import Systemcall Definition File ausgew¨ ahlt werden muss, der restliche Vorgang erfolgt vollautomatisch. Im resultierenden Dialogmodul k¨onnen nun von Hand ¨ etwaig ben¨ otigte Anderungen vorgenommen werden, ohne die Schnittstelle zum TMC-Service ver¨ andern zu m¨ ussen.

164

A DiaGen Benutzerprotokoll

TMC-Dialog in GDML hinzuf¨ ugen Jetzt sollen die neuen TMC-Funktionalit¨ aten in einem Dialog gekapselt werden. Daf¨ ur wird ein neuer GDML Dialog ben¨ otigt, der u ¨ber Ctrl+D oder File - New GDML Dialog zum Projekt hinzugef¨ ugt wird. Die Dialogbox dieses Vorgangs ist auf Abbildung A.2 abgebildet. Die neue Datei wird dlg tmc.gdml genannt. Diese Datei muss editiert und Funktionalit¨ at hinzugef¨ ugt werden. Dazu wird per Rechtsklick eine GDML Dialogdefinition mit dem Namen dlg tmc in die Datei eingef¨ ugt. Um den gleich zu erfolgenden Ja/Nein Dialog korrekt zu initialisieren, wird innerhalb des Dialogs eine lokale Variable vom Typ Dialog State enum definiert und im ersten Dialogschritt auf Dialog State YesNo TMC gesetzt. Nun kann der zuvor erstellte Ja/Nein Dialog referenziert werden. Dazu wird die Funktionalit¨ at von DiaGen zum Aufruf eines Dialogs verwendet, als Parameter wird die Zustandsvariable u uckgabevaria¨bergeben und die n¨otige boolsche R¨ ble wird automatisch als lokale Variable erstellt. Nun wird per Kontextmen¨ u ein Switch u ¨ber die boolsche Variable erstellt. F¨ ur eine negative R¨ uckgabe (der Benutzer m¨ ochte keine Information vom System h¨ oren) wird der Dialog abgebrochen und auf die entsprechende Funktion verwiesen, im anderen Fall geht der Dialog im n¨achsten Dialogschritt weiter. Hier wird zuerst die TMC-Meldung vom Service abgeholt. Da der Service eine Information u ¨ber die eingestellte Sprache ben¨otigt, wird die bereits im automatisch erstellten Projekt enthaltene Variable als Parameter u ¨bergeben. Da die passenden Variablen bereits automatisch angezeigt werden, muss nur noch die korrekte Variable selektiert werden. Die TMC-Meldung im Klartext wird an eine neu zu erstellende lokale Variable u ¨bergeben. Anschließend wird sofort die zweite neu erstellte Funktion des TMC-Services aufgerufen, um die weiteren Einzelheiten der Meldung an den Dialog zu u ¨bergeben. Wird dieser Aufruf referenziert, findet DiaGen keine Variable des ben¨otigten Typs und bittet daher automatisch um die Deklaration einer neuen Variablen, wie f¨ ur die Umleitungsm¨ oglichkeiten als erstem Resultat in Abbildung A.12 dargestellt ist. Nun soll zuerst der Inhalt der TMC-Meldung an einen wieder u ¨ber das Kontextmen¨ u erstellten neuen Prompt u ¨bergeben werden. Dieser wird ohne Text definiert und erh¨ alt einzig und allein den Inhalt der TMC-Meldung als Argument, wie in Abbildung A.13 zu sehen ist. Im Anschluss erfolgt eine weitere Abfrage, ob der Benutzer auf Grund der vorgelesenen Meldung der Umleitung folgen will oder nicht. Hier wird wieder der Ja/Nein Dialog referenziert, als Dialogzustand wird jetzt die Abfrage Dialog State YesNo Detour gew¨ ahlt. Beantwortet der Benutzer die Frage mit nein, wird der Dialog wieder beendet. Im anderen Fall wird ein neuer Dialog aufgerufen, in dem die Art der Umleitung erfragt wird.

A DiaGen Benutzerprotokoll

165

Abbildung A.12. Dialogbox zur Deklaration einer neuen Systemcall ResultVariablen

Abbildung A.13. Dialogbox zur Eingabe des Promptparameters

Abfragedialog zur Umleitungsart hinzuf¨ ugen ¨ Uber das Kontextmen¨ u wird ein neuer Dialog erstellt. Dieser GDML Dialog wird allerdings in der selben Datei verwaltet, da die Funktionalit¨at sehr eng zum bisherigen dazugeh¨ ort. Dieser neue Dialog ben¨otigt als Parameter die R¨ uckgabewerte von TMC GetOptions. Die Variablen sollten entsprechend getypt sein. DiaGen bietet hier die Typen zur Auswahl an, so dass die Erstellung der neuen Dialogdefinition wieder sehr vereinfacht wird. Das weitere Vorgehen ist hier analog zur Erstellung des Ja/Nein Dialogs. Erst wird die Z¨ahlvariable hinzugef¨ ugt, um nach Benutzerfehlern entsprechend ausf¨ uhrlichere Prompts zu erm¨ oglichen, dann wird nach der M¨oglichkeit der Umleitungsalternativen (also dem Inhalt der Variable TMC Options) verzweigt. F¨ ur den Fall, dass es nur eine Alternative gibt, muss keine weitere Nachfrage mehr gestellt werden, daher kann hier dem Benutzer direkt eine Best¨ atigung gegeben werden, bevor der Dialog beendet wird. Da in den u allen eine Alternative zur Wahl steht, wird der Dialogzustand f¨ ur ¨brigen F¨

166

A DiaGen Benutzerprotokoll

die entsprechenden Wahlm¨ oglichkeiten gesetzt und der Spracherkenner damit initialisiert. Nun wird im n¨ achsten anzulegenden Dialogschritt wieder die Z¨ahlvariable inkrementiert und entsprechend der Erkenner aufgerufen. Ebenso wie im Ja/Nein Dialog wird dann automatisch eine Verzweigung u ¨ber die m¨oglichen Erkennergebnisse erstellt. F¨ ur jeden Fall wird dann entsprechend ein passender Dialogprompt erstellt. Abschließend endet der Dialog. Fazit Wie in diesem Protokoll dargestellt wurde, bietet DiaGen durch viele Funktionalit¨ aten einen Vorteil gegen¨ uber der manuellen Codeentwicklung. Wesentlich ist allerdings nicht die Zeitersparnis bei der Erstellung umfangreichen Quellcodes, vielmehr ist es die schnelle Entwicklung benutzerfreundlicher und konsistenter Dialoge, welche die Verwendung von DiaGen bietet. Zahlreiche u ¨bliche Fehlerquellen bei der Entwicklung k¨onnen bei der konsequenten Verwendung von DiaGen ausgeschlossen werden. Dies gilt umso mehr f¨ ur die nur sehr schlecht testbaren Fehler bei Inkonsistenzen zwischen Grammatik und Dialog.

B Beispieldialog

In diesem Abschnitt werden zwei Durchl¨ aufe des TMC-Dialogs gezeigt. Im ersten Fall wird nur ein Beispiel mit einer simplen Umleitungsempfehlung dargestellt, im zweiten eines mit Umleitungsalternativen vorgestellt.

B.1 Ohne Umleitungsalternativen System Neue Verkehrsmeldung verf¨ ugbar, m¨ ochten Sie die Nachricht anh¨oren? Fahrer Ja. System In 10 km Vollsperrung der A7 zwischen den Ausfahrten 118 Niederstotzingen und 117 Giengen/Herbrechtingen. Es wird empfohlen, die Autobahn zu verlassen. Soll eine neue Route berechnet werden? Fahrer Ja, bitte. System Die Umleitung u ¨ber die schnellste Strecke wird berechnet.

B.2 Mit Umleitungsalternativen System Neue Verkehrsmeldung verf¨ ugbar, m¨ ochten Sie die Nachricht anh¨oren? Fahrer Ja. System In 7 km Stau von 10 km L¨ ange auf der A7 zwischen den Ausfahrten 43 Bispingen und 44 Soltau-Ost. Es wird empfohlen, die Autobahn zu verlassen. Soll eine neue Route berechnet werden? Fahrer Ja, bitte. System M¨ ochten Sie die schnellste Strecke fahren, eine sch¨one Strecke fahren oder lieber eine nahe Sehensw¨ urdigkeit besuchen? Fahrer Was ist das f¨ ur eine Sehensw¨ urdigkeit? System Sie befinden sich in der N¨ ahe der wundersch¨onen Landschaft L¨ uneburger Heide. Soll diese Sehensw¨ urdigkeit als Ziel u ¨bernommen werden?

168

B Beispieldialog

Fahrer Ja, gerne. System Die Route zur Landschaft L¨ uneburger Heide wird berechnet.

C Fragebogen

In diesem Abschnitt ist der f¨ ur die Evaluation des Beispieldialogs verwendete Fragebogen abgebildet. Zuerst wurde die Vorbefragung durchgef¨ uhrt:

170

C Fragebogen

Nach dem Versuch folgte die Nachbefragung:

C Fragebogen

171

Nach einem erneuten Abspielen der TMC-Meldung wurden folgende Fragen gestellt:

Abbildungsverzeichnis

1.1 1.2

Schematischer Aufbau eines Dialogsystems . . . . . . . . . . . . . . . . . . Schematischer Aufbau des Schichtenmodells der Sprachdialogmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 5

2.1

Verschiedene Eingangsprompts f¨ ur einen Navigationsdialog . . . . 25

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15

¨ Uberfrachtetes Armaturenbrett im Kfz . . . . . . . . . . . . . . . . . . . . . . Schematische Systemarchitektur eines SBS . . . . . . . . . . . . . . . . . . Headunit der Mercedes-Benz E-Klasse . . . . . . . . . . . . . . . . . . . . . . Hardwaremodul eines SDS aus dem Audi A8 . . . . . . . . . . . . . . . . . Headunit und PTT-Hebel in Mercedes-Benz E-Klasse . . . . . . . . . Headunit und PTT im Audi A8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Headunit und PTT im BMW 7er . . . . . . . . . . . . . . . . . . . . . . . . . . . Nummerndialog eines aktuellen Sprachbediensystems . . . . . . . . . Namensdialog eines aktuellen Sprachbediensystems . . . . . . . . . . . Navigationsdialog eines aktuellen Sprachbediensystems . . . . . . . . Schematische Systemarchitektur eines serverbasierten SDS . . . . . Die Systemarchitektur von ISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispieldialog mit ISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispieldialog mit Bahnauskunft der DB AG . . . . . . . . . . . . . . . . . Beispieldialog mit der Philips-Bahnauskunft . . . . . . . . . . . . . . . . .

4.1

Dialogbox mit Individualisierungsm¨ oglichkeit . . . . . . . . . . . . . . . . 73

5.1 5.2 5.3 5.4 5.5 5.6 5.7

Werkzeuge zur Erstellung eines GDML-Dialogs . . . . . . . . . . . . . . . Definition der Promptkonzepte in GDML f¨ ur Demo-Dialog . . . . Demo-Dialog in GDML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Demo-Dialog in VoiceXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ja/Nein-Grammatik in BNF-Notation . . . . . . . . . . . . . . . . . . . . . . Ja/Nein-Grammatik in JSGF-Notation . . . . . . . . . . . . . . . . . . . . . Ja/Nein-Grammatik in SRGS-Notation . . . . . . . . . . . . . . . . . . . . .

28 36 40 42 43 43 44 45 45 47 52 54 55 57 57

83 84 85 92 96 97 98

174

Abbildungsverzeichnis

6.1 6.2

Beispieldialog im RAD des CSLU-Toolkits . . . . . . . . . . . . . . . . . . . 103 Beispieldialog in VoiceObjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9

Tooltip bei der Projekterstellung mit DiaGen . . . . . . . . . . . . . . . . 118 DiaGen mit Navigationsfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Kontextmen¨ u von DiaGen innerhalb eines GDML <step> . . . . . 120 Erstellung eines neuen Projekts mit DiaGen . . . . . . . . . . . . . . . . . 121 Fehlgeschlagene Kompilierung mit selektierter Fehlerstelle . . . . . 123 Grammatikfenster von DiaGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Automatisch eingef¨ ugte Verzweigung f¨ ur ein Grammatik-Tag . . . 125 ¨ Warnung bei der Ubergabe von Listen als Promptparameter . . . 126 ¨ Warnung bei der Ubergabe von mehr als vier Promptparametern126

8.1 8.2 8.3 8.4

Schematischer Dialogablauf im TMC-Dialog . . . . . . . . . . . . . . . . . 134 Graphische Benutzeroberfl¨ ache des TMC-Service . . . . . . . . . . . . . 136 Dummy-Headunit in Demofahrzeug . . . . . . . . . . . . . . . . . . . . . . . . . 138 Graphische Anzeige bei eintreffender TMC-Meldung . . . . . . . . . . 143

A.1 Dialogbox in DiaGen zur Erstellung eines neuen Projekts . . . . . . 154 A.2 Dialogbox zur Integration eines neuen GDML-Dialogs ins Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 A.3 Dialogbox zur Parameter¨ ubergabe bei Dialogen . . . . . . . . . . . . . . 157 A.4 Dialogbox zur Eingabe des Dialogresultats . . . . . . . . . . . . . . . . . . . 158 A.5 Dialogbox zur Definition einer lokalen Variable . . . . . . . . . . . . . . . 158 A.6 Dialogbox zur Eingabe eines neuen Promptnamens . . . . . . . . . . . 159 A.7 Dialogbox zur Auswahl einer Variable f¨ ur Erkennergebnisse . . . . 160 A.8 Dialogbox zur Erstellung einer neuen Systemcall-Datei . . . . . . . . 161 A.9 Dialogbox zur Erstellung einer neuen Aufz¨ahlungsvariable . . . . . 162 A.10 Dialogbox zur Namenseingabe eines neuen Systemcalls . . . . . . . . 163 A.11 Dialogbox zur Eingabe der Systemcall Parameter . . . . . . . . . . . . . 163 A.12 Dialogbox zur Deklaration einer neuen Systemcall Result-Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 A.13 Dialogbox zur Eingabe des Promptparameters . . . . . . . . . . . . . . . 165

Tabellenverzeichnis

5.1

Vergleich der wichtigsten Codeelemente von VoiceXML und GDML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

8.1 8.2 8.3 8.4 8.5 8.6 8.7

Statistische Daten der Probanden . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Antworten auf die Frage nach einem eigenen Navigationssystem 140 Zusammenfassung der Erlebnisse w¨ ahrend des Tests . . . . . . . . . . 142 Antworten der ersten Nachbefragung . . . . . . . . . . . . . . . . . . . . . . . . 142 Alternativen zum Umgang mit TMC-Meldungen . . . . . . . . . . . . . 144 Zusammenfassung des Memorierungstests . . . . . . . . . . . . . . . . . . . 144 Zusammenfassung zur Frage nach Umleitungsalternativen . . . . . 145

Abku ¨ rzungsverzeichnis

AAC

Advanced Audio Coding (Audio-Dateiformat)

ABNF

angereicherte BNF

ACCeSS

Automated Call Center through Speech understanding System (EU-Projekt)

AGP

Application Generation Platform

ASR

Automatic Speech Recognition

BASt

Bundesanstalt f¨ ur Straßenwesen (Bergisch-Gladbach)

BNF

Backus-Naur-Form

CAN

Controller Area Network (Datenbus der Automobilindustrie)

CCXML

Call Control Extensible Markup Language

CFG

Context-Free Grammar

CGI

Common Gateway Interface

CHAT

Conversational Helper for Automotive Tasks (US-Forschungsprojekt)

COMAND

Cockpit Management and Data System (FIS bei Mercedes-Benz)

CSLU-Toolkit

Werkzeug zur Dialogerstellung, entwickelt am CSLU

D2B

Domestic Digital Data Bus (Datenbus der Automobilindustrie)

D3

Bezeichnung f¨ ur den Audi A8 Modelljahr 2003

DDL

Dialogue Description Language

178

Tabellenverzeichnis

DDS

Dialog Development Studio

DiaGen

Dialog Generator

DiaMod

Dialog Modeling Tool System

DIN

Norm des Deutschen Instituts f¨ ur Normung e.V. (Berlin)

DLL

Dynamic Link Library

DM

Dialogue Manager

DSP

Digital Sound Processor

DSR

Dasa/Digital Speech Recognizer

DTD

Document Type Definition

DTMF

Dual Tone Multi Frequency (Tastenton vom Telefon)

E60

Bezeichnung f¨ ur den BMW 5er Modelljahr 2006

E65

Bezeichnung f¨ ur den BMW 7er Modelljahr 2001

ECMA

European Association for Standardizing Information and Communication Systems (Genf – CH)

EMMA

Extensible Multi-Modal Annotations (DDL)

EMV

Elektromagnetische Vertr¨aglichkeit

EN

Europ¨ aische Norm

FIA

Form Interpretation Algorithm (Steuerungsalgorithmus, der die Grundlage jedes VXI bildet)

FIS

Fahrerinformationssystem (HMI im Automobil)

FSE

Freisprecheinrichtung

G2P

Grapheme to Phoneme (Verfahren textuelle Daten automatisch f¨ ur die Spracherkennung aufzubereiten)

GDialogXML

GEMINI Dialog XML (DDL)

GDC

Generic Dialog Compiler

GDM

Generic Dialog Manager (DM)

GDML

Generic Dialog Modelling Language (DDL)

GDS

Grammar Development System

GEMINI

Generic Environment for Multilingual Interactive Natural Interfaces (EU-Projekt)

GRXML

Grammar XML (Name f¨ ur XML-Form von SRGS)

Tabellenverzeichnis

179

GSL

Grammar Specification Language

GUI

Graphical User Interface

HAL

Heuristic Algorithmic (ber¨ uhmter Film-Computer)

HAM-RPM

Hamburger Redepartner-Modell (Dialogsystem)

HBAS

Harman/Becker Automotive Systems GmbH (Karlsbad)

HDDL

(Harald’s) Dialogue Design Language (DDL)

HMI

Human Machine Interface

HMM

Hidden-Markov-Modell

HU

Headunit

HTML

Hypertext Markup Language

HTTP

Hypertext Transfer Protocol

ID3

Identify an MP3

IDAS

Interactive Directory Assistance Service (EU-Projekt)

IDE

Integrated Development Environment

ISA

IBM Stau Applikation

ISO

International Organization for Standardization (Genf – CH)

IVR

Interactive Voice Response (Bez. f¨ ur SDS am Telefon)

JSGF

Java Speech Grammar Format

LCL

Location Code List (Liste der Namen von BABAusfahrten etc. f¨ ur TMC-Meldungen)

LCT

Lane Change Task

MFL

Multifunktionslenkrad

MMI

Multi-Media Interface (FIS bei Audi)

MP3

MPEG-1 Audio Layer 3 (Audio-Dateiformat)

MTBF

Mean Time Between Failure

MOST

Media Oriented Systems Transport (Datenbus der Automobilindustrie)

OEM

Original Equipment Manufacturer

OOV

Out Of Vocabulary

PARADISE

Paradigm for Dialogue System Evaluation

180

Tabellenverzeichnis

PLS

Pronunciation Lexicon Specification

PNA

Portable Navigation Assistant

PTT

Push To Talk (Bez. f¨ ur Startknopf in einem SDS)

QNX

Betriebssystem von QNX Software Systems (Ottawa – Kanada)

Qt

Plattformunabh¨ angiger Klassenaufsatz f¨ ur C++ (Trolltech)

RAD

Rapid Application Developer (Werkzeug aus dem CSLU-Toolkit)

RDF

Resource Description Framework

RDS

Radio Data System

REWARD

Real World Application of Robust Dialogs (EU-Projekt)

SALT

Speech Application Language Tags

SBS

Sprachbediensystem

SCXML

State Chart XML

SDS

Sprachdialogsystem

SHRDLU

Handlungssystem von Winograd

SIM

Subscriber Identity Module (Identifikationschip im Mobiltelefon)

SISR

Semantic Interpretation for Speech Recognition

SMS

Short Message Service

SPEECON

Speech-Driven Interfaces for Consumer Devices (EU-Projekt)

SRGS

Speech Recognition Grammar Specification

SSML

Speech Synthesis Markup Language

SSS

Speech Service System

SUNDIAL

Speech Understanding in Dialogue (EU-Projekt)

TABA

Telefonische Automatische Bahnfahrplan-Auskunft

Tcl

Tool Command Language

Temic

Telefunken Microelektronic GmbH (N¨ urnberg) (1992 von AEG-Telefunken und Dasa gegr¨ undet, heute Conti-Temic GmbH)

Tabellenverzeichnis

181

Temic SDS

Temic SDS GmbH – Speech Dialog Systems (Ulm) (Abspaltung des Bereichs Speech Processing von der Temic, von HBAS gekauft)

TMC

Traffic Message Channel

TPEG

Transport Protocol Experts Group

TRAINS

Dialogsystem auf G¨ uterzug-Dom¨ane

TTS

Text to Speech

UML

Unified Modeling Language

VERBMOBIL

¨ Automatisches Ubersetzungssystem (BMBF-Projekt)

VGA

Video Graphics Array

VoiceXML

Voice Extensible Markup Language (DDL)

VUI

Voice User Interface

VXI

VoiceXML Interpreter

VXML

Kurzform f¨ ur VoiceXML

W140

Bezeichnung f¨ ur die Mercedes S-Klasse Modelljahr 1991 - 1998

W204

Bezeichnung f¨ ur die Mercedes C-Klasse Modelljahr 2007

W211

Bezeichnung f¨ ur die Mercedes E-Klasse Modelljahr 2003

W220

Bezeichnung f¨ ur die Mercedes S-Klasse Modelljahr 1998 - 2005

W221

Bezeichnung f¨ ur die Mercedes S-Klasse Modelljahr 2005

W3C

World Wide Web Consortium (Cambridge – USA)

WMA

Windows Media Audio (Audio-Dateiformat)

WML

Wireless Markup Language

WOZ

Wizard of Oz

X+V

XHTML + VoiceXML

xHMI

Extensible Human Machine Interface (DDL)

XHTML

Extensible Hypertext Markup Language

XML

Extensible Markup Language

Literatur

[Ackermann und Libossek 2006] Ackermann, C. und Libossek, M. System- versus User-Initiative Dialog Strategy for Driver Information Systems. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 457–460. [ADAC 2004] Allgemeiner Deutscher Automobil-Club e. V. (Hrsg.). Digitaler Verkehrsfunk TMC. ADAC Praxistest, ver¨ offentlicht unter http://www.adac.de/images/TMC-2004-Testbericht tcm8-103288.pdf, 2004. [Akyol et al. 2001] Akyol, S.; Libuda, L. und Kraiss, K.-F. Multimodale Benutzung adaptiver Kfz-Bordsysteme. In: J¨ urgensohn, T. und Timpe, K.-P. (Hrsg.): Kraftfahrzeugf¨ uhrung. Springer, Heidelberg, 2001. [Allen et al. 1982] Allen, J. F.; Frische, A. M. und Litman, D. J. ARGOT: The Rochester Dialog System. In: Proceedings of the Annual Meeting of the American Association of Artificial Intelligence (AAAI). Pittsburgh, USA, 1982, Seiten 66–70. [Allen et al. 1996] Allen, J. F.; Miller, B. W.; Ringger, E. K. und Sikorski, T. Robust Understanding in a Dialogue System. In: Proceedings of the Annual Meeting of the Association for Computational Linguistics (ACL). Santa Cruz, USA, 1996. [Alton-Schneidl 2003] Alton-Schneidl, R. Community Radio Stations use publicVoiceXML. VoiceXML Review, Bd. 3, Nr. 2, 2003. [Aust 1998] Aust, H. Sprachverstehen und Dialogmodellierung in nat¨ urlichsprachlichen Informationssystemen. Dissertation, Mathematisch-Naturwissenschaftliche Fakult¨ at, Rheinisch-Westf¨ alische Technische Hochschule Aachen, Aachen, 1998. [Aust et al. 1995] Aust, H.; Oerder, M.; Seide, F. und Steinbiss, V. The Philips Automatic Train Timetable Information System. Speech Communication, Bd. 17, 1995, Seiten 249–262. [Austin 1962] Austin, J. L. How to do Things With Words. Harvard University Press, Cambridge, USA, 1962. [Averbuch et al. 1986] Averbuch, A.; Bahl, L.; Bakis, R.; Brown, P.; Cole, A.; Daggett, G.; Das, S.; Davies, K.; DeGennaro, S.; de Souza, P.; Epstein, E.; Fraleigh, D.; Jelinek, F.; Katz, S.; Lewis, B.; Mercer, R.; Nadas, A.; Nahamoo, D.; Picheny, M.; Shichman, G. und Spinelli, P. An IBM PC based Large-Vocabulary IsolatedUtterance Speech Recognizer. In: Proceedings of the International Conference on Acoustics, Speech and Signal Processing (ICASSP). Tokyo, Japan, 1986, Seiten 53–56.

184

Literatur

[Axelsson et al. 2004] Axelsson, J.; Cross, C.; Ferrans, J.; McCobb, G.; Raman, T. W. und Wilson, L. XHTML + Voice Profile 1.2. Ver¨ offentlicht unter http://www.voicexml.org/specs/multimodal/x+v/12/, 2004. [Bachfischer et al. 2007] Bachfischer, K.; Bohnenberger, T.; Hofmann, M.; W¨ aller, C. und Wu, Y. Kontext-adaptive Fahrerinformationssysteme am Beispiel eines Navigationssystems. KI – K¨ unstliche Intelligenz, Bd. 21, Nr. 3, 2007, Seiten 57– 63. [Baggia et al. 2007] Baggia, P.; Burnett, D. C.; Carter, J.; Dahl, D. A.; McCobb, G. und Raggett, D. EMMA: Extensible MultiModal Annotation markup language. W3C Candidate Recommendation, ver¨ offentlicht unter http://www.w3.org/TR/emma/, 2007. [Bahl et al. 1993] Bahl, L.; de Souza, P.; Gopalakrishnan, P.; Nahamoo, D. und Picheny, M. Context-Dependent Vector Quantization for Continuous Speech Recognition. In: Proceedings of the International Conference on Acoustics, Speech and Signal Processing (ICASSP). Minneapolis, USA, 1993. [Barnett et al. 2008] Barnett, J.; Akolkar, R.; Auburn, R.; Bodell, M.; Burnett, D. C.; Carter, J.; McGlashan, S.; Lager, T.; Helbing, M.; Hosn, R.; Raman, T. und Reifenrath, K. State Chart XML (SCXML): State Machine Notation for Control Abstraction. W3C Working Draft, ver¨ offentlicht unter http://www.w3c.org/TR/scxml/, 2008. [BASt 2005] Bundesanstalt f¨ ur Straßenwesen (Hrsg.). Jahresbericht 2004. Berichte der Bundesanstalt f¨ ur Straßenwesen, Heft A 28, ver¨ offentlicht unter http://www.bast.de/, 2005. [Baudoin et al. 2005] Baudoin, F.; Bretier, P. und Corruble, V. A Dialogue Agent with Adaptive and Proactive Capabilities. In: Proceedings of the International Agent Technology Conference (IAT). Compiegne, Frankreich, 2005, Seiten 293– 296. [Bazzi und Glass 2000] Bazzi, I. und Glass, J. R. Modelling Out-Of-Vocabulary Words for Robust Speech Recognition. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Peking, China, 2000, Seiten 401–404. [Bennett et al. 2002] Bennett, C.; Llitj´ os, A. F.; Shriver, S.; Rudnicky, A. und Black, A. W. Building VoiceXML-Based Applications. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Denver, USA, 2002, Seiten 2245–2248. [Bernsen et al. 1997] Bernsen, N. O.; Dybkjær, L. und Dybkjær, H. User Errors in Spoken Human-Machine Dialogue. In: Maier, E.; Mast, M. und LuperFoy, S. (Hrsg.): Dialogue Processing in Spoken Language Systems, Bd. 1236 der Reihe Lecture Notes in Artificial Intelligence. Springer, Heidelberg, 1997, Seiten 14–28. [Bernsen et al. 1998] Bernsen, N. O.; Dybkjær, H. und Dybkjær, L. Designing Interactive Speech Systems - From First Ideas to User Testing. Springer, London, Großbritannien, 1998. [Bernsen und Dybkjær 2001] Bernsen, N. O. und Dybkjær, L. Exploring natural interaction in the car. In: Proceedings of the CLASS Workshop on Natural Interactivity and Intelligent Interactive Information Representation. Verona, Italien, 2001. [Bernsen und Dybkjær 2005] Bernsen, N. O. und Dybkjær, L. User Evaluation of Conversational Agent H. C. Andersen. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Lissabon, Portugal, 2005, Seiten 2473–2476.

Literatur

185

[Berton et al. 2007] Berton, A.; Regel-Brietzmann, P.; Block, H.-U.; Schachtl, S. und Gehrke, M. How to Integrate Speech-Operated Internet Information Dialogs into a Car. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Antwerpen, Belgien, 2007, Seiten 2549–2552. [Boer 2001] Boer, E. R. Behavioral Entropy as a Measure of Driving Performance. In: Proceedings of the International Driving Symposium on Human Factors in Driver Assessment, Training and Vehicle Design. Aspen, USA, 2001, Seiten 225– 229. [Booch et al. 2005] Booch, G.; Rumbaugh, J. und Jacobson, I. Unified Modeling Language User Guide. Addison Wesley, Reading, USA, 2005. [Boros 2004] Boros, M. Pl¨ adoyer f¨ ur mehr Dialog-Bewusstsein. In: Tagungsband der 34. Jahrestagung der Gesellschaft f¨ ur Informatik e.V. – ’Informatik 2004’. Ulm, 2004, Seiten 230–231. [Boros et al. 1997] Boros, M.; Aretoulaki, M.; Gallwitz, F.; N¨ oth, E. und Niemann, H. Semantic Processing of Out-of-Vocabulary Words in a Spoken Dialogue System. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Rhodos, Griechenland, 1997, Seiten 1887–1890. [Boufaden und Dumouchel 2008] Boufaden, N. und Dumouchel, P. Leveraging Emotion Detection using Emotions from Yes-No Answers. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Brisbane, Australien, 2008, Seiten 241–244. [Brandstein und Ward 2001] Brandstein, M. und Ward, D. (Hrsg.). Microphone Arrays. Springer, Heidelberg, 2001. [Brøndsted et al. 1998] Brøndsted, T.; Bai, B. N. und Olsen, J. O. The REWARD Service Creation Environment, an Overview. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Sydney, Australia, 1998, Seiten 1175–1178. [B¨ uhler und Hamerich 2004] B¨ uhler, D. und Hamerich, S. W. Towards Embedding VoiceXML Applications Through Compilation. In: Tagungsband der ’Berliner XML-Tage 2004’. Berlin, 2004, Seiten 250–259. [B¨ uhler und Hamerich 2005] B¨ uhler, D. und Hamerich, S. W. Towards VoiceXML Compilation for Portable Embedded Applications in Ubiquitous Environments. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Lissabon, Portugal, 2005, Seiten 3397–3400. [Bußmann 2002] Bußmann, H. (Hrsg.). Lexikon der Sprachwissenschaft. Kr¨ oner Verlag, Stuttgart, 2002. [Cameron 2000] Cameron, H. Speech at the Interface. In: Proceedings of the International Workshop ’Voice Operated Telecom Services’, COST 249. Gent, Belgien, 2000, Seiten 1–7. [Cheng et al. 2004] Cheng, H.; Bratt, H.; Mishra, R.; Shriberg, E.; Upson, S.; Chen, J.; Weng, F.; Peters, S.; Cavedon, L. und Niekrasz, J. A Wizard of Oz Framework for Collecting Spoken Human-Computer Dialogs. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 2269–2272. [Chung 2004] Chung, G. Developing A Flexible Spoken Dialog System Using Simulation. In: Proceedings of the Annual Meeting of the Association for Computational Linguistics (ACL). Barcelona, Spanien, 2004, Seiten 63–70. [Cohen et al. 1990] Cohen, P. R.; Morgan, J. und Pollack, M. E. (Hrsg.). Intentions in Communication. MIT Press, Cambridge, USA, 1990.

186

Literatur

[Colman et al. 2008] Colman, M.; Eshghi, A. und Healey, P. G. T. Quantifzing Ellipsis in Dialogue: An Index of Mutual Understanding. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Columbus, USA, 2008, Seiten 96– 99. [van Compernolle 2000] van Compernolle, D. Recognizing speech of goats, wolves, sheep and ... non-natives. Speech Communication, Bd. 35, Nr. 1-2, 2000, Seiten 71–79. [de C´ ordoba et al. 2004] de C´ ordoba, R.; Fern´ andez, F.; Sama, V.; D’Haro, L. F.; San-Segundo, R. und Montero, J. M. Implementation of Dialog Applications in an Open-Source VoiceXML Platform. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 257–260. [Dahlb¨ ack et al. 1993] Dahlb¨ ack, N.; J¨ onsson, A. und Ahrenberg, L. Wizard of Oz studies: why and how. In: Proceedings of the International Conference on Intelligent User Interfaces (IUI). Orlando, USA, 1993, Seiten 193–200. [Davies et al. 1999] Davies, K.; Donovan, R.; Epstein, M.; Franz, M.; Ittycheriah, A.; Jan, E. E.; LeRoux, J. M.; Lubensky, D.; Neti, C.; Padmanabhan, M.; Papineni, K.; Roukos, S.; Sakrajda, A.; Sorensen, J. S.; Tydlitat, B. und Ward, T. The IBM Conversational Telephony System for Fincancial Applications. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Budapest, Ungarn, 1999, Seiten 275–278. [Denecke 2002] Denecke, M. Rapid Prototyping for Spoken Dialogue Systems. In: Proceedings of the International Conference on Computational Linguistics (COLING). Taipei, Taiwan, 2002. [Ding et al. 2008] Ding, F.; Nurminen, J. und Tian, J. Efficient Join Cost Computation for Unit Selection based TTS Systems. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Brisbane, Australien, 2008, Seiten 589–592. [Drosdowski 1990] Drosdowski, G. (Hrsg.). Duden – Fremdw¨ orterbuch. Dudenverlag, Mannheim, 1990. [Eckert et al. 1995] Eckert, W.; N¨ oth, E.; Niemann, H. und Schukat-Talamazzini, E.-G. Real Users behave Weird – Experience made collecting large HumanMachine-Dialog Corpora. In: Proceedings of the ESCA Workshop on Spoken Dialogue Systems. Vigsø, D¨ anemark, 1995, Seiten 193–196. [ECMA 1999] ECMA (Hrsg.). ECMA-262: ECMAScript Language Specification. Ver¨ offentlicht unter http://www.ecmainternational.org/publications/standards/Ecma-262.htm, 1999. [Ehrlich et al. 1997] Ehrlich, U.; Hanrieder, G.; Hitzenberger, L.; Heisterkamp, P.; Mecklenburg, K. und Regel-Brietzmann, P. ACCeSS - Automated Call Center through Speech Understanding System. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Rhodos, Griechenland, 1997, Seiten 1819–1822. [Failenschmid und Thornton 1998] Failenschmid, K. und Thornton, J. S. End-User Driven Dialogue System Design: The REWARD Experience. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Sydney, Australien, 1998, Seiten 37–40. ¨ [Fischer et al. 2007] Fischer, P.; Osterle, A.; Berton, A. und Regel-Brietzmann, P. How to Personalize Speech Applications for Web-based Information in a Car. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Antwerpen, Belgien, 2007, Seiten 2557–2560.

Literatur

187

[Frisch 2004] Frisch, J. Planung und Dialogdesign gelten als Schwachstellen. Computer Zeitung, Nr. 10, 2004, Seite 16. [G¨ artner et al. 2001] G¨ artner, U.; K¨ onig, W. und Wittig, T. Evaluation of Manual vs. Speech Input when Using a Driver Information System in Real Traffic. In: Proceedings of the International Driving Symposium on Human Factors in Driver Assessment, Training and Vehicle Design. Aspen, USA, 2001. [Gazdar und Mellish 1989] Gazdar, G. und Mellish, C. S. Natural Language Processing in Prolog: an Introduction to Computational Linguistics. Addison-Wesley, Wokingham, Großbritannien, 1989. [Georgila et al. 2004] Georgila, K.; Fakotakis, N. und Kokkinakis, G. A Graphical Tool for Handling Rule Grammars in Java Speech Grammar Format. In: Proceedings of the International Conference on Language Resources and Evaluation (LREC). Lissabon, Portugal, 2004, Seiten 615–618. [Georgila et al. 2006] Georgila, K.; Henderson, J. und Lemon, O. User Simulation for Spoken Dialogue Systems: Learning and Evaluation. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 1065–1068. [Geutner et al. 2002] Geutner, P.; Steffens, F. und Manstetten, D. Design of the VICO Spoken Dialogue System: Evaluation of User Expectations by Wizard-ofOz Experiments. In: Proceedings of the International Conference on Language Resources and Evaluation (LREC). Las Palmas de Gran Canaria, Spanien, 2002, Seiten 1588–1593. [GFU 2006] Gesellschaft f¨ ur Unterhaltungs- und Kommunikationselektronik (Hrsg.). CE im Auto – Vom ersten Autoradio zum mobilen Multimedia-Center. Ver¨ offentlicht unter: http://www.gfu.de/home/historie/autoradio.xhtml, 2006. [Gibbon et al. 1997] Gibbon, D.; Moore, R. und Winski, R. (Hrsg.). Handbook of Standards and Resources for Spoken Language Systems. Mouton de Gruyter, Berlin, 1997. [Goronzy und Beringer 2005] Goronzy, S. und Beringer, N. Integrated Development and on-the-Fly Simulation of Multimodal Dialogs. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Lissabon, Portugal, 2005, Seiten 2477–2480. [Goronzy et al. 2006] Goronzy, S.; Mochales, R. und Beringer, N. Developing Speech Dialogs For Multimodal HMIs Using Finite State Machines. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 1774–1777. [Grice 1975] Grice, P. Logic and Conversation. In: Cole, P. (Hrsg.): Syntax and Semantics: Speech Acts. Academic Press, New York, USA, 1975, Seiten 41–58. [Gruhn et al. 2004] Gruhn, R.; Markov, K. und Nakamura, S. A Statistical Lexicon for Non-Native Speech Recognition. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 1497–1500. [G¨ unther et al. 2000] G¨ unther, C.; Hamerich, S. W.; Kunzmann, S. und Roß, T. ISA: A Traffic Jam Information System based on the IBM ViaVoice Telephony Toolkit. In: Proceedings of the International Workshop ’Voice Operated Telecom Services’, COST 249. Gent, Belgien, 2000, Seiten 63–66. [Haas et al. 2004] Haas, J.; Gallwitz, F. und Schr¨ oder, M. Aus der Praxis: Die automatische Zentrale bei der Sixt AG. In: Tagungsband der 34. Jahrestagung der Gesellschaft f¨ ur Informatik e.V. – ’Informatik 2004’. Ulm, 2004, Seiten 205–209.

188

Literatur

[von Hahn 1980] von Hahn, W. Fachsprachen. In: H. P. Althaus (Hrsg.): Lexikon der germanistischen Linguistik. Niemeyer, T¨ ubingen, 1980. [von Hahn et al. 1978] von Hahn, W.; Hoeppner, W.; Jameson, A. und Wahlster, W. HAM-RPM: Natural Dialogues with an Artificial Partner. In: Proceedings of the European Conference on Artificial Intelligence (ECAI). Hamburg, 1978, Seiten 122–131. [Hamerich 2000] Hamerich, S. W. Strategien f¨ ur Dialogsegmente in nat¨ urlichsprachlichen Anwendungen. Diplomarbeit, Fachbereich Informatik, Universit¨ at Hamburg, Hamburg, 2000. [Hamerich 2005] Hamerich, S. W. Speech Dialogue Systems for Cars - an Overview. SDV – Sprache und Datenverarbeitung, Bd. 29, Nr. 2, 2005, Seiten 107–118. [Hamerich 2007] Hamerich, S. W. Towards Advanced Speech Driven Navigation Systems for Cars. In: Proceedings of the International Conference on Intelligent Environments (IE). Ulm, 2007, Seiten 247–250. [Hamerich 2008] Hamerich, S. W. From GEMINI to DiaGen: Improving Development of Speech Dialogues for Embedded Systems. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Columbus, USA, 2008, Seiten 92–95. [Hamerich et al. 2003] Hamerich, S. W.; Wang, Y.-F. H.; Schubert, V.; Schless, V. und Igel, S. XML-Based Dialogue Descriptions in the GEMINI Project. In: Tagungsband der ’Berliner XML-Tage 2003’. Berlin, 2003, Seiten 404–412. [Hamerich et al. 2004a] Hamerich, S. W.; Schless, V.; Schubert, V. und Wang, Y.F. H. Generating Dialogue Applications with the GEMINI Platform. In: Tagungsband der 34. Jahrestagung der Gesellschaft f¨ ur Informatik e.V. – ’Informatik 2004’. Ulm, 2004, Seiten 215–219. [Hamerich et al. 2004b] Hamerich, S. W.; Schubert, V.; Schless, V.; de C´ ordoba, R.; Pardo, J. M.; d’Haro, L. F.; Kladis, B.; Kocsis, O. und Igel, S. Semi-Automatic Generation of Dialogue Applications in the GEMINI Project. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Cambridge, USA, 2004, Seiten 31–34. [Hamerich et al. 2004c] Hamerich, S. W.; de C´ ordoba, R.; Schless, V.; d’Haro, L. F.; Kladis, B.; Schubert, V.; Kocsis, O.; Igel, S. und Pardo, J. M. The GEMINI Platform: Semi-Automatic Generation of Dialogue Applications. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 2629–2632. [Hamerich et al. 2005] Hamerich, S. W.; K¨ onig, L. und Hennecke, M. E. Sprachdialogsysteme im Kfz. KI – K¨ unstliche Intelligenz, Bd. 19, Nr. 3, 2005, Seiten 29–34. [Hamerich und B¨ uhler 2005] Hamerich, S. W. und B¨ uhler, D. Converging Dialogue Descriptions for Embedded and Server Platforms. In: Proceedings of the International Conference on Speech and Computer (SPECOM). Patras, Griechenland, 2005, Seiten 723–726. [Hamerich und Hanrieder 2004] Hamerich, S. W. und Hanrieder, G. Modelling Generic Dialog Applications for Embedded Systems. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 237–240. [Hanrieder 1998] Hanrieder, G. Integration of a Mixed-Initiative Dialogue Manager into Commercial IVR Platforms. In: Proceedings of the International Workshop on ’Interactive Voice Technology for Telecommunications Applications’ (IVTTA). Turin, Italien, 1998, Seiten 77–82.

Literatur

189

[Hanrieder 2004] Hanrieder, G. Sprachbedienung im KFZ - Eine Erfolgsgeschichte. In: Tagungsband der 34. Jahrestagung der Gesellschaft f¨ ur Informatik e.V. – ’Informatik 2004’. Ulm, 2004, Seiten 220–224. [Hanrieder et al. 1998] Hanrieder, G.; Heisterkamp, P. und Brey, T. Fly with the EAGLES: Evaluation of the ACCeSS Spoken Language Dialogue System. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Sydney, Australien, 1998, Seiten 1153–1156. [H¨ ansler und Schmidt 2004] H¨ ansler, E. und Schmidt, G. Acoustic Echo and Noise Control. John Wiley & Sons, New York, USA, 2004. [Harbluk et al. 2007] Harbluk, J. L.; Burns, P. C.; Lochner, M. und Trbovich, P. L. Using the Lane-Change Test (LCT) to Assess Distraction: Tests of Visual-Manual and Speech-Based Operation of Navigation System Interfaces. In: Proceedings of the International Driving Symposium on Human Factors in Driver Assessment, Training and Vehicle Design. Stevenson, USA, 2007, Seiten 16–22. [Harbluk und Lalande 2005] Harbluk, J. L. und Lalande, S. Performing E-Mail Tasks While Driving: The Impact of Speech-Based Tasks on Visual Detection. In: Proceedings of the International Driving Symposium on Human Factors in Driver Assessment, Training and Vehicle Design. Rockport, USA, 2005, Seiten 311–317. [Harel 1987] Harel, D. Statecharts: A Visual Formalism For Complex Systems. Science of Computer Programming, Nr. 8, 1987, Seiten 231–274. [D’Haro et al. 2006] D’Haro, L. F.; de C´ ordoba, R.; Ferreiros, J.; Hamerich, S. W.; Schless, V.; Kladis, B.; Schubert, V.; Kocsis, O.; Igel, S. und Pardo, J. M. An Advanced Platform to Speed up the Design of Multilingual Dialog Applications for Multiple Modalities. Speech Communication, Bd. 48, Nr. 8, 2006, Seiten 863–887. [Hassel 2006] Hassel, A. L. Adaption und Evaluation von Sprachbediensystemen im Automobilbereich. Dissertation, Centrum f¨ ur Informations- und Sprachverarbeitung, Ludwig-Maximilians-Universit¨ at M¨ unchen, M¨ unchen. Erschienen im Logos Verlag, Berlin., 2006. [Hassel und Hagen 2005] Hassel, L. und Hagen, E. Evaluation of a Dialogue System in an Automotive Environment. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Lissabon, Portugal, 2005, Seiten 155–165. [Heim und Schw¨ ogler 2006] Heim, J. und Schw¨ ogler, S. Sprachdialoge verbessern die Effizienz der Funketiketten. Computer Zeitung, Nr. 24, 2006, Seite 19. [Heisterkamp 2001] Heisterkamp, P. Linguatronic – Product-Level Speech System for Mercedes-Benz Cars. In: Proceedings of the Human Language Technology Conference (HLT). San Diego, USA, 2001, Seiten 1–2. [Heisterkamp 2003] Heisterkamp, P. ’Do not Attempt to Light with Match!’: Some Thoughts on Progress and Research Goals in Spoken Dialog Systems. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Genf, Schweiz, 2003, Seiten 2897–2900. [Heisterkamp und McGlashan 1996] Heisterkamp, P. und McGlashan, S. Units of Dialogue Management: An Example. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Philadelphia, USA, 1996, Seiten 200–203. [Hennecke und Hanrieder 2000] Hennecke, M. E. und Hanrieder, G. Easy Configuration of Natural Language Understanding Systems. In: Proceedings of the International Workshop ’Voice Operated Telecom Services’, COST 249. Gent, Belgien, 2000, Seiten 87–90.

190

Literatur

[Hof 2007] Hof, A. Entwicklung eines adaptiven Hilfesystems f¨ ur multimodale Anzeige-Bedienkonzepte im Fahrzeug. Dissertation, Philosophische Fakult¨ at IV, Universit¨ at Regensburg, Regensburg, 2007. [Hof et al. 2006] Hof, A.; Hagen, E. und Huber, A. Adaptive Help for Speech Dialogue Systems Based on Learning and Forgetting of Speech Commands. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Sydney, Australien, 2006, Seiten 1–8. [Hopcroft und Ullman 1979] Hopcroft, J. E. und Ullman, J. D. Introduction to Automata Theory, Languages, and Computation. Addison-Wesley, Reading, USA, 1979. [Hottelet 2004] Hottelet, U. Spracherkennung und Integration senken Kosten. Computer Zeitung, Nr. 10, 2004, Seite 16. [Huang et al. 2006] Huang, S.; Xie, X. und Kuang, J. Improving the Performance of Out-of-Vocabulary Word Rejection by Using Support Vector Machines. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 1618–1621. [Hunt 2000] Hunt, A. JSpeech Grammar Format. W3C Note, ver¨ offentlicht unter http://www.w3.org/TR/jsgf/, 2000. [Hunt und McGlashan 2004] Hunt, A. und McGlashan, S. Speech Recognition Grammar Specification Version 1.0. W3C Recommendation, ver¨ offentlicht unter http://www.w3c.org/TR/speech-grammar/, 2004. [Iser et al. 2008] Iser, B.; Minker, W. und Schmidt, G. Bandwidth Extension of Speech Signals. Nr. 13 in Lecture Notes in Electrical Engineering. Springer, New York, USA, 2008. [Iskra et al. 2002] Iskra, D.; Grosskopf, B.; Marasek, K.; van de Heuvel, H.; Diehl, F. und Kiessling, A. SPEECON – Speech Databases for Consumer Devices: Database Specification and Validation. In: Proceedings of the International Conference on Language Resources and Evaluation (LREC). Las Palmas de Gran Canaria, Spanien, 2002, Seiten 329–333. [Jekat et al. 1995] Jekat, S. J.; Klein, A.; Maier, E.; Maleck, I.; Mast, M. und Quantz, J. J. Dialogue Acts in Verbmobil. Verbmobil Report 65, Fachbereich Informatik, Universit¨ at Hamburg, Hamburg, 1995. [Jekat-Rommel 1994] Jekat-Rommel, S. J. Zur Struktur gedolmetschter VMDialoge. Verbmobil Memo 11, Fachbereich Informatik, Universit¨ at Hamburg, Hamburg, 1994. [Jelinek 1976] Jelinek, F. Speech Recognition by Statistical Methods. Proceedings of the IEEE, Bd. 64, 1976, Seiten 532–556. [Jelinek 1998] Jelinek, F. Statistical Methods for Speech Recognition. MIT Press, Cambridge, USA, 1998. [Jelinek 2005] Jelinek, F. Some of my Best Friends are Linguists. Language Resources and Evaluation, Bd. 39, Nr. 1, 2005, Seiten 25–34. [Jeschke 2007] Jeschke, B. Design von Sprachdialogen f¨ ur das Kfz – Stand der Technik. In: Tagungsband der Konferenz Elektronische Sprachsignalverarbeitung (ESSV). Cottbus, 2007. [Jeschke 2008] Jeschke, B. Sprachausgaben von Sprachdialogsystemen im Kfz. In: Tagungsband der ITG-Fachtagung Sprachkommunikation. Aachen, 2008. [Jonsson et al. 2005] Jonsson, I.-M.; Zajicek, M.; Harris, H. und Nass, C. Thank You, I did not see that: In-car Speech Based Information Systems for Older Adults. In: Proceedings of the Conference on Human Factors in Computing Systems (CHI), Conference Extended Abstracts. Portland, USA, 2005.

Literatur

191

[Kato et al. 2008] Kato, T.; Okamoto, J. und Shozakai, M. Analysis of Drivers’ Speech in a Car Environment. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Brisbane, Australien, 2008, Seiten 1634– 1637. [Kim et al. 2004] Kim, D.-H.; Roh, Y.-W. und Hong, K.-S. An Implement of Speech DB Gathering System Using VoiceXML. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 2757– 2760. [K¨ olzer 2002] K¨ olzer, A. DiaMod – Ein Werkzeugsystem zur Modellierung nat¨ urlichsprachlicher Dialoge. Dissertation, Fachbereich Informatik, Universit¨ at KoblenzLandau, Koblenz. Erschienen im Mensch und Buch Verlag, Berlin, 2002. [Kun et al. 2007] Kun, A.; Paek, T. und Medenica, Z. The Effect of Speech Interface Accuracy on Driving Performance. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Antwerpen, Belgien, 2007, Seiten 1326–1329. [Labiale 1997] Labiale, G. Cognitive Ergonomics and Intelligent Systems in the Automobile. In: Noy, Y.I. (Hrsg.): Ergonomics and Safety of Intelligent Driver Interfaces. Human Factors in Transportation. Lawrence Erlbaum, Mahwah, USA, 1997, Seiten 169–184. [Larsen 2003] Larsen, L. B. Assessment of Spoken Dialogue System Usability - What are We really Measuring? In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Genf, Schweiz, 2003, Seiten 1945–1948. [Lehtinen et al. 2000] Lehtinen, G.; Safra, S.; Gauger, M.; Cochard, J.-L.; Kaspar, B.; Hennecke, M. E.; Pardo, J. M.; de C´ ordoba, R.; San-Segundo, R.; Tsopanoglou, A.; Louloudis, D. und Mantakas, M. IDAS: Interactive Directory Assitance Service. In: Proceedings of the International Workshop ’Voice Operated Telecom Services’, COST 249. Gent, Belgien, 2000, Seiten 51–54. [Levin und Pieraccini 1997] Levin, E. und Pieraccini, R. A Stochastic Model of Computer-Human Interaction for Learning Dialogue Strategies. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Rhodos, Griechenland, 1997, Seiten 11–23. [Lewandowski 1979] Lewandowski, T. Linguistisches W¨ orterbuch. Nr. 200 in UniTaschenb¨ ucher (UTB). Quelle und Meyer, Heidelberg, 1979. [Lindstr¨ om et al. 2008] Lindstr¨ om, A.; Villing, J.; Larsson, S.; Seward, A.; ˚ Aberg, N. und Holtelius, C. The Effect of Cognitive Load on Disfluencies During In-Vehicle Spoken Dialogue. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Brisbane, Australien, 2008, Seiten 1196–1199. [Linke et al. 1994] Linke, A.; Nussbaumer, M. und Portmann, P. R. Studienbuch Linguistik. Nr. 121 in Reihe Germanistische Linguistik. Niemeyer, T¨ ubingen, 1994. [Liu und Liu 2008] Liu, F. und Liu, Y. What Are Meeting Summaries? An Analysis of Human Extractive Summaries in Meeting Corpus. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Columbus, USA, 2008, Seiten 80–83. [Ludwig 2004] Ludwig, B. Ein konfigurierbares Dialogsystem f¨ ur Mensch-MaschineInteraktion in gesprochener Sprache. Dissertation, Technische Fakult¨ at, Universit¨ at Erlangen-N¨ urnberg, Erlangen. Erschienen im Logos Verlag, Berlin, 2004. [Mann et al. 2007] Mann, S.; Berton, A. und Ehrlich, U. How to Access Audio Files of Large Data Bases Using In-car Speech Dialogue Systems. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Antwerpen, Belgien, 2007, Seiten 138–141.

192

Literatur

[Maracke 2003] Maracke, E. VoiceXML 2.0. Galileo Computing, Bonn, 2003. [Mast 1993] Mast, M. Ein Dialogmodul f¨ ur ein Spracherkennungs- und Dialogsystem. Dissertation, Lehrstuhl f¨ ur Mustererkennung, Universit¨ at Erlangen-N¨ urnberg, Erlangen. Erschienen als DISKI 50 bei infix, St. Augustin, 1993. [Mast et al. 2000] Mast, M.; G¨ unther, C.; Kunzmann, S. und Roß, T. Multimodal Output for a Conversational Telephony System. In: Proceedings of the International Conference on Multimedia and Expo. New York, USA, 2000. [Mattes 2003] Mattes, S. The Lane Change Task as a Tool for Driver Distraction Evaluation. In: Proceedings of the Conference of the International Society for Occupational Ergonomics and Safety (ISOES). M¨ unchen, 2003, Seiten 57–60. [Matzer und Frisch 2003] Matzer, M. und Frisch, J. Sprachcomputer entlasten Callcenter-Agents. Computer Zeitung, Nr. 37, 2003, Seite 11. [McGlashan et al. 2004] McGlashan, S.; Burnett, D. C.; Carter, J.; Danielsen, P.; Ferrans, J.; Hunt, A.; Lucas, B.; Porter, B.; Rehor, K. und Tryphonas, S. Voice Extensible Markup Language (VoiceXML) Version 2.0. W3C Recommendation, ver¨ offentlicht unter http://www.w3c.org/TR/voicexml20/, 2004. [McTear 1998] McTear, M. F. Modelling Spoken Dialogues with State Transition Diagrams: Experiences with the CSLU-Toolkit. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Sydney, Australien, 1998, Seiten 1223–1226. [McTear 2004] McTear, M. F. Spoken Dialogue Technology – Toward the Conversational User Interface. Springer, London, Großbritannien, 2004. [MegatTajuddin 2005] MegatTajuddin, M. Z. Konversion GDML VoiceXML. Diplomarbeit, Institut f¨ ur Elektrotechnik, Universit¨ at Ulm, Ulm, 2005. [Merat 2003] Merat, N. Loading Drivers to Their Limit: The Effect of Increasing Secondary Task on Driving. In: Proceedings of the International Driving Symposium on Human Factors in Driver Assessment, Training and Vehicle Design. Park City, USA, 2003, Seiten 13–18. [Miller 1956] Miller, G. The Magical Number Seven Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review, Bd. 63, Nr. 2, 1956, Seiten 81–97. [Minker et al. 2004] Minker, W.; Haiber, U.; Heisterkamp, P. und Scheible, S. The Seneca Spoken Language Dialogue System. Speech Communication, Bd. 43, Nr. 1-2, 2004, Seiten 89–102. [Minker et al. 2006] Minker, W.; Pittermann, J.; Pittermann, A.; Strauß, P.-M. und B¨ uhler, D. Next-Generation Human-Computer Interfaces - Towards Intelligent, Adaptive and Proactive Spoken Language Dialogue Systems. In: Proceedings of the International Conference on Intelligent Environments (IE). Athen, Griechenland, 2006. [Mischke et al. 2007] Mischke, M.; Hamberger, W. und Spanner-Ulmer, B. Eignen sich multimodale Bedienkonzepte zur Korrektur von Fehlern der Sprachbedienung im Fahrzeug. VDI-Berichte, Nr. 2015, 2007, Seiten 245–250. [M¨ oller 1999] M¨ oller, J.-U. Dia-MoLE: Modellierung gesprochen-sprachlicher Dialoge unter Zuhilfenahme eines maschinellen Lernverfahrens. Dissertation, Fachbereich Informatik, Universit¨ at Hamburg, Hamburg. Erschienen als DISKI 221 bei Infix, St. Augustin, 1999. [M¨ uller und Hamerich 2007] M¨ uller, K. und Hamerich, S. W. Komfortable Sonderzieleingabe per Sprache im Automobil. In: Tagungsband der Konferenz Mensch & Computer. Weimar, 2007.

Literatur

193

[Naur et al. 1960] Naur, P.; Backus, J. W.; Bauer, F. L.; Green, J.; Katz, C.; McCarthy, J.; Perlis, A. J.; Rutishauser, H.; Samelson, K.; Vauquois, B.; Wegstein, J. H.; van Wijngaarden, A. und Woodger, M. Report on the Algorithmic Language ALGOL 60. Communications of the ACM, Bd. 3, Nr. 5, 1960, Seiten 299–314. [Niedermair 1987] Niedermair, G. T. Syntactic Analysis in Speech Understanding. In: European Conference on Speech Technology. Edinburgh, Großbritannien, 1987, Seiten 1005–1008. [Nielsen 1993] Nielsen, J. Usability Engineering. Academic Press, Boston, USA, 1993. [Nordholm et al. 2001] Nordholm, S.; Claesson, I. und Grbic, N. Adaptive Microphone Arrays for Speech Input in Automobiles. In: Brandstein, M. und Ward, D. (Hrsg.): Microphone Arrays. Springer, Heidelberg, 2001, Seiten 307–329. [Oshry et al. 2007] Oshry, M.; Auburn, R. J.; Baggia, P.; Bodell, M.; Burke, D.; Burnett, D. C.; Candell, E.; Carter, J.; McGlashan, S.; Lee, A.; Porter, B. und Rehor, K. Voice Extensible Markup Language (VoiceXML) 2.1. W3C Recommendation, ver¨ offentlicht unter http://www.w3.org/TR/voicexml21/, 2007. [Papineni et al. 1999] Papineni, K. A.; Roukos, S. und Ward, R. T. Free-Flow Dialog Management using Forms. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Budapest, Ungarn, 1999, Seiten 1411–1414. [Peckham 1993] Peckham, J. A new Generation of Spoken Dialogue Systems: Results and Lessons from the SUNDIAL Project. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Berlin, 1993, Seiten 33–40. [Peissner et al. 2004] Peissner, M.; Biesterfeld, J. und Heidmann, F. Akzeptanz und Usability von Sprachapplikationen in Deutschland. Fraunhofer IRB Verlag, Stuttgart, 2004. [Peters 1999] Peters, K. Nat¨ urlichsprachliche Kommunikation mit handelnden Systemen. Dissertation, Technische Fakult¨ at, Universit¨ at Bielefeld, Bielefeld. Erschienen im Logos Verlag, Berlin, 1999. [Petrik et al. 2005] Petrik, S.; Wang, Y.-F. H. und Hamerich, S. W. Hierarchical Dialogue Structure Representation for Wizard of Oz Experiments on Speech Dialogue Systems. In: Proceedings of the International Conference on Speech and Computer (SPECOM). Patras, Griechenland, 2005, Seiten 207–210. [Pieraccini et al. 2003] Pieraccini, R.; Dayanidhi, K.; Bloom, J.; Dahan, J.-G.; Phillips, M.; Goodman, B. R. und Prasad, K. V. A Multimodal Conversational Interface for a Concept Vehicle. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Genf, Schweiz, 2003, Seiten 2233–2236. [Pieraccini und Huerta 2005] Pieraccini, R. und Huerta, J. Where do we go from here? Research and Commercial Spoken Dialog Systems. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Lissabon, Portugal, 2005, Seiten 1–10. [Pieraccini und Huerta 2008] Pieraccini, R. und Huerta, J. M. Where do we go from here? – Research and Commercial Spoken Dialogue Systems. In: Dybkjær, L. und Minker, W. (Hrsg.): Recent Trends in Discourse and Dialogue, Bd. 39 der Reihe Text, Speech and Language Technology. Springer, Dordrecht, Niederlande, 2008, Seiten 1–24. [Pon-Barry et al. 2006] Pon-Barry, H.; Weng, F. und Varges, S. Evaluation of Content Presentation Strategies for an In-car Spoken Dialogue System. In: Proceedings

194

Literatur

of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 1930–1933. [Rademacher 2004] Rademacher, R. Mobilkommunikation bildet HypeWellenkamm. Computer Zeitung, Nr. 35/36, 2004, Seite 9. [Rieser und Lemon 2006] Rieser, V. und Lemon, O. Cluster-Based User Simulations for Learning Dialogue Strategies. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 1766– 1769. [Rieser 2003] Rieser, V. T. Entwurf und Implementierung einer Sprachschnittstelle f¨ ur eine Waschmaschine. Magisterarbeit, Philosophische Fakult¨ at IV, Universit¨ at Regensburg, Regensburg, 2003. [R¨ obke-Doerr 2006] R¨ obke-Doerr, P. Staumelder – Die Unterschiede zwischen TMC und TMCpro. Heise Mobil Artikel vom 24.07.2006, siehe http://www.heise.de/mobil/artikel/75174, 2006. [Rockwell 1972] Rockwell, T. H. Eye Movement Analysis of Virtual Information Acquisition in Driving – an Overview. In: Proceedings of the 6th Conference of the Australian Road Research Board. Canberra, Australien, 1972, Seiten 662–667. [Rubin 1994] Rubin, J. Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests. John Wiley & Sons, New York, USA, 1994. [Salmen 2002] Salmen, A. Multimodale Men¨ uausgabe im Fahrzeug. Dissertation, Philosophische Fakult¨ at IV, Universit¨ at Regensburg, Regensburg. Erschienen im Herbert Utz Verlag, M¨ unchen, 2002. [ScanSoft 2004] ScanSoft (Hrsg.). Revolutionizing Conversational Applications With xHMI. Ver¨ offentlicht unter http://www.nuance.com/xhmi/, 2004. [Scharenborg und Seneff 2005] Scharenborg, O. und Seneff, S. Two-Pass Strategy for Handling OOVs in a Large Vocabulary Recognition Task. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Lissabon, Portugal, 2005, Seiten 1669–1672. [Schiel et al. 2006] Schiel, F.; Draxler, C. und Libossek, M. Lingua Machinae - An Unorthodox Proposal. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 1926–1929. [Schubert und Hamerich 2005] Schubert, V. und Hamerich, S. W. The Dialog Application Metalanguage GDialogXML. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Lissabon, Portugal, 2005, Seiten 789–792. [Schulz et al. 2007] Schulz, S.; Hamerich, S. W. und Donker, H. Use of Non-Speech Elements for the Navigation in Music Collections in an In-Car Scenario. In: Proceedings of the International Conference on Humans and Computers. D¨ usseldorf, 2007. [Schulz und Donker 2006] Schulz, S. und Donker, H. An User-Centered Development of an Intuitive Dialog Control for Speech-Controlled Music Selection in Cars. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 61–64. [Searle 1969] Searle, J. R. Speech Acts. Cambridge University Press, Cambridge, Großbritannien, 1969. [Sharma und Kunins 2002] Sharma, C. und Kunins, J. VoiceXML – Strategies and Techniques for Effective Voice Application Development. John Wiley & Sons, New York, USA, 2002.

Literatur

195

[Shneiderman 1980] Shneiderman, B. Natural vs. Precise Concise Languages for Human Operation of Computers: Research Issues and Experimental Approaches. In: Proceedings of the Annual Meeting of the Association for Computational Linguistics (ACL). Philadelphia, USA, 1980, Seiten 139–141. [Shneiderman 2002] Shneiderman, B. User Interface Design. mitp Verlag, Bonn, 2002. [Shriberg und Stolcke 2008] Shriberg, E. und Stolcke, A. The Case for Automatic Higher-Level Features in Forensic Speaker Recognition. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Brisbane, Australien, 2008, Seiten 1509–1512. [Strauß 2006] Strauß, P.-M. A SLDS for Perception and Interaction in Multi-User Environments. In: Proceedings of the International Conference on Intelligent Environments (IE). Athens, Greece, 2006. [Suhm 2003] Suhm, B. Towards Best Practices for Speech User Interface Design. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Genf, Schweiz, 2003, Seiten 2217–2220. [Sun 1998a] Sun Microsystems, Inc. (Hrsg.). Grammar Format Specification – Version 1.0. Ver¨ offentlicht unter http://java.sun.com/products/javamedia/speech/forDevelopers/JSGF/, 1998. [Sun 1998b] Sun Microsystems, Inc. (Hrsg.). Action Tags for JSGF. Internes Dokument, 1998. [Syed und Williams 2008] Syed, U. und Williams, J. D. Using Automatically Transcribed Dialogs to Learn User Models in a Spoken Dialog System. In: Proceedings of the Annual Meeting of the Association for Computational Linguistics (ACL). Columbus, USA, 2008, Seiten 121–124. [van Tichelen und Burke 2007] van Tichelen, L. und Burke, D. Semantic Interpretation for Speech Recognition Version 1.0. W3C Recommendation, ver¨ offentlicht unter http://www.w3c.org/TR/semantic-interpretation/, 2007. [Tomko und Rosenfeld 2004a] Tomko, S. und Rosenfeld, R. Speech Graffiti habitability: What do users really say? In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Cambridge, USA, 2004, Seiten 81–84. [Tomko und Rosenfeld 2004b] Tomko, S. und Rosenfeld, R. Speech Graffiti vs. Natural Language: Assessing the User Experience. In: Proceedings of the Human Language Technology Conference (HLT) and the Annual Meeting of the North American Chapter of the ACL (NAACL). Boston, USA, 2004, Seiten 73–76. [Tomko und Rosenfeld 2004c] Tomko, S. und Rosenfeld, R. Shaping Spoken Input in User-Initiative Systems. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 2825–2828. [Tomko 2006] Tomko, S. L. Improving User Interaction with Spoken Dialog Systems via Shaping. Dissertation, School of Computer Science, Carnegie Mellon University, Pittsburgh, USA, 2006. [Toptsis 2005] Toptsis, I. Multimodale Dialogsteuerung f¨ ur Roboteranwendungen. Dissertation, Technische Fakult¨ at, Universit¨ at Bielefeld, Bielefeld. Erschienen im Logos Verlag, Berlin, 2005. [Torres et al. 2005] Torres, F.; Sanchis, E. und Segarra, E. Learning of Stochastic Dialog Models Through a Dialog Simulation Technique. In: Proceedings of the European Conference on Speech Communication and Technology (EUROSPEECH). Lissabon, Portugal, 2005, Seiten 817–820. [Traum und Larsson 2003] Traum, D. R. und Larsson, S. The Information State Approach to Dialogue Management. In: van Kuppevelt, J. C. J. und Smith, R. W.

196

Literatur

(Hrsg.): Current and New Directions in Discourse and Dialogue. Kluwer Academic Publishers, Dordrecht, Holland, 2003. [Vary et al. 1998] Vary, P.; Heute, U. und Hess, W. Digitale Sprachsignalverarbeitung. Teubner Verlag, Stuttgart, 1998. [Vollrath 2005] Vollrath, M. Sprechen und Fahren – L¨ osung oder Problem? SDV – Sprache und Datenverarbeitung, Bd. 29, Nr. 2, 2005, Seiten 119–134. [Wahlster 2000] Wahlster, W. (Hrsg.). Verbmobil: Foundations of Speech-to-Speech Translation. Springer, Heidelberg, 2000. [Wahlster et al. 1983] Wahlster, W.; Marburger, H.; Jameson, A. und Busemann, S. Over-Answering Yes-No Questions – Extended Responses in a NL Interface to a Vision System. In: Proceedings of the International Joint Conference on Artificial Intelligence (IJCAI). Karlsruhe, 1983, Seiten 643–646. [Walker et al. 1997] Walker, M.; Litman, D.; Kamm, C. und Abella, A. PARADISE: A Framework for Evaluating Spoken Dialogue Agents. In: Proceedings of the Conference of the European Chapter of the Association for Computational Linguistics (EACL). Madrid, Spanien, 1997, Seiten 271–280. [Wang et al. 2003] Wang, Y.-F. H.; Hamerich, S. W.; Schubert, V.; Schless, V. und Igel, S. Multi-Modal and Modality Specific Error Handling in the GEMINI Project. In: Proceedings of the ISCA Workshop on Error Handling in Spoken Dialogue Systems. Chateau d’Oex, Schweiz, 2003, Seiten 139–144. [Wang et al. 2005] Wang, Y.-F. H.; Hamerich, S. W.; Hennecke, M. E. und Schubert, V. M. Speech-controlled Media File Selection on Embedded Systems. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Lissabon, Portugal, 2005, Seiten 217–221. [Wang und Hamerich 2008] Wang, Y.-F. H. und Hamerich, S. W. Designing SpeechControlled Media File Selection for Automotive Systems. In: Dybkjær, L. und Minker, W. (Hrsg.): Recent Trends in Discourse and Dialogue, Bd. 39 der Reihe Text, Speech and Language Technology. Springer, Dordrecht, Niederlande, 2008, Seiten 25–43. [Weizenbaum 1966] Weizenbaum, J. ELIZA - A Computer Program for the Study of Natural Language Communication between Man and Machine. Communications of the ACM, Bd. 9, Nr. 1, 1966, Seiten 36–45. [Weng et al. 2004] Weng, F.; Cavedon, L.; Raghuanathan, B.; Mirkovic, D.; Cheng, H.; Schmidt, H.; Bratt, H.; Mishra, R.; Peters, S.; Upson, S.; Shriberg, E.; Bergmann, C. und Zhao, L. A Conversational Dialogue System for Cognitively Overloaded Users. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 233–236. [Weng et al. 2006] Weng, F.; Varges, S.; Raghunathan, B.; Ratiu, F.; Pon-Barry, H.; Lathrop, B.; Zhang, Q.; Bratt, H.; Scheideck, T.; Xu, K.; Purver, M.; Mishra, R.; Lien, A.; Raya, M.; Peters, S.; Meng, Y.; Russell, J.; Cavedon, L.; Shriberg, E.; Schmidt, H. und Prieto, R. CHAT: A Conversational Helper for Automotive Tasks. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Pittsburgh, USA, 2006, Seiten 1061–1064. [Weng et al. 2007] Weng, F.; Yan, B.; Feng, Z.; Ratiu, F.; Raya, M.; Lathrop, B.; Lien, A.; Varges, S.; Mishra, R.; Lin, F.; Purver, M.; Bratt, H.; Meng, Y.; Peters, S.; Scheideck, T.; Raghunathan, B. und Zhang, Z. CHAT to your Destination. In: Proceedings of the SIGdial Workshop on Discourse and Dialogue. Antwerpen, Belgien, 2007, Seiten 79–86. [Wickens und Hollands 1999] Wickens, C. D. und Hollands, J. D. Engineering Psychology and Human Performance. Prentice Hall, Upper Saddle River, USA, 1999.

Literatur

197

[Wiegand 2008] Wiegand, D. Wie sag ichs meinem Navi? – Bedienkonzepte bei Navigationsger¨ aten mit Spracherkennung. c’t – magazin f¨ ur computertechnik, Nr. 13, 2008, Seiten 158–161. [Willett 2004] Willett, D. Error-Weighted Discriminative Training for HMM Parameter Estimation. In: Proceedings of the International Conference on Spoken Language Processing (ICSLP). Jeju, Korea, 2004, Seiten 1661–1664. [Winograd 1972] Winograd, T. Understanding Natural Language. Academic Press, New York, USA, 1972. [Zue et al. 2000] Zue, V.; Seneff, S.; Glass, J. R.; Pao, J. P. C.; Hazen, T. J. und Hetherington, L. JUPITER: A Telephone-Based Conversational Interface for Weather Information. IEEE Transactions on Speech and Audio Processing, Bd. 8, Nr. 1, 2000, Seiten 85–96.

Index

Akzeptanz, 11, 16, 58, 62, 63, 67, 71, 145 ¨ Außerung, 5, 14, 14, 15–18, 24, 25, 31, 32, 38, 46–48, 65, 67, 88, 95, 99, 159 Backend, 18, 53, 54 barge-in, 56 Bedienbarkeit, 4, 16, 28, 35, 56, 61, 62, 62, 68, 106 Bedienphilosophie, 20, 28, 29, 33–35, 42, 44, 106 ¨ Benutzer¨ außerung, siehe Außerung Benutzerfreundlichkeit, 4, 5, 11, 61, 62, 62, 63, 66, 68, 72, 73, 76, 77, 146 Datensammlung, 19, 20 DDS, 82 Designfehler, 16, 65, 111, 116, 123, 127 DiaGen, 8–10, 12, 95, 99, 129, 132, 133, 135, 137, 141, 147, 149–153, 158, 160–166 Dialog, 2, 5, 10, 11, 13, 13, 14, 15, 18, 23–25, 31, 38, 44, 48, 53, 63, 66, 67, 71, 73, 75, 82–84, 88, 91, 93, 95–97, 106, 109, 111, 115, 116, 119, 123, 127, 129, 130, 134, 135, 137, 139, 153, 157, 158, 161–166, 169 Bahnauskunft, 23, 55, 56, 58 command and control, 22 gemischt initiativ, 23, 23, 55, 81, 88, 104 Internetzugriff, 48

Medienspieler, 48, 49 MP3, 48, 69 Namenswahl, 45 Nummernwahl, 44, 46, 49 proaktiv, 10, 12, 36, 129, 130, 132–135, 137, 139–141, 145–147, 150, 151 Radiosteuerung, 47, 49 systemgesteuert, 22, 55, 81, 88 TMC, 10, 12, 129, 132, 134, 137–139, 141, 143, 144, 146, 147, 150, 151, 153, 164, 167 Zieleingabe, 46, 47–49, 137, 138, 140, 145 Dialogakt, 16, 17, 24, 38, 97 Dialogbeschreibung, 1, 9, 17, 39, 55, 58, 59, 77, 81, 83, 88–90, 95, 99, 102, 105, 109, 113, 122 Dialogbeschreibungssprache, 9, 17, 21, 79, 80, 81, 82, 86, 89, 90, 95, 99, 105 EMMA, 89 GDialogXML, 89, 108, 109, 111, 113 GDML, 81, 81, 81–86, 88–94, 97, 99, 101, 105, 108–115, 117, 118, 120, 121, 124, 126, 136 HDDL, 90 SALT, 89, 89, 90 SCXML, 88, 90 VoiceXML, 81, 82, 86, 86–94, 97–99, 101, 105–107, 109, 110, 113, 114 X+V, 89 xHMI, 90

200

Index

Dialogdesign, 9, 11, 25, 26, 58, 65, 66, 69, 80, 83, 92, 105, 112, 114, 126, 149 Dialogdom¨ ane, 4, 7, 16, 22, 23, 26, 31, 50, 56, 65, 72, 96, 150 Dialogfluss, 7, 16, 20, 21, 25, 74, 95, 102, 104 Dialogkontrolle, siehe Dialogmanager Dialogmanager, 16–18, 21, 35, 39, 53, 55, 59, 64–66, 69, 70, 81, 82, 87, 89, 94, 129, 133, 137 Dialogmodell, 7, 11, 16, 16, 17–23, 55, 79, 91, 97, 99, 101, 104, 108, 109, 111, 112, 150 Dialogmodellierung, 17, 18–20, 23, 104, 107, 150 frame-based, 17, 87 planbasiert, 7, 18, 20, 23, 79 regelbasiert, 7, 17, 20, 23, 79, 84, 87 statistisch, 8, 18, 20, 23, 79 zustandsbasiert, 7, 8, 17, 20, 22, 55, 79, 84, 85, 87, 99, 105, 113, 150 Dialogparameter, 24, 95, 97, 115 Dialogsegment, 14, 16, 115 Dialogsequenz, 14 Dialogspezifikation, 7, 17–21, 25, 32, 33, 35, 39, 99, 101, 102, 105, 106, 108, 119, 122, 134 Dialogsteuerung, siehe Dialogmanager Dialogstrategie, 11, 16, 17, 19, 22, 22, 23, 24, 56, 68, 75, 77 direktiv, 22, 48, 75, 76 kooperativ, 22, 44, 75 reaktiv, 22, 44, 48, 55, 75 Dialogsystem, 1–3, 5–10, 23–27, 31, 32, 33, 35–37, 39, 45, 50, 51, 53, 54, 56, 61, 63–73, 79, 86, 95–97, 99, 112, 127, 137 eingebettet, 2, 27, 41, 50 serverbasiert, 27, 33, 35, 49–56, 70 telefonisch, 2, 11, 50, 52–54, 56 Dialogziel, 15, 16, 22–24, 24, 31, 56, 63, 65, 66, 71, 99 DIN EN ISO 9241, 25, 26, 62, 66, 73, 74, 77 DSR, 82, 106, 114

D2B, 40 MOST, 39, 40 Evaluation, 10, 12, 35, 67–70, 73, 77, 126, 133, 141, 143–147, 150, 151, 169 Benutzerevaluation, 68, 77, 141, 150 black-box evaluation, 67, 68 glass-box evaluation, 67, 68 Performanzevaluation, 67, 77, 139, 141

Entertainment-Bus, 39, 42, 82 CAN, 40

Mikrofon, 3, 36, 37, 41, 42, 51, 52, 133, 138

Fachsprache, 23 Fahrerinformationssystem, 29, 29, 30, 36, 41, 71, 73, 74 Fehlerkennung, 26, 36, 64, 72 Form Interpretation Algorithm, 87, 88, 91 Freisprecheinrichtung, 28, 31, 36, 74 G2P, 45, 48, 49 GDC, 82, 114 GDM, 81, 82 GDS, 82, 114 GEMINI, 2, 9, 89, 108, 109–111, 113, 117, 121 Grammatik, 4, 12, 25, 38, 65, 72, 79, 83, 87, 92, 94–99, 101, 103–107, 109, 120, 123–125, 129, 150, 151, 154–156, 160, 166 BNF, 87, 96, 98 GSL, 97 JSGF, 82, 87, 97, 97, 98, 99 SRGS, 87, 98 Grice’sche Maximen, 5, 14, 17, 24, 25, 31, 58, 66 Hardwareanforderungen, 8, 32, 38, 39, 41, 47, 49, 56, 63, 82 Headunit, 39, 40–43, 46, 53, 133, 138, 143 Hilfedialog, 26, 73, 158 HMI, 34, 35, 43 Information State Approach, 18 Infotainmentsystem, 27, 29, 41 IVR, 53, 55 Linguatronic, 1, 43, 44, 49, 50

Index mixed initiative dialogue, siehe Dialog, gemischt initiativ Multifunktionslenkrad, 36, 42, 45 OOV-Fehler, 24, 64, 82, 141 Parsing, 4, 37, 38, 52, 65, 117 Prompt, 25, 25, 40, 44, 52, 53, 72–76, 82–84, 88, 93, 94, 103–106, 119, 125, 126, 142, 151, 159, 164–166 Prompter, 35, 82, 133 PTT, 36, 39, 42, 45, 52, 70, 129, 133, 138 Schichtenmodell, 4, 7, 9, 11, 12, 26, 59, 77, 99, 107, 109–111, 116, 127, 149, 150 Shortcut, 30, 34, 106, 153 Spezifikation, siehe Dialogspezifikation Sprachausgabe, 21, 41, 51, 54, 76, 77, 80, 82, 93, 103 Sprachbediensystem, 1, 2, 8, 20, 21, 23, 30, 31, 32, 33, 35, 36, 40–42, 44, 45, 49–51, 56, 61, 68–70, 72, 74–77, 89, 91, 92, 94, 99, 103–105, 110, 113, 114, 122, 126, 127, 133, 150, 152 Sprachbedienung, siehe Sprachbediensystem Sprachdaten, 38, 39, 95 Sprachdialogsystem, 3, 5–7, 11, 12, 24, 26, 27, 30, 31, 31, 32, 38, 39, 51–53, 55, 56, 58, 62, 63, 66, 68, 72, 79, 86, 90, 96, 97, 101, 103, 105, 140, 152 Spracheingabe, 3, 17–19, 21, 30, 31, 36, 37, 41, 46, 47, 51, 52, 58, 64, 65, 72, 87, 95, 103, 123 Spracherkenner, siehe Spracherkennung

201

Spracherkennung, 12, 18, 21, 25, 26, 35, 37, 37, 39, 45, 49, 52, 54, 55, 58, 65, 67, 79, 80, 82, 83, 87, 91, 95, 105, 107, 109, 114, 123, 133, 139, 154, 158, 160, 166 Sprachmodell, 25, 95 Sprachsteuerung, siehe Sprachbediensystem Sprechakt, 2, 15 SSS, 82, 114 system driven dialogue, siehe Dialog, systemgesteuert Systemcall, 83, 86, 91, 115, 122, 135, 161–163 Systemintegration, 6, 8, 11, 41, 41, 42, 52, 58, 135, 137, 149, 150 Theorie der multiplen Ressourcen, 29 Timeout-Fehler, 64, 83, 92 TMC-Meldung, 40, 49, 131, 134, 135, 140, 143–147, 151, 164, 171 TTS, 21, 40, 49, 53, 55, 82, 84, 93, 131, 137 Turn, 14 ¨ Uberbeantwortung, 22 Usability, siehe Bedienbarkeit Verifikation, 90 explizit, 55 implizit, 55 VoiceXML Interpreter, 87, 88, 91 Vokabular, 22, 23, 45, 64, 65, 72, 75, 92, 106, 139, 141 VUI Completeness, 19, 20, 24, 33 Wizard of Oz, 69, 75, 135 Wording, 25, 91, 93