PDF-Format - Prof. Dr. Alexander Keller - Universität Ulm
PDF-Format - Prof. Dr. Alexander Keller - Universität Ulm
PDF-Format - Prof. Dr. Alexander Keller - Universität Ulm
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Handheld und Ubiquitous Computing<br />
Hauptseminar an der <strong>Universität</strong> <strong>Ulm</strong><br />
Fakultät für Informatik<br />
UNIVERSITÄT ULM · SCIENDO · DOCENDO · CURANDO ·<br />
Wintersemester 2002/2003
Inhaltsverzeichnis<br />
Inhaltsverzeichnis<br />
1 Ubiquitous Computing - Ansätze, Ziele, Beispiele 5<br />
1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
1.2 Einführung und Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
1.3 Vision und Kennzeichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
1.4 Beispiel 1: Wearable Computing . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
1.5 Beispiel 2: Das intelligente Haus . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
1.6 Ausblick und kritische Würdigung . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
Literatur 11<br />
2 UI Patterns 13<br />
2.1 UI Patterns - Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.2 Anwendung auf verschiedenen Plattformen und Anpassung an unterschiedliche<br />
Umgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
2.3 Einsatz von Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
Literatur 33<br />
3 Styleguides 34<br />
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
3.2 Styleguides für Palm OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
3.3 Styleguides für Microsoft Windows CE . . . . . . . . . . . . . . . . . . . . . . 43<br />
3.4 Styleguides für Java ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />
3.5 Styleguides für GSM Applikationen . . . . . . . . . . . . . . . . . . . . . . . . 50<br />
3.6 Schlußbetrachtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
Literatur 52<br />
4 Smart-Its und intelligente Geräte 53<br />
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
4.2 Kommunikationstechnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
4.3 Energieversorgung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
4.4 Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59<br />
4.5 Projekte, Visionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
Literatur 63<br />
5 Mobile Ad-Hoc-Metzwerke 64<br />
5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64<br />
5.2 Ad-hoc-Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64<br />
5.3 Netzwerk-Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66<br />
5.4 Routing in mobilen Ad-Hoc-Netzen . . . . . . . . . . . . . . . . . . . . . . . . 71<br />
5.5 Anwendung im Ubiquitous Computing . . . . . . . . . . . . . . . . . . . . . . 77<br />
5.6 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . 81<br />
Literatur 82<br />
6 Location Models 83<br />
6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83<br />
2
Inhaltsverzeichnis<br />
6.2 Basic Location Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86<br />
6.3 Modellentwicklungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93<br />
6.4 Abschlussbemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97<br />
Literatur 97<br />
7 Location based services (LBS) 99<br />
7.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99<br />
7.2 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101<br />
7.3 Applikationen (Fallbeispiele) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104<br />
7.4 Datenschutz Limitationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105<br />
Literatur 107<br />
8 Privacy und Security in mobilen Endgeräten und im Mobilfunk 109<br />
8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109<br />
8.2 Privacy und Security betreffende Bereiche . . . . . . . . . . . . . . . . . . . . 111<br />
8.3 Gefahrenpotentiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114<br />
8.4 Abschließende Bemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120<br />
Literatur 121<br />
9 Security and Privacy - Anonymität 122<br />
9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122<br />
9.2 Anonymität im Festnetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124<br />
9.3 Anonymität im Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126<br />
9.4 Anonymität in zelluaren Mobilfunknetzen . . . . . . . . . . . . . . . . . . . . . 134<br />
9.5 Abschließende Bemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136<br />
Literatur 136<br />
10 Java-2 Micro Edition 138<br />
10.1 Java-2 Editionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138<br />
10.2 Struktur der Java-2 Micro Edition . . . . . . . . . . . . . . . . . . . . . . . . . 138<br />
10.3 MIDlet Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144<br />
10.4 Aktuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149<br />
Literatur 150<br />
11 Wearable Computing 152<br />
11.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152<br />
11.2 Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155<br />
11.3 Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157<br />
11.4 Konkrete Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162<br />
11.5 Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165<br />
Literatur 166<br />
12 Einführung Physical-Virtual Integration 169<br />
12.1 Was ist Physical-Virtual Integration? . . . . . . . . . . . . . . . . . . . . . . . 169<br />
12.2 Wozu dient sie? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169<br />
12.3 Wesentliche Abstufungen von Physical-Virtual Integration . . . . . . . . . . . 169<br />
3
Inhaltsverzeichnis<br />
12.4 Welche Formen von Physical-Virtual Integration sind derzeit möglich? . . . . 171<br />
12.5 Was bringt die Zukunft? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178<br />
Literatur 181<br />
4
1 Ubiquitous Computing - Ansätze, Ziele, Beispiele<br />
Zusammenfassung<br />
Die folgende Ausarbeitung soll eine Einführung<br />
in das Gebiet des Ubiquitous<br />
Computing geben und die dahinterstehende<br />
Vision verdeutlichen. Anhand eines<br />
Beispiels werden dann die Kennzeichen<br />
von Ubiquitous Computing etwas<br />
näher erläutert.<br />
1.1 Einleitung<br />
Die Möglichkeit, jederzeit und überall auf<br />
Informationen zuzugreifen, ist mittlerweile<br />
durch mobile Geräte (Laptop, Handy, PDA)<br />
und verbesserter drahtloser Kommunikation<br />
(WLAN, Bluetooth, UMTS) Realität geworden.<br />
Ubiquitous Computing umfasst jedoch<br />
weitaus mehr als das bis dato Erreichte. Ziel<br />
hiervon ist die Ausstattung von Alltagsgegenständen<br />
mit eigener miniaturisierter Rechenleistung<br />
und Sensoren und die Möglichkeit<br />
der Kommunikation untereinander, so dass<br />
sie sich nahtlos und unsichtbar zum Ziel der<br />
Unterstützung der Menschen in das Umfeld<br />
integrieren.<br />
1.2 Einführung und Überblick<br />
1.2.1 Entwicklung der<br />
Computer-Technologie<br />
Die elektronische Datenverarbeitung wurde<br />
in den letzten 50 Jahren durch zwei Trends<br />
geprägt, die auch die Beziehung zwischen<br />
Mensch und Maschine bestimmt haben: Zum<br />
einen die Großrechner (Mainframes) und<br />
später die Einzelplatzrechner (PC). Die ersten<br />
Mainframesysteme in den 50er Jahren<br />
dienten mehreren Anwendern, oft gesamten<br />
Organisationen. Anfang der 80er ermöglichten<br />
die technologischen Entwicklungen im<br />
Ozan Doksöz<br />
ozan.doksoez@informatik.uni-ulm.de<br />
Bereich der Elektronik und der damit verbundene<br />
Preisverfall von Komponenten und<br />
Systemen die Herstellung von preiswerten,<br />
kompakten und leistungsfähigen Einzelplatzrechnern.<br />
Der Trend ging von EDV-Systemen<br />
bei denen viele Anwender an einem Rechner<br />
arbeiten über zu Arbeitsplätzen denen je ein<br />
Rechner zur Verfügung stand.<br />
Abbildung 1: Trends [Dan97]<br />
Heutzutage verbindet das Internet fast alle<br />
Computer der Welt [Mat02a]. Anfangs<br />
war die Vernetzung von PCs ein Mittel,<br />
durch die Nutzung gemeinsamer Ressourcen<br />
und den Austausch von Dateien die<br />
klassische Zweckbestimmung der PCs aufzuwerten.<br />
Heutzutage hat sich mittlerweile<br />
das Bild gewendet: der PC steht nicht mehr<br />
im Mittelpunkt, an dem andere Netzperipherie<br />
angeschlossen wird. Vielmehr hat das<br />
Netz als solches eine unabhängige, dauerhafte<br />
Existenz angenommen und spielt die<br />
dominante Rolle, d.h. PC’s werden angeschafft<br />
weil es das Internet gibt und durch<br />
den PC der Zugang zum WorldWideWeb<br />
überhaupt erst möglich wird. Inzwischen sind<br />
jedoch der WAP-Standard in Europa und<br />
das i-mode System in Japan, die einen eingeschränkten,<br />
drahtlosen Internetzugang ermöglichen,<br />
erste Anzeichen dafür, daß sich<br />
5
Ozan Doksöz<br />
das Internet über seine klassische Domäne<br />
hinaus auszubreiten beginnt. Der Trend geht<br />
hin, den Informationszugang sofort, überall<br />
und zu allem zu ermöglichen. Umgekehrt<br />
können mittlerweile auch Handys auch<br />
als mobile WWW-Server fungieren, und beispielsweise<br />
den Aufenthaltsort fernabfragbar<br />
machen. Das Internet verbindet charakteristisch<br />
Elemente der Mainframesystemen<br />
mit Elementen von Einzelplatzrechnersysteme<br />
- es handelt sich hier um traditionelle<br />
Client-Server Beziehung, jedoch in einem<br />
sehr großem Ausmaß, bei dem die PCs die<br />
(Web)Clients und die Webserver die Mainframes<br />
sind. Das sogenannte Internet-Zeitalter<br />
kann als Übergangsphase zwischen dem<br />
PC-und dem Ubiquitous Computing-Zeitalter<br />
betrachtet werden.<br />
1.2.2 Was ist Ubiquitous Computing?<br />
Ubiquitous Computing setzt als Ziel die<br />
digitale Unterstützung des Lebensumfeldes<br />
aller Menschen durch die modernen<br />
Informationstechnologien.[DP01] “Ubiquitous“<br />
heißt auf Deutsch allgegenwärtig,<br />
im konkreten Fall: der Computerzugang ist<br />
überall möglich. Die Unsichtbarkeit der Computer<br />
zielt darauf ab den Nutzer fast vollständig<br />
von der Kenntnis beliebiger technischer<br />
Details der verwendeten Ressourcen zu entbinden.<br />
Demnach sollen Computer als einfache,<br />
ubiquitär verfügbare Werkzeuge dienen.<br />
Die Computerfunktionen sollen für den Nutzer<br />
intuitiv und selbstverständlich sein.<br />
1.2.3 Technische Voraussetzungen für<br />
die Realisierung<br />
Heutzutage weisen die Technologietrends<br />
bereits auf “verschwindende“ und gleichzeitig<br />
allgegenwärtige Computertechnik hin. Im folgenden<br />
werden die wichtigsten Entwicklungen<br />
näher erläutert [Mat02b].<br />
6<br />
Moorsches Gesetz: Dem Mooreschen<br />
Gesetz folgend, verdoppelt sich die<br />
Leistung (Geschwindigkeit und Speicherkapazität)<br />
von Mikroprozessoren<br />
alle achtzehn Monate. Andere Technologieparameter<br />
wie Speicherdichte<br />
oder Kommunikationsbandbreite zeigen<br />
auch einen ähnlich steigenden<br />
Trend. Damit wird der Preis der elektronischen<br />
Bauelemente bei konstanter<br />
Leistungsfähigkeit immer billiger.<br />
Diese elektronischen Fortschritte bietet<br />
die Möglichkeit der zukünftigen Massenproduktion<br />
unterschiedlicher Computer.<br />
Entwicklungen in der Materialwissenschaft:<br />
Die ubiquitären Computer<br />
der Zukunft werden sich äusserlich von<br />
den heutigen sehr stark unterscheiden.<br />
Sie werden viel mehr in die Alltagsgegenstände<br />
integriert und verschmelzen<br />
mit der Umgebung. Flexible Bildschirme<br />
und intelligentes Papier, intelligente<br />
Stifte sind Beispiele für neue Materialen,<br />
welche die Entwicklung des Ubi-<br />
Comp massgeblich beeinflussen werden.<br />
Fortschritte in der Kommunikationstechnik:<br />
Große Fortschritte werden<br />
derzeit auf dem Gebiet der drahtlosen<br />
Kommunikation erzielt. Internetfähige<br />
Handys, PDAs, u.ä. kommunizieren<br />
drahtlos mit anderen Geräten<br />
ihrer Umgebung. Neue Kommunikationstechnologien<br />
(z.B. Body Area Networks),<br />
-standards (z.B. Bluetooth) und<br />
-konzepte (z.B. Spontaneous Networking)<br />
bringen neue Awendungspotenziale.<br />
Verbesserungen in der Sensor-<br />
Technik: Kleinste integrationsfähige<br />
Sensoren reagieren nicht nur auf Licht,<br />
Beschleunigung, Temperatur sondern<br />
analysieren auch Flüssigkeiten und<br />
Gase und ermöglichen so intelligenten<br />
Geräten die autonome Aufnahme<br />
ihrer Umgebung.
1.3 Vision und Kennzeichen<br />
1.3.1 Ziel und Vision<br />
“The most profound technologies are those<br />
that disappear.“[Wei91] Dieser Satz<br />
kann als Leitsatz der Vision Marc Weisers<br />
betrachtet werden. Damit ist jedoch nicht gemeint<br />
dass die Geräte physisch unsichtbar<br />
werden. Vielmehr soll die Benutzung der Geräte<br />
derart wenig Aufmerksamkeit erfordern,<br />
dass ihre Technologie vom Benutzer nicht<br />
bewußt wahrgenommen wird. Es soll eine<br />
Verschmelzung der Technologie mit dem alltäglichen<br />
Leben stattfinden, bis sie davon<br />
nicht mehr zu unterscheiden ist.<br />
Abbildung 2: Marc Weiser [Wei]<br />
Marc Weiser führt als Beispiel für “verschwindende“<br />
Technologie die Technik des Schreibens<br />
und Lesens an. Die Fähigkeit, Zeichen<br />
zum Abspeichern von Informationen zu verwenden,<br />
ermöglicht es, Wissen langfristig<br />
und unabhängig von der beschränkten Erinnerungsfähigkeit<br />
des Menschen zu speichern.<br />
Heutzutage ist diese Möglichkeit, abgesehen<br />
von Ländern mit hohen Analphabetenquoten,<br />
so selbstverständlich geworden,<br />
daß die Menschen es kaum noch bewußt<br />
wahrnehmen. Der Mensch ist ständig<br />
von irgendwelchen Schriftzeichen umgeben,<br />
sei es Bücher, Straßenschilder oder Werbeplakate.<br />
Die Aufnahme der Information erfolgt<br />
völlig unbewußt und ohne besondere<br />
Anstrengung. Auch wenn es um eine Notiz<br />
geht, im Vordergrund steht der Inhalt dieser<br />
Notiz und nicht die Technik wie die einzel-<br />
1.3 Vision und Kennzeichen<br />
nen Buchstaben zu schreiben sind. So unbewußt<br />
und intuitiv soll nach Marc Weiser<br />
auch die Benutzung von Computern sein. Sie<br />
sollen allgegenwärtig in großer Zahl verfügbar<br />
sein, aber keinerlei Aufmerksamkeit erfordern.<br />
Primär sollen sie nur ihre Aufgaben<br />
erledigen, die dem Benutzer bei seiner Arbeit<br />
helfen. Dabei sollen sie sich vollständig<br />
in die Umwelt integrieren und den Benutzer<br />
nicht von seinen eigentlichen Zielen ablenken.<br />
Ubiquitous Computing hat zum Ziel<br />
computergespeicherte Daten und Informationen<br />
so einfach wie möglich ohne zusätzliche<br />
Belastung zur Verfügung zu stellen. Heutige<br />
Computer entsprechen diesen Anforderungen<br />
in keiner Weise. Die Benutzung ist<br />
kompliziert und erfordert komplexes Wissen<br />
für effizientes Nutzen. Weiterhin sind Computer<br />
keinesfalls in die alltägliche Umgebung<br />
integriert. Sie bilden eine eigene, isolierte<br />
Welt, die mit den normalen Arbeitsvorgängen<br />
nichts zu tun hat. Zwischen der eigentlichen<br />
Arbeit in der realen Welt und der Computerwelt<br />
besteht ein Bruch, den der Benutzer<br />
überwinden muß, indem er mit dem Computer<br />
in einer Fachsprache kommuniziert. Dabei<br />
muß sich der Benutzer dem Computer<br />
anpassen und nicht umgekehrt. Ein weiteres<br />
Hemmnis bei der Benutzung von Computern<br />
ist, dass der Fokus des Benutzers auf<br />
einen einzelnen Bildschirm gerichtet ist. Dadurch<br />
wird der Blick auf die reale Umgebung,<br />
also z.B. die Kollegen, die sich im selben Büro<br />
aufhalten, geschmälert. Ubiquitous Computing<br />
soll diese Probleme in seiner Vision<br />
beheben. Hunderte von miteinander vernetzten<br />
Computern sollen dem Büroarbeiter der<br />
Zukunft unauffällig die Arbeit erleichtern und<br />
nicht schwerer zu benutzen sein als ein Stück<br />
Papier und ein Bleistift.<br />
1.3.2 Kennzeichen von Ubiquitous<br />
Computing<br />
Einbettung [Gel00] Das Prinzip der Einbettung<br />
lässt sich mit einem Satz auf den<br />
Punkt bringen: “Computer in der Welt statt<br />
Welt im Computer“. D.h, das Ziel von Ubiquitous<br />
ist eine mit Informationen angereicherte<br />
7
Ozan Doksöz<br />
Welt zu schaffen und nicht weiterhin in einer<br />
Art Parallelwelt auf Informationen zugreifen<br />
zu müssen. Computer werden als Sekundärartefakt<br />
(so wie Elektromotoren) betrachtet.<br />
Somit ist eine weitere Dezentralisierung der<br />
Computerleistung vom Mainframe zu Smart<br />
Devices nötig. Grundsätzlich unterscheidet<br />
man zwischen physischer und kognitiver Einbettung.<br />
Physische Einbettung: Einbettung elektronischer<br />
Geräte (Haushalt, A/V, Spielzeug,<br />
Auto, etc) in alle Lebensbereiche.<br />
98<br />
Kognitive Einbettung: Die elektronischen<br />
Geräte sollen nicht nur aus den<br />
Augen sondern vor allem aus dem<br />
Sinn verschwinden: Computernutzung,<br />
die sich in alltägliche Abläufe einfügen<br />
lässt.<br />
Vernetzung<br />
8<br />
Vernetzung aller Informations(quellen):<br />
Aus der vergangenen Entwicklung sind<br />
wir daran gewöhnt, dass Computer,<br />
z.B. in Form von Workstations, vernetzt<br />
werden. Heutzutage wird die Vernetzung<br />
aller Geräte (z.B. Auto, Haushalt,<br />
etc.) angestrebt. Das Ziel in Zukunft<br />
sämtliche Gegenstände des alltäglichen<br />
Gebrauchs miteinander verbinden<br />
zu können, soll mit der Forschung<br />
erreicht werden.<br />
Spontane Vernetzung: Es wird eine offene,<br />
verteilte und dynamische Welt angestrebt,<br />
in der sich die Objekte zur<br />
vorübergehenden Zusammenarbeit finden<br />
und sich a priori nicht kennen müssen,<br />
um einander nutzen zu können.<br />
Vernetzung kompensiert Dezentralisierung:<br />
Durch die Vernetzung wird die<br />
Kohärenz in dezentralisierten Systemen<br />
gewahrt. Zusätzlich wird die Disaggregation<br />
ermöglicht, d.h. die Auslagerung<br />
von Komponenten aus zentralisierten<br />
Systemen.<br />
Allgegenwart Die Realisierung des Prinzips<br />
“Anytime, Anywhere Computing“. Die<br />
Mobilität soll einen ortsunabhängigen Zugriff<br />
ermöglichen und die Ubiquität für die Verfügbarkeit<br />
sorgen.<br />
Kontext Der Kontext bzw. der Bezug zur<br />
realen Welt steht im Mittelpunkt der Betrachtung.<br />
Nach Weiser kann ein Computer nur<br />
mit dem Wissen in welcher Umgebung er ist,<br />
sein Verhalten dementsprechend anpassen.<br />
Die Schnittstellen zwischen realer und virtueller<br />
Welt sind herzustellen, den sog. fließenden<br />
Übergang zwischen “der Welt der Atome“<br />
und der “Welt der Bits“. Des weiteren<br />
ist situatives Verhalten anzustreben indem<br />
vom expliziten Dialog zur impliziter Interaktion<br />
übergegangen wird.<br />
Neue Geräte - smart devices Dieser<br />
Punkt stellt ein Hauptmerkmal der Post-<br />
PC Generation dar, nämlich die Diversifikation.<br />
Die Geräte werden für verschiedene<br />
Anwendungen verwendet (“Information<br />
Appliances“). Diversifikation bezüglich Rechenleistung,<br />
Kommunikation, Form- Faktor,<br />
Betriebssystem, User Interface, Schnittstelle<br />
zur realen Welt usw. Bei den Smart Devices<br />
wird also mehr Gewicht auf Interaktion, Kontext<br />
und auf Vernetzung gelegt, weniger auf<br />
den eigenen Funktionsumfang und die eigene<br />
Interaktion.<br />
1.4 Beispiel 1: Wearable Computing<br />
Unter Werable Computer versteht man diejenigen<br />
Computer, deren Systemkomponenten<br />
am Körper getragen werden. Diese Form<br />
von Technik hat das Ziel den Benutzer in seiner<br />
Arbeit zu unterstützen ohne ihn zu einzuschränken<br />
oder zu behindern.<br />
Als konkretes Bespiel soll die Datenbrille unter<br />
den vorher genannten Aspekten näher<br />
betrachtet werden.
Abbildung 3: Datenbrille [Hum99]<br />
Der Einsatz von Displays die direkt vor das<br />
Auge des Benutzers montiert werden, haben<br />
einen großen Vorteil. So können z.B. gerade<br />
benötigte Skizzen von einem Bauteil mittels<br />
Spiegel auf die Brille eines Ingenieurs<br />
projeziert werden ohne dass sein Sichtfeld<br />
beeinträchtigt wird. Mittels einer integrierten<br />
Kamera und einer Auswertung des Bildes<br />
kann das Wearable nützliche Informationen<br />
auf das Display ausgeben und z.B. als Bedienungsanleitung<br />
dienen.<br />
Das Prinzip der Einbettung ist an diesem<br />
Beispiel klar. Die Datenbrille ist sowohl physisch<br />
als auch kognitiv in das Leben, z.B. das<br />
Arbeitsleben eines Ingenieurs, integriert und<br />
unterstützt den Tragenden bei seiner Arbeit<br />
ohne ihn dabei zu hindern. Bei der Vernetzung<br />
ist es von Bedeutung in welchem Maße<br />
die Person lokale Informationen benötigt,<br />
oder inwieweit die Infrastruktur es zuläßt Informationen<br />
z.B. per Funknetz zu holen. z.B.<br />
müßte ein Arbeiter in einem Bergwerk die für<br />
seine Tätigkeit benötigten Informationen mit<br />
sich tragen, während man sich für Büroarbeit<br />
in der Stadt die nötigen Informationen<br />
per Funk holen kann. Allgegenwart und Kontext<br />
sind komplementäre Konzepte. Durch<br />
die Mobilität der Datenbrille wird ortsunabhängiger<br />
Zugriff auf die Informationen ermöglicht<br />
und die Ubiquität der Informationen<br />
sorgt für die Verfügbarkeit. Aus dem Kontext<br />
wird die Person mit den richtigen Informationen,<br />
zum richtigen Zeitpunkt am richtigen<br />
1.5 Beispiel 2: Das intelligente Haus<br />
Ort versorgt. Situatives Verhalten mit impliziter<br />
Interaktion ist hiermit gewährleistet.<br />
Die Anwendungsgebiete von Wearable Computing<br />
sind sehr vielfältig. Die Möglichkeiten<br />
sind nahezu unbegrenzt und lassen noch viel<br />
Platz für Phantasie.<br />
1.5 Beispiel 2: Das intelligente Haus<br />
“Ist die Kaffemaschine aus , der Heizstrahler<br />
an, die Balkontür zu ? Zweifel, die Menschen<br />
bei der Arbeit, im Urlaub oder unterwegs<br />
plagen können“ [Mil02]. Noch sind die<br />
Haushaltsgeräte und -systeme untereinander<br />
nicht kommunikationsfähig. Sie arbeiten<br />
eigenständig und isoliert, ohne Kontakt zu<br />
anderen Geräten. Das Smart-Haus von morgen<br />
sieht vor, alle Geräte und Systeme eines<br />
Haushalts miteinander zu vernetzen, teilweise<br />
zu automatisieren und eine Fernsteuerung<br />
zu ermöglichen.<br />
Funktionsweise Die Vernetzung wird<br />
durch ein hausinternes Netzwerk gewährleistet,<br />
basierend auf leitungsgebundener als<br />
auch drahtloser Technologie mit Anbindung<br />
an externe Netze für die Ausführung und<br />
Überwachung der Geräte innerhalb und ausserhalb<br />
des Hauses. Der Austausch der Daten<br />
und Informationen erfolgt über ein BUS-<br />
System, das individuell angepasst werden<br />
kann.<br />
Abbildung 4: Das intelligente Haus [Zie]<br />
9
Ozan Doksöz<br />
Vorteile Neben Energieeinsparung, Erhöhung<br />
der Sicherheit und des Komforts ist<br />
das Ziel der Smart-Haus-Technik die Ermöglichung<br />
neuer Dienstleistungen. Weiterhin<br />
kann die intelligente Haustechnik älteren<br />
und körperlich behinderten Menschen dabei<br />
helfen, Barrieren im Alltag zu überwinden<br />
und zu einer selbständigen Lebensführung<br />
beitragen.<br />
Sicherheit Smart-Häuser bieten eine Menge<br />
von Möglichkeiten, um die Sicherheit im<br />
eigenen Haus zu erhöhen. Mit dem Telefon<br />
vernetzte Rauchmelder können im Falle<br />
eines Brandes die Feuerwehr alarmieren.<br />
Glasbruchsensoren und Bewegungsmelder<br />
können einen Einbruch registrieren und die<br />
Polizei alarmieren. Simulation der Anwesenheit<br />
während eines Urlaubs oder Überwachung<br />
der Sicherheitsanlage von aussen<br />
sind weitere Möglichkeiten.<br />
Komfort Spielereien und Dinge, die den<br />
Komfort und die Bequemlichkeit erhöhen,<br />
sind ebenfalls in Vielfalt angeboten. Kühlschränke,<br />
die eine schnelle, übersichtliche<br />
und einfache Vorratshaltung ermöglichen<br />
und Einkaufslisten erstellen, oder über das<br />
Internet selbständig die Milch bestellen, oder<br />
einen darauf hinweisen, dass morgen das<br />
Haltbarkeitsdatum der Käse abläuft. Intelligente<br />
Badewannen, die ferngesteuert und<br />
nach persönlichen Vorlieben eingestellt werden<br />
können. Ein intelligenter Badezimmerspiegel<br />
mit eingebautem Display für Frühstücksfernsehen<br />
oder Börsenkurse kann das<br />
Körpergewicht überprüfen und als Gedächtnisstütze<br />
dienen, in dem es an die Einnahme<br />
von Medikamenten erinnert. Waschmaschinen,<br />
die bei Defekten automatisch den<br />
Installateur kontaktieren oder per SMS melden,<br />
dass der Waschvorgang beendet ist. Eine<br />
Raumsensorik im Wohnzimmer erkennt<br />
Personen und reguliert Raumklima und Licht<br />
den Wünschen entsprechend.<br />
10<br />
Ökologische Aspekte Funktionen zum<br />
Energiesparen ist ein wichtiger Schwerpunkt<br />
in den intelligenten Häusern. So können<br />
Heizungs- und Belüftungssysteme optimal<br />
aufeinander abgestimmt werden [Erk99].<br />
Heizkörper werden in Räumen abgeschaltet,<br />
in denen die Fenster geöffnet sind, oder das<br />
Licht in Räumen, in denen sich niemand aufhält,<br />
ausgeschaltet. Sensoren zur Messung<br />
der Temperatur, Feuchtigkeit und Luftqualität<br />
öffnen und schliessen die Fenster automatisch.<br />
Beim Verlassen des Hauses wird die<br />
Heizung reduziert und bei einem Gewitter<br />
macht sich das Haus wetterfest.<br />
Die genannten Beispiele beschreiben Möglichkeiten<br />
wie ein Haus der Zukunft aussehen<br />
könnte. Viele weitere Beispiele ließen<br />
sich diesen noch anfügen. An der Vision<br />
vom intelligenten Haus wird bereits geforscht<br />
und experimentiert. Pilothäuser sind<br />
in USA, Japan, Holland, Schweiz, Schweden<br />
und Deutschland in Betrieb [woh].<br />
Die Frage, ob so etwas notwendig ist, stellt<br />
sich immer wieder. Nach anfänglicher Skepsis<br />
und Kritik werden zukünftige Entwicklungen<br />
und Technologien, so wie bei der Erfindung<br />
der Eisenbahn oder Waschmaschine<br />
oder des Handys, nach und nach akzeptiert<br />
und in das tägliche Leben integriert .<br />
Situation- und Location Awareness sind Begriffe,<br />
an die sich zukünftige Produkte halten<br />
müssen, d.h. sie müssen erkennen können,<br />
“wo sie sind, wer sie sind und mit wem<br />
sie es zu tun haben“ [Ehr01]. Anforderungen<br />
wie eigenständige Konfiguration, Überwachung<br />
und Fehlertoleranz je nach Situation<br />
sind zu erfüllen.<br />
1.6 Ausblick und kritische Würdigung<br />
Der Trend zeigt eindeutig in Richtung einer<br />
weiteren Informatisierung der Welt - beispielsweise<br />
durch die Einbettung von immer<br />
mehr Prozessoren in Alltagsdinge und<br />
durch den zunehmenden Anschluss von allerlei<br />
Geräten an das Internet. Ubiquitous<br />
Computing ist ein Konzept, daß den Menschen<br />
in den Mittelpunkt stellt. Nicht die
technische Machbarkeit soll bei der Entwicklung<br />
von elektronischen Geräten ausschlaggebend<br />
sein, sondern der Nutzen für den Anwender.<br />
Solche Geräte sollen sich auf diejenigen<br />
Funktionen beschränken, die der Benutzer<br />
auch tatsächlich braucht und nicht alles<br />
können, was technisch gerade möglich<br />
ist. Dadurch soll eine leichtere Bedienung ermöglicht<br />
werden. Weiterhin sollen die Geräte<br />
in den normalen Arbeitsablauf integriert sein,<br />
so daß der Benutzer nicht durch das Gerät<br />
von seiner eigentlichen Arbeit abgelenkt<br />
wird. Durch solche Entwicklungen kann die<br />
Effizienz der Arbeit und die Akzeptanz der<br />
Benutzer sicherlich deutlich gesteigert werden.<br />
In dieser Hinsicht ist eine Entwicklung in<br />
die Richtung, die Marc Weiser aufzeigt, sehr<br />
begrüßenswert. Es gibt aber auch eine Reihe<br />
von Gefahren, die eine solche Entwicklung<br />
mit sich bringt. Zum einen ist das Problem<br />
des Datenschutzes zu nennen. Die Speicherung<br />
einer Vielzahl von sensiblen Daten einer<br />
Person birgt immer das Potential, daß diese<br />
Daten mißbraucht werden. Da das Ubiquitous<br />
Computing das Ziel verfolgt, Systeme<br />
zu bauen, die möglichst intuitiv nutzbar<br />
sind, wird der Benutzer sich nicht mit komplizierten<br />
Authentifizierungs- und Verschlüsselungsoperationen<br />
herumschlagen wollen.<br />
Trotzdem muß auf irgendeine Art die Datensicherheit<br />
gewährleistet werden. Solange<br />
dieses Problem nicht gelöst ist, muß die Entwicklung<br />
von ubiquitären Systemen immer<br />
auch kritisch betrachtet werden. Eine weite-<br />
Literatur<br />
re Gefahr ist die zunehmende Abhängigkeit<br />
von Computern. Zum Einen steigt diese Abhängigkeit<br />
schon allein wegen der größeren<br />
Anzahl von Computern. Wenn in einem Veranstaltungsraum<br />
keine herkömmlichen Tafeln,<br />
sondern nur noch elektronische Boards<br />
verwendet werden, ist der Raum bei einem<br />
eventuellen Stromausfall nicht mehr zu gebrauchen.<br />
Eine normale Tafel dagegen kann<br />
unter fast jeden Umständen verwendet werden.<br />
Genauso verhält es sich mit allen anderen<br />
Gegenständen, die im Ubiquitous Computing<br />
durch Computer ersetzt werden sollen.<br />
Zusätzlich erhöht aber auch die Idee des<br />
Ubiquitous Computing an sich die Abhängigkeit.<br />
Je weniger Wissen und Können die Verwendung<br />
eines elektronischen Geräts erfordert,<br />
desto weniger wird der Nutzer auch im<br />
Falle eines Fehlers die Ursache herausfinden<br />
können. Ein weiters Problem, das von Marc<br />
Weiser überhaupt nicht angesprochen wird,<br />
ist die Umweltbelastung durch eine wachsende<br />
Anzahl elektronischer Geräte. Schon<br />
heute stellt die Zunahme von Elektroschrott,<br />
der giftige Schwermetalle enthält und eigentlich<br />
gesondert recycelt und entsorgt werden<br />
muß, ein großes Problem dar. Die Entwicklung<br />
von billigen und kleinen Geräten, die zu<br />
Hunderten und Tausenden in Einsatz kommen<br />
sollen, wird dieses Problem wesentlich<br />
verstärken. Trotzdem ist Marc Weisers Konzept<br />
ein beachtenswerter Ansatz, der wesentliche<br />
Verbesserungen in der Computertechnologie<br />
bringen kann.<br />
[Dan97] Alan Daniels: Ubiquitous Computing. http://www.cc.gatech.edu/<br />
classes/cs6751_97_fall/projects/gacha/daniels% _essay.html,<br />
1997.<br />
[DP01] Bernd Skiera Donovan Pfaff: Ubiquitous computing - abgrenzung,merkmale<br />
und auswirkungen aus betriebswirtschaftlicher sicht. In Wirtschaftsinformatik:<br />
Der Mensch im Netz-Ubiquitous Computing,4. Liechtensteinisches<br />
Wirtschaftsinformatik-Symposium an der Fachhochschule Liechtenstein. Britzelmaier<br />
Bernd, Geberl Stephan, Weinmann Siegfried (Hrsg.), 2001.<br />
11
Literatur<br />
[Ehr01] Reichl Ehret, Pelka: Mikroelektronik gestaltet die Zukunft. http://www.izm.<br />
fhg.de/vue/pdf/strategie.pdf, 2001.<br />
[Erk99] Thomas Erkert: TeleCare und Intelligentes Haus - Intelligente Technik für die Pflege<br />
und den Haushalt. http://www.bagso.de/715/9904_3_04.htm, 1999.<br />
[Gel00] Hans W. Gellersen: Ubiquitous Computing - Vorlesung im WS 00/01. http://<br />
www.teco.edu/lehre/ubiqws0001/skript/01.pdf, 2000.<br />
[Heu01] Markus Heurung: PC Konfektion. http://homepages.fh-giessen.de/~<br />
hg10013/Lehre/MMS/WS0102/pc-konfektion% /text.htm, 2001.<br />
[Hum99] Simone Humml: Forscher drehten das Weltbild um. http://rhein-zeitung.<br />
de/on/99/07/06/topnews/weltbild.html, 1999.<br />
[Kne00] Daniel Knebel: Mikrosystemanwendungen. http://www.rs.uni-siegen.de/<br />
Lehre/seminarmaterialien/MST-Seminar_SS200% 0/Ausarbeitung_<br />
Knebel.pdf, 2000.<br />
[Mat01a] Friedemann Mattern: Allgegenwärtigkeit des computers? datenschutz in einer welt<br />
intelligenter alltagsdinge. In Sicherheitskonzepte für das Internet. G. Müller, M.<br />
Reichenbach (Hrsg.), 2001.<br />
[Mat01b] Friedemann Mattern: Pervasive/Ubiquitous Computing. Informatik Spektrum,<br />
6/2001, S. 147.<br />
[Mat02a] Friedemann Mattern: Ubiquitous computing: Der trend zur informatisierung und<br />
vernetzung aller dinge. In Mobile Internet,Tagungsband 6. Deutscher Internet-<br />
Kongress. Gerhard Rossbach (Hrsg.), 2002.<br />
[Mat02b] Friedemann Mattern: Ubiquitous computing: Szenarien einer informatisierten welt.<br />
In E-Merging Media - Digitalisierung der Medienwirtschaft. A. Zerdick, A.Picot, K.<br />
Schrape, J.-C. Burgelman, R. Silverstone (Hrsg.), 2002.<br />
[Mil02] Franz Miller: Vernetzt und smart: Vom Kühlschrank bis zur Badewanne. http://<br />
www.bauelite.de/deutsch/news/newsdata_id191.html, 2002.<br />
[Mio00] Paul Miotti: Geschichte des Ubquitous Computing und wegweisende Projekte.<br />
http://www.inf.ethz.ch/vs/edu/SS2000/UC/papers/Miotti.<br />
html, 2000.<br />
[Wei] Marc Weiser: http://www.ubiq.com/hypertext/weiser/weiser.html.<br />
[Wei91] Marc Weiser: The Computer for the 21st Century. Scientific American,<br />
265(3)/1991, S. 94–104.<br />
[woh] wohnseiten.de: InHaus: Innovationszentrum -Intelligentes Haus Duisburg-. http:<br />
//www.wohnseiten.de/inhaus.html.<br />
[Zie] Augusta Ziegelbau: Der zukunftsweisende Trend in der Gebäudesystemtechnik.<br />
http://augusta-ziegelbau.de/bus/bus01.html.<br />
12
2 UI Patterns<br />
Zusammenfassung<br />
Bei der Erstellung von immer komplexeren<br />
Anwendungen mit einer wachsenden<br />
Zahl an Anforderungen ist der Einsatz<br />
von Patterns in nahezu allen Abschnitten<br />
des Entwicklungsprozesses ein bewährtes<br />
Hilfsmitel. Die folgende Ausarbeitung<br />
geht jedoch nicht nur auf den Begriff eines<br />
einzelnen Patterns ein, sondern soll<br />
verdeutlichen, wie man durch die Hintereinanderanwendung<br />
mehrer, zueinander<br />
im Bezug stehender Patterns zur<br />
Komplettlösung eines gesamten Systems<br />
gelangen kann. Dabei wird erläutert, in<br />
welcher Weise eine Patternsprache als<br />
alleiniges Hilfsmittel Lösungen für Systeme<br />
bereitstellt, die auf verschiedenen<br />
Plattformen und in unterschiedlichen<br />
Hardware- und Verwendungsumgebungen<br />
lauffähig sind. Da aufgrund der<br />
weit gefächerten Verwendung von Patterns<br />
ein Vielzahl variierender Formen,<br />
<strong>Format</strong>e und Verwendungszwecke besteht,<br />
soll hier versucht werden einen groben<br />
Einblick in die grundlegenden Eigenschaften<br />
der Patterns zu geben und deren<br />
mögliche Verwendung in der Praxis illustrieren.<br />
2.1 UI Patterns - Grundlagen<br />
2.1.1 Einleitung<br />
Patterns sind in der Softwareentwicklung vor<br />
allem im objektorientierten Bereich, ein bedeutendes<br />
Thema. Es handelt sich hierbei<br />
um eine Beschreibung von bewährten Lösungsstrategien<br />
zu wiederholt auftretenden<br />
Problemen. Die Ursprünge dieser Lösungsmuster<br />
sind in der Architektur zu finden. Auch<br />
hier werden sie, wie auch in vielen anderen<br />
Vera Pfeiffer<br />
vera.pfeiffer@informatik.uni-ulm.de<br />
Berufszweigen, zur Weitergabe von Erfahrungen<br />
immer noch erfolgreich verwendet.<br />
Für jede Wissenschaft oder Entwicklungsdisziplin<br />
ist ein gemeinsames Vokabular von<br />
großer Bedeutung. Ein Ziel der Patterns<br />
liegt darin, durch eine gemeinsame Sprache<br />
Kommunikationsprobleme zwischen Designern,<br />
Programmierern und Planern zu lösen,<br />
die alle aus unterschiedlichen Bereichen<br />
kommen.<br />
Durch die leicht verständliche Beschreibung<br />
eines allgemeinen Lösungsmusters können<br />
Algorithmen, Quellcode und ganze Module<br />
auch in weiteren Projekten wiederverwendet<br />
werden und dadurch die Komplexität von Anwendungen<br />
deutlich reduzieren. Damit eine<br />
solche Ansammlung von einzelnen Lösungen<br />
die Grundlage für eine Kommunikation<br />
darstellen kann, muss eine gewisse Vollständigkeit<br />
vorausgesetzt werden. Dies bedeutet,<br />
dass jedes Pattern eine Teillösung eines<br />
großen Ganzen darstellt und es für jedes<br />
Teilproblem ein dazu passendes Pattern<br />
geben sollte. Ein Pattern wird nicht isoliert<br />
betrachtet, sondern ist in eine hierarchische<br />
Struktur eingebettet, die es ermöglicht, ein<br />
komplexes Netzwerk auf der Basis von Patterns<br />
zu schaffen. Sind diese Voraussetzungen<br />
erfüllt, spricht man von einer Patternsprache.<br />
2.1.2 Historie<br />
Die derzeitige Bedeutung des Begriffs Patterns<br />
stammt aus den Schriften von Christopher<br />
<strong>Alexander</strong>, der verschiedene Bücher<br />
über Städteplanung und Architektur veröffentlichte.<br />
Er war der Meinung, dass die derzeitig<br />
entworfenen Bauten nicht die Ansprüche<br />
und Anforderungen der Menschen und<br />
der Gesellschaft erfüllen und ihrer Hauptaufgabe,<br />
der Verbessserung der Lebensbe-<br />
13
Vera Pfeiffer<br />
dingungen, nicht gerecht werden. Er fordert,<br />
dass Architekten anstreben sollen, mit ihren<br />
Arbeiten die Lebensqualität der Bewohner zu<br />
verbessern. Diese Forderung setzt sich aus<br />
drei Konzepten zusammen: the quality, the<br />
gate and the way.<br />
Mit Qualität meint <strong>Alexander</strong> alle wesentlichen<br />
Bedürfnisse, deren Erfüllung dem Leben<br />
Qualität verleihen, wie z.B. Frieden, Harmonie<br />
und Offenheit. Unter ”gate” versteht<br />
er den Mechanismus, der es ermöglicht, diese<br />
Qualität zu erreichen. Dahinter verbirgt<br />
sich eine Ansammlung verschiedener Patterns,<br />
die es erlaubt, verschiedene Designs<br />
zu schaffen, die all die unterschiedlichen Ansprüche<br />
erfüllen. Die Benutzung des ”ways”<br />
meint die Anwendung der Patterns, welche<br />
im ”gate” erläutert werden. Durch eine lebendige<br />
gemeinsame Patternsprache, welche<br />
die einzelnen Patterns miteinander in<br />
Beziehung setzt und untereinander verlinkt,<br />
soll eine allmählich anwachsenden Problemlösung<br />
möglich sein, bis am Ende die Qualität<br />
erreicht ist. [App00]<br />
Dazu gehört auch, dass sich der Entwurf eines<br />
Städtebauelements nach seiner Verwendung<br />
richten sollte und deshalb die Patterns<br />
nicht von Architekten, sondern von Bewohnern<br />
in einer allgemein verständlichen Sprache<br />
geschrieben werden sollten. Ein erstes<br />
Experiment zur Verwendung von Patterns in<br />
der Softwaretechnik führten 1987 Ward Cunningham<br />
und Kent Beck durch. Sie versuchten<br />
eine Smalltalk-Oberfläche zu entwerfen<br />
ohne Smalltalk zu beherrschen.<br />
Das große Vorbildwerk über Patterns in der<br />
Softwaretechnik veröffentlichte 1995 die sogenannte<br />
”Gang of Four”. Das Buch ”Design-<br />
Patterns - Elements of Reusable Object-<br />
Oriented Software” der vier Programmierer<br />
Helm, Johnson, Gamma und Vlissedes ist eine<br />
Sammlung von Patterns für objektorientiertes<br />
Design. Da sie jedoch zur Beschreibung<br />
nur Diagramme und Skizzen verwendeten,<br />
entsprechen diese nicht <strong>Alexander</strong>s Anforderungen<br />
für einen ausformulierten, leicht<br />
verständlichen Aufbau. Trotz einer übersicht-<br />
1 Zitat von Christopher <strong>Alexander</strong><br />
14<br />
lichen Gliederung der Patterns nach ihrem<br />
Verhalten, dem Aufbau und ihrer Struktur, ist<br />
diese Sammlung nicht vollständig und stellt<br />
deshalb keine komplette Patternsprache dar.<br />
Heute gibt es zahlreiche sehr unterschiedliche<br />
Patternsprachen, bei denen sich einige<br />
eher der Form <strong>Alexander</strong>s anpassen und<br />
andere wiederum die strukturelle Darstellung<br />
der GoF bevorzugen.<br />
Auf verschiedenen Kongressen, der bekannteste<br />
ist wohl die sogenannte Hillside Group,<br />
findet eine intensive Kommunikation und Diskussion<br />
statt, welche die Bedeutung von Patterns<br />
immer stärker verdeutlicht.<br />
2.1.3 Definition<br />
Each pattern is a three-part rule, which expresses<br />
a relation between a certain context,<br />
a problem and a solution. 1 ,<br />
Laut <strong>Alexander</strong> ist jedes Pattern eine dreiteilige<br />
Regel, die eine Beziehung zwischen<br />
einem in einem bestimmten Zusammenhang<br />
auftretenden Problem und der zugehörigen<br />
Lösung verdeutlicht. Doch warum sagt er<br />
nicht einfach: Ein Pattern ist eine Lösung eines<br />
Problems in einem bestimmten Zusammenhang?<br />
Ein Pattern ist nicht nur eine Instruktion allein,<br />
sondern muss auch in einen bestimmten<br />
Ablauf eingeordnet sein. Es handelt sich<br />
also um eine Regel, die sowohl erklärt, wie<br />
man ein bestimmtes Ding erzeugt, als auch<br />
angibt, wann man es erzeugen muss.<br />
Dieses Konzept <strong>Alexander</strong>s ist nicht einfach<br />
zu verstehen, nicht umsonst verfasste er ein<br />
500 Seiten umfassendes Buch über diese<br />
Thematik. Seine Definition erläutert er noch<br />
genauer, indem er ein Pattern als eine Element<br />
in der Welt beschreibt, das eine Beziehung<br />
zwischen einem Zustand und einem<br />
System aus verschiedenen Kräften herstellt,<br />
die in diesem Zusammenhang wiederholt<br />
auftreten. Zu dieser Beziehung existiert<br />
dann eine räumliche Anordnung, d.h eine Lösung,<br />
welche die wirkenden Kräfte gegenseitigt<br />
auflöst. Entscheidend ist dabei die Pro-
lemumgebung sowohl vor als auch nach der<br />
Lösung. [JO02]<br />
Konkret heißt dies, dass ein Pattern nicht nur<br />
eine Lösung zu einer bestimmten Problemstellung<br />
innerhalb eines größeren Projektes<br />
ist, sondern auch gleichzeitig Verweise auf<br />
nachfolgende Patterns gibt und seinerseits<br />
auch aus der Anwendung eines ihm übergeordneten<br />
Patterns zur Anwendung kommt.<br />
Die zwei größten und auch bekanntesten<br />
Patternsprachen für User Interfaces ist die<br />
”Common Ground”- Sammlung von Jennifer<br />
Tidwell und die Patterns von Martijn van Welie.<br />
Für Martijn van Welie sind Patterns ein<br />
Weg um alle Möglichkeiten einer guten User<br />
Interface Entwicklung festzuhalten, die er in<br />
seiner täglichen Arbeit als Webdesigner angesammelt<br />
hat. Jennifer Tidwell dagegen beschreibt<br />
Patterns als mögliche gute Lösungen<br />
zu einem allgemeinen Designproblem in<br />
einem bestimmten Zusammenhang. Sie beschreibt<br />
die unveränderbaren Eigenschaften<br />
eines Problems um eine Allgemeingültigkeit<br />
der Lösungen zu erreichen.<br />
Patterns sind eine allgemeine Anleitung in einem<br />
<strong>Format</strong>, dass verständlich und für jedermann<br />
leicht zu lesen ist. Sie übermitteln Wissen<br />
über gutes Design.<br />
Patterns sind:<br />
[App02]<br />
wiederverwendbare Lösungen zu allgemeinen<br />
Problemen<br />
abhängig vom Zusammenhang, in welchem<br />
das zu lösende Problem auftritt<br />
”alte Hüte” für erfahrene Experten<br />
eine textuelle Form um die besten Vorgehensweisen<br />
festzuhalten<br />
ein gemeinsames Vokabular zur Diskussion<br />
Patterns sind nicht<br />
nur für Software- oder Objektorientiertes<br />
Design geeignet<br />
[App02]<br />
2.1 UI Patterns - Grundlagen<br />
ungetestete Ideen und Theorien von<br />
neuen Erfindungen<br />
Lösungen, die nur einmal funktioniert<br />
haben oder nur einmal angewendet<br />
wurden<br />
abstrakte Heurismen und Prinzipien<br />
universelle Anwendungsvorschläge innerhalb<br />
jedes Zusammenhangs<br />
Was ist ein gutes Interface und was sind<br />
gute Patterns ?<br />
Patterns sollen nach der Definition von Christopher<br />
<strong>Alexander</strong> nicht die Probleme der Architekten<br />
oder Entwickler, sondern die der<br />
Anwender lösen.<br />
Die drei Erfolgsfaktoren für gutes Interfacedesign<br />
verbergen sich hinter den drei Begriffen<br />
”Visibility”, ”Affordances” und ”Constraints”.<br />
Der Benutzer sollte auf den ersten<br />
Blick erfassen können, was man im System<br />
alles steuern kann und wie man dabei vorzugehen<br />
hat. Durch sogenannte ”Affordances”<br />
soll gezeigt werden, wie das System<br />
zu benutzen ist. Hierbei sollen ”Constraints”<br />
helfen, welche die Bedienungsmöglichkeiten<br />
reduzieren. Patterns beschreiben also nach<br />
der Definition <strong>Alexander</strong>s die Möglichkeiten<br />
diese drei Faktoren umzusetzten. Hierbei soll<br />
die Beschreibung jedoch auf das ”was” und<br />
nicht auf das ”wie”, d.h. auf die technische<br />
Umsetzung ausgerichtet sein. Dennoch gibt<br />
es zahlreiche Patternsammlungen und Sprachen,<br />
die gegen die Forderung nach einer allgemeingültigen,<br />
auf den Benutzer ausgerichtete<br />
Beschreibung verstoßen und Lösungsstrategien<br />
für spezielle Techniken und Anwendungsbereiche<br />
geben.<br />
2.1.4 Bestandteile<br />
Trotz einer inzwischen sehr großen Anzahl<br />
verschiedener Patternsprachen gibt es kein<br />
eindeutiges und einheitlich gültiges <strong>Format</strong>.<br />
15
Vera Pfeiffer<br />
<strong>Alexander</strong> definierte eine dreiteilige Regel,<br />
die er später um Bilder und Beispiele erweiterte.<br />
Auf diese Beschreibung baut die sogenannte<br />
”Kanonische Form” auf, die mit kleinen<br />
Veränderungen heute von den meisten<br />
Patternautoren benutzt wird. Bei dieser Form<br />
sollten all die folgenden wesentlichen Elemente<br />
in einem Pattern klar wiederzuerkennen<br />
sein:<br />
16<br />
1. Name: Ein Pattern sollte eine kurze<br />
selbsterklärende Bezeichnung für das<br />
beschriebene Konzept haben. Die Namen<br />
der Patterns formen das Vokabular<br />
des Designerteams.<br />
2. Problem: Die konkrete Problemstellung<br />
und Absicht soll erläutert werden, d.h<br />
die Ziele, die man in einem bestimmten<br />
Zusammenhang innerhalb verschiedener<br />
Kräfte erreichen möchte. Hierbei<br />
wirken die verschiedenen Kräfte meist<br />
gegeneinander und auch entgegen die<br />
gewünschte Zielsetzung.<br />
3. Kontext: Um die Anwendbarkeit des<br />
Patterns sicherzustellen, müssen die<br />
Vorbedingungen dargestellt werden<br />
unter denen das Problem und seine<br />
Lösung wiederkehren und die für die<br />
Lösung wünschenswert sind.<br />
4. Kräfte: Eine Beschreibung der bedeutenden<br />
Konflikte und Beschränkungen<br />
und ihre wechselseitigen Wirkungen<br />
aufeinander, auch im Bezug auf die<br />
Ziele, die man erreichen möchte. Ebenso<br />
können hier unterschiedliche Prioritäten<br />
auf die einzelnen Konflikte und<br />
Gegebenheiten vergeben werden. Für<br />
eine Motivation zur Anwendung des<br />
Patterns wird hier auch oft schon, dem<br />
Beispiel vorweggreifend, ein konkretes<br />
Scenario beschrieben. Die Komplikationen<br />
eines Problems müssen aufgedeckt<br />
und alle möglichen Kompromisse,<br />
die in der Gegenwart zur Aufhebung<br />
der Spannung zu bewerkstelligen<br />
sind, müssen definiert werden.<br />
5. Lösung: Statisch definierte Beziehungen<br />
und dynamisch beschriebene Regeln,<br />
die es ermöglichen, das gewünschte<br />
Ergebnis zu erzielen. Die<br />
Beschreibung sollte Bilder, Diagramme<br />
und Text umfassen, welche die Struktur<br />
des Patterns, die vorkommenden<br />
Teilnehmer und deren Zusammenspiel<br />
identifizieren. Es soll nicht nur eine statische<br />
Strukturbeschreibung, sondern<br />
ebenso ein dynamisches Verhaltenskonzept<br />
verdeutlicht werden.<br />
6. Beispiele: Durch mehrere Anwendungsbeispiele<br />
des Patterns soll der<br />
spezifische Zusammenhang und die<br />
richtige Einordnung des Pattern zur<br />
Konstruktion einer Gesamtlösung verdeutlicht<br />
werden. Bewährte Anwendungen<br />
zu existierenden Lösungen verdeutlichen<br />
den Gebrauch und die Anwendbarkeit.<br />
7. Konsequenzen: Hier wird nun der Zustand<br />
der Problemstellung nach der<br />
Anwendung des Patterns beschrieben<br />
und sowohl die guten als auch die<br />
schlechten Konsequenzen und Probleme<br />
dargestellt, welche in dem neu entstandenem<br />
Zusammenhang nun auftreten<br />
könnten, d.h. die Nachbedingungen<br />
und Seiteneffekte. Auch sollte<br />
genannt werden, welche der Konflikte<br />
sich gelöst haben und welche immer<br />
noch bestehen. Dies hilft den resultierenden<br />
Zusammenhang aus der Anwendung<br />
eines Patterns in Beziehung<br />
zu einer Anfangssituation eines anderen<br />
Patterns zu setzten, da ein Pattern<br />
oft nur ein einzelner Schritt in der Bewerkstelligung<br />
eines großen Projektes<br />
ist.<br />
8. Einordnung: Eine Rechtfertigung der<br />
Schritte und Regeln des Patterns und<br />
seine Einordnung im kompletten Umfeld,<br />
um zu sehen, wie und warum alles<br />
so funktioniert. Es wird das Zusammenspiel<br />
der Konflikte erklärt und<br />
verdeutlicht, wie die erreichte Harmonie<br />
erzeugt wurde. Während im Lö-
sungsteil die nach außen sichtbare<br />
Struktur und das Verhalten beschrieben<br />
wird, folgt in diesem Teil die Darstellung<br />
des eigentlichen Schlüsselmechanismus,<br />
der alles bewirkt.<br />
9. Verwandte Patterns: Hier geht es um<br />
die statischen und dynamischen Zusammenhänge<br />
zwischen diesem einzelnen<br />
Pattern und den anderen in der<br />
gesamten Patternsprache. In verwandten<br />
Pattern wirken oft die gleichen Kräfte<br />
und bestehen ähnliche Konflikte. Sie<br />
haben oft Anfangs- oder Folgezustände,<br />
die auf Anfangs- oder Endzusammenhänge<br />
von anderen Patterns passen.<br />
Die Anwendung eines Patterns<br />
führt zur Anwendung eines ihm verwandten.<br />
10. Bekannte Verwendungen: Durch das<br />
Aufzeigen der Verwendung des Patterns<br />
in existierenden Systemen soll<br />
bestätigt werden, dass es sich gewiss<br />
um eine geprüfte Lösung zu eiem wiederkehrenden<br />
Problem handelt. Dieser<br />
Teil kann jedoch auch schon im Beispielteil<br />
mit abgedeckt werden.<br />
[App00]<br />
Nicht alle diese Teile müssen in einer Patternbeschreibung<br />
explizit auf diese Art erklärt<br />
sein. Es muss jedoch, um die Anforderungen<br />
<strong>Alexander</strong>s an ein Patternformat<br />
zu erfüllen, ein Kontext-Problem-Lösungs-<br />
Schema erkennbar sein, welches die oben<br />
genannten Teile implizit enthält.<br />
Neben dieser textuell beschreibenden Form<br />
verwenden viele Autoren auch ein mehr<br />
strukturierteres <strong>Format</strong>. Da dieses auf die<br />
”GoF” (Gang of Four) zurückzuführen ist,<br />
wird es auch ”GoF <strong>Format</strong>” genannt. Diese<br />
Autoren verzichteten komplett auf eine textuelle<br />
Beschreibung und verwendeten weitestgehend<br />
Struktur- und Flußdiagramme.<br />
Die erste größere Zusammenfassung von<br />
User Interface Patterns, die Gommon<br />
Ground von Jenifer Tidwell, hält sich im Aufbau<br />
der Patterns stark an die gewünschten<br />
2.1 UI Patterns - Grundlagen<br />
Vorgaben von <strong>Alexander</strong>. Welie dagegen verwendet<br />
eine Kombination der Definitionen<br />
von <strong>Alexander</strong> und den Ansätzen der ”GoF”.<br />
Dies ermöglicht, durch Skizzen und Beispiele<br />
schneller den Inhalt eines Patterns zu erkennen<br />
und festzustellen, ob es das ist, wonach<br />
man sucht.<br />
Pattern von Jenifer Tidwell<br />
Step-by-Step Instructions<br />
Examples:<br />
Wizards<br />
Installation instructions for all kinds of<br />
appliances, software, etc.<br />
Recipes<br />
Context: A user needs to perform a complex<br />
task, with limited time, knowledge, attention,<br />
or space. Alternatively, the nature of the<br />
task is step-by-step, and it’s meaningless to<br />
show all the action possibilities at once. Problem:<br />
How can the artifact unfold the possible<br />
actions to the user in a way that does not<br />
overwhelm or confuse them, but instead guides<br />
them to a successful task completion?<br />
Forces:<br />
The user doesn’t always want, or need,<br />
to understand all the details of what<br />
they are doing.<br />
A user presented with a bunch of possible<br />
actions, in no prescribed order, may<br />
not have any practical way to figure out<br />
what to do first, second, etc.<br />
A user who is afraid of doing something<br />
wrong may prefer that the actions they<br />
have to perform be explicitly spelled out<br />
for them.<br />
The whole task can’t be performed entirely<br />
automatically, because it requires<br />
choices or information from the user.<br />
17
Vera Pfeiffer<br />
Solution: Walk the user through the task one<br />
step at a time, giving very clear instructions<br />
at each step. Use visual similarities in<br />
all the steps, e.g. typography and layout, to<br />
maintain a rhythm throughout the task; make<br />
each step a focal point, both visually and<br />
in the user’s ”attention space.” If information<br />
is needed from the user, ask for it in simple<br />
terms and with brevity; by keeping it short,<br />
you can better maintain the user’s sense of<br />
flow through the whole step-by-step process.<br />
The task may branch like a flow chart, depending<br />
upon what information the user gives<br />
it, but the user doesn’t necessarily need<br />
to know about all the available paths through<br />
the task. If it’s not likely to confuse the<br />
user, show the steps as a Map of Navigable<br />
Spaces. If possible, allow the user to back out<br />
of the steps (Go Back One Step, Go Back<br />
to a Safe Place). If the sequence of steps<br />
as seen by the user is too long – more than<br />
ten steps, for example – try to break it up into<br />
manageable sub-sequences, so it doesn’t<br />
get too tedious for the user. Make sure the<br />
sub-sequences relate to each other in a meaningful<br />
way, however, or the user may see it<br />
as gratuitous or annoying. Sometimes users<br />
may want to know more about what they’re<br />
doing – Optional Detail On Demand gives<br />
you a way to present that extra information.<br />
Also, if a user has gone through a lot of steps,<br />
they have trouble remembering what they’ve<br />
done and why. At least provide a Progress Indicator<br />
if the number of steps grows beyond<br />
seven or eight, which is the average limit of<br />
short-term memory. If a lot of user interaction<br />
is necessary, such as for branching decisions,<br />
consider providing an Interaction History.<br />
Resulting Context: Narrative is a good choice<br />
for presenting the task steps themselves;<br />
the use of natural language to describe what<br />
needs to be done is intuitively obvious, and<br />
puts a user at ease. Go Back One Step and<br />
Go Back to a Safe Place, along with a corresponding<br />
Forward control, can be used to<br />
move through an interactive task. To get information<br />
from the user, you can use a Form<br />
or its simpler component patterns, especi-<br />
18<br />
ally Choice from a Small Set and Forgiving<br />
Text Entry. Using Good Defaults with them<br />
allows the user to move smoothly past the<br />
points where extra data entry is unnecessary,<br />
again preserving the sense of flow. Finally,<br />
a small set of Convenient Environment Actions<br />
should give the user ways to cancel or<br />
suspend the task without having to back out<br />
of it one step at a time.<br />
Notes: Be aware that this pattern may irritate<br />
experienced users. If a user knows exactly<br />
what they need to do, and want to do it quickly,<br />
constraint to this step-by-step presentation<br />
can feel like a straitjacket! Also, if the task to<br />
be accomplished isn’t inherently linear – i.e.<br />
you don’t really have to do one step first, another<br />
step second, etc. – you might provide an<br />
alternative ”random access” presentation of<br />
the possible actions, such as a Stack of Working<br />
Surfaces.<br />
[Tid99a]<br />
Pattern von Martijn van Welie<br />
Wizard<br />
Problem: The user wants to achieve a single<br />
goal but several decisions need to be made<br />
before the goal can be achieved completely,<br />
which may not be know to the user Principle<br />
User Guidance (Visibility) Context A nonexpert<br />
user needs to perform an infrequent<br />
complex task consisting of several subtasks<br />
where decisions need to be made in each<br />
subtask. The number of subtasks must be<br />
small e.g. typically between 3 and 10.<br />
Forces:<br />
The user wants to reach the overall<br />
goal but may not be familiar or interested<br />
in the steps that need to be performed.<br />
The task can be ordered but are not<br />
always independent of each other i.e.<br />
a certain task may need to be finished<br />
before the next task can be done.<br />
To reach the goal several steps need to<br />
be taken but the exact steps required
may vary because of decisions made<br />
in previous steps.<br />
Solution; Take the user through the entire<br />
task one step at the time. Let the user step<br />
through the tasks and show which steps exist<br />
and which have been completed. When the<br />
complex task is started, the user is informed<br />
about the goal that will be achieved and<br />
the fact that several decisions are needed.<br />
The user can go to the next task by using<br />
a navigation widget (for example a button).<br />
If the user cannot start the next task before<br />
completing the current one, feedback is<br />
provided indicating the user cannot proceed<br />
before completion (for example by disabling<br />
a navigation widget). The user is also able<br />
to revise a decision by navigating back to a<br />
previous task. The users are given feedback<br />
about the purpose of each task and the users<br />
can see at all times where they are in the sequence<br />
and which steps are part of the sequence.<br />
When the complex task is completed,<br />
feedback is provided to show the user<br />
that the tasks have been completed and optionally<br />
results have been processed. Users<br />
that know the default options can immediately<br />
use a shortcut that allows all the steps<br />
to be done in one action. At any point in the<br />
sequence it is possible to abort the task by<br />
choosing the visible exit. Rationale The navigation<br />
buttons suggest the users that they<br />
are navigating a path with steps. Each task<br />
is presented in a consistent fashion enforcing<br />
the idea that several steps are taken.<br />
The task sequence informs the user at once<br />
which steps will need to be taken and where<br />
the user currently is. The learnability and<br />
memorability of the task are improved but it<br />
may have a negative effect of the performance<br />
time of the task. When users are forced to<br />
follow the order of tasks, users are less likely<br />
to miss important things and will hence make<br />
fewer errors.<br />
Examples:<br />
2.1 UI Patterns - Grundlagen<br />
Abbildung 5: Lösungsbeispiel von Martijn<br />
van Welie<br />
This example is taken from the KLM web site<br />
where you can buy tickets online.<br />
Known Uses: www.klm.nl; www.amazon.com<br />
(the checkout process)<br />
[vW01a]<br />
2.1.5 Patternarten<br />
In der Softwaretechnik existieren heute Patternsammlungen<br />
und Patternsprachen zu<br />
nahezu allen Aspekten. Neben Patterns zur<br />
Analyse und Organisation beschreiben zum<br />
Beispiel ”Process Patterns” einen komplexen<br />
Entwicklungsprozess und erleichtern damit<br />
die Aufgaben des Managements. Diese sind<br />
als die oberste ”Meta-Collection” der Patterns<br />
in der Softwaretechnik anzusehen.<br />
Da es immer häufiger der Fall ist, dass gute<br />
Systeme aufgrund einer schlechten Benutzeroberfläche<br />
keinen Anklang finden, rückt<br />
auch die Bedeutung einer weiteren Gruppe,<br />
den ”Usability Patterns” immer stärker in den<br />
Vordergrund. Designer vernachlässigen in<br />
der Gestaltung häufig den Aspekt ”feel” und<br />
konzentrieren sich oft nur auf das ”look”, d.h.<br />
der Gestaltung. Da Usability praktisch als<br />
Input für gutes Design dienen sollte und die<br />
Evaluation von Prototypen nicht genug ist um<br />
Benutzerfreundlichkeit zu garantieren, sind<br />
nun auch für diesen Bereich einige Sammlungen<br />
entstanden. Hierzu zählen zum einen<br />
die ”Patterns of Tasks”. Sie beschreiben alle<br />
Tätigkeiten des Anwenders auf dem User Interface<br />
und geben damit eine Einsicht in die<br />
volle Funktionalität des Programms. Diese<br />
19
Vera Pfeiffer<br />
Patterns bilden ein mächtiges Kommunikationstool<br />
für Anwender und Entwickler.<br />
Daneben gibt es zahlreiche weitere, wie die<br />
”Patterns of Entire Systems” zur Klassifizierung<br />
von ganzen Systemen nach Usability<br />
Attributen, externen Faktoren oder nach der<br />
Aufgabe des Systems.<br />
Die wohl wichtigsten Patterns in der Collection<br />
der ”Usability Patterns” sind die ”Patterns<br />
of Users”. Durch deren Kategorisierung der<br />
User nach bestimmten Gesichtspunkten, wie<br />
z.B. Computererfahrung oder Alter, werden<br />
dem Entwickler spezielle Designvorschläge<br />
angeboten, die an bestimmte Benutzergruppen<br />
angepasst werden können.<br />
Beispiel eines Pattern of Users<br />
Name: Intermediate User, Domain Expert<br />
Context: Any System where a domain expert<br />
is likely to use the system long enough to make<br />
the transition from novice to intermediate.<br />
Forces: Software should provide substantial<br />
assistance to novices, but these features<br />
can distract, obstruct, or irritate users as they<br />
become more fluent. Solution: The intermediate<br />
user is comfortable with working in the<br />
regular environment. Dialogues with ”Don’t<br />
ask me again” checkboxes and other mechanisms<br />
should be used to help the user<br />
customize their environment without having<br />
to enter specialised modes. [Boh02]<br />
Die Patterngruppe, die sich in der Softwaregesellschaft<br />
jedoch am stärksten herauskristallisiert,<br />
sind die Design Patterns. Im Buch<br />
der GoF werden diese als ”Beschreibung<br />
miteinander kommunizierender Objekte oder<br />
Subsysteme beschrieben, die ein allgemeines<br />
Designproblem in einem speziellen Zusammenhang<br />
lösen sollen”. Sie benennen,<br />
abstrahieren und identifizieren die Schlüsselaspekte<br />
einer Struktur und ermöglichen damit<br />
die Wiederverwendbarkeit des Designs.<br />
Die Patterns definieren alle beteiligten Subsysteme,<br />
beschreiben, wann diese zur Anwendung<br />
kommen sollten und wie sie mit den<br />
anderen in Verbindung stehen. Daneben geben<br />
sie auch ein Beispiel für eine mögliche<br />
20<br />
Implementation. Der Begriff ”Design Pattern”<br />
wird jedoch häufig für jedes Pattern verwendet,<br />
das mit Softwarearchitektur, Design oder<br />
Implementation zu tun hat. Da diese jedoch<br />
in ihrem Abstaktionsgrad und ihrer Detailgenauigkeit<br />
sehr stark variieren, sollte man sie<br />
in die Gruppen ”Architectural or Conceptional<br />
Patterns”, ”Design Patterns” und ”Idioms”<br />
(d.h. Programming Patterns) kategorisieren.<br />
Architektur- oder Konzeptionspatterns beschreiben<br />
die fundamentale, strukturelle Organisation<br />
eines Softwaresystems. Sie definieren<br />
Subsysteme und deren Zusammenhänge<br />
und enthalten Regeln und Guidelines<br />
um deren Beziehungen zu organisieren. Diese<br />
Patterns sind Strategien zur Konzeption<br />
der höchsten Ebene, sie zeigen die globalen<br />
Fähigkeiten und Mechanismen eines Systems.<br />
Die zweite Stufe bilden konkret die<br />
”Design Patterns”. Sie stellen Lösungen für<br />
die jeweiligen kleineren Subsysteme zur Verfügung<br />
und beschreiben allgemeine wiederkehrende<br />
Strukturen von miteinander kommunizierenden<br />
Komponenten. Sie definieren<br />
die Mikroarchitektur, aber beeinflussen nicht<br />
die übergeordnete Systemstruktur.<br />
Idiome, bzw. Implementations Patterns bilden<br />
die unterste Abstraktionsebene. Sie beschreiben,<br />
wie man die einzelnen Aspekte<br />
der Komponenten und ihre Beziehungen<br />
mit den gegebenen Möglichkeiten einer bestimmten<br />
Programmiersprache am geeignetsten<br />
umsetzten kann. [App00]<br />
2.1.6 Patternsprache<br />
Ein einzelnes Pattern allein ist jedoch noch<br />
nicht viel mehr wert als ein einzelnes Wort<br />
oder ein Ausdruck in einer Sprache. Die Patterns<br />
bilden sozusagen das Vokabular, aber<br />
es fehlt die Grammatik um eine wirklich gute<br />
und nützliche Lösung zu generieren. Schon<br />
<strong>Alexander</strong> erklärte, dass die nützlichsten Patterns<br />
”generativ” sind. Damit meinte er:<br />
Die Lösungsmuster in unserem Gehirn sind<br />
mehr oder weniger mentale Bilder von einzelnen<br />
Mustern in der realen Welt. Diese Abbildungen,<br />
die wir in unserem Gedächtnis wirken,<br />
sind dynamisch. Sie sagen uns, was zu
2.2 Anwendung auf verschiedenen Plattformen und Anpassung an unterschiedliche Umgebungen<br />
tun ist, wie wir vorgehen sollen und vor allem<br />
in welchem Zusammenhang wir sie verwenden<br />
sollen. Wenn man Patterns schreibt,<br />
sollte man also darauf achten, ein System<br />
nicht nur zu charakterisieren, sondern auch<br />
beschreiben, wie man es bildet. Patterns,<br />
und vor allem Patternsprachen sollten dazu<br />
geeignet sein, vollständige und lebendige<br />
Strukturen zu generieren. Sie müssen es<br />
ihren Benutzern ermöglichen, Systeme zu<br />
entwerfen die sich dynamisch an alle Änderungen<br />
und wechselnden Ansprüche anpassen.<br />
Patterns, die jedes für sich ein eigenes<br />
Problem mit der zugehörigen Lösung beschreiben,<br />
sollen es ermöglichen, durch eine<br />
geziehlt gewählte Reihenfolge, ein großeres<br />
und komplexeres Problem zu lösen. [App00]<br />
Ein Patternsprache stellt also nicht nur eine<br />
große Sammlung einzelner Patterns dar,<br />
sondern enthält ebenso Regeln und Guidelines,<br />
die erklären, wie und wann mehrere<br />
Patterns kombiniert werden sollen um ein<br />
größeres Problem zu lösen als das, was<br />
ein einzelnes Patterns könnte. Da nicht alle<br />
Patterns in ein solches Sprachnetzwerk eingebunden<br />
sind, kategorisiert man zwischen<br />
Patternkatalogen, Patternsystemen nd Patternsprachen.<br />
Ein Patternkatalog ist lediglich<br />
eine Zusammenstellung sich ähnelnder<br />
Patterns, die meistens in keinem Zusammenhang<br />
zueinander stehen. Manchmal findet<br />
man ein Unterteilung in verschiede Kategorien,<br />
die unterschiedliche Aspekte beschreiben.<br />
Ein Patternsystem dagegen ist in<br />
sich geschlossen und beschreibt miteinander<br />
verwandte Patterns. Ein solches System<br />
ermöglich die Generierung einer über einzelne<br />
Patterns hinausgehenden Lösung. Es<br />
ist in Gruppen unterteilt, und beschreibt die<br />
Beziehungen unter ihnen und den einzelnen<br />
Patterns selbst. Man sieht also, dass sowohl<br />
Patternsysteme als auch Patternsprachen ineinander<br />
verwobene Patternsstrukturen beschreiben.<br />
Jedoch im Gegensatz zu einem<br />
Patternsystem, ist eine Patternsprache jedoch<br />
robust, begreiflich und leicht zu verstehen<br />
und vor allem vollständig. Sie zeigt alle<br />
möglichen Kombinationen der Patterns und<br />
die verschiedenen Varianten, um komplettes<br />
System zu schaffen.<br />
2.2 Anwendung auf verschiedenen<br />
Plattformen und Anpassung an<br />
unterschiedliche Umgebungen<br />
2.2.1 Organisation einer Patternsprache<br />
Wichtiger als der Aufbau eines einzelnen<br />
Patterns ist die Organisation einer kompletten<br />
Patternsprache.<br />
Möchte man den Aufbau eines kompletten<br />
Frameworks mit Hilfe einer Patternsprache<br />
entwerfen, dann fällt es oft sehr schwer, die<br />
hierarchische Struktur eines Patternsystems<br />
zu verstehen.<br />
Patternorganisation von Jenifer Tidwell<br />
Die Common Ground Sammlung von Tidwell<br />
kategorisiert die Patterns in verschiedene<br />
Gruppen anhand fundamentaler Basisentscheidungen,<br />
die bei der Erstellung<br />
eines Anwendungsdesign nötig sind. Jenifer<br />
Tidwell legt großen Wert darauf, mit vielen<br />
Beispielen die Aussagen jedes einzelnen<br />
Patterns zu verdeutlichen. Sie möchte keine<br />
neuen innovativen Grundlagen und Techniken<br />
präsentieren, sondern bewährtes Wissen<br />
zu Designaspekten in einer praktischen<br />
und leicht erlernbaren Form darstellen. Sogenannte<br />
”Primary Patterns” bilden den Hintergrund<br />
der von ihr definierten Sprache.<br />
Hiervon existieren einige, welche die Grundlagenentscheidung<br />
anhand des zu erstellenden<br />
Inhalts betreffen. Dazu zählen ”Status<br />
Display Patterns”, die sowohl die Erstellung<br />
einer Wanduhr, eines Autoamaturenbretts<br />
als auch die einer VCR-Anzeige beinhalten.<br />
Eine andere Gruppe sind die ”High-density<br />
Information Display Patterns”, zu denen Darstellungen,<br />
Tabellen und Diagramme gehören.<br />
Zusätzlich unterteilt sie die Patterns der<br />
obersten Stufe anhand der Aktionen, die<br />
ausgeführt werden sollen. Ein Beispiel einer<br />
Kategorie hierzu sind die ”Composed<br />
Command Patterns”, die sich auf kommandobasiert<br />
gesteuerte Software aller Art bezieht,<br />
wie z.B. die Unix-Shell oder Debugger.<br />
Schon auf der nächsten Abstraktionsstufe<br />
21
Vera Pfeiffer<br />
wird es jedoch bei der von Ihr gewählten<br />
Vorgehensweise schwer, eine klare Vorgehensstruktur<br />
zu erkennen. Die folgenden Unterteilungen<br />
erfassen verschiedene Wege,<br />
eine Unterteilung sowohl anhand des darzustellenden<br />
Inhaltes als auch nach den verfügbarern<br />
Aktionen vorzunehmen. Manche<br />
Patterns jedoch sind sowohl in die eine als<br />
auch in die andere Gruppe einzuordnen. Außerdem<br />
existieren auf dieser Ebene noch<br />
zusätzliche Kategorien, die eine Unterteilung<br />
anhand des Platzverbrauches, den Navigationstechniken<br />
oder verschiedenen Abhängigkeiten<br />
voneinander treffen. Eine zusätzliche<br />
Erschwerung der richtigen Kontexteinordnung<br />
eines Patterns ist, dass jedes Pattern<br />
auf mehreren Skalierungsleveln oder Ebenen<br />
anzuwenden ist. Zwar hat Jenifer Tidwell<br />
versucht durch die Definition von Subsprachen<br />
eine Erleichterung im Umgang und<br />
Gebrauch der Patterns zu erreichen, doch<br />
stellen diese nichts weiter als eine relativ lose<br />
Zusammensetzung dar, die nichts weiter<br />
als geeignete Vorschläge sind.<br />
Jenifer Tidwels Patternorganisation<br />
Pattern Descriptions:<br />
What is the basic shape of the content?<br />
Narrative<br />
High-density Information Display<br />
Status Display<br />
What is the basic shape of the actions taken<br />
with the artifact?<br />
Form<br />
Control Panel<br />
WYSIWYG Editor<br />
Control Composed Command<br />
WYSIWYG Social Space (unwritten)<br />
How does the content or available actions unfold<br />
before the user?<br />
22<br />
Navigable Spaces<br />
Control Overview Beside Detail<br />
Step-by-Step Instructions<br />
Small Groups of Related Things<br />
Series of Small Multiples (unwritten)<br />
Hierarchical Set<br />
Tabular Set<br />
Chart or Graph<br />
Optional Detail On Demand<br />
Disabled Irrelevant Things<br />
Pointer Shows Affordance<br />
Short Description<br />
How does the artifact generally use space<br />
and the user’s attention?<br />
Sovereign Posture<br />
Helper Posture<br />
Background Posture<br />
How is the content or action organized into<br />
working surfaces?<br />
Central Working Surface<br />
Tiled Working Surfaces<br />
Stack of Working Surfaces<br />
Pile of Working Surfaces<br />
How can the user navigate through the artifact?<br />
Map of Navigable Spaces<br />
Clear Entry Points<br />
Color-Coded Sections<br />
Go Back One Step
2.2 Anwendung auf verschiedenen Plattformen und Anpassung an unterschiedliche Umgebungen<br />
Go Back to a Safe Place<br />
What specific actions should the user take?<br />
Convenient Environment Actions<br />
Localized Object Actions<br />
Actions for Multiple Objects<br />
Choice from a Small Set<br />
Choice from a Large Set<br />
Sliding Scale<br />
Editable Collection<br />
Forgiving Text Entry<br />
Structured Text Entry<br />
Toolbox<br />
How can the user modify the artifact?<br />
User Preferences<br />
Personal Object Space<br />
Scripted Action Sequence<br />
User’s Annotations<br />
Bookmarks<br />
How can the artifact be made visually clear<br />
and attractive?<br />
Iconic Reference (unwritten)<br />
Calm Grid (unwritten)<br />
Repeated Framework<br />
Few Hues, Many Values (unwritten)<br />
How else can the artifact actively support the<br />
user?<br />
Good Defaults<br />
Remembered State<br />
Interaction History<br />
[Tid99c]<br />
Progress Indicator<br />
Important Message<br />
Reality Check<br />
Demonstration<br />
Quick Access (unwritten)<br />
Familiar Quantity (unwritten)<br />
23
Vera Pfeiffer<br />
Patternorganisation von Martijn van Welie<br />
24<br />
Abbildung 6: Patterns für Webanwendungen<br />
Abbildung 7: Patterns für standardmäßige grafische Oberflächen
2.2 Anwendung auf verschiedenen Plattformen und Anpassung an unterschiedliche Umgebungen<br />
[vW01b]<br />
Viele andere Sammlungen, wie auch die<br />
Patternsprache von Martijn van Welie, tendieren<br />
dazu, die Patterns anhand der Anwendungsdomäne<br />
zu kategorisieren. in der<br />
das zu erstellenden System einzusetzten<br />
ist. Es existieren hier verschiedene Gruppen<br />
mit Patterns für Webanwendungen, GUI-<br />
Anwendungen und eigene Patterns für Mobile<br />
Computers. Diese Gruppen enthalten wiederum<br />
Unterpatterns zur Navigation, Suche,<br />
Auswahl, etc. Mit dieser lexikonartigen Organisation<br />
fällt es vielen Designer leichter, ein<br />
spezielles übergeordneteres Problem zu lösen.<br />
Das Problem hierbei ist jedoch, dass bei<br />
dieser Organisation oft eine hierarchische<br />
Strukturierung verschiedener Stufen fehlt.<br />
Weitere Organisationsmöglichkeiten<br />
Zunehmend wird versucht eine hierarchische<br />
Struktur in den Klassifikationsschemata der<br />
Patterns zu definieren. Die Patterns der obersten<br />
Anwendungsebene müssen eindeutig<br />
aufzeigen, welche niedriger eingestuften Patterns<br />
zur Umsetzung angewandt werden sollen.<br />
Doch auch die Gegenrichtung muss ge-<br />
Abbildung 8: Patterns für mobile Geräte<br />
währleistet sein. Man benötigt einen durchsichtigen,<br />
konzeptionellen Rahmen, der die<br />
logische Struktur einer Patternsprache darstellt,<br />
damit auch die Anwender, die eine<br />
Lösung innerhalb einer Anwendung suchen,<br />
sehen, an welcher Stelle unterhalb der Anwendungsebene<br />
sie einsetzten können. Im<br />
Bereich objektorientiertr Analyse und Design<br />
wird daher eine Unterscheidung zwischen<br />
Patterns anhand unterschiedlicher Beziehungen<br />
getroffen. Man findet oft eine Unterscheidung<br />
in ”Derivation-”, ”Aggregation-”<br />
und ”Associationpatterns” vor. Derivation beschreibt<br />
”is-a” -Beziehungen , d.h Eltern-Kind<br />
Verbindungen, die Fähigkeiten und Qualitäten<br />
von höher eingestuften Patterns auf niedrigere<br />
vererben. ”Aggragation” beschreibt die<br />
einzelnen Unterpatterns eines übergeordneten,<br />
was einer ”has a”-Verbindung entspricht<br />
und mit ”Assoziation” sind Querverbindungen<br />
gemeint, die einer ”uses”-Verbindung<br />
ähnlich sind.<br />
In vorherigem Kapitel wurden Design Patterns<br />
in verschiedene Unterkategorien, die<br />
Konzeptions-, die Design Patterns und Idio-<br />
25
Vera Pfeiffer<br />
me, d.h. Programmiervorschläge unterteilt.<br />
Findet man alle diese Unterkategorien in einer<br />
einzelnen Patternsammlung wieder, so<br />
erhält man eine Patternsprache, die anhand<br />
des Aktivitätsgrades unterscheidet. Um eine<br />
komplette Softwareanwendung zu erstellen<br />
braucht man ein konzeptionelles Modell,<br />
das Definitionen und Namen für alle Modi,<br />
Systemzustände und Plätze hat, auf die der<br />
Nutzer treffen kann, und alle Objekte definiert,<br />
die dabei verändert oder erstellt werden.<br />
[App00]<br />
Des Weiteren muss ein bestimmtes Präsentationsdesign<br />
entstehen: die Form der Darstellung<br />
aller Funktionen und Ausgaben. Dieser<br />
Punkt steht für das ”look” einers guten<br />
”look and fell”. Außerdem müssen Interaktionsaspekte<br />
erläutert werden, die beschreiben,<br />
wie der Benutzer Funktionen und Objekte<br />
manipulieren kann. Durch die Definition<br />
von Interaktionstechniken entsteht das ”feel”.<br />
2.2.2 Anwendung auf verschiedenen<br />
Plattformen<br />
Heutzutage existiert eine immer größere<br />
Bandbreite an Softwareanwendungen. Das<br />
Spektrum reicht hier von passiven Informationsprogrammen<br />
mit keiner oder nur wenig<br />
Interaktion bis hin zu benutzergesteuerten<br />
Anwendung in unterschiedlichen Größen<br />
und an variierenden Orten.<br />
Videospiele, Kontrollsysteme für industrielle<br />
Prozesse, Webseiten, On-line Dokumentationen,<br />
multimediale Lernsoftware, sprachbasierte<br />
Oberflächen, Designwerkzeuge für<br />
Grafiken und auch Palmtops und Handhelds<br />
stellen immer großere Anforderungen<br />
an Designer und Softwareentwickler. Aber<br />
auch ganz traditionelle Desktopanwendungen<br />
müssem so entwickelt werden, dass<br />
sie sowohl auf Windows und Macintosh-,<br />
als auch auf Unix/Linux- Plattformen installiert<br />
werden können. Gleichzeitig müssen sie<br />
auch die Belange und Ansprüche von Benutzergruppen<br />
verschiedenen Alters und unterschiedlicher<br />
Computererfahrung erfüllen.<br />
All diese Softwarearten sind unglaublich unterschiedlich<br />
in ihren speziellen Zielen und in<br />
26<br />
ihrem Interaktionsgrad, sowie in zahlreichen<br />
anderen Faktoren. Doch aus der Perspektive<br />
eines Designers existieren unter ihnen<br />
mehr Gemeinsamkeiten, als man zunächst<br />
annimmt.<br />
Ob ein Pattern oder eine Patternsprache allgemeingültige<br />
Lösungen für alle Bereiche<br />
aufzeigt, ist von der Art des Patterns abhängig<br />
und von den Anforderungen, die der jeweilige<br />
Autor an die von ihm beschriebene<br />
Patternsprache oder Patternsammlung gestellt<br />
hat.<br />
Jenifer Tidwell ist der Meinung, mit einer vollständigen<br />
Patternsprache alle Bereiche abdecken<br />
zu können. Eine wirklich gute und<br />
bewährte Lösung muss bei ihr in allen verschiedenen<br />
Bereichen, in Desktop-GUI’s, Videospielen,<br />
Hardware und sogar in Papierform<br />
anwendbar sein. Der Anspruch, eine<br />
Patternsprache zu definieren, die allumfassend<br />
angewandt werden kann, stellt vor allem<br />
bei der Sprache von Jenifer Tidwell häufig<br />
ein großes Problem für die praktische Anwendung<br />
einer solchen Sammlung dar. Zwar<br />
können diese Patterns leicht existierenden<br />
Systemen zugeordnet werden, doch sind sie<br />
meist nicht in der Lage, die Benutzer einer<br />
solchen Sprache zu einer erfolgreichen Designstrategie<br />
zu führen. [Tid99b]<br />
Martijn van Welie vertritt die Meinung, dass<br />
einige Patterns Lösungskonzepte zu Problemen<br />
darstellen, die in allen Bereichen gleich<br />
auftreten und somit Allgemeingültigkeit besitzen,<br />
andere aber wiederum nur in einem speziellen<br />
Bereich anwendbar sind. Um diesem<br />
Problem gerecht zu werden hat er schon vorweg<br />
eine Patternszuordnung in verschiedene<br />
Bereiche getroffen, in denen er dann speziell<br />
auf die variierenden Teilaspekte eingeht. Er<br />
unterscheidet daher im Gegensatz zu Jenifer<br />
Tidwell schon auf der obersten Ebene des<br />
System, in welche Richtung es gehen soll,<br />
und bezieht sich mehr auf gleiche Möglichkeiten<br />
in der Ausgestaltung auf der unteren<br />
Ebene.<br />
Von anderen wird die Meinung vertreten,<br />
dass die Designentscheidung auf jeder Ebene<br />
unabhängig von den Entscheidungen auf<br />
den anderen ist und somit zu einem konzeptionelle<br />
Modell, das in allen Bereichen gül-
2.2 Anwendung auf verschiedenen Plattformen und Anpassung an unterschiedliche Umgebungen<br />
tig ist, verschiedene spezielle Funktions- und<br />
Interaktionsmöglichkeiten gefunden werden<br />
können.<br />
Mit Java hingegen wurde ein Tool geschaffen,<br />
das es Entwicklern ermöglicht, mit dem<br />
jeweils gleichen Konzeptions-, Funktionsund<br />
Präsentationsdesign aus einer Patternsprache<br />
eine Anwendung erstellen zu können,<br />
die für alle Plattformen eine spezifische<br />
Darstellung bietet.<br />
E++ - Eine Patternsprache für<br />
J2EE-Applikationen<br />
Um diese plattformübergreifende Darstellung<br />
jedoch in der Praxis umzusetzten muss ein<br />
Designer oder Entwickler zuerst aus all der<br />
Vielzahl unterschiedlicher Patterns und Patternsprachen<br />
die für ihn geeignetste finden<br />
und sie richtig anwenden. Ebenso muss er<br />
die einzelnen Lösungskonzepte der untersten<br />
Ebene einzelnen J2EE-Komponenten<br />
zuordnen. Um diesen Prozess zu erleichtern<br />
wurde mit E++ eine Patternsprache für<br />
J2EE-Applikationen geschaffen, die genau<br />
diesen Prozess erleichtern soll. Im direkten<br />
Bezug auf bewährte Patterns wird ein konkreter<br />
Aufbau eines Frameworks und seiner<br />
Umsetzung in Java erläutert. E++ stellt dem<br />
Entwickler einen klaren hierarchischen Aufbau<br />
zur Verfügung, dessen oberste Ebene<br />
das sogenannte ”Layered Architecture Pattern”<br />
bildet. Hier werden die verschiedenen<br />
Funktionen einer Anwendung in unterschiedliche<br />
Stufen eingeteilt. Anhand dieser eindeutig<br />
definierten Wurzel wird dem Entwickler<br />
ein hierarchischer Baum von Patterns zur<br />
Verfügung gestellt, der unter anderen auch<br />
das Model-View-Controler-Pattern enthält.<br />
27
Vera Pfeiffer<br />
Abbildung 9: Hierarchsches Patternschema<br />
von E++<br />
[Yan01]<br />
Ein oft verwendetes Pattern, das zum ersten<br />
Mal von der ”Gang of Four” definiert<br />
wurde, ist das ”Model-View-Controller” Pattern.<br />
Dieses Pattern unterteilt Funktionen in<br />
drei Komponenten. Das ”Model” ist der Informationsträger<br />
der Daten, welche von der<br />
Anwendung benutzt und manipuliert werden.<br />
Im ”View” wird die visuelle Darstellung der<br />
Informationen aus dem ”Model” implementiert.<br />
Ändert sich daher das ”Model”, sind alle<br />
hierzu existierenden ”Views” zu ändern. Die<br />
dritte Komponente kontrolliert alle Vorgänge.<br />
Dieser Controller empfängt die Eingaben und<br />
entscheidet anhand derer, was zu tun ist. Er<br />
ermittelt die betroffenen Views und ändert<br />
die dazugehörigen Modelle.<br />
28<br />
Abbildung 10: Grafische Darstellung des<br />
”Model-View-Controller” Konzepts<br />
[Yan01]<br />
E++ beschreibt dem Programmierer jedoch<br />
nicht nur das zu vermittelnde Konzept, sondern<br />
auch die konkrete Umsetzung in Java.<br />
Um den Austausch der Darstellungen<br />
zur Laufzeit, d.h. das sogenannte ”pluggable<br />
look-and-feel” zu verwirklichen, definiert man<br />
in Java ein UI-delegate, das ein View mit Listenern<br />
implementiert und somit eine Kombination<br />
der Komponenten View und Controller<br />
des klassischen Konzepts ist. Dies ermöglicht<br />
es der Klasse JCOmponent, aus Swing<br />
das ”look-and-feel” an diese Komponente zu<br />
delegieren. [Yan01]<br />
Patterns zur Umgehung von<br />
Darstellungsfehlern der JVM<br />
Leider stößt auch dieser praktische Ansatz<br />
in der Realität oft schnell an seine Grenzen.<br />
Kleine Unterschiede bei der Implementation<br />
der Java Virtual Machines lösen unberechenbares<br />
Verhalten und unkonsistente<br />
Darstellungen aus. Die Browser von Netscape<br />
und Microsoft enthalten unterschiedliche,<br />
jede auf eine andere Art fehlerhafte JVM, Java’s<br />
Abstract Windowing ToolkitAWT produziert<br />
User Interfaces, die sich auf den unterschiedlichen<br />
Plattformen dennoch uneinheitlich<br />
verhalten und die Java Foundation Classes,<br />
wie zum Beispiel Swing, sind oft nicht<br />
in den Brwowsern integriert oder aktiviert.<br />
Doch um auch diese Probleme zu lösen existieren<br />
seperate Patterns, die den Entwicklern<br />
helfen sollen das Ideal von Sun zu verwirklichen,<br />
eine portable, dynamische Sprache,<br />
die ein plattformübergreifendes ”Lookand-Fell”<br />
ermöglicht.<br />
Beispiel<br />
Requirements: Same ”look and fell” across<br />
Browsers<br />
run within Netscape Navigator 2.01+ on<br />
the PC
2.2 Anwendung auf verschiedenen Plattformen und Anpassung an unterschiedliche Umgebungen<br />
run within Internet Explorer 3.0+ on the<br />
PC<br />
run within Netscape Navigator 3.0+ on<br />
the Mac<br />
look and behave exactly the same on<br />
all supported browsers<br />
download quickly<br />
Problem: Java’s AWT UI’s<br />
Java’s Abstract Windowing Toolkit UI’s don’t<br />
look the same across platforms or inside<br />
browsers. AWT components are buggy and<br />
require a good deal of sub-classing to add<br />
the functionality you need. Sub-classing, or<br />
using third-party controls, requires larger,<br />
time-intensive downloads, and many thirdparty<br />
controls aren’t lightweight. AWT font<br />
support is lacking: It supports only simple<br />
fonts, and font rarely look the same across<br />
platforms and browsers. AWT layout managers<br />
don’t produce great-looking UI’s. <strong>Dr</strong>agn-<strong>Dr</strong>op<br />
tools don’t produce great UI code und<br />
suffer from the same AWT cross-platform<br />
bugs.<br />
Solution: Images and Code<br />
Use images and write code to remove ties to<br />
the AWT.<br />
GIFs and JPEGs really and truelly look<br />
the same across platforms or inside<br />
browsers.<br />
Using images to represent components<br />
frees you up to create stunning,<br />
professional-looking Uis<br />
Using images, you can easily separate<br />
a UI’s ”look” from ist ”behavior” //<br />
You can use whatever fonts you like,<br />
since fonts will ultiately be imagebased<br />
You no longer rely on AWTlayout managers<br />
You must write ”behavior” code for your<br />
components<br />
[JK98]<br />
Patterns für Pocket Computers<br />
All die bis jetzt vorgestellten Ansätze sind<br />
zwar weitgehend bei allen unterschiedlichen<br />
Softwareversionen in der Lage die fundamentalen<br />
Organisationsschemata und die<br />
verschiedenen Funktionen mit unterschiedlichen<br />
Navigationsmöglichkeiten in einem Lösungsschemata<br />
zu erläutern, scheitern aber<br />
jedoch an den unterschiedlichen Ansprüchen<br />
bei den Benutzerein- und ausgaben.<br />
Es entsteht zunehmend eine ”one-size fits<br />
all”-Mentalität, die nicht berücksichtigt, dass<br />
kleinere Geräte, wie zum Beispiel Palms, eine<br />
kleinere Fläche für das User Interface<br />
haben und ein weitaus kleineres Spektrum<br />
an Eingabemöglichkeiten zur Verfügung haben.<br />
Einen ersten Ansatz in eine andere Richtung<br />
beschreiben Charles Weir und James<br />
Noble in einer kleinen Patternsammlung,<br />
die spezielle Patterns für Pocket Computers<br />
enthält. Ihre Ansprüche liegen hier nicht in<br />
der Definition einer vollständigen Sprache,<br />
sondern in der Verwirklicheung grundlegender<br />
Interfaceaspekte, die durch die Anwendung<br />
der Patterns umgesetzt werden sollen.<br />
Sie möchten durch ihre Lösungsvorschläge<br />
einen möglichst großen ”ease-of-use”,<br />
d.h. eine große Benutzerfreundlichkeit erreichen,<br />
die auf einem konsistenten Interface,<br />
der Sichtbarkeit der möglichen Funktionen<br />
und der leichten Erlernbarkeit des Systems<br />
basieren. Die entgegenwirkenden Kräfte bei<br />
diesen Anwendungen sind in erster Linie der<br />
kleine Screen zur Darstellung und die in der<br />
Regel große Anzahl an Funktionen, die das<br />
System beherrschen sollte.<br />
29
Vera Pfeiffer<br />
[WN01]<br />
Abbildung 11: Spezielle Patterns für mobile Anwendungen<br />
Als Basispattern liegt dieser Sprache das<br />
”One true Window Pattern” zugrunde. Dessen<br />
Hauptaussagen ist, dass es zwar viele<br />
Vorteile bei der Arbeit mit mehreren Fenstern<br />
gibt, diese jedoch auf einem kleinen Screen<br />
auch viele Probleme mit sich bringen. Sie benötigen<br />
viel Platz für die Dekoration und es<br />
muss Funktionen geben, um die Interaktion<br />
der Fenster untereinander zu gewährleisten.<br />
Es muss ein Fensterlayout generiert werden,<br />
das in vielen verschiedenen Größen steuerbar<br />
ist. Verwendet man in Anwendungen,<br />
die wenig Screenfläche zu Verfügung haben,<br />
also nur ein Fenster, so entfallen auch die<br />
Darstellungsformen für sämtliche Kontrollmechanismen<br />
zur Veränderung der Fenstergrößen.<br />
Doch nicht nur die Ausgabe unterliegt<br />
Einschränkungen durch den geringen<br />
Platz, auch bei der Eingabe müssen zusätzliche<br />
Faktoren beachtet werden.<br />
Folgendes Beispiel erläutert wie das Problem<br />
der einfachen, benutzerfreundlichen<br />
Eingabe trotz Platzmangels gut gelöst werden<br />
kann: Beispiel: The big thumb<br />
How big should you make common controls<br />
on the screen ?<br />
30<br />
Many pocket Computers have touch screens.<br />
Controls for applications are important, but<br />
they take up space on the screen.<br />
Most people use styluses tu use the computer.<br />
But perhaps they don’t e.g. one hand use<br />
Therefore: Make important controls big<br />
enough to press with your thumb! Make important<br />
controls large enough to be used directly<br />
also makes them easier to select with<br />
a stylus, because Fitts law states the time to<br />
select something on screen is proportional<br />
to ist area (james: check this and get a reference).<br />
In the Palm pilot Todo application,<br />
the buttons across the bottom of the screen<br />
are large enough to be used by the pad of a<br />
thumb or forefinger, (or the back of the nail).<br />
Whereas the scroll controls are not. This is<br />
not a problem in the Palm, because it provides<br />
physical scroll buttons to scroll the display,<br />
so there is no reason to use the scroll<br />
controls in the window (as described in the<br />
Scrolling Pattern, these serve mostly to indicate<br />
that the display can be scrolled).<br />
Abbildung 12: Beispieldarstellung
[WN01]<br />
Consequenzes:<br />
However:<br />
[WN01]<br />
Bid controls are be faster to use than<br />
small ones (ref Fitts Law)<br />
You will be able to use your pocket computer<br />
one handed<br />
You will be able to use yout pocket computer<br />
when you’ve lost your stylus between<br />
seats in economy class<br />
Big controls take up more space than<br />
smaller ones!<br />
People may not use the machine onehanded<br />
anyway, because it makes the<br />
screnn too grubby<br />
Kommentar<br />
Es existiert eine große Vielzahl an Patterns,<br />
die in ihrem <strong>Format</strong>, ihrer Zusammenstellung,<br />
ihrer Vollständigkeit, ihrer Abstraktionstiefe<br />
und ihren Inhalten sehr stark variieren.<br />
Einige von ihnen haben den Anspruch auf<br />
Allgemeingültigkeit in diversen Bereichen.<br />
Weitgehend kann dies auch gelingen, doch<br />
oft scheitert dies vor allem im Bereich der Interfacegestaltung<br />
daran, dass verschiedene<br />
durch die Hardware vorgegebenen Größenvoraussetzungen<br />
und andere äußere Faktoren<br />
nicht beachtet werden. Wie jedoch Patterns<br />
trotz der großen Fülle und Unübersichtlichkeit<br />
bei der Entwicklung sinnvoll eingesetzt<br />
werden können, soll das folgende Kapitel<br />
erläutern.<br />
2.3 Einsatz von Patterns<br />
2.3 Einsatz von Patterns<br />
2.3.1 Praktischer Umgang mit Patterns<br />
Patternsammlungen und Patternsprachen<br />
enthalten oft eine große Menge individueller<br />
Ratschläge, die sehr stark in ihrem Abstraktionsgrad<br />
voneinander variieren. Es gibt<br />
Patterns für die unterschiedlichsten Bereiche,<br />
bei denen es den Entwicklern oft schwer<br />
fällt, das zu erstellende System richtig einzuordnen.<br />
Eine andere Möglichkeit Lösungsvorschläge<br />
einzuholen und ein gutes Design<br />
zu erstellen ist die Benutzung von Guidelines.<br />
Doch auch im Umgang mit diesen trifft<br />
der Entwickler auf diverse Probleme. Guidelines<br />
sind oft sehr stark vereinfacht und abstrahiert,<br />
deshalb ist es schwer, das Richtige<br />
auszuwählen und dieses im Bezug auf<br />
das vorliegende Problem richtg zu interpretieren.<br />
Guidelines haben den Anspruch ”absolutes”<br />
Wissen zu verkörpern und lassen<br />
dabei die unterschiedlichen Zusammenhänge,<br />
in denen ein Problem auftreten kann, außer<br />
Acht.<br />
Um eine optimale Konstruktionshilfe bei der<br />
Entwicklung von User Interfaces oder aber<br />
auch kompletten Softwareanwendungen zu<br />
erreichen muss also ein Brücke zwischen<br />
Patterns, Guidelines und auch wiederverwendbaren<br />
bestehenden Komponenten geschaffen<br />
werden. Ein User Interface besteht<br />
aus einer zugrunde liegenden Struktur für<br />
die Information und Navigation, einem Layout,<br />
einem gut definierten ”Flow” zur Interaktion<br />
und den darzustellenden Inhalten. Alle<br />
diese Aspekte werden innerhalb von vier<br />
Ebenen, dem Concept level, dem Task level,<br />
dem Presentation level und dem Technical<br />
level mit unterschiedlichen Gewichtungssfaktoren<br />
und Detailgenauigkeit umgesetzt. Folgende<br />
Darstellung zeigt welche Hilfsmittel<br />
auf welchem Level am sinnvollsten einzusetzten<br />
sind und welche Ebenen Patterns mit<br />
welcher Bandbreite abdecken:<br />
31
Vera Pfeiffer<br />
[dG02]<br />
2.3.2 Fazit<br />
Abbildung 13: Patternverwendung im Entwicklungsprozess<br />
Patterns sind eine hervorragende Möglichkeit<br />
Erfahrungen weiterzugeben und ein gutes<br />
Mittel zur Kommunikation innerhalb von<br />
Designteams. Sie sind vielfach wiederverwendbar<br />
und können die Komplexität bei der<br />
Erstellung einer größeren Anwendung stark<br />
reduzieren. Patternsprachen werden sich immer<br />
weiter profilieren und bereits bestehende<br />
Sprachen werden von Jahr zu Jahr immer<br />
mehr vervollständigt werden. Wenn mit der<br />
Zeit jede Patternsprache für sich eine längere<br />
Entwicklung vollzogen hat und mehr Anhänger<br />
gefunden hat, dann wird man auch<br />
festellen, dass in der Struktur und der Benennung<br />
von Patternsprachen grundlegende<br />
Änderungen nötig sind. Es werden neue und<br />
speziellere Sprachen entwickelt werden, die<br />
immer detaillierter in die jeweiligen Anwendungsarten<br />
und verschiedenen Plattformen,<br />
auf die die Anwendungen verwendet wer-<br />
32<br />
den sollen, vordringen. Ohne eine aufeinander<br />
abgestimmte Koordination der einzelnen<br />
Sprachen, wird es eine Schwemme an Auflistungen<br />
indivudueller Erfahrungen geben,<br />
die es dem Benutzer unmöglich machen, aus<br />
der großen Bandbreite unterschiedlicher Anwendungen<br />
die Ricgtige zu wählen.<br />
Bevor die Anwendung von Patterns sich aufgrund<br />
einer wachsenden Unbenutzbarkeit im<br />
Sand verläuft, sollte eine einheitliche Struktur<br />
und Zusammensetzung der Sprachen definiert<br />
werden.
Literatur<br />
[App00] Brad Appleton: Patterns and Software,Essential Concepts and Terminology.<br />
http://www.enteract.com/~bradapp/docs/patterns-intro.html,<br />
2000.<br />
[App02] Brad Appleton: Patterns in a Nutshell, The bare essentials of Software<br />
Patterns. http://www.enteract.com/~bradapp/docs/patternsnutshell.html,<br />
2002.<br />
[Boh02] Hendrik Bohn: Patterns - Usability Patterns, Design Patterns, Process<br />
Patterns. http://www.informatik.uni-rostock.de/~bohn/vortrag/<br />
gesamt.html, 2002.<br />
[dG02] Boyd de Groot: Patternsinpractice:aworkshopforuidesigners. In Position Paper for<br />
the CHI 2002 Workshop for UI Designers. Satama Interactive, 2002.<br />
[JK98] delivered at Object Expo ’98 in New York City Joshua Kerievsky, Industrial Logic<br />
Inc: Techniques and Patterns For Writing Once And Running Anywhere. http:<br />
//www.industriallogic.com/papaers/wora.html, 1998.<br />
[JO02] Illinois James O.Coplien, Bell Laboratories Naperville: A Patterns Definition, Software<br />
Patterns. http://hillside.net/patterns/definition.html, 2002.<br />
[KM02] REACTOR Experience Design Kevin Mullet: Structuring Pattern Languages to<br />
Faciliate Design. http://www.welie.com/patterns/chi2002-workshop/<br />
Mullet.pdf, 2002.<br />
[Tid99a] Jenifer Tidwell: Beispielpattern, Step by Step Instruction. http://www.mit.edu/<br />
~jtidwell/language/step-by-step_instructions.html, 1999.<br />
[Tid99b] Jenifer Tidwell: The Case for HCI Design Patterns. http://www.mit.edu/~<br />
jtidwell/ui_patterns_essay.html, 1999.<br />
[Tid99c] Jenifer Tidwell: Common Ground. http://www.mit.edu/~jtidwell/intro.<br />
html, 1999.<br />
[vW01a] Martijn van Welie: Beispielpattern: Wizard. http://www.welie.com/<br />
patterns/gui/wizard.html, 2001.<br />
[vW01b] Martijn van Welie: Interaction Design Patterns. http://www.welie.com/<br />
patterns/index.html, 2001.<br />
[Web02] <strong>Prof</strong>. <strong>Dr</strong>. Michael Weber: Interaktionsmuster. In Skript zur Vorlesung Mediale Informatik.<br />
<strong>Universität</strong> <strong>Ulm</strong>, 2002.<br />
[WN01] Charles Weir und James Noble: Some small patterns for user interfaces: A window<br />
in your pocket. In Proceedings of the European Conference on Pattern Languages<br />
of Program Design. EuroPloP, 2001.<br />
[Yan01] Bin Yang: E++ - A Pattern Language for J2EE Applications: Build better J2EE applications<br />
with a high-level pattern language. http://www.javaworld.com/<br />
javaworld/jw-04-2001/jw-0420-eplus_p.html, 2001.<br />
33
3 Styleguides<br />
Zusammenfassung<br />
Johannes Hein<br />
Seminar Handheld and Ubiquitous Computing<br />
<strong>Universität</strong> <strong>Ulm</strong>, Wintersemester 2002/2003<br />
johannes.hein@informatik.uni-ulm.de<br />
Styleguides definieren das Aussehen<br />
und das Verhalten der Benutzerschnittstelle<br />
eines Computersystems. Die konsequente<br />
Anwendung systemspezifischer<br />
Styleguideregeln vermittelt dem Benutzer<br />
ein einheitliches Look-and-Feel für<br />
alle Anwendungen seiner Betriebssystemplattform.<br />
Bei Handheld Computern<br />
konzentrieren sich die Styleguides insbesondere<br />
auf den Umgang mit den eingeschränkten<br />
Hardware- und Bildschirmplatzkapazitäten<br />
und bieten Lösungen an,<br />
trotz dieser Beschränkungen eine effizient<br />
bedienbare Oberfläche zu schaffen.<br />
3.1 Einleitung<br />
3.1.1 Definition<br />
Der Begriff Styleguide kennzeichnet die<br />
einheitliche Gestaltung einer graphischen<br />
Benutzungsoberfläche zur Erreichung einer<br />
vertrauten, konsistenten und intuitiv bedienbaren<br />
Benutzerschnittstelle. Durch die Bindung<br />
von graphischen User Interfaces an<br />
die Styleguides einer Betriebssystemplattform<br />
wird selbst die Bedienung der unterschiedlichsten<br />
Programme durch standardisierte<br />
und somit intuitive Bedienungsregeln<br />
vereinfacht.<br />
Styleguides legen jedoch nicht nur die rein<br />
optische Repräsentation von Bedienelementen<br />
fest, sondern befassen sich ebenso mit<br />
der Zugriffssteuerung auf die vom Anwendungsprogramm<br />
zur Verfügung gestellten<br />
Informationen und Operationen. So fällt auch<br />
eine schnelle und effiziente Benutzerführung<br />
in den Bereich der Styleguidedefinition.<br />
34<br />
3.1.2 Motivation<br />
In erster Linie ist der Einsatz Styleguidekonformer<br />
Anwendungsprogramme eine<br />
Benutzungserleichterung für den Anwender.<br />
Indem Bedienelemente, die nicht auf den<br />
Einsatz in einer Anwendung beschränkt sind,<br />
sowie deren grundsätzliche Anordnung einheitlich<br />
gestaltet werden, verringert sich für<br />
den Anwender der Lernaufwand bei einer<br />
neuen Anwendung. Das Berücksichtigen<br />
von Styleguides bei der Applikationsentwicklung<br />
erfüllt das Gestaltungsgütekriterium der<br />
Erwartungskonformatität; der Benutzer kann<br />
die Bedienungselemente und Gadgets einer<br />
Oberfläche intuitiv bedienen, da sie in ihren<br />
Funktionen seinen Erfahrungen und Erwartungen<br />
entsprechen.<br />
Doch auch die Gruppe von Entwicklern<br />
profitiert von den Gestaltungsrichtlinien, da<br />
Betriebssysteme die per Styleguide festgelegten<br />
Bedienelemente in ihrem Application<br />
Programmers Interface (API) anbieten können.<br />
Somit entfallen für die Entwickler stetige<br />
Neuentwicklung und -implementierung<br />
derartiger Standardgadgets. Dennoch muß<br />
beachtet werden, daß Styleguides nicht nur<br />
die optische Ebene beschreiben. Die Gestaltungsrichtlinien<br />
sollen insbesondere dazu<br />
verhelfen, die Bedienung von Programmoberflächen<br />
komfortabler, effizienter und<br />
übersichtlicher zu machen. Dabei ist jedoch<br />
zu beachten, daß selbst eine durchgängige<br />
Befolgung der Styleguide-Empfehlungen in<br />
keinem Fall eine separate Evaluation der<br />
Benutzbarkeit von Applikationen überflüssig<br />
macht. Nur durch ausgiebige Tests<br />
mit Mitgliedern künftiger Benutzergruppen
oder durch Analysen von Usability Experten<br />
kann eine wahrhaftige Benutzerfreundlichkeit<br />
sichergestellt werden.<br />
Bei allen genannten Punkten bleibt stets zu<br />
bedenken, daß die meist von den Betriebssystementwicklern<br />
vorgegebenen Styleguides<br />
nur Gestaltungsrichtlinien sind. Letztendlich<br />
ist es dem Entwickler überlassen,<br />
sich über diese Empfehlungen hinwegzusetzen.<br />
Um jedoch den Applikationsbenutzer<br />
nicht zu verwirren, sollten Entscheidungen<br />
zum Bruch Styleguide-konformer Gestaltung<br />
wohlüberdacht und durch eindeutige Gründe<br />
zu belegen sein. Häufig sinnvoll ist dagegen<br />
die Definition applikationsspezifischer Styleguides,<br />
wobei der Entwickler für ein Produkt<br />
oder eine Produktserie eigene Gestaltungsrichtlinien<br />
ansetzt und jene in der gesamten<br />
Produktrealisierung konsequent und konsistent<br />
anwendet.<br />
3.1.3 Bekannte Beispiele<br />
Der zentrale Teil dieser Arbeit befaßt sich mit<br />
Interfacestyleguides für portable Systeme.<br />
Weiterhin sind die Kontrollgadgets in Aussehen<br />
und Verhalten sowie in ihrem Einsatzgebiet<br />
Teil des Styleguides. Als einleuchtendes<br />
Beispiel seien die Radio Buttons ge-<br />
Abbildung 14: Standard Win32 Dialoge<br />
3.1 Einleitung<br />
Um jedoch vorab den Einsatz und die<br />
Bedeutung der Styleguides zu verdeutlichen,<br />
sei anhand des weit verbreiteten Desktop<br />
Betriebssystems Microsoft Windows (Win32)<br />
ein einführendes Beispiel gegeben.<br />
Anwender von Microsoft Windows Programmen<br />
können die Grundfunktionen der meisten<br />
Anwendungen ohne weitere Einarbeitungszeit<br />
erfassen und benutzen. Der Grund<br />
hierfür ist das konsistente Design und das<br />
einheitliche Verhalten der diversen Windows-<br />
Applikationen, welche den von Microsoft in<br />
dem Band Microsoft Windows User Experience<br />
aufgestellten Interface Guidelines folgen.<br />
Die Anwender sind also mit dem<br />
Look-and-Feel einer Windows Applikation<br />
vertraut; anwendungsübergreifende Eigenschaften<br />
wie die Taste F1 für Hilfsfunktionen,<br />
die Tastenkombinationen Strg-X bzw.<br />
Strg-V zum Ausschneiden bzw. Einfügen<br />
oder gar lediglich Aussehen Funktionen der<br />
Maximierungs- und Abbruch-Piktogramme in<br />
der oberen rechten Fensterhälfte resultieren<br />
aus der Befolgung des Win32 Styleguides.<br />
nannt, die in Microsoft Windows und zahlreichen<br />
anderen graphischen Betriebssystemen<br />
für exklusive Auswahlmöglichkeiten (1<br />
aus n Auswahl) eingesetzt werden. Hierfür<br />
35
Johannes Hein<br />
sieht der Styleguide neben dem Aussehen<br />
(vgl. obige Abbildung) vor, daß Radio Buttons<br />
stets einzeilig bzw. einspaltig angeordnet<br />
sind, und daß die Auswahl eines Radio<br />
Buttons niemals eine direkte Systemfunktion<br />
aufruft. Des weiteren wird die Verwendung<br />
von Radio Buttons für nicht-exklusive (m aus<br />
n) Auswahlen untersagt.<br />
Anwendungen können die Empfehlungen der<br />
Interface Richtlinien bei speziellen Problemen<br />
übergehen und eigene Strategien zum<br />
Oberflächendesign verfolgen. Es gibt sogar<br />
Beispiele für Applikationen, die komplett<br />
auf Styleguidekonformität verzichten. Der bekannteste<br />
und meistzitierte Vertreter dieser<br />
Gruppe ist mit Sicherheit die Warpingsoftware<br />
Kai’s Power Goo (siehe untenstehende<br />
Abbildung), die neben eigenem Fensterdesign<br />
auch selbstdefinierte Buttons verwendet,<br />
die im Gegensatz zu den monochromen<br />
und rechteckigen Buttons des Windows<br />
Standards rund und farbig erscheinen.<br />
Abbildung 15: Beispiel für fehlende Styleguidekonformität<br />
[DiP96]<br />
[Cor99]<br />
3.1.4 Besonderheiten bei Handheld<br />
Devices<br />
Nachdem nun Styleguides im Bereich der<br />
Desktop Computer vorgestellt wurden, gilt<br />
es, die unterschiedlichen Bedingungen im<br />
Einsatz portabler Handheld Computer zu<br />
charakterisieren.<br />
36<br />
Maßgebliche Unterschiede ergeben sich allein<br />
durch die Betrachtung des Parameters<br />
Einsatzdauer. Die durchschnittliche Benutzungsdauer<br />
eines Personal Digital Assistent<br />
(PDA) liegt deutlich unter der Arbeitszeit an<br />
einem stationären PC respektive Laptop. Im<br />
Gegensatz zu diesen in der Länge stark<br />
verschiedenen Sitzungen steht die Häufigkeit<br />
des Computerzugriffs. Desktop Computer<br />
werden in der Regel wenige Male am Tag<br />
gestartet, bei Handheld Einheiten sind die<br />
Zugriffe deutlich häufiger.<br />
Ebenso differieren die Computertypen in der<br />
Art der verwendeten Applikationen. Während<br />
die Anwendungsvielfalt auf einem Desktop<br />
Computer mit großem Farbmonitor kaum eingeschränkt<br />
ist, bietet ein PDA meist nur eine<br />
kleinere Auswahl von Programmen, die<br />
auf den mobilen Betrieb zugeschnitten sind;<br />
im allgemeinen gehören Termin- und Adreßverwaltungen<br />
sowie einfache Textverarbeitungen<br />
zu diesen Applikationen. Komplexere<br />
Anwendungen wie Graphikbearbeitungsprogramme<br />
sind auf diesen Geräten wegen unzureichender<br />
Bearbeitungseffizienz und der<br />
meist nicht für diese Zwecke ausgelegten<br />
Hardware dagegen selten vertreten.<br />
Hieraus werden bereits die essentiellen Ziele<br />
für die Entwicklungen von Anwendungen für<br />
Handheld Computer deutlich: Der Benutzer<br />
soll sein Ziel schnell und einfach erreichen.<br />
Ein Großteil der Aufgaben, die mit PDAs erledigt<br />
werden, sind häufig wiederkehrende Abläufe.<br />
Diese sollten dem Anwender möglichst<br />
direkt angeboten werden.<br />
Zudem gilt es stets die eingeschränkte Hardwarekapazität<br />
von PDA Computern zu beachten.<br />
Die Geräte verfügen über einen vergleichsweise<br />
kleinen, häufig niedrigauflösenden<br />
Bildschirm, der die Positionierungsmöglichkeiten<br />
für Bedienungselemente stark einschränkt.<br />
Viele der Bildschirme sind monochrom<br />
oder bieten lediglich einige Grauabstufungen,<br />
wodurch der Umgang mit Farben<br />
stets abgewogen werden sollte. Des weiteren<br />
müssen PDA Applikationen auf die spezielle<br />
Eingabehardware – meist in Form eines<br />
Stiftwerkzeugs – abgestimmt sein.
Diese Ausarbeitung legt den Schwerpunkt<br />
auf das Betriebssystem Palm OS, welches<br />
zu diesem Zeitpunkt marktführend und am<br />
weitesten verbreitet ist. An diesem Beispiel<br />
wird der Aufbau eines User Interfaces für<br />
Handheld PCs detailliert besprochen. Anschließend<br />
folgt eine Betrachtung der Konkurrenzprodukte<br />
Microsoft Windows Compact<br />
Edition und Sun Java Micro Edition.<br />
Komplettiert wird die Ausarbeitung durch ein<br />
Kapitel über GSM Applikationen für Mobiltelefone<br />
sowie eine Abschlußbetrachtung.<br />
3.2 Styleguides für Palm OS<br />
3.2.1 Einsatzgebiete<br />
Die heute am weitesten verbreiteten Handheld<br />
Computer stammen von der Firma<br />
Palm, welche gleichzeitig das Betriebssystem<br />
Palm OS für all ihre Geräte zur Verfügung<br />
stellt.<br />
Computer des Palm-Typs verfügen über eine<br />
einheitliche Basisausstattung von Bedienungselementen,<br />
die bei größeren und im<br />
Funktionsumfang reicheren Modellen lediglich<br />
erweitert wird. Ebenso bietet die Betriebssoftware<br />
bereits die wichtigsten Applikationen,<br />
welche den Einsatz von Handheld<br />
Computern sinnvoll machen, darunter<br />
Adreß- und Terminverwaltungen, textbasierte<br />
Memoaufzeichnung sowie ToDo-Listen.<br />
Abbildung 16: Standard Palm PC [Ost02]<br />
Alle Palm Computer verwenden für die Dateneingabe<br />
und Benutzerinteraktionen ein<br />
3.2 Styleguides für Palm OS<br />
stiftähnliches Werkzeug (Tap-Stylus). Dieses<br />
ermöglicht die Anwahl von Funktionen<br />
durch direktes Berühren der Funktionselemente<br />
auf dem Bildschirm. Ebenso kann der<br />
Stift verwendet werden, um Text im pseudohandschriftlichen<br />
Graffiti Standard einzugeben.<br />
Für diesen Zweck besitzt jeder Palm<br />
Computer im unteren Bereich ein Graffiti-<br />
Eingabefeld, über welches alternativ auch eine<br />
stilisierte QWERTZ-Tastatur zur Eingabe<br />
aufgerufen werden kann.<br />
Abbildung 17: Graffiti Zone [Ost02]<br />
Ebenso in der Graffiti Zone untergebracht<br />
sind vier zentrale Icons, welche den Application<br />
Launcher, das Funktionsmenü, den Taschenrechner<br />
sowie ein Suchwerkzeug aktivieren.<br />
Dies sind die vier am häufigsten aufzurufenden<br />
Funktionen und werden aus diesem<br />
Grund dauerhaft angeboten.<br />
Komplettiert wird die Grundausstattung der<br />
Palm Computer durch mindestens sieben<br />
physikalische Knöpfe, die sogenannten Hard<br />
Keys. Neben dem Ein-/Aus-Schalter sind<br />
dies zwei Scroll-Buttons zum Rollen durch<br />
den Bildschirminhalt sowie vier Application<br />
Buttons. Über die Application Buttons lassen<br />
sich die Applikationen Terminkalender,<br />
Adreßverwaltung, ToDo-Liste und Memoaufzeichnung,<br />
die zur Basisausrüstung aller<br />
Palm Handhelds gehören, mit einem Tastendruck<br />
starten.<br />
[Ost02]<br />
3.2.2 User Interface Guidelines<br />
Die Richtlinien für die Bedienung von Palm<br />
Computern stützen sich deutlich auf den raschen<br />
Zugriff auf häufig verwendete Funktionen<br />
und empfehlen Lösungen zum Umgang<br />
mit der im Vergleich zu Desktoprechnern eingeschränkt<br />
leistungsfähigen Hardware. Einige<br />
wichtige Aspekte, welche die schnelle Zu-<br />
37
Johannes Hein<br />
greifbarkeit von Applikationen betreffen, sind<br />
bei Palm Computern bereits in der Hardware<br />
durch die Hard Keys realisiert. Die Richtlinien<br />
zum Interface Design setzen dieses Konzept<br />
nun in sofern fort, daß sie die Positionierung<br />
wichtiger und häufig benutzter Funktionen<br />
in den unteren Bildschirmbereich in<br />
die Nähe der Hard Keys und insbesondere<br />
der Graffiti Zone empfehlen. Somit spart der<br />
User häufige Neuorientierung und reduziert<br />
ebenso die Bewegung und Neufokussierung<br />
des Stift-Eingabewerkzeugs.<br />
Im Gegensatz hierzu empfiehlt der User Interface<br />
Styleguide die Platzierung wichtiger,<br />
nur zu lesender Daten, im linken oberen Bereich<br />
der Oberfläche. Dieser Vorschlag basiert<br />
auf der in der westlichen Welt kulturell<br />
üblichen Leserichtung von links oben nach<br />
rechts unten. Dementsprechend wird den im<br />
linken oberen Bereich positionierten Informationen<br />
die höchste Aufmerksamkeit geschenkt.<br />
Da die typischen Benutzungsmerkmale einer<br />
PDA Applikation eine schnelle Auffindung<br />
bzw. Speicherung kurzer Datensätze beinhalten,<br />
ist für die Bedienung eine generell<br />
andere Benutzerführung vonnöten. In herkömmlichen<br />
Desktop-Anwendungen müssen<br />
die Anwender Änderungen an Datensätzen<br />
für gewöhnlich durch <strong>Dr</strong>ücken eines<br />
Speichern- oder Ändern-Buttons bzw. durch<br />
Auswahl eines entsprechenden Menüeintrags<br />
bestätigen. In mobilen Palm Systemen<br />
wurde auf diesen zusätzlichen Benutzungsschritt<br />
verzichtet. Der Styleguide sieht<br />
vor, daß das System grundsätzlich Änderungen<br />
an Datensätzen ohne explizite Aufforderungen<br />
übernehmen sollte, solange das<br />
Minimum der notwendigen Angaben vorhanden<br />
ist. Der Grund hierfür wird insbesondere<br />
durch den Einsatz der Hard Keys ersichtlich,<br />
da diese direkt eine neue Applikation in der<br />
Vordergrund schalten, ohne daß sich der Benutzer<br />
um die Datensicherung sowie Beendigung<br />
der zuvor benutzen Anwendung Gedanken<br />
zu machen braucht. Gleichsam verhält<br />
es sich mit dem Ausschalten des Palm<br />
PCs, was aus jeder beliebigen Situation ohne<br />
Datenverlust geschehen kann.<br />
38<br />
Wie die graphisch-orientierten Betriebssysteme<br />
für Desktop Computer bietet auch das<br />
Palm System eine Standardbibliothek von<br />
Gadgets an. Um die Eingewöhnung zu erleichtern,<br />
sind sie im wesentlichen an die<br />
Vorbilder der großen Betriebssysteme angelehnt,<br />
müssen sich allerdings den geänderten<br />
Benutzungsbedingungen auf Handheld<br />
Devices anpassen. Die wichtigsten Gadgets<br />
seien hier kurz vorgestellt.<br />
Zentrale Bedienungselemente von Palm OS<br />
sind Buttons und Menüs. Sie dienen beide<br />
dem Aufruf neuer Funktionen und Dialoge,<br />
ihre Einsatzgebiete unterscheiden sich jedoch.<br />
Buttons sind ideal für häufig verwendete<br />
Funktionen, die durch einmaliges Anwählen<br />
mit dem Stiftwerkzeug aufgerufen werden<br />
können. Der Styleguide sieht eine einzelne<br />
Leiste von Buttons im unteren Fensterbereich<br />
vor, um die Nähe zum Kommandobereich<br />
im Graffiti Feld zu wahren.<br />
Abbildung 18: Buttons im unteren Fensterbereich<br />
[Ost02]<br />
Buttons sollen standardmäßig einfach und<br />
abgerundet umrandet sein, in der Höhe 12<br />
Pixel und in der Breite mindestens 36 Pixel<br />
betragen. Die Buttonbreite kann bei zahlreichen<br />
unterzubringenden Buttons durchaus<br />
geringer gewählt werden, soll jedoch laut<br />
Styleguide die Untergrenze von Inhalt + 10<br />
Pixels nicht unterschreiten. Die Mindestgröße<br />
der Buttonelemente resultiert neben der<br />
besseren Übersichtlichkeit aus der Option,<br />
alternativ zum Stiftwerkzeug auch die Finger<br />
zur Eingabe zu benutzen, welche eine größere<br />
Angriffsfläche als der Tap-Stylus benötigen.
Es sei an dieser Stelle erwähnt, daß prinzipiell<br />
auch Buttons mit lediglich graphischem<br />
Inhalt, vergleichbar den Piktogrammleisten<br />
zum Direktaufruf in MS Windows, in Palm OS<br />
möglich sind. Aufgrund der niedrigen graphischen<br />
Auflösung und der Tatsache, daß Palm<br />
OS das Konzept der Tool Tips nicht unterstützt,<br />
welche beim Einsatz derartiger Graphikbuttons<br />
essentiell wären, rät der Styleguide<br />
von der Benutzung solcher Elemente<br />
ab.<br />
Menüs sind im Gegensatz zu Buttons während<br />
der meisten Zeit verborgen und werden<br />
erst durch Benutzeraktivität vollständig<br />
sichtbar. Dementsprechend bieten sie sich<br />
für seltener benutzte sowie sensible Funktionen,<br />
beispielsweise Löschoperationen, an.<br />
Als Benutzerschnittstellenstandard ist an dieser<br />
Stelle zu nennen, daß es immer ein Edit-<br />
Menü mit den Funktionen Ausschneiden, Kopieren,<br />
Einfügen etc. geben muß, sobald der<br />
zugehörige Dialog Textfelder anbietet.<br />
Abbildung 19: Beispiel für Edit-Menü [Ost02]<br />
Für geübte Benutzer ist ab der OS Version<br />
3.5 die Möglichkeit von Shortcuts für<br />
Menüpunkte gegeben, wobei der Styleguide<br />
von diesen bei sensiblen Operationen<br />
wie Löschen abrät. Das Konzept aufklappbarer<br />
Untermenüs wurde in Palm OS aufgrund<br />
des Platzmangels nicht realisiert. Anders als<br />
bei gewöhnlichen Applikationen für Desktop<br />
Computer weist der Palm OS Styleguide ausdrücklich<br />
darauf hin, Kommandoaufrufmöglichkeiten<br />
nicht zu duplizieren, d. h. Funktionen<br />
nicht parallel per Button und Menüpunkt<br />
anzubieten. Als Grund hierfür ist wiederum<br />
die Übersichtlichkeit bei eingeschränkter Gestaltungsfläche<br />
aufzuführen.<br />
Weitere Standardgadgets dienen hauptsächlich<br />
verschiedenster Arten von Auswahlmöglichkeiten.<br />
Nahezu analog zu bekannten<br />
3.2 Styleguides für Palm OS<br />
Gadgets in den Desktop Betriebssystemen<br />
verhalten sich die Checkboxes in Palm OS.<br />
Sie bieten die einzige Möglichkeit, mehrere<br />
Optionen aus einer Menge von Einstellungen<br />
zu wählen (m aus n). Aktiviert werden<br />
Checkboxes durch einen einfachen Klick mit<br />
dem Stiftwerkzeug, woraufhin die Checkbox<br />
abgehakt wird. Der Styleguide empfiehlt, den<br />
zugehörigen Beschreibungstext konsistent in<br />
Fettschrift zu setzen und weist ausdrücklich<br />
auf die Positionierung des Textes rechts der<br />
Checkbox hin.<br />
Abbildung 20: Beispiel für Checkboxes<br />
[Ost02]<br />
Für Optionsselektionen des Typ 1 aus n sollen<br />
Checkboxes nicht eingesetzt werden, da<br />
es folgende Alternativen gibt: Push Buttons<br />
ermöglichen eine derartige 1 aus n Selektion,<br />
indem die gewählte Funktion exklusiv<br />
dunkel hinterlegt wird. In ihrer Funktionsweise<br />
sind sie gleichbedeutend und gleichmächtig<br />
mit den Radio Buttons in Windows oder<br />
MacOS, welche in Palm OS keine direkte<br />
optische Entsprechung besitzen. Zur Unterscheidung<br />
von normalen Buttons sind die<br />
Push Buttons mit einem rechteckigen Rand<br />
umgeben. Der Einsatz von Push Buttons<br />
empfiehlt sich nur für Einstellungsdialoge mit<br />
mehr als zwei verschiedenen Optionen, da<br />
der Benutzer ansonsten nicht sofort erfassen<br />
kann, ob der dunkel oder der hell unterlegte<br />
Button der aktive sein soll. Die Positionierung<br />
der Push Buttons kann sowohl horizontal als<br />
auch vertikal erfolgen, wobei zu beachten ist,<br />
daß sie nur einzeilig bzw. einspaltig platziert<br />
werden dürfen.<br />
39
Johannes Hein<br />
Abbildung 21: Beispiel für Push Buttons<br />
[Ost02]<br />
Eine weitere Alternative für eine 1 aus n Auswahl<br />
besteht in der Pop Up Liste, die vergleichbar<br />
einer Combobox in herkömmlichen<br />
Systemen ist. Der Unterschied besteht darin,<br />
daß eine Pop Up Liste keinerlei Texteingabe<br />
ermöglicht, sondern eine nur eine feste<br />
Optionsauswahl zur Verfügung stellt. Der<br />
Einsatz der Pop Up Listen wird nahegelegt,<br />
wenn der Bildschirmplatz für eine entsprechende<br />
Anzahl von Push Buttons nicht ausreicht,<br />
sowie wenn die Zahl der Einstellungsoptionen<br />
sieben übersteigt. Pop Up Listen<br />
sollen soviele Einstellungsoptionen wie möglich<br />
gleichzeitig zeigen; sollte die Anzahl der<br />
Optionen dennoch größer sein, werden automatisch<br />
Scrollpfeile hinzugefügt, die weitere<br />
Navigation erlauben. Der Styleguide weist<br />
daraufhin, daß der User nie mehr als zweimal<br />
pro Pop Up Liste die Scrollpfeile betätigen<br />
soll, um an sein Ziel zu gelangen. Die<br />
Einträge sind daraufhin zu beschränken.<br />
Abbildung 22: Beispiel für Pop Up Listen<br />
[Ost02]<br />
Sollten tatsächlich noch mehr Optionen zur<br />
Verfügung stehen, wie beispielsweise im untenstehenden<br />
Beispiel zur Angabe der Zeitzone,<br />
so bieten sich sogenannte Selection<br />
Trigger an, die alle Auswahlmöglichkeiten in<br />
einer Liste in einem gesonderten, modalen<br />
Dialog aufführen. Zu erkennen sind Selection<br />
40<br />
Trigger an ihrer gepunkteten Umrandung.<br />
Abbildung 23: Bespiel für Selection Trigger<br />
[Ost02]<br />
Weitere Gadgets sind insbesondere zur Einstellung<br />
von Werten aus kontinuierlichen<br />
Mengen gedacht. Zum einen sei das Slider<br />
Gadget (verfügbar ab Palm OS 3.5) genannt,<br />
welches grundsätzlich ebenso generell als<br />
1 aus n Selektor eingesetzt werden kann,<br />
im Styleguide jedoch nur für nicht Wertspezifische<br />
Einstellungen wie Helligkeitsoder<br />
Lautstärkeregelungen nahegelegt wird.<br />
Sollten Sliderelemente dennoch in anderen<br />
Bereichen eingesetzt werden, so empfehlen<br />
die Richtlinien die zusätzliche Bereitstellung<br />
einer selbstaktualisierenden Statusanzeige,<br />
wie sie die untenstehende Abbildung zeigt.<br />
Abbildung 24: Beispiel für Slider [Ost02]<br />
Alternativ zum Slider Gadget kann auf<br />
Inkrement- und Dekrementpfeile zurückgegriffen<br />
werden, was sich wie in der folgenden<br />
Abbildung häufig zum Einstellen der Uhrzeit<br />
eignet.<br />
Abbildung 25: Beispiel für Inkrement- / Dekrementpfeile<br />
[Ost02]<br />
Wie bei den Gadgets bereits gesehen gibt es<br />
auch im Bereich des Fensterlayouts durchaus<br />
Analogien zwischen den Desktopsystemen<br />
und Palm OS. In Palm OS gibt es ebenso<br />
modale Unterdialoge wie Warnungs- und
Hilfsfenster. Als primäre Dialogform werden<br />
Formulare des Typs Modeless definiert. Sie<br />
entsprechen für gewöhnlich den Hauptdialogen<br />
einer Applikation und nehmen die gesamte<br />
Größe des Bildschirms ein; sollte es<br />
nicht möglich sein, den gesamten Informationsgehalt<br />
des Dialogs auf einer Bildschirmseite<br />
unterzubringen, so empfiehlt der Styleguide<br />
die sinnvolle Gruppierung der Daten<br />
und die Navigation per rechtsseitiger Scrollbar.<br />
Den generellen Aufbau zeigt die folgende<br />
Abbildung, wobei die beschriebene, ideale<br />
Positionierung der Kontrollelemente im unteren<br />
Bereich sowie wichtiger Informationen<br />
im linken oberen Bereich auch hier deutlich<br />
wird.<br />
Abbildung 26: Beispiel für Dialogtyp Modeless<br />
[Ost02]<br />
In der rechten oberen Zone des Bildschirms<br />
befindet sich im allgemeinen eine Kategorieanzeige,<br />
welche dem Benutzer in Verbindung<br />
mit dem linksseitigen Fenstertitel die<br />
Navigation in den verschiedenen Formularen<br />
einer Applikation erleichtern soll. Über<br />
die <strong>Dr</strong>opdown-Liste ist die Möglichkeit des<br />
Wechsels zu anderen Kategorien der Applikation<br />
möglich. Eine ständige Anzeige ist<br />
besonders sinnvoll, da viele Anwendungen<br />
für Palm PCs aufgrund der eingeschränkten<br />
Graphikfähigkeiten der Plattform sehr ähnlich<br />
aussehen und es somit leicht zu Verwechslungen<br />
zwischen Programmen kommen<br />
kann.<br />
Im Gegensatz zu den Modeless Dialogen<br />
stehen Formulare modalen Typs, welche in<br />
der Regel nur einen Teil des Bildschirms<br />
ausfüllen. Meist werden über solche Dialoge<br />
Detailinformationen oder Ausführungsbe-<br />
3.2 Styleguides für Palm OS<br />
stätigungen realisiert. Durch eine breite, umschließende<br />
Begrenzungslinie (Border) heben<br />
sich derartige Dialoge deutlich von den<br />
randlosen Modeless-Typen ab. Da der Platz<br />
auf dem Bildschirm eines Handheld PCs<br />
sehr begrenzt ist, empfiehlt der Styleguide,<br />
die Zahl der Dialoge von modalen Typs, insbesondere<br />
die der gleichzeitig geöffneten<br />
Teilfenster, möglichst gering zu halten.<br />
Abbildung 27: Beispiel für Dialogtyp Modal<br />
[Ost02]<br />
Komplettiert werden die Palm OS Dialoge<br />
durch Warnungsfenster (Alert Dialogs), welche<br />
ähnlich der MS Windows-Warnungen<br />
Piktogramme zur Signalisierung der Art der<br />
Warnung (Information, Bestätigung, Warnung,<br />
Fehlermeldung) verwenden.<br />
Abbildung 28: Beispiel für Infodialog [Ost02]<br />
Eine weitere Dialogform sind Fortschrittsanzeigen.<br />
Da die Initialisierungs- und Arbeitsgeschwindigkeiten<br />
von Handheld Applikationen<br />
meist sehr schnell sind, bedarf es expliziter<br />
Kennzeichnung, sobald eine Anwendung<br />
längere Berechnungs- oder Wartezeiten<br />
beinhaltet. Für diesen Fall stellt der Styleguide<br />
diesen Fenstertyp zur Verfügung. Sogenannte<br />
About-Dialoge zeigen Hintergrundinformationen<br />
wie Versionsnummern zu einer<br />
Applikation an und sind somit eng verwandt<br />
mit gleichen Fenstertypen im Desktop<br />
OS Bereich. Als letzter Dialogtyp sei der<br />
41
Johannes Hein<br />
Tips-Dialog zu nennen, welcher als Online-<br />
Hilfe jederzeit Informationen zum verwendeten<br />
Programm bieten soll und somit das Problem<br />
der in Palm OS fehlenden Tool Tips entschärfen<br />
soll. Tips-Dialoge sind über das Informationssymbol<br />
im Titel modaler Fenster<br />
erreichbar.<br />
Abschließend sei ein Blick auf die unterschiedlichen<br />
Darstellungsmodi für Daten geworfen.<br />
In Anlehnung an die Einsatzzwecke<br />
von Handheld PCs sind in erster Linie Darstellungen<br />
von Textinformationen von Interesse.<br />
Für die Texteingabe sind sogenannte<br />
Textfelder vorgesehen, die an gepunkteten,<br />
linksausgerichteten Zeilen zu erkennen<br />
sind. Bei Textverarbeitungen sowie in der<br />
Standardapplikation MemoPad können Textfelder<br />
mehrzeilig mit automatischem Zeilenumbruch<br />
sein. Für Formulare werden meist<br />
mehrere einzeilige Felder gesetzt, bei denen<br />
der Zeilenwechsel explizit durch Feldauswahl<br />
mit dem Stiftwerkzeug oder durch ein Graffiti<br />
Kommando eingegeben werden muß.<br />
Abbildung 29: Beispiel für Textfeld [Ost02]<br />
Textfelder stellen eine Schreibmarke zur Verfügung;<br />
die stets richtige Positionierung des<br />
Cursors durch die Applikation wird vom<br />
Styleguide als wichtige Eigenschaft guten<br />
Interface Designs für Palm OS betrachtet.<br />
Ebenso sollen Textfelder immer in der<br />
rechten unteren Ecke des jeweiligen Dialogfensters<br />
eine Shift Funktion zur Aktivierung<br />
der Großschrift anbieten. Bereits zuvor<br />
wurde die Notwendigkeit eines Edit-Menüs<br />
zum Ausschneiden, Kopieren und Einfügen<br />
von Text bei Textfeldern erwähnt. Weitere<br />
Styleguideempfehlungen für Textfelder sind<br />
automatische Großschreibung am Satzan-<br />
42<br />
fang sowie eine standardmäßige Scrollbar<br />
bei mehrzeiligen Feldern.<br />
Palm OS bietet überdies auch Repräsentationsmöglichkeiten<br />
für Listen, die nicht an<br />
Kontrollelemente wie Pop Up Gadgets oder<br />
Selection Trigger gebunden sind. Prinzipiell<br />
gelten für diese Listen, die im Zuge eines<br />
modalen Dialogs erscheinen, die gleichen<br />
Gestaltungsrichtlinien wie für die bereits<br />
beschriebenen. Ebenso kann Palm OS<br />
Informationen tabellarisch darstellen, wie es<br />
z.B. in der Standardapplikation AdressBook<br />
zum Einsatz kommt. Für Tabellen sieht der<br />
Styleguide weder Rahmen noch Spaltentitel<br />
vor, um wertvollen Gestaltungsraum zu sparen.<br />
Des weiteren wird empfohlen, Tabellen<br />
nicht direkt, sondern nur über einen Unterdialog<br />
editierbar zu machen, obwohl eine direkte<br />
Zugriffsmöglichkeit nicht ausgeschlossen<br />
wird. Erlaubt sind ebenso graphische<br />
Kontrollgadgets in Tabellen, z.B. Checkboxen.<br />
Abbildung 30: Beispiel für Tabellen [Ost02]<br />
[Ost02]<br />
3.2.3 Diskussion<br />
Computer mit dem Betriebssystem Palm OS<br />
sind die meistverkauften Systeme im Bereich<br />
der Handheld PCs. Die Betrachtung<br />
der Styleguides für Palm OS hat gezeigt,<br />
daß sich diese sehr konsequent auf die speziellen<br />
Einsatzzwecke und Hardwarevoraussetzungen<br />
der PDA-Welt konzentrieren. Zugleich<br />
bietet das Look-and-Feel des Palm<br />
Betriebssystems eine ausgewogene Kombination<br />
zwischen bekannten Bedienungsele-
menten aus der Domäne der Desktop Betriebssysteme<br />
und neu gestalteter, auf den<br />
konkreten Einsatzzweck abgestimmter Gadgets,<br />
wodurch eine sehr schnelle und effiziente<br />
Arbeitsweise ermöglicht wird. Die folgenden<br />
Kapitel sollen nun die Vor- und Nachteile<br />
anderer Handheld Plattformen im Vergleich<br />
zum Marktführer Palm unter Zuhilfenahme<br />
der jeweiligen User Interface Guidelines<br />
verdeutlichen.<br />
3.3 Styleguides für Microsoft Windows<br />
CE<br />
3.3.1 Einsatzgebiete<br />
Mit der Compact Edition ihres weit verbreiteten<br />
und marktführenden Desktop Betriebssystems<br />
Windows hat die Softwarefirma Microsoft<br />
eine Portierung der bewährten Benutzerschnittstellenansätze<br />
realisiert. Zentrales<br />
Anliegen von Windows CE ist es daher, dem<br />
Benutzer ein vertrautes Gefühl durch weitgehende<br />
Verwendung des standardisierten<br />
Windows Look-and-Feels zu vermitteln. Die<br />
Analyse der Interface Richtlinien im folgenden<br />
Kapitel wird zeigen, daß sich Styleguideempfehlungen<br />
häufig auf dieses Hauptkriterium<br />
zurückführen lassen.<br />
Microsoft Windows CE war zu Beginn seiner<br />
Existenz das Basisbetriebssystem für mobile<br />
Computer der Handheld PC (H/PC) Serie.<br />
Dies wurde über die Nachfolgemodelle bis<br />
zur heute aktuellen Pocket PC Serie beibehalten.<br />
Handheld Computer des Typs Pocket<br />
PC werden von diversen Herstellern geliefert<br />
und bieten im Vergleich zu Palm PDAs<br />
meist höhere Rechenleistungen sowie Farbbildschirme,<br />
da Windows CE analog zu seinen<br />
Pendants im Desktop Computer Bereich<br />
recht intensiv Farbdarstellungen einbezieht<br />
und die Ergebnisse auf Monochrom- oder<br />
Graustufenbildschirmen entsprechend eher<br />
enttäuschend sind; aus diesem aufwendigeren<br />
Screenmanagement folgt auch die notwendige,<br />
höhere Prozessorleistung. In Anlehnung<br />
an die Office Produkte von Micro-<br />
3.3 Styleguides für Microsoft Windows CE<br />
soft gehören Applikationen wie die Textverarbeitung<br />
Pocket Word oder die Tabellenkalkulation<br />
Pocket Excel zu den im Lieferumfang<br />
inbegriffenen Programmen von Windows<br />
CE. Ergänzt wird das Anwendungsspektrum<br />
durch PDA-typische Appliktionen<br />
wie Memoaufzeichnung, Termin- und Adreßverwaltung.<br />
[Zub01]<br />
3.3.2 User Interface Guidelines<br />
Die Verwandtschaft der Compact Edition zu<br />
den 32 bit Versionen (Win32) von Microsoft<br />
Windows zieht sich wie ein roter Faden<br />
durch die User Interface Richtlinien für<br />
dieses Handheld Betriebssystem. Um die<br />
Eingewöhnung der Benutzer zu erleichtern,<br />
übernahm Microsoft möglichst viele Bedienungselemente<br />
aus den bekannten Desktopsystemen.<br />
Ebenso wurde die Desktopmetapher,<br />
die bei den Win32 Versionen die Bedienung<br />
der graphischen Benutzeroberfläche<br />
mit den Abläufen an realen Schreibtischen simuliert,<br />
in die Standardschnittstelle von Windows<br />
CE überführt. Daraus folgt, daß auch<br />
Windows CE in der Grundeinstellung piktogrammbasiert<br />
funktioniert und Pendants von<br />
Mülleimern und Ordnern auch hier auf den<br />
Bildschirmen zu finden sind. Die Interfacerichtlinien<br />
erlauben Applikationsprogrammierern<br />
Abweichungen von der Desktopmetapher,<br />
solange dies innerhalb einer Anwendung<br />
konsistent geschieht; Grundlage des<br />
Betriebssystems bleibt jedoch das bekannte<br />
Schema.<br />
Die untenstehende Abbildung zeigt einen typischen<br />
Arbeitsbildschirm von Windows CE.<br />
Es fällt insbesondere die Startleiste auf, die<br />
ihrem Vorbild in den Win32 Versionen stark<br />
ähnelt und auch hier als Startzentrum für Applikationen<br />
dient. Ebenso bietet MS Windows<br />
CE die Übersicht über alle geöffneten Fenster<br />
sowie weitere Statusinformationen in der<br />
standardmäßig am unteren Bildschirmrand<br />
platzierten Startleiste an.<br />
43
Johannes Hein<br />
Abbildung 31: Beispiel für einen Windows CE Dialog [Cor02]<br />
Analog zu Win32 und auch zu den bereits bei<br />
Palm OS betrachteten Spezifikationen stellt<br />
das Windows CE System verschiedene Fenstertypen<br />
zur Verfügung. Dabei wird auch<br />
hier zwischen Fenstern vom Typ Modeless<br />
und modalen Dialogen unterschieden, wobei<br />
letztere erst geschlossen werden müssen,<br />
bevor mit anderen Dialogen weitergearbeitet<br />
werden kann. Der Styleguide empfiehlt<br />
für beide Dialogtypen einen Standardaufbau.<br />
Anwendungsdialoge sollen zur Fensterkontrolle<br />
eine Auswahl Windows-typischer Kontrollpiktogramme<br />
in der rechten oberen Fensterecke<br />
besitzen. Im unteren Abbildungsbeispiel<br />
sind dies das Hilfsicon (?), eine<br />
Bestätigungs- (OK) und eine Abbruchfunktion<br />
(X). Die Richtlinien empfehlen diese Piktogramme<br />
für alle nicht-modalen Dialoge mit<br />
der Einschränkung, daß das Abbruchicon (X)<br />
entfallen kann, wenn durch <strong>Dr</strong>ücken des OKund<br />
des X-Piktogramms die gleiche Funktion<br />
ausgeführt wird. Dies ist beispielsweise der<br />
Fall, wenn die in einem Formular vorgenommenen<br />
Änderungen in jedem Fall übernommen<br />
würden.<br />
Anders verhalten sich die sogenannten Messageboxes,<br />
die Informations-, Warn- oder<br />
Fehlermeldungen enthalten können. Diese<br />
modalen Dialoge bieten zur Bestätigungsbzw.<br />
Abbruchfunktion vollwertige Buttons an,<br />
wie es ihre Vorbilder in den Win32 Versionen<br />
ebenfalls tun. Das Beispiel zeigt eine solche<br />
44<br />
Messagebox aus Pocket Word.<br />
Abbildung 32: Beispiel für Windows CE Messagebox<br />
[Cor02]<br />
Die Ausstattung von Windows CE mit Gadgets<br />
und weiteren Kontrollelementen entspricht<br />
in ihrer Mächtigkeit weitgehend der<br />
der Win32 Implementierungen. Dabei gilt,<br />
daß alle im Kapitel für Palm OS beschriebenen<br />
Gadgets Windows-typisch gestaltete<br />
Entsprechungen in Windows CE haben. Allgemein<br />
ist zu beachten, daß sich die Kontrollelemente<br />
für Windows CE analog zu ihren<br />
Vorbildern in Win32 verhalten sollen, und<br />
daher den Styleguides dieser Systeme folgen<br />
sollten. Hierzu gehören beispielsweise<br />
die Eigenschaften, daß Gadgets mit Ausnahme<br />
der Buttons, demnach z.B. die Auswahl<br />
von Radio Buttons, Checkboxes oder einer<br />
Karteikarte (Tab Sheet), keine direkte Systemoperation<br />
auslösen sollen. Die wichtigsten<br />
Ergänzungen seien hier kurz erläutert.
Abbildung 33: Beispiel für Windows CE Gadgets<br />
[Cor02]<br />
Das obige Beispiel in der Abbildung zeigt bereits<br />
die Bedienelemente Radio Button und<br />
Karteikarte (Tab Sheet). Radio Buttons sind<br />
eine übersichtliche, wenngleich häufig platzintensive<br />
Möglichkeit, eine 1 aus n Auswahl<br />
zu realisieren. Die Designrichtlinien empfehlen<br />
ihren Einsatz daher nur, wenn der Gestaltungsraum<br />
auf dem meist beschränkten Bildschirm<br />
reichlich vorhanden ist. Als Alternativen<br />
bei Platzproblemen werden in Windows<br />
CE <strong>Dr</strong>opdown Listen (vgl. Pop Up Listen in<br />
Palm OS) empfohlen, die es in einer Variante<br />
auch mit der Möglichkeit der Texteingabe gibt<br />
(Combobox). Als Möglichkeit, den vorhandenen<br />
Platz in einem Fenster zu vervielfachen,<br />
3.3 Styleguides für Microsoft Windows CE<br />
können Tab Sheets benutzt werden. Der Styleguide<br />
sieht Tab Sheets immer dann vor,<br />
wenn Dialoge die Eingabe mehrerer, logisch<br />
trennbarer Daten vorsehen; für jede logische<br />
Einheit kann dann eine Karteikarte zur Verfügung<br />
gestellt und mit individuellen Kontrollen<br />
ausgerüstet werden.<br />
Die Anzahl der Möglichkeiten, in Windows<br />
CE Kontroll- und Auflistungsmechanismen<br />
zur Verfügung zu stellen, ist noch um einiges<br />
größer. So gibt es verschiedene Arten<br />
von Listboxes, baumartige Datenstrukturierung<br />
(Tree View) und vieles andere, welches<br />
in den Win32 Versionen durchaus sinnvolle<br />
und zahlreiche Einsatzgebiete gefunden hat.<br />
Diesen Elementen ist jedoch gemein, daß ihr<br />
Einsatz im Windows CE Styleguide nur vorgesehen<br />
ist, wenn die hierfür benötigte, weiträumige<br />
Gestaltungsfläche vorhanden ist.<br />
Abschließend für diese Betrachtung sei ein<br />
wichtiges, neues Element in Windows CE genannt.<br />
Ab Version 3.0 empfehlen die User<br />
Interface Richtlinien, für Applikationen eine<br />
Kommandozeile (Command Bar) einzurichten,<br />
welche ständig auf dem Bildschirm präsent<br />
ist und dem User die wichtigsten Funktionen<br />
der Anwendung stets per Menü und<br />
Buttons zugänglich macht.<br />
Abbildung 34: Beispiel für Windows CE Kommandozeile [Cor02]<br />
Die im Beispiel vorhandene Eingabebox für<br />
Adressen ist optional; es ist möglich, diese<br />
anwendungsspezifisch zu verändern oder<br />
gar auf sie zu verzichten. Der Styleguide<br />
schließt die Benutzung weiterer Komponenten<br />
in der Kommandozeile nicht aus. So<br />
können beispielsweise Radio Buttons hinzugefügt<br />
werden, um zwischen verschiedenen<br />
Dateneinheiten im zugehörigen Applikationsfenster<br />
umzuschalten. Für das Hauptmenü<br />
wird eine Standardreihenfolge vorgeschlagen:<br />
File, Edit, View, Insert, <strong>Format</strong>,<br />
Tools und Window; sollte der Entwickler diese<br />
Menüs verwenden wollen, müssen sie<br />
in dieser Reihenfolge vorkommen. Die Benutzung<br />
anderer Menüpunkte steht jedoch<br />
grundsätzlich frei. Für die Buttons sieht der<br />
Styleguide direkte Hilfe per Tool Tips vor, da<br />
insbesondere für Neulinge die rein graphischen<br />
Buttonsignaturen nicht immer auf den<br />
ersten Blick eindeutig sind.<br />
[Cor02], [Dun00]<br />
3.3.3 Diskussion<br />
Die Verkaufszahlen für Pocket PCs mit dem<br />
Betriebssystem Windows CE liegen weit hin-<br />
45
Johannes Hein<br />
ter denen von PDAs mit Palm OS zurück 2 .<br />
Daraus läßt sich schließen, daß die Entscheidung,<br />
die Windows Bedienungsphilosophie<br />
inklusive der Desktopmetapher auf Handheld<br />
Systeme zu übertragen, nicht ideal war. Sicher<br />
bieten Konzepte wie die zuletzt geschilderte<br />
Kommandozeile gute Ansätze für eine<br />
komfortable und effiziente Bedienung, können<br />
jedoch offensichtlich nicht mit den speziell<br />
auf PDAs zugeschnittenen Interface Guidelines<br />
und Bedienungsstrategien für Palm<br />
PCs konkurrieren. Erschwerend kommt hinzu,<br />
daß viele der Kontrollelemente, die Windows<br />
CE von den 32 bit-Systemen geerbt<br />
hat, aufgrund des Platzmangels bei Handheld<br />
PCs meist nicht sinnvoll eingesetzt werden<br />
können.<br />
3.4 Styleguides für Java ME<br />
3.4.1 Einsatzgebiete<br />
Die Java 2 Micro Edition, kurz Java ME oder<br />
J2ME, ist von der Firma Sun Microsystems<br />
als Kompaktvariante ihrer plattformunabhängigen,<br />
objektorientierten Programmiersprache<br />
Java entwickelt worden. Während Java<br />
in den Paketen Standard Edition (J2SE)<br />
bzw. Enterprise Edition (J2EE) in erster Linie<br />
als Entwicklungssprache im Bereich der<br />
Desktopsysteme verwendet wird, eignet sich<br />
die Micro Edition für den Einsatz auf tragbaren<br />
Computern.<br />
Die Einsatzgebiete von Java ME teilen sich<br />
in diverse <strong>Prof</strong>ile auf, welche sowohl Mobiltelefone<br />
als auch Set Top Boxen oder in<br />
Haushaltsgeräte eingebettete Systeme umfassen.<br />
Das <strong>Prof</strong>il, welches in diesem Kontext<br />
besonders interessant ist, da es sich auf<br />
den Einsatz von Handheld Computern bezieht,<br />
ist das Mobile Information Device <strong>Prof</strong>ile<br />
(MIDP). Applikationen, die dem MID <strong>Prof</strong>il<br />
zugeordnet werden können, werden auch<br />
kurz als MIDlets bezeichnet.<br />
Das wichtigste Prinzip, welches von Java ME<br />
verfolgt wird, ist die Portabilität von Appli-<br />
kationen. Dies bedeutet, daß eine Anpassung<br />
des Quellcodes eines Programms für<br />
den Einsatz auf verschiedenen Hardwareplattformen<br />
vermieden werden soll. Für jede<br />
Plattform, auf der in Java ME geschriebene<br />
Programme ablaufen, muß ein MIDP-System<br />
verfügbar sein. Das MIDP-System setzt auf<br />
die Java Virtual Machine auf und übernimmt<br />
bei der Ausführung die Anpassung der Applikation<br />
an die zugrundeliegende Hardware.<br />
Dieses Konzept hat essentielle Auswirkungen<br />
auf die im folgenden beschriebenen<br />
Richtlinien für die Benutzerschnittstelle.<br />
[Mic02]<br />
3.4.2 User Interface Guidelines<br />
Die Portabilität von Java ME Anwendungen<br />
impliziert einen der wichtigsten Aspekte im<br />
Bezug auf die zugehörigen Interface Guidelines.<br />
Durch die systemspezifische MIDP<br />
Implementierung kann eine in Java ME codierte<br />
Applikation für den Benutzer so dargestellt<br />
werden, als sei sie eine Plattformnative<br />
Anwendung. Im Idealfall bemerkt der<br />
Anwender demnach nicht, daß eine Java ME<br />
Anwendung ausgeführt wird, da ihm weiterhin<br />
das gewohnt-typische Look-and-Feel<br />
präsentiert wird. Hierdurch wird ersichtlich,<br />
daß dieses Gestaltungskriterium sehr auf die<br />
Gestaltungsaspekte der Vertrautheit und Erwartungskonformität<br />
abzielt.<br />
Zugriffe auf den Bildschirm eines Computers<br />
werden in Java ME durch die Klassen des<br />
Paketes LCDUI gesteuert. Der Applikationsprogrammierer<br />
hat durch LCDUI zwei prinzipielle<br />
Möglichkeiten, die Graphikroutinen von<br />
Java ME zu verwenden.<br />
Als erste Variante, welche für die Programmierung<br />
von Anwendungsapplikationen außerhalb<br />
des Spielesektors vom Java ME Styleguide<br />
empfohlen wird, ist die High-Level<br />
API zu nennen. Im Fall der Benutzung von<br />
High-Level Komponenten gibt der Programmierer<br />
lediglich die Art der Gadgets an, die<br />
er für seine Applikation benötigt. Die explizite<br />
2 17,5 Mio. Palm PCs vs. 2 Mio. Pocket PCs. Quelle: Schätzung von Dataquest, Stand Januar 2002 [Ost02]<br />
46
Darstellung und Platzierung sowie das graphische<br />
Rendering wird bei High-Level Komponenten<br />
ausschließlich vom MIDP-System<br />
übernommen und hat daher auf verschiedenen<br />
Plattformen unterschiedliche Erscheinungsbilder.<br />
Aus diesem Grund hat der Applikationsprogrammierer<br />
bei Verwendung der<br />
High-Level API weniger auf die Darstellungsform<br />
als auf die inhaltliche Gestaltung seiner<br />
Anwendung zu achten. Der effiziente<br />
und adäquat benutzbare graphische Aufbau<br />
der Oberfläche ist im wesentlichen von<br />
der Implementierung des zugrundeliegenden<br />
MIDP-Systems abhängig.<br />
In einigen Fällen benötigen Entwickler jedoch<br />
einen direkteren Zugriff auf die graphischen<br />
Kapazitäten des jeweils zugrundeliegenden<br />
mobilen Systems. Für diese Art von Anwendungen,<br />
welche in erster Linie bei Spielen<br />
Verwendung finden, stellt LCDUI auch eine<br />
Low-Level API zur Verfügung. Low-Level Zugriffe<br />
erfolgen über die Klasse Canvas, wodurch<br />
das Zeichnen von graphischen Primitiven<br />
sowie die Benutzung von benutzerdefinierten<br />
Graphiken ermöglicht wird. Sollte<br />
sich ein Applikationsentwickler für die Benutzung<br />
der Low-Level API entscheiden, so<br />
obliegt ihm in diesem Fall die graphische<br />
Gestaltung und Aktualisierung der Bildschirme;<br />
das MIDP-System beschränkt sich in erster<br />
Linie auf die Steuerung der Ein- und<br />
Ausgabemechanismen. Sollte eine Applikation<br />
mit Low-Level Zugriff zu stark Plattformspezifische<br />
Komponenten ansprechen bzw.<br />
auf die Kapazitäten einer bestimmten Plattform<br />
ausgelegt sein, so kann dies die Portabilität<br />
auf andere Systeme gefährden.<br />
Die beiden unterschiedlichen APIs erfordern<br />
ebenso unterschiedliche Richtlinien zur Anwendungsgestaltung.<br />
Zudem gilt es bei Styleguides<br />
für Java ME stets zwischen Implementierungsrichtlinien<br />
sowohl für die Applikation<br />
als auch für das MIDP-System zu differenzieren.<br />
Für den Fall der Canvas Bildschirme der<br />
Low-Level API sollten MIDP Systemimplementierer<br />
stets die Abbildung der Bedienungsfunktionen,<br />
welche bei Spielprogram-<br />
3.4 Styleguides für Java ME<br />
men hauptsächlich die vier Bewegungsrichtungen<br />
sowie eine Auswahl- bzw. Feuerfunktion<br />
darstellen, analog zu Systemnativen<br />
Applikationen realisieren. Sollte eine<br />
Hardwareplattform über berührungssensitive<br />
Anzeigekomponenten verfügen, sollte<br />
ein MIDP-System eine diesbezügliche Einbindung<br />
auch für Canvas Bildschirme anbieten.<br />
Anwendungsentwickler sollte bei der Verwendung<br />
von Canvas Bildschirmen die begrenzten<br />
Hardwarekapazitäten der Handheld<br />
Computer und Mobiltelefone beachten. Die<br />
Verarbeitung von Bildern mit hohen Farbtiefen<br />
kann unter Umständen lange Verarbeitungszeiten<br />
erfordern. Insbesondere wenn<br />
trotz Verwendung von Canvas Bildschirmen<br />
die Portabilität der Anwendung gewährleistet<br />
bleiben soll, empfehlen sich Graphiken, die<br />
auch in Monochrom- oder Graustufendarstellungen<br />
gut zu erkennen sind. Analog ist bei<br />
der Größe der Graphiken zu verfahren, die in<br />
einem skalierbaren <strong>Format</strong> vorliegen sollten,<br />
um sie somit problemlos an die verschiedenen<br />
Bildschirmgrößen der Geräte des MIDP<br />
anpassen zu können.<br />
High-Level Bildschirme verwenden die Routinen<br />
des MIDP-Systems für die graphische<br />
Darstellung der Bedienungselemente. Um<br />
den Eindruck zu erwecken, eine Java ME Applikation<br />
sei eine System-native, bietet sich<br />
bei Betriebssystemen wie Palm OS, die bereits<br />
eine eigene Gadget-Bibliothek zur Verfügung<br />
stellen, eine direkte Abbildung der Java<br />
ME-Komponenten auf die nativen Gadgets<br />
an. Bei Mobiltelefonen ist dagegen häufig<br />
ein explizites Design der Kontrollelemente<br />
durch den MIDP Implementierer notwendig.<br />
Die Gadget-Bibliothek von Java ME umfaßt<br />
weitgehend all die bereits in den vorherigen<br />
Kapiteln beschriebenen Elemente. Dazu gehören<br />
insbesondere Auswahllisten verschiedener<br />
Typen. Das folgende Beispiel zeigt<br />
eine exklusive Auswahl im Darstellungsvergleich<br />
zwischen Mobiltelefon und PDA.<br />
47
Johannes Hein<br />
Abbildung 35: Vergleich des Erscheinungsbildes<br />
auf Mobiltelefon und<br />
PDA [Mic02]<br />
Beim Mobiltelefon wurde das Konzept der<br />
Radio Buttons übernommen, wobei der ausgewählte<br />
Eintrag als zusätzliche Kennzeichnung<br />
auf dem niedrigauflösenden, monochromen<br />
Display graphisch invertiert wurde.<br />
Das Beispiel verdeutlicht gleichzeitig die Notwendigkeit,<br />
sich bei derartigen Small Screen<br />
Applications (SSA) auf die absolut essentiellen<br />
Informationen zu beschränken. Java ME<br />
Applikationen nach MID <strong>Prof</strong>il kommen bereits<br />
auf Bildschirmgrößen von 96 x 54 Pixels<br />
zum Einsatz, PDAs weisen in der Regel mindestens<br />
160 x 160 Pixels auf.<br />
Die genannten Gründe ergeben weitere Regeln,<br />
welche der MIDP Styleguide umfaßt.<br />
“Layout forms vertically” [Mic02] (Gestalten<br />
Sie Ihre Dialoge vertikal) lautet ein Grundsatz,<br />
da Systeme des MID <strong>Prof</strong>ils meist nur<br />
über eine vertikale Scrollfunktion in Hardware<br />
verfügen. Dementsprechend sollten auch<br />
durch die Software keinerlei horizontalen<br />
Scrollgadgets angeboten werden. Gleichzeitig<br />
schränkt auch der Java ME Styleguide<br />
die Länge der Formulare ein, welche bei<br />
einer PDA Applikation nicht die dreifache<br />
und bei Anwendungen für Mobiltelefone nicht<br />
die vierfache Länge des Bildschirms überschreiten<br />
sollten, da ansonsten das häufige<br />
Scrollen die Übersicht und Arbeitseffizienz<br />
zu stark beeinträchtigen würde. Ebenso<br />
richtet der Styleguide ein besonderes Augenmerk<br />
auf die bereits bei Palm OS beschriebene<br />
Möglichkeit, Dialoge jederzeit zu beenden<br />
(“Make everything interruptable”) [Mic02]. Ein<br />
deutliches Beispiel hierfür sind wiederum<br />
Auswahllisten, bei denen dem Benutzer nie-<br />
48<br />
mals eine Entscheidung aufgezwungen werden<br />
soll, sondern neben einer Auswahl- bzw.<br />
Fortfahren-Funktion immer die Option des<br />
Abbruchs anzugeben ist.<br />
Der Styleguide für Java ME verteilt die Verantwortlichkeiten<br />
für die Entstehung eines<br />
Programms sehr deutlich. Am Beispiel eines<br />
Hauptformulars einer Applikation soll diese<br />
Verteilung geschildert werden. Die folgenden<br />
Funktionalitäten müssen von der MIDP<br />
Implementierung festgelegt und eingehaten<br />
werden:<br />
1. Titelzeile<br />
1a. Platzierung<br />
1b. Größe<br />
1c. Schriftart<br />
1d. Darstellung (Umbruch, Scrolling etc.)<br />
2. Ticker<br />
2a. Platzierung<br />
2b. Größe<br />
2c. Schriftart<br />
2d. Scrollrichtung<br />
2e. Scrollgeschwindigkeit<br />
3. Formularschriftart<br />
4. Verwendete Farben<br />
5. Layout der Kontrollelemente<br />
[Mic02]<br />
Die Funktion des Tickerbandes wird als<br />
durchaus vielseitig beschrieben. Bei vernetzten<br />
Applikationen kann der Ticker aktuelle<br />
Nachrichten oder Werbebotschaften wiedergeben;<br />
denkbar und sinnvoll ist jedoch auch<br />
die Verwendung als Status- oder Hilfsanzeige.<br />
Die Verantwortlichkeiten des Anwendungsentwicklers<br />
belaufen sich nun auf die folgenden<br />
Punkte:<br />
1. Text für die Titelzeile<br />
2. Text für den Ticker<br />
3. Reihenfolge der Kontrollelemente
4. Inhalt der Kontrollelemente<br />
5. Funktionskommandos<br />
[Mic02]<br />
Der Begriff Funktionskommandos bezieht<br />
sich in diesem Fall auf den Aufruf weiterer<br />
Bildschirme der Applikation bzw. auf die<br />
Weiterverarbeitung ausgewählter Daten. Bei<br />
PDAs sind solche Kommandos in Buttonund<br />
Menüform vorhanden; Mobiltelefone ermöglichen<br />
die kontextabhängige Belegung<br />
variabler Funktionstasten (Soft Keys).<br />
Neben den Hauptformularen gibt es auch in<br />
Java ME vorgefertigte Fenstertypen modalen<br />
Typs (Alert Windows). Vergleichbar mit Palm<br />
OS, Windows CE und Desktop Betriebssystemen<br />
können den modalen Dialogen Typbeschreibungen<br />
zugeordnet werden, welche<br />
später den Dialog durch entsprechende Piktogramme<br />
identifizieren. Mögliche Typen sind<br />
dabei Information, Warnung, Fehlermeldung,<br />
Alarm sowie eine Bestätigungsabfrage. Analog<br />
zu den betrachteten Systemen sind auf<br />
diesen Dialogen keine weiteren Bedienungselemente<br />
vorgesehen. Der Java ME Styleguide<br />
weist jedoch darauf hin, insbesondere<br />
bei Anwendungen auf Mobiltelefonen die<br />
Erscheinungsdauer des Dialogs zeitlich zu<br />
begrenzen; nach Ablauf einer kurzen Zeitspanne<br />
schließt sich der Dialog automatisch.<br />
Hierdurch spart der Benutzer bereits eine Aktion<br />
ein. Da die Nachrichten in modalen Dialogen<br />
dieses Typs laut Styleguide kurz und<br />
aussagekräftig sein sollen, reicht meist eine<br />
Zeitbegrenzung von wenigen Sekunden.<br />
Abbildung 36: Vergleich eines Informationsdialogs<br />
auf Mobiltelefon und<br />
PDA [Mic02]<br />
Die weiteren Empfehlungen des Styleguides<br />
3.4 Styleguides für Java ME<br />
gehen weitgehend konform mit den Designempfehlungen<br />
für die anderen in dieser Ausarbeitung<br />
betrachteten Betriebssysteme und<br />
sollten dementsprechend von der MIDP Implementierung<br />
der jeweiligen Plattform unterstützt<br />
werden. Da ein Anwendungsentwickler<br />
sich jedoch nicht stets auf ein gutes MIDP-<br />
System verlassen kann, müssen bei der Softwareentwicklung<br />
für Java ME die grundsätzlichen<br />
Regeln für gutes Oberflächendesign<br />
sowie für Benutzerführung besonders beachtet<br />
werden. Hierzu seien als Beispiele<br />
die Konsistenz und Vorhersagbarkeit eines<br />
Systems, die Beibehaltung einer einfachen<br />
Oberfläche sowie die Vorbeugung von Benutzerfehlern<br />
genannt. Letzteres wird in Java<br />
ME beispielsweise insofern unterstützt, daß<br />
dem Benutzer bei Eingaben in String-Felder<br />
bereits Beschränkungen bezüglich des Inhalts<br />
auferlegt werden. So kann ein Textfeld<br />
den Parameter NUMERIC erhalten, falls dort<br />
lediglich Zahlwerte verlangt werden; nichtnumerische<br />
Werte würden von der Textbox<br />
nicht angenommen. Weitere Textparameter<br />
sind z.B. PHONENUMBER, EMAIL<br />
oder URL.<br />
[Mic02], [Gro02], [Web01]<br />
3.4.3 Diskussion<br />
Die Plattformunabhängigkeit von Java ME<br />
Applikationen ist ein interessanter Aspekt,<br />
der jedoch große Teile des Bereichs Bedienbarkeit<br />
von der hardwarespezifisch verwendeten<br />
MIDP Implementierung abhängig<br />
macht. Die Anwendungsimplementierer haben<br />
auf diese Art das letztendliche Aussehen<br />
ihres Programms auf unterschiedlichen Plattformen<br />
- mit Ausnahme der Canvas Bildschirme<br />
- kaum in der Hand. Eine gute Benutzerführung<br />
durch Anwendung allgemeingültiger<br />
Regeln für gutes Interface Design führt<br />
in diesem Fall in Zusammenarbeit mit einer<br />
qualitativ hochwertigen, an das jeweilige Gerät<br />
angepaßte MIDP Implementierung zu einer<br />
guten Benutzerschnittstelle.<br />
49
Johannes Hein<br />
3.5 Styleguides für GSM Applikationen<br />
3.5.1 Hypertextvarianten<br />
Seit einigen Jahren gibt es Mobiltelefone, die<br />
nicht nur das Telefonieren, sondern auch den<br />
Zugriff auf spezielle Internetseiten über das<br />
GSM Kommunikationsnetz erlauben. Der Zugriff<br />
erfolgt über das Wireless Application<br />
Protocol (WAP) und erlaubt die Darstellung<br />
von Internetseiten, die in Varianten der Internet<br />
Hypertextsprachen codiert sind.<br />
Die Sprache, in der GSM kompatible Internetseiten<br />
codiert sind, ist die Wireless Markup<br />
Language (WML), die wie XHTML eine<br />
Untermenge von XML ist. Hieraus werden<br />
auch gleich die Beschränkungen von<br />
WML für die graphische Gestaltung deutlich.<br />
Als Markup Sprache gibt WML lediglich die<br />
Struktur einer WAP Internetseite vor, legt deren<br />
Design jedoch nicht eindeutig fest, so<br />
daß verschiedene Browsertypen auf unterschiedlichen<br />
Handys (z.B. Openwave oder<br />
die Nokia Browser) zu individuellen Ergebnissen<br />
kommen.<br />
Des weiteren ist die Anwendungsmöglichkeit<br />
des GSM Netzes für Internetdienste relativ<br />
beschränkt. Die Übertragungsgeschwindigkeit<br />
beträgt lediglich 9,6 Kilobit pro Sekunde<br />
und stellt somit neben den vergleichsweise<br />
bescheidenen Hardwarekonfigurationen der<br />
Mobiltelefone einen weiteren Engpaß dar.<br />
[Inc00]<br />
3.5.2 GSM Applikationen<br />
Einen grundlegenden Styleguide für alle<br />
GSM Applikationen gibt es nicht. Dagegen<br />
haben einige Softwarefirmen, die an der Entwicklung<br />
von WAP Browsern beteiligt sind<br />
(z.B. PhoneCom Incorporated), Regelsätze<br />
für das Design von WAP Internetseiten erstellt,<br />
die jedoch häufig auf die Produkte der<br />
entsprechenden Firmen zugeschnitten sind.<br />
Anfangs muß man sich den Unterschied zwischen<br />
dem Einsatz von Internetseiten auf<br />
50<br />
WAP Browsern und auf Desktop PCs verdeutlichen.<br />
Die bereits genannten Beschränkungen<br />
Übertragungsgeschwindigkeit sowie<br />
Hardwareausstattung, insbesondere Display,<br />
erlauben bei effizienter Nutzungsweise lediglich<br />
die Übertragung von Textnachrichten.<br />
Auch wenn es inzwischen Handys mit farbfähigen<br />
Displays gibt, ist insbesondere farbige<br />
Bildinformation bei GSM Applikationen<br />
fehl am Platz. Als weiterer Punkt ist die Eingabehardware<br />
zu nennen, die außer bei wenigen,<br />
speziellen Mobiltelefontypen lediglich<br />
aus Zahlentasten besteht, welche eine alphabetische<br />
Tastatur nur emulieren. Hieraus<br />
folgt für das Design von WML Seiten, daß<br />
Texteinträge möglichst minimiert, wenn nicht<br />
sogar vermieden werden sollten.<br />
Dieser Aspekt leitet zum Anwendungsprofil<br />
der GSM Netzapplikationen über. WAP<br />
Seiten werden meist zum Empfang stetig<br />
wechselnder Informationen wie beispielsweise<br />
von Börsenkursen verwendet. Der Abruf<br />
erfolgt demnach meist gezielt und hat kaum<br />
die Eigenschaft eines ausgiebigen Durchsuchens<br />
verschiedenster Inhalte (Internet<br />
Surfing), wie es auf Internetbrowsern bei<br />
Desktop PCs üblich ist. Ein weiterer Aspekt,<br />
der daraus resultiert, ist die allgemein sehr<br />
kurze Nutzungszeit von WAP Seiten, was<br />
durch die derzeit noch hohen Kosten für diese<br />
Art von Netzzugriff weiter verstärkt wird.<br />
All diese Beschränkungen sind nun beim<br />
Entwurf von GSM Applikationen zu beachten.<br />
Das klare Anwenderprofil ermöglicht eine<br />
Abstimmung auf deren bevorzugte Interessen<br />
und eine entsprechend direkte Bereitstellung<br />
der wichtigsten Informationen. Anwendungsmöglichkeiten,<br />
die über diese essentiellen<br />
Informationen hinausgehen, sind<br />
bei WAP Internetseiten zu vermeiden. Des<br />
weiteren ist insbesondere bei dieser Art<br />
von Applikation eine einfache und konsistente<br />
Navigationsführung im Hinblick auf die<br />
beschränkte Auswahl von Navigationstasten<br />
der Hardware anzustreben.<br />
Eine GSM Applikation setzt sich aus sogenannten<br />
Cards zusammen, die einen Bildschirm<br />
der Anwendung bilden. Cards sollten
den Standardaufbau einer Titelzeile, dem eigentlich<br />
Cardinhalt und der Toolbar im unteren<br />
Bereich, welche häufig Navigationszwecken<br />
dient, haben. Mehrere zusammengehörige<br />
Cards einer Applikation werden<br />
auch als Deck bezeichnet. Die Titelzeile einer<br />
Card sollte aussagekräftig sein, um dem<br />
Anwender seinen derzeitigen Navigationspunkt<br />
stets sichtbar zu machen.<br />
Das Augenmerk bei GSM Applikationsdesign<br />
ist insbesondere auf Cardinhalt und Navigation<br />
zu richten. Der Cardinhalt ist insofern<br />
problematisch, daß die Textzeilenanzahl auf<br />
handelsüblichen Mobiltelefonen in der Regel<br />
nur vier beträgt. Meist kann daher ein Scrollen<br />
der Cardinformation nicht vermieden werden.<br />
Für das Design der Card stehen die<br />
in WML spezifizierten Möglichkeiten zur Verfügung.<br />
So gibt es Felder zur Texteingabe,<br />
welche stets einzeilig gehalten sein müssen<br />
und aufgrund der genannten Beschränkungen<br />
bei der Eingabe bereits Default-Werte<br />
enthalten sollten. WML ermöglicht ebenso<br />
den Einsatz von Tabellen zur Gruppierung<br />
von Daten, was jedoch nicht von jedem WAP<br />
Browser unterstützt wird.<br />
Die Navigation in WML Seiten erfolgt ebenso<br />
über Hyperlinks, von deren Anwendung<br />
man insbesondere Gebrauch machen sollte,<br />
um zu lange Textseiten zu vermeiden.<br />
Ihr Aussehen ist Browser-spezifisch, aktiviert<br />
werden sie über die OK- bzw. Bestätigen-<br />
Taste des Mobiltelefons. Als Unterschiede<br />
zu bekannten Internet-Hyperlinks sind aufzuführen,<br />
daß nicht zwischen bereits besuchten<br />
und neuen Links unterschieden wird,<br />
und daß Links in Bildform (Imagelinks) nicht<br />
eingesetzt werden sollten. Die Navigationsstruktur<br />
ist bei WAP Seiten sehr wichtig. Die<br />
Struktur sollte einen Standardpfad durch das<br />
gesamte Deck vorgeben, wobei Ausweichmöglichkeiten<br />
bei bestimmten Detailanfragen<br />
sowie stets eine Rückkehrmöglichkeit<br />
gegeben sein sollten.<br />
Abschließend seien einige weitere Strategien<br />
genannt, um den beschränkten Platz<br />
bei der Informationspräsentation besser zu<br />
nutzen. Die SAP WAP Guidelines haben<br />
3.6 Schlußbetrachtung<br />
hierzu einige Vorschläge, welche die Verkürzung<br />
von Textnachrichten zur Folge haben.<br />
Zum einen wird von der durchgehenden<br />
Benutzung von Großbuchstaben abgeraten;<br />
für lokalisierte Applikationen, insbesondere<br />
in deutscher Sprache, wird die Verwendung<br />
der Umlaute ä, ö, ü anstelle der<br />
Diphthonge ae, oe, ue nahegelegt. Weitere<br />
Aspekte dieser Strategie sind die Vermeidungen<br />
von Redundanzen im Text durch die<br />
Verwendung aussagekräftiger Abkürzungen,<br />
wodurch zum Beispiel “Document Type” zu<br />
“DocType” oder “Fixed capacity requirement”<br />
zu “Fix.CapReq.” wird. Die meist fachspezifisch<br />
informierte Anwendergruppe ermöglicht<br />
solche Einsparungen.<br />
[Gui00], [Inc00]<br />
3.6 Schlußbetrachtung<br />
3.6.1 Zusammenfassung<br />
Die betrachteten Beispiele haben gezeigt,<br />
daß im Bereich des Handheld Computing<br />
die Notwendigkeit des konsequenten Usability<br />
Engineering aufgrund der beschränkten<br />
Platz- und Hardwarekapazitäten noch um einiges<br />
größer ist als im Desktop Bereich. Die<br />
Anwendungen für PDAs sowie Mobiltelefone<br />
müssen sich diesen Einschränkungen unterwerfen<br />
und dennoch die bestmögliche Benutzungsqualität<br />
für den Anwender anstreben,<br />
um am Markt erfolgreich zu sein. Die<br />
Übertragung bereits bekannter und bewährter<br />
Designphilosophien aus dem Desktop<br />
Computer Bereich ist keine Universallösung<br />
für Handheld Devices, da die bei den großen<br />
Systemen mögliche Designfreiheit in diesen<br />
Fällen nicht gegeben ist.<br />
3.6.2 Ausblick<br />
Mit Sicherheit werden sich die Möglichkeiten<br />
der PDAs, die Ausstattungen der Hardware<br />
sowie die Anwendungsmöglichkeiten<br />
des mobilen Internets in den nächsten Jahren<br />
deutlich verbessern. Die derzeitigen Ein-<br />
51
Literatur<br />
schränkungen, die im Kapitel über GSM Applikationen<br />
angesprochen wurden, werden<br />
sich mit der Zeit durch den Einsatz moderner<br />
Mobiltelefone sowie neuer Übertragungstechniken<br />
(z.B. UMTS) vermutlich lösen.<br />
Eventuell ist sogar eine wachsende Verschmelzung<br />
der Gerätetypen Mobiltelefon<br />
und Handheld PC zu einem mobilen Kommunikationszentrum<br />
möglich. Die gegenüber<br />
Literatur<br />
Desktop Computern beschränkten Eingabemöglichkeiten<br />
werden jedoch vermutlich<br />
bestehen bleiben. Somit werden auch die<br />
zukünftigen Generationen von Geräten des<br />
Handheld Computings zur Erreichung besserer<br />
Benutzungseigenschaften auf die konsistente<br />
Umsetzung von User Interface Guidelines<br />
angewiesen sein.<br />
[Cor99] Microsoft Corporation, Hrsg.: Microsoft Windows User Experience. Microsoft<br />
Press, 1999.<br />
[Cor02] Microsoft Corporation: Microsoft Windows CE 3.0 - Application Design Guide.<br />
http://msdn.microsoft.com/library/default.asp?url=/library/<br />
en-us/wcede% sign/htm/_wcesdk_designing_a_user_interface_<br />
for_windows_ce.asp, 2002.<br />
[DiP96] DiP: A Quick Look at Kai’s Power Goo. http://www.algonet.se/~dip/goo_<br />
1p.html, 1996.<br />
[Dun00] Jason Dunn: Pocket PC UI Suggestions. http://windowsce.kensai.com/<br />
uichange.htm, 2000.<br />
[Gro02] Little Springs Design Group: A UI Designer’s Guide to J2ME and MIDP. http://<br />
littlespringsdesign.com/design/index.html, 2002.<br />
[Gui00] SAP Design Guild: SAP Interaction Design for WAP Applications. http://www.<br />
sapdesignguild.org/resources/wap_guidelines/wap_guidelines.%<br />
pdf, 2000.<br />
[Inc00] PhoneCom Inc.: WML Application Styleguide. http://www.sapdesignguild.<br />
org/resources/wap_guidelines/wap_guidelines.% pdf, 2000.<br />
[Mic02] Sun Microsystems: MIDP Style Guide Version 1.0a. http://java.sun.com/<br />
j2me/docs/alt-html/midp-style-guide7/index.html, 2002.<br />
[Ost02] Jean Ostrem: Palm OS User Interface Guidelines. http://www.palmos.com/<br />
dev/support/docs/UIGuidelines.zip, 2002.<br />
[Web01] <strong>Prof</strong>. <strong>Dr</strong>. Michael Weber: Interaktive Systeme, Vorlesungsskript Sommersemester<br />
2001 an der <strong>Universität</strong> <strong>Ulm</strong>. http://medien.informatik.uni-ulm.de/<br />
lehre/courses/ss01/interaktiv/IS-K% apitel5.1-5.4.pdf, 2001.<br />
[Zub01] Sarah Zuberec: Windows CE Interaction Design. http://www.cs.umd.edu/<br />
class/fall2001/cmsc838s/Chapter5.ppt, 2001.<br />
52
4 Smart-Its und intelligente Geräte<br />
Zusammenfassung<br />
Smart-Its sollen den Menschen unterstützen,<br />
aber ihn vor der Komplexität<br />
der Computertechnologie bewahren. Sie<br />
sind ubiquitär (allgegenwärtig) und erweitern<br />
normale Alltagsgegenstände mit<br />
Computerfuntionalität. Einige interessante<br />
Technologien und Projekte für Smart-<br />
Its werden in dieser Arbeit vorgestellt.<br />
4.1 Einleitung<br />
Das Leben eines Menschen ist kurz. Vom Tage<br />
seiner Geburt an bis hin zum Tod, lernt er<br />
mit seiner Umwelt zu interagieren um dann<br />
die Umgebung seinen Bedürfnissen anzupassen.<br />
Wie erfolgreich die Bemühungen<br />
sind, hängt sehr davon ab wie schnell gelernt<br />
wird und welchen Zeitbedarf die Veränderungen<br />
benötigen. Werkzeuge vereinfachen<br />
die Manipulation der Umwelt, aber<br />
erfordern einen gewissen Lernaufwand bevor<br />
sie genutzt werden können. Für eine effektive<br />
Gestaltung des Lebens liegt es somit<br />
nahe, diesen Aufwand zu minimieren. Die<br />
Computertechnologie stellt ein neues, wertvolles<br />
und bereits heute fast überall verfügbares<br />
Werkzeug dar. Das Problem derzeit erhältlicher<br />
Technologie ist der Mensch selbst,<br />
denn er muss sich an den Gebrauch anpassen.<br />
Jedoch bietet gerade diese neue Art<br />
von Hilfsmitteln interessante Wege an, das<br />
Werkzeug dem Menschen anzunähern. Die<br />
Smart-Its sind eine von vielen Ideen die diese<br />
Wege umzusetzen versuchen. Dabei handelt<br />
es sich um kleine Geräte die in Alltagsgegenstände<br />
integriert sind. Sie sollen den<br />
Menschen in seinen Tätigkeiten unterstützen<br />
oder diese vereinfachen. Sie sind praktisch<br />
nicht sichtbar für den Benutzer und werden<br />
unbewusst mitbenutzt. Während herkömmliche<br />
Computer bei ihrer Verwendung im Mit-<br />
Detlef Köntges<br />
detlef.koentges@informatik.uni-ulm.de<br />
telpunkt stehen, kommt bei Smart-Its das<br />
eigentliche Ziel des Benutzers in den Vordergrund.<br />
Völlig normale Gegenstände werden<br />
durch eine Computerfunktionalität erweitert,<br />
aber ihre Handhabung verändert sich nicht.<br />
Damit entsteht trotz der Erleichterung der<br />
Zielerfüllung kein zusätzlicher Lern- und Arbeitsaufwand.<br />
Smart- Its bieten zwar weniger<br />
Leistungen als Computer, ermöglichen aber<br />
nicht digitalen Objekten eine Leistungserweiterung.<br />
Sie sind gekennzeichnet durch eine<br />
einfache Benutzerschnittstelle und Sensoren<br />
über die sie die Umwelt wahrnehmen<br />
können, außerdem ermöglicht ihnen eine<br />
Netzwerkverbindung die Kommunikation mit<br />
anderen Geräten. Damit eröffnet sich ein<br />
weites Anwendungsfeld für Smart-Its, den<br />
Menschen bestmöglichst in seinem Leben<br />
und seinen Zielen zu unterstützen. Im Folgendem<br />
wird genauer auf die verschiedenen<br />
Technologien eingegangen, die in Smart- Its<br />
Anwendung finden können. Dabei werden<br />
die Bereiche Vernetzung, Stromversorgung,<br />
Sensoren, Speicher und Software angesprochen.<br />
Es existieren bereits viele Projekte und<br />
Visionen zum Thema Smart-Its und einige<br />
davon werden im nachstehenden Text vorgestellt.<br />
53
Detlef Köntges<br />
4.2 Kommunikationstechnologie<br />
Aufgrund der geringen Größe von Smart-<br />
Its sind neue Technologien erforderlich, die<br />
im Miniaturbereich Kommunikation, Speicherung,<br />
Energieversorgung usw. ermöglichen.<br />
Einige wichtige Entwicklungen werden in diesem<br />
Kapitel vorgestellt und bewertet hinsichtlich<br />
ihres Wertes für die Verwendung in<br />
Kleinstgeräten.<br />
Der wohl wichtigste Vorteil von Smart-Its ist<br />
ihre Fähigkeit sich mit anderen Geräten zu<br />
einem Netzwerk zu verbinden. Um diese<br />
Verbindung zu gewährleisten stehen einige<br />
Kommuniktionstechniken zur Verfügung.<br />
4.2.1 Bluetooth<br />
Die von der Firma Ericsson hergestellte<br />
Übertragungstechnik hat ihren Namen von<br />
König Harald II geerbt. Bereits 1984 wurde<br />
dieses Verfahren entwickelt, ist aber erst<br />
Jahre später, von einer Gruppe von Firmen<br />
die sich zu einem Interessenverband zusammengeschlossen<br />
haben, aufgegriffen worden.<br />
Da Bluetooth eine von vielen kabellosen<br />
Datenüberrtragungstechniken ist, stellt sich<br />
die Frage welche Vorteile sie bietet, die sie<br />
von anderen Verfahren unterscheidet. Unter<br />
dieser Fragestellung sollten sich vor allem<br />
die geringen Herstellungskosten und die<br />
universelle Einsetzbarkeit der Technologien<br />
abheben. Die Bluetooth-Module haben eine<br />
Reichweite von ca. 10 Metern, ohne das<br />
Sichtkontakt zwischen Sender und Empfänger<br />
bestehen muss. Zwar könnte die Reichweite<br />
auf 100 m erhöht werden, aber aus<br />
Stromersparnisgründen wird die 10 Metervariante<br />
bevorzugt. Weiterhin bieten sie eine<br />
Verschlüsselung auf Hardwareebene und die<br />
maximale Datenübertragungsrate von 1 Mbps<br />
an. Geräte die mit diesen Modulen ausgestattet<br />
sind können in einem Piconet mit 8<br />
Teilnehmern zusammengeschlossen werden<br />
und höchstens 10 Piconets lassen sich dann<br />
zu einem Scatternet verbinden. Die folgende<br />
Grafik erläutert nur kurz die Strukturen dieser<br />
54<br />
Netze, da dies Thema einer späteren Arbeit<br />
ist.<br />
Abbildung 37: Piconet und Scatternet<br />
[Sie02]<br />
Die Übertragung erfolgt auf dem in fast allen<br />
Ländern lizenzfreien Band von 2,402 bis<br />
2,480 GHz, in einem Bereich neben dem<br />
auch funkbetriebene Garagentore, Mirkowellen<br />
und vieles andere arbeitet. Die Module<br />
selbst sind für Störungen wenig anfällig,<br />
jedoch haben sie selbst einen unerfreulichen<br />
Einfluss auf andere Funkquellen. Um<br />
so etwas gering zu halten, werden mittels<br />
Frequenzmultiplexing potentielle Störquellen<br />
und Datenstaus vermieden. Dabei handelt<br />
es sich um Frequenzsprünge auf 79 Kanälen<br />
innerhalb des Frequenzbandes mit einem<br />
Abstand von 1 MHz, in einer Periode von<br />
1600 Sprüngen pro Sekunde. In einem Piconet<br />
werden alle teilnehmenden Module auf<br />
die selbe Sprungfrequenz synchronisiert. Ein<br />
weiteres Feature sind die sogenannten <strong>Prof</strong>ile,<br />
welche definieren wie sich Module untereinander<br />
erkennen und das völlig unabhängig<br />
vom jeweiligen Hersteller. Zum Aufbau einer<br />
Kommunikation zweier oder mehrer Geräte,<br />
identifizieren diese sich über eine Seriennummer<br />
(48-Bit) und verwenden für die<br />
Verbindung das Protokoll ’Service Discovery<br />
Protocol’(SDP).Jedes Gerät hat eine eigene<br />
Registry, welche Informationen über seinen<br />
Gerätetyp und andere spezifische Informationen<br />
enthält, so dass dann eine optimale<br />
Nutzung der Verbindung erfolgen kann. Die<br />
Module können aber nicht nur eine Verbin-
dung nutzen sondern sogar mehrere parallele<br />
Datentransfers durchführen. Dies wird erreicht<br />
durch die Verteilung der Informationskanäle<br />
auf unterschiedliche Sprungfrequenzen,<br />
somit können mehrere Wege gleichzeitig<br />
genutzt werden. Daten werden asynchron<br />
übertragen, und da es sich besser eignet,<br />
wird Sprache synchron übertragen. Nachteilig<br />
sind der bisher hohe Preis, die geringe<br />
Reichweite, die schmale Übertragungsrate<br />
und es stehen der breiten Nutzung auch<br />
noch Inkompatibilitäten der Geräte von verschieden<br />
Herstellern entgegen.[Duy01]<br />
Die Architektur eines Bluetoothmoduls wird<br />
in der folgenden Darstellung veranschaulicht.<br />
kurz zur Erläuterung:<br />
-L2CAP: logische Verbindung, Protokollanpassung<br />
-Link Management: Verwaltung von Piconetzen<br />
-Baseband: Auffinden von Geräten, Synchronisation,<br />
Fehlerbehandlung<br />
-RF-Schicht: physikalische Übertragung<br />
Abbildung 38: Bluetooth-Architektur [Bei00]<br />
Der Stromverbrauch wird in einem Gerät dieser<br />
Art mit Hilfe von vier Modi minimiert, die<br />
alle gleichzeitig aktiv sein können. Der Verbrauch<br />
der einzelnen Zustände wird in der<br />
4.2 Kommunikationstechnologie<br />
nachfolgenden Tabelle erfasst.<br />
Modus Verbrauch<br />
Sleep/Park 30 Mikroampere<br />
Hold 60 Mikroampare<br />
Sniff/Bereitschaft 300 Mikroampare<br />
Senden/Empfangen 3-30 Milliampare<br />
Tabelle 1: Verbrauch [Duy01]<br />
Im Parkmodus wird das Gerät mit anderen<br />
synchronisiert, aber nimmt nicht am Datentransfer<br />
teil. Der Holdmodus ist die Verbindungsbereitschaft<br />
des Moduls, ohne jedoch<br />
wirklich Daten zu übertragen. Jedes Modul<br />
hört im Sniffmodus die verschieden Frequenzen<br />
ab, mit einer Periode von 32 Frequenzen<br />
in etwa 1,28 Sekunden. Dieser Zustand ist<br />
der normale Zustand von Bereitschaft für ein<br />
Bluetoothmodul.<br />
Will nun ein Gerät Kontakt mit einem anderen<br />
Modul aufnehmen, wird es zum Busmaster,<br />
da die Master/Slave-Rollen dynamisch vergeben<br />
werden können. Der Master sendet an<br />
die Slaves eine Inquiry-Nachricht und falls er<br />
das Gerät noch nicht kennt, eine zusätzliche<br />
Page Nachricht. Dabei werden unter anderem<br />
die Adressen und der Frequenzsprung-<br />
Algorithmus abgefragt. Anschließend wir die<br />
Datenübertragung durch eine Nachricht auf<br />
16 Frequenzen initialisiert. Der Verbindungsmaster<br />
bestimmt welche Verbindungsarten<br />
auf den jeweils angeschlossen Geräten aktiv<br />
sind und wie schnell ein Interface kommuniziert.<br />
Dieser Verbindungssaufbau funktioniert<br />
leider nur so lange keine schnellen<br />
Bewegungen auftreten, da die zuvor erwähnten<br />
Zustandswechsel zu lange dauern.<br />
Abschließend lässt sich noch feststellen,<br />
dass mit Bluetooth ein weites Anwendungsfeld<br />
erschlossen werden kann, dies gilt vor allem<br />
i auf dem Bereich der Smart-Its. Es bietet<br />
neben einer hohen Gerätedichte, eine kabellose<br />
Vernetzung an und erweitert die einfache<br />
Funkübertragung durch eine umfassende<br />
Protokollarchitektur. Da die Entwicklung<br />
aber noch am Anfang steht, sind noch einige<br />
Probleme aus dem Weg zu räumen, zu denen<br />
unter anderem der hohe Stromverbrauch<br />
gehört.[Duy01]<br />
55
Detlef Köntges<br />
In dem Nachfolgenden Bild wird ein Bluetoothmodul<br />
von Ericsson dargestellt. Mit einer<br />
Größe von 33 x 17 x 3.65 mm Größe kostet<br />
es zur Zeit 20 bis 30 Dollar. Geplant ist<br />
eine neue Chip-Architektur, in der alle Komponenten<br />
auf die Fläche von 9 x 9 mm integriert<br />
werden.[Duy01]<br />
4.2.2 IrDA<br />
Abbildung 39: Bluetooth [Bei00]<br />
Die Infrarotstrahlung (IR-Strahlung) ist eine<br />
vom Auge nicht wahrnehmbare elektromagnetische<br />
Strahlung, die an die langwellige<br />
Grenze des Sichtbaren Lichts anschließt und<br />
sich bis ins Mikrowellengebiet erstreckt. Basierend<br />
auf dieser Strahlung werden mit dem<br />
IrdA-Standard der Infrared Data Association<br />
drahtlose Punkt zu Punkt Verbindungen<br />
möglich, die eine Entfernung von etwa einem<br />
Meter zulassen. Ursprünglich war diese<br />
Technologie für den Einsatz in kabelloser Tastatur,<br />
Maus und anderen Peripheriegeräten<br />
gedacht. Dabei werden IR- Dioden eingesetzt<br />
um die Signale im Infrarotbereich zu<br />
erzeugen. Diese strahlen ein diffuses Licht<br />
aus, welches von Wänden reflektiert wird.<br />
Für die Kommunikation zwischen Geräten ist<br />
eine Ausrichtung der Strahlenquelle zu den<br />
Sensoren erforderlich. Die Orientierung der<br />
Quelle auf die Sensoren des Empfängers<br />
sollte dabei nicht über einen 30 Grad Kegel<br />
hinaus gehen. Der Grund für diese Einschränkung<br />
ist die Vermeidung von Reflektion<br />
und anderen unerwünschten Einflüssen,<br />
die dem Aufbau von Piconetzen entgegengestanden<br />
hätten. IrdA ist derzeit ein aktueller<br />
Standart in Mobilrechnern, so zum Beispiel<br />
um die Verbindung von Digitalkamera und<br />
56<br />
<strong>Dr</strong>ucker zu ermöglichen. Folgeprobleme dieser<br />
Einschränkung sind, dass in bestimmten<br />
Situationen einige Teilnehmer eines Netzes<br />
sich nicht sehen können. Gelöst wird diese<br />
Frage in IrdA über eine Master-Slave-<br />
Beziehung.<br />
Die Vorteile der IR-Technologie sind vor allem<br />
die niedrigen Kosten und eine einfache<br />
Herstellung der Geräte, außerdem sind keine<br />
Lizenzen, wie sie häufig in der Funktechnologie<br />
auftreten, erforderlich. Auch die Abschirmung<br />
ist einfach, um Interferenzen mit anderen<br />
Quellen zu vermeiden. Probleme treten<br />
aber bei der Einstrahlung von Sonnenlicht<br />
auf und auch andere Wärmequellen könne<br />
ungewollte Einflüsse auf die Kommunikation<br />
haben. Außerdem lässt sich die Infrarotstrahlung<br />
leicht abschatten und bietet nur eine<br />
niedrige Bandbreite. Das heißt auf asynchronen<br />
Datentransfers können etwa 115,2 Kbps<br />
übertragen werden und bei synchronen Verbindungen<br />
wird mit ungefähr 1,152 Mbps<br />
etwas mehr ermöglicht.[Bei00]<br />
4.2.3 Ad-hoc Netzwerk<br />
Smart-Its sind durch die Beweglichkeit der<br />
Gegenstände an die sie gebunden sind,<br />
nicht in herkömmliche Netzwerkstrukturen<br />
einzubinden. Es ist nicht vorherzusehen welche<br />
Geräte sich gerade in Reichweite befinden.<br />
Daher ist die Fähigkeit der Bluetoothund<br />
IrdA- Technologie ein Netzwerk ad hoc<br />
(aus dem Augeblick heraus) aufzubauen von<br />
schwerwiegender Bedeutung für die Verbindung<br />
zwischen Smart-Its. Dabei kommunizieren<br />
die Netzwerkteilnehmer direkt miteinander<br />
ohne irgendwelche Basisstationen.<br />
Damit ist die für Smart-Its notwendige räumliche<br />
Unabhängigkeit gewährleistet, die aber<br />
durch den Empfangsbereich eingeschränkt<br />
wird.
Abbildung 40: Ad-hoc Netzwerk<br />
4.2.4 Andere Übertragungsmedien<br />
Neben den herkömmlichen Techniken wie<br />
Funk- und IR-Verbindungen, werden neue<br />
Wege des Datentransfers entwickelt. Eine<br />
Idee dazu ist die Intra-Body-Kommunikation,<br />
bei der Information über den menschlichen<br />
Körper übertragen wird.<br />
Abbildung 41: Datenübertragung per Berührung<br />
[Bei00]<br />
Diese in den MIT MediaLab entwickelte<br />
Technologie kann über Ströme im nA-<br />
Bereich 3 eine Datenrate von mehreren Kbps<br />
erreichen. Sie ist sehr energieeffizient<br />
und stellt berührungskontrollierte Verbindungen<br />
zwischen dem Menschen und seinen<br />
Werkzeugen her. So könnte man sich vorstellen,<br />
dass ein Werkzeug eine Verbindung,<br />
mit einem Smart-It das in der Kleidung untergebracht<br />
ist, über den menschlichen Körper<br />
3 Nano Ampere ist die Stromstärke<br />
4.2 Kommunikationstechnologie<br />
aufnimmt und direkt alle persönlichen Einstellung<br />
an sich selbst vornimmt, die der Anwender<br />
benötigt.<br />
Abbildung 42: persönliche Einstellungen bei<br />
einer Kamera [Bei00]<br />
Eine weitere Möglichkeit Informationen zwischen<br />
Smart-Its auszutauschen, besteht<br />
über Oberflächen. So wird bei einem Projekt<br />
an der University of Cambridge an einer<br />
Tischplatte gearbeitet, die als Übertragungsmedium<br />
dient, für alle Geräte die darauf abgestellt<br />
sind. Die Oberfläche des Tisches besteht<br />
aus Kacheln, während die universelle<br />
Schnittstelle an den Geräten eine Runde<br />
Form aufweist. Diese Formgebung ermöglicht<br />
erst die sichere Bereitstellung der erforderlichen<br />
Anzahl von Pins, die für eine Verbindung<br />
notwendig sind.<br />
57
Detlef Köntges<br />
Abbildung 43: Schema für Kontaktfläche<br />
[Bei00]<br />
Abbildung 44: Versuchsaufbau des Tisches<br />
[Bei00]<br />
4.2.5 Powerline Communication (PLC)<br />
Für Smart-Its die in Geräten mit einem Anschluss<br />
an das Stromnetz integriert sind, besteht<br />
außer der Möglichkeit die Energieversorgung<br />
mit zu nutzen, Informationen über<br />
das Kabel zu versenden oder zu empfangen.<br />
Die Powerline Communication nutzt die<br />
Verkabelung eines Hauses zur Stromversorgung<br />
um Daten zu übertragen, mit den<br />
Steckdosen als Zugang. Leider können solche<br />
Geräte nicht mobil eingesetzt werden.<br />
Für Smart-Its kann dies aber ein Zugang zu<br />
anderen Netzen sein, wie etwa die Verbindung<br />
zweier Piconets die räumlich zu weit<br />
auseinanderliegen. Die Daten werden als<br />
hochfrequentes Signal auf 50/60 Hz Wechselstrom<br />
übertragen. Der Bereich ist eingeschränkt<br />
durch die Reservierung von 4<br />
Bändern zwischen 10 bis 150 kHz für die<br />
Energieversorgungsunternehmen, wie sie in<br />
Europa angewendet wird. Wegen der fehlen-<br />
58<br />
den Abschirmung der stromführenden Kabel,<br />
sind diese als Übertragungsmedium sehr anfällig<br />
für die Einstrahlung von Elektrogeräten<br />
und Funkquellen. Zudem werden die Signale<br />
mit zunehmender Entfernung schwächer, so<br />
das eine Verstärkung in bestimmten Intervallen<br />
erforderlich wäre.[Bei00]<br />
4.3 Energieversorgung<br />
Das Hauptproblem jedes derzeit verfügbaren<br />
mobilen Rechners ist seine Versorgung mit<br />
Energie. Im Falle der Smart-Its wird dieser<br />
Zustand durch die geringe Größe der Artefakte<br />
verschärft. Falls keine Quelle an dem<br />
Gegenstand existiert, in welchem das Smart-<br />
It integriert ist, muss die Energie etwa aus einer<br />
Batterie gewonnen werden. Die Entwicklung<br />
ist in diesem Bereich bereits sehr weit<br />
fortgeschritten, nicht nur die Haltbarkeit wurde<br />
erhöht sondern auch die Wiederverwendbarkeit.<br />
So könnte ein Smart-It-Artefakt sich<br />
an bestimmten Orten wieder neu laden. Das<br />
Wechseln der Energiequelle durch den Anwender,<br />
wäre bei steigender Zahl von solchen<br />
Geräten sehr aufwendig. Gerade dort<br />
könnten Energiequellen eingesetzt werden,<br />
die sich aus ihrem Umfeld versorgen. Zu<br />
solche Quellen zählt neben der Sonne, der<br />
Mensch selbst.<br />
4.3.1 Photovoltaik<br />
Die Lichtenergie, die in der Umgebung frei<br />
verfügbar ist, wird seit langer Zeit genutzt.<br />
Wir kennen sie aus der Satellitentechnik und<br />
Raumfahrt, aber auch Taschenrechner, Uhren,<br />
Handys oder die Versorgung eines ganzen<br />
Hauses mit elektrischer Energie sind<br />
Beispiele für die weitreichende Verwertung.
Abbildung 45: eine Bild der Photvoltaik wie<br />
es jeder kennt [Gno02]<br />
Der Einsatz für Kleinstgeräte bietet sich an,<br />
da sie nur einen geringen Bedarf an Energie<br />
haben. Der Nachteil dieser Technologie<br />
ist ihre Abhängigkeit zu einem hellen Platz,<br />
um genügend Elektrizität aus dem Licht zu<br />
gewinnen. Daher ist sie für Smart-Its nur bedingt<br />
einsetzbar, nämlich gerade für solche<br />
die in Gegenständeeingebaut sind, die eine<br />
gut beleuchtete Oberfläche besitzen.<br />
4.3.2 Windenergie<br />
Bereits die Mühle im Mittelalter nutzte die<br />
Kraft des Windes, warum sollten nicht auch<br />
Smart-Its davon Gebrauch machen. Etwa an<br />
einer Jacke angebracht oder einem Fahrzeug<br />
könnte die Bewegung der Luft die Quelle der<br />
Energie sein, die ein Geräte für seine Funktion<br />
benötigt.<br />
4.3.3 Piezoelektrik<br />
Bei dieser Variante der Energieversorgung<br />
wird die Bewegung genutzt, um Energie zu<br />
erzeugen. So kann zum Beispiel die Bewegung<br />
des Menschen dazu dienen, eine Reihe<br />
von Smart-Its die an seinem Körper an-<br />
4.4 Sensoren<br />
gebracht sind, mit Energie zu versorgen. Um<br />
die Bewegung zu nutzen, benötigt man piezoelektrische<br />
Materialien, die bei mechanische<br />
Belastung elektrische Energie produzieren.<br />
Dabei kann sich zum Beispiel um<br />
eine Verbindung aus Blei- Zirkonat-Titanat<br />
(PZT) oder um Polyvinyliden Fluorid (PVDF)<br />
handeln. Im folgenden Bildbeispiel wird eine<br />
schematische Darstellung eines Schuhs gezeigt,<br />
der mit den entsprechenden Substanzen<br />
ausgerüstet ist.[Gno02]<br />
Abbildung 46: Verwendung der Piezoelektrik<br />
[Gno02]<br />
4.4 Sensoren<br />
Die Fenster der Smart-Its in die Außenwelt<br />
sind ihre Sensoren, über die sie ihre Umgebung<br />
wahrnehmen können. Wichtige Eigenschaften<br />
die einen Sensor für ein Smart-It<br />
benötigt, sind eine geringe Größe und ein<br />
niedriger Stromverbrauch. Außerdem muss<br />
die Ausgabe des Sensors einfach zu interpretieren<br />
sein. Solche Informationen sind etwa<br />
eindimensionale Muster wie sie zum Beispiel<br />
bei der Messung von Spannungsverläufen<br />
entstehen oder zweidimensionale Art<br />
wenn etwa Bilder aufgezeichnet werden. Zusätzlich<br />
zu diesen Daten zählen auch Informationen<br />
über interne und externe Sensorzustände.<br />
Zu vielen Parametern die unsere Umwelt<br />
kennzeichnen, gibt es Sensoren um diese<br />
messen.<br />
Geometrische Parameter: Winkel, Länge, Distanz,<br />
Position, Präsenz, ...<br />
59
Detlef Köntges<br />
Mechanische Parameter: Gewicht, Biegung,<br />
<strong>Dr</strong>uck, Vibration, Beschleunigung, ...<br />
Zeitparameter: Relative /absolute Zeit, Dauer<br />
Klimatische Angaben: Temperatur, Feuchtigkeit,<br />
Wind, Luftdruck<br />
Optische Parameter: Lichtintensität, Wellenlänge,<br />
Spektrum, Muster<br />
Akustische Parameter: Lautstärke, Frequenz,<br />
Muster<br />
Elektrische /Technische Parameter: Spannung,<br />
Strom, Durchfluss<br />
Chemische /Biologische /Umwelt Parameter:<br />
Ozon, Gas, pH, Radioaktivität<br />
Gesundheitsparameter: Blutdruck, Sauerstoffsättigung,<br />
Pulsrate, Hautleitfähigkeit<br />
[Bei00]<br />
4.5 Projekte, Visionen<br />
4.5.1 Smart-Its Projekt<br />
Das Smart-Its Projekt ist ein von der Europäischen<br />
Kommission und dem Schweizer Bundesministerium<br />
für Bildung und Wissenschaft<br />
finanziertes Projekt, mit dem Auftrag Alltagsgegenstände<br />
mit einer gewissen Intelligenz<br />
auszustatten. Die dort entwickelte Technologie<br />
stellt die Basis für viele weitere Projekte<br />
dar. In den folgenden Bildern werden einige<br />
dieser Elemente, zu denen Sensorplatinen,<br />
Funknetzwerkadapter und Minicomputer gehören,<br />
dargestellt.<br />
Abbildung 47: Smart-It mit Bluetooth [Gel02]<br />
60<br />
Abbildung 48: Smart-It mit RF-Modul [Gel02]<br />
Abbildung 49: Smart-It mit Display und Temperatursensor<br />
[Gel02]<br />
4.5.2 Smart-Its Friends<br />
Die Entwickler diese Projektes hatten sich<br />
die Aufgabe gestellt, dass Gegenstände miteinander<br />
eine Verbindung eingehen können<br />
und diesen bei Bedarf auch wieder lösen.<br />
Dabei sollte auf ein herkömmliches User<br />
Interface verzichtet werden, und nur der<br />
gemeinsame Kontext der Gegenstände als<br />
Auslöser für die Verbindung dienen. Dies bedeutet,<br />
wenn zwei Artefakte die gleichen vordefinierten<br />
Umweltbedingungen haben, wird<br />
eine Zusammengehörigkeit festgelegt. Dabei<br />
wurde die Bewegung als erforderliche Umwelteigenschaft<br />
betrachtet, d.h. wenn zwei
Smart-Its Friends auf die selbe Art und Weise<br />
bewegt werden, erfassen sie den jeweils<br />
anderen als Partner und lösen die Verbindung<br />
erst bei unterschiedlichen Bewegungen.<br />
Zwei solche miteinander verknüpfte Artefakte<br />
sollen, sobald sie sich aneinander<br />
annähern, wiedererkennen können und ein<br />
akustische Signal bei Trennung und Verbindung<br />
ausgeben. Die Smart-Its Friends sind<br />
aus zwei Hauptbestandteilen aufgebaut. Die<br />
Sensor- und Kommunikationsplatine stellt,<br />
mit Bewegungssensoren für zwei Richtungen<br />
und einem kleine Funkmodul für die kabellose<br />
Kommunikation, den Kontakt zur Umwelt<br />
dar. Die zweite Platine besitzt einen Prozessor<br />
samt Speicher, der die Daten der Sensoren<br />
verarbeitet und die Funkverbindung mit<br />
anderen Smart-Its Friends steuert. Die gesamte<br />
Anordnung wird über eine Batterie mit<br />
Energie versorgt, zu der unter anderem auch<br />
ein Lautsprecher und Sensoren für einen<br />
Energiesparmodus gehören. Dieser Energiesparmodus<br />
wird geschaltet sobald keine Bewegung<br />
mehr von außen auf das Artefakt<br />
einwirkt.<br />
Die Ausgaben der Bewegungssensoren werden<br />
ausgewertet und an andere Smart-<br />
Its Friends übertragen. Sobald die Bewegungsmuster<br />
zweier Smart-Its übereinstimmen<br />
wird eine Verknüpfung etabliert und gespeichert.<br />
Darauf wird die Verbindung akustisch<br />
bestätigt und sobald sich die beiden<br />
Geräte außerhalb der Reichweite ihrer Funkmodule<br />
befinden oder sie diesen Bereich<br />
wieder erreichen wird ebenfalls ein Signal<br />
ausgegeben. Die Bewegungen der beiden<br />
Elemente wird permanent verglichen und so<br />
bald sie stark voneinander abweichen, wird<br />
die Verknüpfung wieder gelöscht und mit einem<br />
akustischen Signal bestätigt.<br />
4.5 Projekte, Visionen<br />
Abbildung 50: ein Größenvergleich [Bei00]<br />
Abbildung 51: Smart-Its-Friends [Abe02]<br />
Abbildung 52: Verknüpfung durch gemeinsame<br />
Bewegung [Bei00]<br />
Eine praktische Anwendung für diese Idee<br />
wäre zum Beispiel Gegenstände wie Ohrringe<br />
oder Geldbörse und Kreditkarte damit<br />
auszustatten. Bei Bedarf würde ein Signal ertönen<br />
wenn einer der Partner weiter als erlaubt<br />
sich vom anderen entfernt.<br />
61
Detlef Köntges<br />
4.5.3 MediaCup<br />
Abbildung 53: MediaCub [Bei00]<br />
Dieses Projekt beschäftigt sich mit einer Tasse,<br />
die mit Sensoren für Temperatur, <strong>Dr</strong>uck<br />
und Bewegung ausgerüstet wurde. Außerdem<br />
verfügt die Tasse über zwei aufladbare<br />
Kondensatoren die sie mit Strom versorgen.<br />
Sie kann mit einer IrdA-Schnittstelle<br />
Verbindung zu anderen Smart-Its aufnehmen,<br />
was neben anderen Tassen auch eine<br />
Kaffeemaschine oder Positionsartefakte<br />
in Schränken oder Räumen sein können<br />
(Router). Die Nutzung dieser Tasse ist sehr<br />
vielfältig, so kann sie zum Beispiel feststellen<br />
wieviele Tassen Kaffee schon getrunken<br />
wurden und dann berechnen wieviel Koffein<br />
aufgenommen wurde. Bei Bedarf informiert<br />
sie die Kaffeemaschine darüber und<br />
diese schaltet dann auf Entkoffeinierten um.<br />
Sie kann auch an entsprechend ausgestattete<br />
Ausgabe-Smart-Its (etwa ein Armband<br />
mit Display) Informationen über das Getränk<br />
weitergeben (Ausgaben wie: wird kalt, trinken<br />
oder aber auch die Temperatur ist möglich).<br />
Sehr entscheidend ist die Fähigkeit des<br />
MediaCup-Systems, neue Artefakte einfach<br />
62<br />
zu integrieren, diese können ohne Vorwissen<br />
mit anderen Geräten aus der Umgebung<br />
kommunizieren.[Bei00]<br />
Ziel dieser Entwicklung war es Erfahrungen<br />
mit intelligenten Geräten zu machen, Vernetzungen<br />
zu testen und mit Anwendungen zu<br />
experimentieren.<br />
Abbildung 54: Architektur [Bei00]<br />
Abbildung 55: Kaffeemaschine [Bei00]
4.5.4 Ikea<br />
Am Institut für Wissenschaftliches Rechnen<br />
der ETH Zürich wurde ein Problem aufgegriffen<br />
das fast jeder kennt, nämlich der richtige<br />
Zusammenbau eines Ikeaschrankes. Niemand<br />
liest gern die Bauanleitung für ein Möbelstück,<br />
da diese langweilig oder einfach<br />
unverständlich sind. Für einen Schrank fanden<br />
die Forscher <strong>Prof</strong>essor Bernt Schiele,<br />
Stavros Antifakos und Florian Michahelles<br />
heraus, das es 44 Möglichkeiten des Zusammenbaus<br />
gibt, aber nur 8 dieser Varianten<br />
sind sicher. Um nun den Hobbybastler zu<br />
unterstützen haben die Wissenschaftler diesen<br />
Schrank mit Smart-It-Technologie ausgestattet.<br />
Die einzelne Teile des Möbel wurden<br />
mit <strong>Dr</strong>uck- und Bewegungssensoren versehen,<br />
um den Zusammenbau zu sichern.<br />
Die einzelenen Sensoren tauschen untereinander<br />
Daten aus und bestimmen so die Lage<br />
Literatur<br />
jedes Bestandteils des Schrankes. Sie sind<br />
in der Lage dem Anwender auf einem seperaten<br />
Bildschirm Tipps und Warnungen zu<br />
geben, mit dem sie über eine dratlose Verbindung<br />
in Kontakt stehen. Diese Ausgabe<br />
kann auch über farbige Lämpchen geregelt<br />
werden, die den Anwender während des Zusammenbaus<br />
leiten.[Zür02]<br />
Abbildung 56: smartes Brett [Zür02]<br />
[Abe02] Ulrich Abend: Endgeräte des Ubiquitous Computing. http://snake.cs.tuberlin.de:8081/~tom/ubig-2002,<br />
2002.<br />
[Bei00] Michael Beigl: Ubiquitäre Informationstechnologien. http://www.teco.edu/<br />
lehre/ubiqws0102, 2000.<br />
[Duy01] Manfred Duy: Bluetooth Die Zukunft kabelloser Kommunikation. www.aboutIT.<br />
de/01/25/07.html, 2001.<br />
[Gel02] <strong>Prof</strong>. Hans Gellersen: The Smart-Its Project. http://www.smart-its.org/,<br />
2002.<br />
[Gno02] <strong>Alexander</strong> Gnodtke: Stromversorgung ubiquitärer Systeme. http://snake.cs.<br />
tu-berlin.de:8081/~tom/ubig-2002, 2002.<br />
[Mat01a] Friedemann Mattern: Ubiquitous Computing - der Trend zur Informatisierung und<br />
Vernetzung aller Dinge. Informatik, 5/2001, S. 2-3.<br />
[Mat01b] Friedemann Mattern: Ubiquitous Computing - Vision und technische Grundlage.<br />
Informatik, 5/2001, S. 4-8.<br />
[Sie02] Frank Siegemund: Kontextbasierte Bluetooth-Scatternetz-Formierung in ubiquitären<br />
Systemen. http://www.inf.ethz.ch/~siegemun/publ/scatternet.<br />
pdf, 2002.<br />
[Zür02] ETH Zürich: Idiotensicherer Möbelzusammenbau. www.ethlife.ethz.ch,<br />
2002.<br />
63
5 Mobile Ad-Hoc-Metzwerke<br />
Zusammenfassung<br />
In dieser Arbeit geht es um mobile Adhoc-Netzwerke<br />
(MANET’s). Die Themen<br />
umfassen eine allgemeinere Einführung,<br />
Hardware für drahtlose Vernetzung, Routing<br />
in Ad-hoc-Netzen sowie die Einbettung<br />
in den Bereich des Ubiquitous Computing<br />
durch Vorstellung von Einsatz-<br />
Szenarien und bereits existierenden Projekten.<br />
5.1 Einleitung<br />
Netzwerke zwischen jeglicher Art von Hardware<br />
werden immer beliebter. Es gibt inzwischen<br />
fast keine Computer mehr, die nicht<br />
auf irgendeine Weise mittels eines Netzwerks<br />
untereinander kommunizieren. Diese<br />
Entwicklung wird sich noch weiter verstärken<br />
und insbesondere die drahtlosen Netze<br />
werden immer mehr Zuspruch gewinnen.<br />
Das eröffnet auch vielen anderen Geräten -<br />
den Embedded Systems, Peripheriegeräten,<br />
PDA’s und Handys - den Zugang zu den ubiquitären<br />
Netzen.<br />
Im Gegensatz zu den mehr oder weniger fest<br />
verdrahteten, stationären Netzen wird es in<br />
Zukunft vermehrt „spontane“ Netzwerke, die<br />
Ad-hoc-Netzwerke, geben, die sich automatisch<br />
konfigurieren und ohne weiteres Zutun<br />
des Benutzers Nachrichten untereinder austauschen<br />
können.<br />
Die Vision ist, beliebige Geräte, mobil oder<br />
stationär, bei sich möglicherweise ständig<br />
ändernder Topologie und gegenseitiger Erreichbarkeit<br />
bezüglich Bandbreite und Verzögerung,<br />
robust und effizient miteinander zu<br />
verbinden.<br />
4 Dynamic Host Configuration Protocol<br />
64<br />
Elmar Schoch<br />
<strong>Universität</strong> <strong>Ulm</strong><br />
Fakultät für Informatik<br />
elmar.schoch@informatik.uni-ulm.de<br />
5.2 Ad-hoc-Netzwerke<br />
Was macht Ad-hoc-Netzwerke aus? Worin<br />
unterscheiden sie sich von anderen, bekannten<br />
Netzwerktypen?<br />
Der grundlegendste Unterschied zu normalen,<br />
statischen Netzwerken besagt schon der<br />
Name: sie kommen spontan zustande, ohne<br />
eine permanente, gleichbleibende Infrastruktur.<br />
Ein weiteres Kriterium ist das autonome<br />
und adaptive Verhalten. Das Netzwerk<br />
soll sich automatisch selbst konfigurieren<br />
und neue Knoten dynamisch integrieren.<br />
Dadurch erhält man auch eine prinzipiell beliebige<br />
Skalierbarkeit. Dennoch gibt es aufgrund<br />
der Weiterleitungsproblematik Grenzen<br />
der Erweiterbarkeit (siehe Abschnitt 5.4).<br />
Diese bisher beschriebenen Charakteristika<br />
sind prinzipiell auf jedes Netzwerk, drahtgebunden<br />
oder drahtlos, anwendbar. So gibt<br />
es ja zum Beispiel für die automatische<br />
Vergabe von IP-Adressen und der TCP/IP-<br />
Konfiguration von Rechnern das etablierte<br />
DHCP 4 -Protokoll, das gewisse Teile eines<br />
Netzwerks leicht erweiterbar und bezüglich<br />
der Konfiguration anpassbar macht. DHCP<br />
benötigt aber einen zentralen Server; ein<br />
DHCP-Netz ist also nicht komplett autonom.<br />
5.2.1 Mobile Ad-hoc-Netzwerke<br />
Das Thema dieser Arbeit aber sind mobile<br />
Ad-hoc-Netzwerke, bei denen die Geräte frei<br />
beweglich sind. Aus dieser Mobilität und der<br />
deswegen erforderlichen, drahtlosen Kommunikation<br />
ergeben sich weitere Herausforderungen,<br />
denen bei der Entwicklung der
Kommunikationsprotokolle Rechnung getragen<br />
werden muss [Mac99].<br />
Dynamische Netzwerktopologie<br />
Durch die Anforderung, dass sich Teilnehmer<br />
(im MANET-Kontext in der Regel als<br />
Knoten bezeichnet) jederzeit beliebig weit<br />
und beliebig schnell bewegen können, ändert<br />
sich die Netzwerktopologie, also die Anordnung<br />
und die Erreichbarkeit der Knoten<br />
untereinander potentiell permanent. Es können<br />
zu jedem Zeitpunkt Verbindungen zu benachbarten<br />
Knoten abreißen oder entstehen,<br />
wenn Knoten in die direkte Reichweite kommen.<br />
Zusätzlich müssen Verbindungen nicht<br />
notwendigerweise bidirektional sein, weil es<br />
durchaus möglich ist, das ein Knoten einen<br />
anderen Knoten erreicht, umgekehrt aber<br />
nicht.<br />
Übertragungskapazität<br />
und Verbindungsqualität<br />
Grundsätzlich gilt momentan, dass die<br />
maximale Bandbreite der „wireless links“<br />
der drahtgebundener Netzwerktechnologien<br />
deutlich unterlegen ist. Demzufolge<br />
ist die technologisch verfügbare Übertragungskapazität<br />
in mobilen Netzen äußerst<br />
beschränkt. Die verschiedenen, nutzbaren<br />
Technologien werden in Abschnitt 5.3 näher<br />
betrachtet.<br />
Die Dynamik des Netzwerks hat außerdem<br />
zur Folge, dass sich die Qualität der drahtlosen<br />
Verbindungen zwischen zwei benachbarten<br />
Knoten jederzeit ändern kann, wenn<br />
sich die beiden Knoten aufeinander zu oder<br />
voneinander weg bewegen. Je kürzer der Abstand,<br />
umso höher wird die Feldstärke und<br />
umso besser ist der gegenseitige Empfang<br />
- gleichbleibende Sendeleistung vorausgesetzt.<br />
Aber nicht nur der Parameter der Distanz<br />
zwischen Knoten und die eingesetzte Technik<br />
sorgt für begrenzte Übertragungskapazitäten.<br />
Allein die Mobilität verringert die<br />
Bandbreite noch weiter, weil Interferenzen<br />
und Störungen, wie Abschattung, Beugung,<br />
Streuung und Reflexion der Signale, die<br />
durch die Bewegung entstehen, eine schnel-<br />
5.2 Ad-hoc-Netzwerke<br />
le, korrekte Übertragung verhindern. Hauptsächlich<br />
dadurch entsteht das erwähnte Problem<br />
der asymmetrischen, unidirektionalen<br />
Verbindungen.<br />
Das alles führt dazu, dass eine nicht unerhebliche<br />
Anzahl von Paketen verloren gehen.<br />
Speziell bei der für Anwendungen entscheidenden<br />
End-to-End-Qualität einer Verbindung<br />
spielt das Thema Quality of Service<br />
(QoS) gerade in MANETs eine wichtige Rolle.<br />
Wegfindung und Weiterleitung<br />
Jeder einzelne Knoten hat je nach verwendeter<br />
Technologie nur eine bestimmte Reichweite,<br />
in der er direkt mit anderen Knoten<br />
kommunizieren kann. Um mit weiter entfernten<br />
Stationen Verbindung aufnehmen zu können,<br />
ist es notwendig, dass andere, eigentlich<br />
unbeteiligte Knoten, die Daten zum Empfänger<br />
weiterleiten. Deshalb muss jeder Knoten<br />
gleichzeitig auch Router-Funktion haben,<br />
oft auch als Relaying bezeichnet.<br />
1<br />
Sender<br />
2 3<br />
drahtlose Verbindung<br />
mobiler Knoten (mit Reichweite)<br />
4<br />
Empfänger<br />
Abbildung 57: Weiterleitung in MANET’s<br />
Unter den Gesichtspunkten der dynamischen<br />
Topologie und der variablen Verbindungsqualitäten<br />
muss ein Paket durch das<br />
Netzwerk übertragen werden. Wie wir bereits<br />
gesehen haben, ergeben sich für das Routing<br />
in MANETs verschiedenste Fragestellungen:<br />
Wie findet ein Paket überhaupt seinen<br />
Weg? Was passiert bei Abbruch einer<br />
Route? Wie verhindert man lokale Engpässe?<br />
65
Elmar Schoch<br />
Bei mobilen Ad-hoc-Netzwerken unterscheidet<br />
man zusätzlich noch isolierte Netze und<br />
solche mit Gateways in statische Netze. MA-<br />
NETs sind momentan allerdings nicht dafür<br />
gedacht, dass sie auch als Backbone<br />
für durchwandernde Pakete benutzt werden<br />
können.<br />
Das alles ist zur Zeit Hauptgegenstand der<br />
Forschung in diesem Bereich, und es gibt<br />
bereits mehrere Verfahren und Algorithmen,<br />
wie man die Probleme lösen könnte. Mehr<br />
dazu im Abschnitt 5.4.<br />
Energieversorgung<br />
In der Regel sind die für die Nutzung in MA-<br />
NETs designierten, mobilen Geräte klein und<br />
leicht, und nicht an eine dauerhafte Stromversorgung<br />
angeschlossen, sondern werden<br />
batterie- oder akku-betrieben. Die vorhandene<br />
Energie ist also begrenzt und sollte sparsam<br />
benutzt werden. Deshalb ist die Tatsache,<br />
dass Knoten auch als Relay-Station<br />
für Verbindungen von anderen Knoten arbeiten,<br />
etwas problematisch, da ein Relay-<br />
Knoten ja Aufwand für andere Knoten betreiben<br />
muss. Das betrifft vor allem die dazu benötigte<br />
Energie und die für ihn maximal vorhandene<br />
Übertragungskapazität. Als Router<br />
muss er Teile seiner beschränkten Energie<br />
und Übertragungskapazität für Verbindungen<br />
aufwenden, die er selbst gar nicht effektiv<br />
nutzt; es sollte also ein Ziel für ein MANET<br />
sein, diesen Aufwand möglichst gerecht zu<br />
verteilen und zu entscheiden, ob ein Knoten<br />
als Relay dienen kann oder nicht.<br />
Sicherheitsaspekte<br />
Nicht zuletzt stellt sich gerade für MANETs<br />
die Frage nach der Sicherheit. Aufgrund des<br />
drahtlosen Mediums können Nachrichten<br />
von jeder Station in der Übertragungsreichweite<br />
empfangen werden, genauso wie ein<br />
böswilliger Knoten beliebig korrupte Nachrichten<br />
verschicken oder das Netz mit unsinnigen<br />
Nachrichten verstopfen kann. Es ergeben<br />
sich drei zentrale Punkte:<br />
Datensicherheit und Vertraulichkeit<br />
Die Sicherheit der übertragenen Daten be-<br />
66<br />
trifft mehrere Ebenen. Auf unterster Ebene<br />
sollen natürlich Pakete exakt so beim Emfänger<br />
ankommen, wie sie der Sender abgeschickt<br />
hat. Das kann beispielsweise mit<br />
CRC-Prüfsummen erledigt werden. Auf höheren<br />
Ebenen betrifft die Datensicherheit die<br />
Nutzdaten, die nicht von Eindringlingen oder<br />
unberechtigten Knoten mitgelesen werden<br />
sollen. Diese passive Art der Sicherheitsverletzung<br />
kann zum Beispiel verhindert werden,<br />
in dem Nutzdaten verschlüsselt zwischen<br />
Sender und Empfänger übertragen<br />
werden oder ein Knoten innerhalb eines Virtual<br />
Private Networks agiert.<br />
Sicherheit des Netzwerks<br />
Bei der Gefährung der Netzwerkstruktur handelt<br />
es sich um einen aktiven Eingriff. Ein<br />
böswilliger Knoten kann beispielsweise Routen<br />
verfälschen oder andere Signale durch<br />
eigene überstrahlen. Aufgrund der bewußt<br />
offenen Architektur eines MANETs, und insbesondere<br />
deswegen, weil jeder Knoten<br />
auch als Router tätig ist, ergeben sich hier<br />
etliche mögliche Angriffspunkte. Gleichzeitig<br />
ist diese dezentrale Architektur aber auch ein<br />
Vorteil gegenüber jedem zentral organisierten<br />
Netz, da es keinen „singe-point-of-failure“<br />
gibt.<br />
Sicherheit der Einzelknoten<br />
Da jeder Einzelknoten im MANET als Router<br />
eine nicht unwichtige Rolle spielt, kann<br />
ein Denial-of-Service-Angriff auf ausgewählte<br />
Einzelknoten unter Umständen die Funktionsfähigkeit<br />
des ganzen Netzwerks lahmlegen.<br />
Da sich die Knoten konzeptionell aber<br />
ständig bewegen, ist dies allerdings weniger<br />
ein Problem wie in statischen Netzen.<br />
5.3 Netzwerk-Technik<br />
Die Netzwerktechnik in mobilen Ad-Hoc-<br />
Netzwerken ist drahtlos. Das ist die Basiseigenschaft,<br />
die Voraussetzung ist, wenn<br />
mobile Geräte miteinander kommunizieren<br />
möchten. Realisiert man das Routing auf IP-<br />
Layer, wie in statischen Netzen auch, ist es
zunächst einmal egal, welche spezielle Technologie<br />
mit all ihren spezifischen Eigenschaften<br />
eingesetzt wird. Es ist sogar auch gut<br />
denkbar, dass mobile Geräte mehrere Technologien<br />
einsetzen, über die sie ereichbar<br />
sind. So gibt es ja auch heute schon PDAs<br />
oder Handys im Handel, die sowohl Infrarot<br />
als auch Bluetooth unterstützen.<br />
5.3.1 Vorhandene Technologien<br />
Überblick<br />
Zum jetzigen Zeitpunkt gibt es schon etliche<br />
Technologien, die drahtlose Verbindungen<br />
ermöglichen [Sch02] [Kar01]. Die allererste<br />
Technik war wohl Infrarot-Licht. Aufgrund der<br />
geringen Übertragungsrate und der notwendigen<br />
Sichtverbindung zwischen Sender und<br />
Empfänger ist Infrarot aber eher für direkte<br />
low-level Verbindungen bei wenigen Metern<br />
Entfernung geeignet. Der IrDA5-Standard erlaubt<br />
beispielsweise nur einen Abstand von<br />
maximal 1,5 Metern und eine auf 30<br />
genaue<br />
Ausrichtung der Transceiver.<br />
Daneben existieren diverse Funksysteme,<br />
die im Vergleich zu IrDA den Vorteil haben,<br />
dass keine Sichtverbindung erforderlich<br />
und Broadcast möglich ist. Der europäische<br />
Schnurlos-Telefon-Standard DECT ist<br />
vermutlich in den meisten Haushalten präsent;<br />
mit DECT können aber auch Daten<br />
übertragen werden. Eine frühe, reine Datenfunktechnik<br />
war HomeRF. Es konkurriert zum<br />
heute verbreiteten IEEE 802.11b-Standard,<br />
arbeitet ebenfalls im lizenzfreien ISM 6 -Band<br />
bei 2,4 GHz und unterstützt eine Datenrate<br />
von 1-2 MBit/s bei einer maximalen Reichweite<br />
von 50 Metern in Gebäuden.<br />
Eine weitere Alternative stellen die<br />
Standards Wireless ATM, HIPER-<br />
LAN/HIPERLINK dar. HIPERLAN kann bei<br />
5 GHz Datenraten von 24 MBit/s erreichen,<br />
HIPERLINK bietet 155 MBit/s auf Frequenzen<br />
bei 17 GHz. Obwohl HIPERLAN einige<br />
interessante Eigenschaften wie Multi-Hop<br />
5 Infrared Data Association<br />
6 Industrial, Scientific, Medical<br />
5.3 Netzwerk-Technik<br />
auf MAC-Layer und eine dezentrale Ad-hoc-<br />
Struktur bietet, hat es keine praktische Relevanz,<br />
da keine Produkte verfügbar sind.<br />
Bluetooth<br />
Bluetooth wurde 1998 von einer Special Interest<br />
Group (SIG) der Firmen Ericsson, IBM,<br />
Intel, Nokia und Toshiba ins Leben gerufen<br />
und die erste Spezifikation 1999 vorgestellt.<br />
Es handelt sich dabei um eine Nahbereichsfunktechnik,<br />
mit der in mehreren <strong>Prof</strong>ilen Daten,<br />
Sprache und auch eine Kombination daraus<br />
übertragen werden kann. Bluetooh verfolgt<br />
von Grund auf die Prinzipien eines Adhoc-Netzwerks.<br />
Ziele<br />
Das primäre, naheliegendste Ziel ist die<br />
drahtlose Anbindung von Peripheriegeräten<br />
und die drahtlose Verbindung von mobilen<br />
Geräten wie PDA’s und Handys. Auf diese<br />
Weise ist es beispielsweise möglich, mit<br />
dem PDA seine E-Mails zu lesen, die über<br />
die Internet-Verbindung, die das Handy aufgebaut<br />
hat, abgerufen werden. Das Handy<br />
kann dabei in der Tasche bleiben - es kommuniziert<br />
ohne lästige Kabel per Bluetooth<br />
mit dem PDA. Das ganze wäre weniger praktisch,<br />
wenn Bluetooth sich nicht selbst konfigurieren<br />
würde - ein weiteres Ziel. Wie bereits<br />
in der Einleitung erwähnt, kommt es bei<br />
mobilen Geräten auch auf die sparsame Benutzung<br />
von Energie an. Diesem Problem<br />
wurde im Bluetooth-Standard dadurch Rechnung<br />
getragen, dass Geräte sich in einen<br />
Energiesparmodus schalten können. Wichtig<br />
für den Erfolg am Markt ist nicht zuletzt auch<br />
der Preis, weshalb beim Entwurf auf die Realisierung<br />
einer kostengünstigen, integrierten<br />
1-Chip-Lösung geachtet wurde. Dieses Design<br />
kommt gleichzeitig auch dem Einsatz in<br />
kleinen Geräten zugute.<br />
Technik<br />
Auch Bluetooth funkt bei 2,4 GHz im ISM-<br />
Band und teilt es in 79 Kanäle mit der Breite<br />
67
Elmar Schoch<br />
von 1 MHz auf. Da es in diesem Frequenzraum<br />
zu Störungen durch andere Benutzende<br />
kommen kann, betreibt Bluetooth das sogenannte<br />
„Frequency Hopping“ mit einer Frequenz<br />
von 1600 Hz.<br />
Maximale Übertragungsrate ist 1 MBit/s, wobei<br />
es verschiedene <strong>Prof</strong>ile für verschiedene<br />
Anforderungen gibt: synchrone Sprachdienste<br />
mit 64 kBit, asynchroner Datenkanal mit<br />
ca. 700 kBit etc. .<br />
Grundsätzlich ist Bluetooth für Ad-hoc-<br />
Piconetze mit einem Funkbereich von 10 Metern<br />
vorgesehen und arbeitet dann mit einer<br />
Sendeleistung von 1 mW. Zusätzlich existiert<br />
aber auch eine Variante mit einer Sendeleistung<br />
von 100 mW, die dann eine Reichweite<br />
von ca. 100 Metern hat.<br />
Netzwerkstruktur<br />
Die aktiven Knoten sind in sogenannten Piconets<br />
organisiert, wobei ein Piconet maximal<br />
8 Teilnehmer haben kann, von denen<br />
genau ein Knoten der „Master“ ist. Zusätzlich<br />
können sich einem Piconet noch passive<br />
Knoten anschließen, die nur den Datenstrom<br />
lesen. Die Knoten in einem Piconetz<br />
haben gemeinsam, dass sie die selbe Hüpfsequenz<br />
zwischen den Kanälen verwenden,<br />
die der Master bestimmt.<br />
Master<br />
Slave<br />
Bridge<br />
Piconet<br />
Abbildung 58: Bluetooth Piconet & Scatternet<br />
Ein Scatternet ergibt sich durch eine Gruppe<br />
von Piconetzen; die Verbindung zwischen<br />
den Piconetzen kommt durch Knoten zustan-<br />
68<br />
de, die ständig zwischen Piconetzen wechseln<br />
und so eine Brücke zwischen diesen<br />
bilden. Es ist sowohl möglich, dass ein solcher<br />
Brückenknoten in einem Piconetz Master<br />
und im anderen Piconetz Slave ist, als<br />
auch, dass eine Bridge in beiden Piconetzen<br />
Slavestatus hat. Bluetooth ist dahingehend<br />
optimiert, dass 10 Piconetze parallel in<br />
einem Scatternet betrieben werden können.<br />
Visionen & Szenarien<br />
Das Hauptziel ist auch die Hauptvision: Bluetooth<br />
soll Standard in der Anbindung von Peripheriegeräten<br />
und mobilen Agenten an stationäre<br />
Rechner werden. Geräte sollen ohne<br />
Kabelverbindungen mit dem PC beziehungsweise<br />
einer Feststation oder untereinander<br />
Daten austauschen können.<br />
Durch die Verfügbarkeit eines kostengünstigen,<br />
universellen Systems zur drahtlosen<br />
Kommunikation in geringen Reichweiten entstehen<br />
aber Möglichkeiten, die vom simplen<br />
Datenaustausch konzeptionell weit entfernt<br />
und eher im Bereich des Ubiquitous Computing<br />
angesiedelt sind. Beispielszenarien:<br />
Intelligenter Einkauf<br />
Bluetooth könnte ermöglichen, dass man auf<br />
seinem PDA die aktuellen Angebote im Supermarkt<br />
abruft, genauso wie man weitere<br />
Informationen zu bestimmten Produkten bekommen<br />
könnte, wenn man gerade direkt vor<br />
dem Regal steht.<br />
Berührungslose Bezahlungssysteme<br />
Man könnte durch die Kommunikation des<br />
Handys oder des PDAs mit Kassensystemen,<br />
Fahrkartenautomaten, etc. ohne Kleingeld<br />
und berührungslos bezahlen. Ein solches<br />
System könnte bisherige Zahlungsmöglichkeiten<br />
per EC-Karte, Geldkarte oder<br />
ähnlichem in einem einzigen, mobilen Gerät<br />
zusammenfassen.<br />
Wireless Personal Area Networks (WPANs)<br />
Nicht zuletzt ist Bluetooth für sogenannte Wireless<br />
Personal Area Networks geeignet, die<br />
gewissermaßen ein System vernetzer Geräte<br />
am und um den Körper herum darstellen.<br />
Ein Ansatz zu einem solchen WPAN ist beispielsweise<br />
ein drahtloses Headseat, das per<br />
Bluetooth mit dem Handy kommuniziert.
IEEE 802.11 (WLAN)<br />
Die WLAN-Technik ist die Datenfunktechnik,<br />
die derzeit am meisten im Blickpunkt steht.<br />
Auf dem Markt ist eine Vielzahl von Produkten<br />
verfügbar, die Kosten dafür sind überschaubar<br />
geworden. Vermehrt werden in Unternehmen,<br />
aber auch in öffentlichen Gebäuden<br />
sogenannte „Hotspots“ aufgebaut, also<br />
lokal begrenzte, mit IEEE 802.11-Technik<br />
ausgestattete Bereiche, in denen man drahtlos<br />
auf ein Netzwerk Zugriff hat. Aufgrund<br />
der mittleren Reichweiten, der Kostentransparenz<br />
und dem großen Angebot, sowie der<br />
Möglichkeit, WLAN-Adapter in einem Ad-<br />
Hoc-Modus zu betreiben, eignet sich dieser<br />
Standard auch gut für MANETs und das Ubiquitous<br />
Computing.<br />
Technik<br />
Die erste Version des IEEE 802.11-<br />
Standards umfasst drei verschiedene Möglichkeiten,<br />
Daten drahtlos zu übertragen:<br />
zwei mit Funkübertragung im 2,4 GHz ISM-<br />
Band, eine mittels Infrarot bei Wellenlängen<br />
von 850-950 nm. Die zwei Varianten<br />
per Funk unterscheiden sich durch die<br />
Übertragungsweise; die erste verwendet ein<br />
Frequency-Hopping-Verfahren, die andere<br />
ein Spreizcode-Verfahren (Direct Sequence<br />
Spread Spectrum). Beide bieten Übertragunsgraten<br />
von 1-2 MBit/s.<br />
Heute gibt es mehrere Erweiterungen des<br />
Standards - die heute hauptsächlich benutzten<br />
Geräte sind 802.11b-konform. IEEE<br />
802.11b kann maximal 11 MBit/s Datenrate<br />
erreichen, eine andere Erweiterung, wie<br />
802.11b auch auf dem 2,4 GHz-Band, bringt<br />
es auf über 20 MBit/s. Diese und andere<br />
Erweiterungen sind heute allerdings (noch)<br />
nicht relevant. So gibt es beispielsweise noch<br />
802.11a, eine Variante, die im ISM-Band bei<br />
5,7 GHz arbeitet und Übertragungsraten von<br />
54 MBit/s bieten soll und erst vor kurzem in<br />
Deutschland zugelassen wurde. Auch dazu<br />
gibt es in Form von 802.11h schon eine Abwandlung<br />
mit noch höheren Datenraten. Im<br />
Rahmen des 802.11 sind aber auch Erweiterungen<br />
im Bereich der Quality of Service und<br />
5.3 Netzwerk-Technik<br />
des Power Managements (802.11e), sowie<br />
im Bereich Sicherheit und Authentifizierung<br />
(802.11i) zusammengefasst.<br />
Die heute gebräuchliche Version bietet<br />
Reichweiten von 50 - 300 Metern, mit speziellen<br />
Antennen sind auch Entfernungen von<br />
mehreren Kilometern möglich.<br />
Netzwerkstruktur<br />
Die Zugangskomponenten zu einem WLAN<br />
nach 802.11 bieten grundsätzlich zwei Betriebsarten:<br />
den Infrastucture-Modus und<br />
den Ad-hoc-Modus. Beim Infrastructure-<br />
Modus wird festgelegt, dass sich der drahtlose<br />
Client am einem Accesspoint anmeldet<br />
und dadurch eine Verbindung in die feste<br />
Infrastruktur erhält. Mit einer drahtlosen<br />
Schnittstelle auf der einen und einer drahtgebundenen<br />
Schnittstelle, meistens Ethernet,<br />
auf der anderen Seite, bilden Accesspoints<br />
„Brücken“ zwischen der drahtlosen<br />
und der drahtgebundenen Infrastruktur. Verbindungen<br />
zwischen zwei mobilen Geräten<br />
im Infrastructure-Modus, die sich im gleichen<br />
Einflussbereich eines Accesspoints (BSS,<br />
Basic Service Set) befinden, aber auch technisch<br />
direkt untereinander kommunizieren<br />
könnten, bleibt nur der Weg über den Accesspoint.<br />
Accesspoint<br />
Mobiler Knoten<br />
Abbildung 59: IEEE 802.11<br />
Infrastuktur-Modus<br />
Mobiler Knoten<br />
Wenn größere Bereiche mit einer Funkversorgung<br />
abgedeckt werden sollen, müssen<br />
mehrere Accesspoints installiert und ins statische<br />
Netz integriert werden. Die mobilen<br />
Clients können dann je nach Erreichbarkeit<br />
Roaming zwischen Accesspoints betreiben.<br />
69
Elmar Schoch<br />
Der zweite Modus, der Ad-hoc-Modus, bietet<br />
den Clients die Möglichkeit, ohne jede andere<br />
Infrastruktur direkt miteinander Kontakt<br />
aufzunehmen.<br />
Mobiler Knoten<br />
Mobiler Knoten<br />
Abbildung 60: IEEE 802.11 Ad-hoc-Modus<br />
Der IEEE 802.11b-Standard hat inzwischen<br />
eine weite Verbreitung, wird allerdings meist<br />
im Infrastructur-Modus betrieben.<br />
Für die Benutzung von IEEE 802.11(b)<br />
in MANETs spielt auch die MAC-Layer-<br />
Realisierung eine Rolle. Dort ist vorgesehen,<br />
dass eine Übertragung durch die Zielstation<br />
mit einem Acknowledge bestätigt werden<br />
muss. Auf diese Weise sind aber nur bidirektionale<br />
Links möglich, was für ein Routingprotokoll<br />
eine gewisse Vereinfachung darstellt,<br />
weil Routen somit ebenfalls bidirektional<br />
sind. Ein Problem stellt noch die Sicherheit<br />
dar. Der aktuelle Ansatz in Form von<br />
WEP (Wired Equivalent Privacy), der den<br />
Datenverkehr mit 40 bzw. 128 Bit verschlüsselt,<br />
hat sich als nicht besonders zuverlässig<br />
erwiesen.<br />
5.3.2 Zukünftige Möglichkeiten<br />
In Zukunft werden die versteckten, winzigen<br />
Rechner überall zu finden sein und kleine,<br />
aber feine Aufgaben verrichten. Für Ubiquitous<br />
Computing bietet es sich daher an,<br />
dass sich jede Komponente einfach mit anderen<br />
verständigen kann, ohne vorher eine<br />
Einrichtung zu vollziehen. Das ist genau die<br />
Domäne der mobilen Ad-hoc-Netzwerke. Als<br />
Kommunikationskanäle bieten sich selbstverständlich<br />
die Funktechnologien an, wie in<br />
den vorhergehenden Abschnitten beschrieben.<br />
Aber es wird auch Möglichkeiten für die<br />
ad-hoc-Übertragung von Daten geben, die<br />
aus heutiger Sicht recht ungewöhnlich sind.<br />
70<br />
Wearable Networks<br />
Beim Begriff der „Wearable Networks“ handelt<br />
es sich um in Stoffe eingewobene, leitfähige<br />
Fasern. Auf diese Weise können insbesondere<br />
in sogenannten Personal Area Networks<br />
Daten übertragen werden. So wurden<br />
beispielsweise schon Hosenträger als Datenbus<br />
verwendet [Bei02].<br />
Body-Networks<br />
Die Body-Networks bieten die Möglichkeit,<br />
Daten über den menschlichen Körper zu<br />
übertragen. Im Rahmen eines Projekts des<br />
MIT Media Lab und IBM wurden auf diese<br />
Weise per Handschlag die jeweiligen elektronischen<br />
Visitenkarten der Personen ausgetauscht<br />
und beim Gegenüber gespeichert.<br />
Die im Versuch erreichte Übertragunsrate<br />
entsprach der eines 2400 Baud-Modems,<br />
theoretisch sollen 400 kBit möglich sein.<br />
Abbildung 61: Visitenkartenübertragung<br />
bei Berührung<br />
Surface Networks<br />
Als „Surface Networks“ bezeichnet man<br />
die Möglichkeit, durch Oberflächen respektive<br />
spezielle Materialien von Oberflächen,<br />
wie eine Tischplatte, Daten zu übertragen.<br />
So könnten möglicherweise Gegenstände<br />
auf einem Schreibtisch Nachrichten austauschen.
5.4 Routing in mobilen Ad-Hoc-Netzen<br />
5.4.1 Besondere Aspekte<br />
Routing in MANETs dient der internen 7 Weiterleitung<br />
von Daten zwischen Knoten, die<br />
nicht direkt miteinander kommunizieren können,<br />
über andere, erreichbare Knoten. Dass<br />
dieses Vohaben, das in statischen Netzwerken<br />
kein allzu großes Problem darstellt, in<br />
MANETs nicht ganz so trivial ist, liegt an den<br />
Charakteristika dieses Netzwerktyps und seinen<br />
teilnehmenden Geräten. Die bereits in<br />
Abschnitt 5.2.1 beschriebenen Herausforderungen<br />
haben einen konkreten Einfluss auf<br />
den Entwurf des Routing-Systems:<br />
Verteiltheit und Skalierbarkeit<br />
Es gibt keine globale Sicht der Topologie,<br />
jeder Knoten muss aufgrund<br />
der ihm zur Verfügung stehenden Informationen<br />
entscheiden, über welchen<br />
Nachbarn Daten weitergeleitet werden<br />
sollen. Das System wird nicht zentral<br />
administriert, es können jederzeit neue<br />
Knoten aufgenommen werden, zu denen<br />
es auch Routen geben muss.<br />
dynamische Netzwerktopologie<br />
Da sich die Verbindungen zwischen<br />
Knoten permanent ändern können,<br />
muss auf Verbindungsabbrüche reagiert<br />
werden und neue, möglicherweise<br />
effektivere Verbindungswege in das<br />
Routing einbezogen werden. Gleichzeitig<br />
muss das Routing-Protokoll sicherstellen,<br />
dass keine zirkulären Routen<br />
entstehen können.<br />
asymmetrische Verbindungen<br />
Es kann Routen geben, die nur in eine<br />
Richtung funktionieren, weil Verbindungen<br />
zwischen Knoten unidirektional<br />
sein können. Für den Rückweg muss<br />
5.4 Routing in mobilen Ad-Hoc-Netzen<br />
gegebenenfalls eine andere Route gefunden<br />
werden.<br />
Interferenzen und Störungen aufgrund<br />
der Nutzung des Funkmediums<br />
Möglicherweise steht eine bestimmte<br />
Route temporär nicht mehr zur Verfügung,<br />
obwohl sich die Netzwerktopologie<br />
nicht geändert hat, weil beispielsweise<br />
eine Interferenz aufgrund der<br />
Sendeaktivität anderer Stationen entsteht.<br />
sparsamer Umgang mit Energie<br />
Der Aufwand, der für die Weiterleitung<br />
einer Nachricht betrieben werden<br />
muss, kostet den Relay-Knoten Energie.<br />
Es könnte sinnvoll sein, Stationen<br />
mit „vollem Akku“ als Router zu benutzen.<br />
Ebenso sollte die Route-Discovery<br />
nicht aktiv, sondern „On demand“ geschehen,<br />
da sonst zu viel Energie und<br />
Bandbreite allein für das Routing verloren<br />
ginge.<br />
besondere Anforderungen an die Sicherheit<br />
Es ist leicht möglich, Routing-<br />
Nachrichten umzulenken oder zu verfälschen,<br />
insbesondere weil die physikalische<br />
Sicherheit aufgrund der Nutzung<br />
eines drahtlosen Mediums fehlt.<br />
5.4.2 Allgemeine Verfahren<br />
Es existieren verschiedene, grundlegende<br />
Ansätze, Routing-Informationen aufzubauen.<br />
Link State<br />
Der Ansatz besteht darin, dass jeder Knoten<br />
Informationen über den Zustand seiner Verbindungen<br />
zu seinen Nachbarn 8 durch Fluten<br />
9 im Netz verbreitet. So erfährt jeder Knoten<br />
von jedem anderen Knoten im Netz, wel-<br />
7 Man geht davon aus, dass nur innerhalb des MANETs geroutet werden muss, und keine Pakete das MANET<br />
von einem Ende zu einem anderen Ende passieren. Es besteht aber die Möglichkeit eines Gateways zu einem<br />
Festnetz.<br />
8 Nachbarn bezeichnen im MANET-Kontext die Stationen, die ein Teilnehmer direkt per Funkverbindung erreicht<br />
9 Jeder Knoten sendet eine empfangene Nachricht wiederum an alle seine Nachbarn, bis alle Knoten im Netz sie<br />
einmal bekommen haben<br />
71
Elmar Schoch<br />
che Verbindungen diese haben. Auf diese<br />
Weise kann jeder einzelne Knoten die gesamte<br />
Netzwerktopologie generieren. Bei jeder<br />
Änderung der direkten Verbindungen eines<br />
Knoten sendet dieser seine Zustandsinformationen<br />
erneut, und die anderen können<br />
daraus ihre lokale Topologie anpassen. Die<br />
Erstellung einer Route ist mit dieser Verfahrensweise<br />
dann natürlich sehr einfach - jeder<br />
Knoten kann die komplette Route mittels<br />
eines graphentheoretischen Algorithmus’ direkt<br />
auf seinen lokalen Topologieinformationen<br />
ermitteln und die Daten an den entsprechenden<br />
Nachbarn senden.<br />
Wie aus den bisherigen Betrachtungen klar<br />
ersichtlich, erfordert diese Vorgehensweise<br />
bei für MANETs typischen permanenten Topologieänderungen<br />
viel zu viel Aufwand an<br />
Netzwerkverkehr. Außerdem ist klar, dass die<br />
Topologie nicht zu jedem Zeitpunkt aktuell<br />
sein kann. Das liegt zum einen daran, dass<br />
ein Knoten nur in bestimmten Intervallen seine<br />
Nachbarschaft ermitteln wird und zum anderen,<br />
dass es eine gewisse Zeit dauert, bis<br />
das Fluten beendet ist, also bis die Information<br />
alle Knoten im Netz erreicht hat. Speziell<br />
in größeren Ad-hoc-Netzen ist dann auch<br />
die Menge an Protokolldaten zu hoch und die<br />
Dauer des Flutens zu lange.<br />
Link State, in Festnetzen mit dem OSPF 10 -<br />
Algorithmus weit verbreitet, macht in MA-<br />
NETs deswegen keinen Sinn. Erst als reaktive<br />
Variante in Form des DSR-Protokolls (siehe<br />
Abschnitt 5.4.3 kann eine Art Link-State-<br />
Verfahren trotzdem benutzt werden.<br />
Distance Vector<br />
Für Distance-Vector-Algorithmen speichert<br />
jeder einzelne Knoten für jedes Ziel im Netz<br />
und jeden seiner direkten Nachbarn die Kosten<br />
dieses Weges. Wenn Daten zur Weiterleitung<br />
anstehen, leitet der Knoten diese an<br />
denjenigen Nachbarn weiter, bei dem die Kosten<br />
für den Weg zum Ziel der Daten am geringsten<br />
sind.<br />
Für die Verbreitung der benötigten Informationen<br />
senden die einzelnen Knoten regel-<br />
10 Open Shortest Path First<br />
72<br />
mäßig die aus ihrer Sicht kürzesten Wege zu<br />
Zielen (also der Weg mit den geringsten Kosten<br />
pro Ziel) an ihre Nachbarn und propagieren<br />
Änderungen in ihren Nachbarschaftsbeziehungen.<br />
In diesem Fall ist also keine globale Sicht auf<br />
die ganze Topologie des Netzwerks notwendig.<br />
Jede Routing-Entscheidung basiert auf<br />
dem Ziel der Daten und über welchen Nachbarn<br />
dieses Ziel am „kostengünstigsten“ erreicht<br />
wird. Auf diese Weise muss sich jeder<br />
Knoten nur mit seinen nächsten Nachbarn<br />
über die Routen austauschen, das Netzwerk<br />
muss nicht mit Protokollinformationen geflutet<br />
werden.<br />
Ein Nachteil an der Vorgehensweise liegt<br />
darin, dass es mangels einer globalen Sicht<br />
auf die Topologie unter Umständen zu Kreisen<br />
in Routen kommen kann. Deswegen<br />
werden bei Protokollen dieser Klasse den<br />
Daten Sequenznummern beigefügt, um weiterzuleitende<br />
Pakete gegebenenfalls als solche<br />
zu erkennen, die „im Kreis“ gelaufen<br />
sind.<br />
Proaktives Routing (Table-driven)<br />
Der zentrale Punkt bei der Unterscheidung<br />
proaktiver und reaktiver Wegfindung ist der<br />
Zeitpunkt, wann Routen ermittelt werden. Bei<br />
proaktivem Vorgehen werden Wege gesucht<br />
und evaluiert, bevor ein Weg tatsächlich benötigt<br />
wird. Jeder Knoten hält für jeden Zielknoten<br />
im Netz eine Route bereit. Das hat<br />
den Vorteil, dass Daten bei Bedarf sofort<br />
einzig durch Auslesen der Route für den<br />
entsprechenden Zielknoten übertragen werden<br />
können. Im Endeffekt erhält man für die<br />
Übertragung also geringe Verzögerungszeiten.<br />
Allerdings wird auch schnell deutlich, warum<br />
proaktives Routing in MANETs problematisch<br />
ist. Es wird Übertragungskapazität für<br />
die Ermittlung und Pflege, sowie Speicher<br />
für die Vorhaltung von Wegen benötigt, die<br />
möglicherweise niemals tatsächlich benutzt<br />
werden. Da zudem die Pflege der Routen in
dynamischen Topologien grundsätzlich aufwendig<br />
ist, entsteht hier wie bei Link State-<br />
Verfahren ein für die beschränkten Bandbreiten<br />
in MANETs zu hoher Kommunikationsoverhead.<br />
Reaktives Routing (On-Demand)<br />
Im Gegensatz zu proaktivem Routing werden<br />
beim reaktiven Verfahren die Wege erst ermittelt,<br />
wenn wirklich Daten zum Senden vorliegen<br />
(On-Demand). Die Vor- und Nachteile<br />
sind logischerweise orthogonal zu denen<br />
des proaktiven Routings. Die höhere Verzögerung<br />
durch die Ermittlung einer Route<br />
vor dem Sendebeginn der Daten ist offensichtlich.<br />
Es ist daher ein wichtiger Punkt für<br />
entsprechende Protokolle, möglichst schnell<br />
möglichst optimale Routen zu finden. Dafür<br />
können die ganzen Problemstellungen<br />
zur Aktualisierung und Pflege der vorgehaltenen<br />
Routing-Tabellen wegfallen. Die dadurch<br />
merklich verringerte Last auf dem Netzwerk<br />
und der damit geringere Energieverbrauch<br />
der Knoten, aber auch die Speicherersparnis<br />
zeigen die Eignung des reaktiven Routings<br />
für MANETs.<br />
Ein kleiner Nachteil besteht darin, dass prinzipiell<br />
für jedes Paket die Route neu ermittelt<br />
werden müsste. Das kann man möglicherweise<br />
mit kurzfristigem Routen-Caching<br />
beheben, wobei die Dauer des Cachings je<br />
nach „Dynamik“ des Netzwerks tatsächlich<br />
sehr kurz sein muss.<br />
5.4.3 Routing-Algorithmen<br />
AODV<br />
AODV steht für Ad-hoc On-demand Distance<br />
Vector Routing [Das02]. Es handelt sich<br />
also um ein Distance-Vector-Verfahren, ohne<br />
Verwaltung einer globalen Topologie in jedem<br />
Router-Knoten. Desweiteren ist AODV<br />
reaktiv, so dass Routen nur nach Bedarf ermittelt<br />
werden.<br />
Funktionsweise der Route Discovery<br />
Jeder Knoten verwaltet für sich eine Routing-<br />
5.4 Routing in mobilen Ad-Hoc-Netzen<br />
Tabelle, die für beliebige Zieladressen festhält,<br />
an welchen Nachbar die Daten weitergeleitet<br />
werden müssen, wieviele Hops es<br />
noch bis zum Ziel sind und welche Nachbarn<br />
den Knoten zur Weiterleitung an die Zieladresse<br />
benutzen, sowie Angaben zur logischen<br />
und temporalen Gültigkeit der Route.<br />
Zu Beginn dürfen diese Tabellen leer sein;<br />
möchte ein Knoten zu einem anderen Knoten<br />
eine Verbindung aufbauen, überprüft er<br />
zunächst die Routing-Tabelle auf einen bereits<br />
existierenden Eintrag für das benötigte<br />
Ziel. Ist der Zielknoten (repräsentiert<br />
z.B. durch seine IP-Adresse) nicht in der<br />
Tabelle registriert, sendet er ein spezielles<br />
Routing-Control-Paket, einen Route Request<br />
(RREQ), per Broadcast an alle seine Nachbarn.<br />
1<br />
Sender<br />
3<br />
2<br />
4<br />
5<br />
Empfänger<br />
Abbildung 62: AODV Route Request<br />
Jeder Knoten, der seinerseits ein RREQ<br />
empfängt, legt zunächst einen Eintrag in<br />
seiner Routing-Tabelle ab, der als Ziel den<br />
im RREQ-Paket angegebenen Ursprungsknoten<br />
und den Nachbarn angibt, von dem<br />
der RREQ empfangen wurde. Dann wird<br />
die Tabelle auf das vom RREQ gewünschte<br />
Ziel überprüft. Ist der Knoten selbst das<br />
Ziel der Anfrage oder besitzt der Knoten eine<br />
gültige Route zum gewünschten Ziel, so<br />
sendet dieser ein anderes Routing-Control-<br />
Paket, eine Route Reply (RREP), auf genau<br />
dem Weg zurück zum Urspungsknoten,<br />
den der RREQ genommen hat. Falls<br />
der Knoten ebenfalls keine Route zum Ziel<br />
kennt, leitet er den RREQ auch an alle seine<br />
Nachbarn weiter (bis auf denjenigen, von<br />
dem der RREQ hergekommen ist) und erhöht<br />
den Hop-Count des RREQ. Auf diese<br />
Weise muss irgendwann der Zielknoten<br />
erreicht werden, falls noch keine bestehen-<br />
73
Elmar Schoch<br />
den Routen zu diesem existieren. Voraussetzung<br />
ist natürlich auch, dass dieser im Netz<br />
erreichbar ist. Das Kriterium einer gültigen<br />
Route ist erfüllt, wenn der Knoten, den ein<br />
RREQ erreicht, einen Eintrag für das gesuchte<br />
Ziel hat, bei dem die gespeicherte Destination<br />
Sequence Number mindestens so groß<br />
ist, wie die im RREQ-Paket enthaltene Destination<br />
Sequence Number. Auf diese Weise<br />
wird verhindert, dass alte Routinginformationen<br />
propagiert werden.<br />
1<br />
Sender<br />
3<br />
Abbildung 63: AODV Route Reply<br />
2<br />
4<br />
5<br />
Empfänger<br />
Der Rückweg des RREP-Paketes erfolgt also<br />
per Unicast. Das ist deswegen möglich,<br />
weil jeder Knoten auf dem Weg des<br />
RREQ-Paketes sich ja die Route zurück zum<br />
Ursprungsknoten eingetragen hat. Auf dem<br />
Rückweg des RREP-Paketes erfolgt wiederum<br />
dasselbe, das heißt, jeder Knoten, der<br />
ein RREP empfängt, trägt für die Quelladresse<br />
der RREP (entspricht der Zieladresse des<br />
RREQ) den Nachbarn als Next Hop ein,<br />
von dem die PREP kam. Wenn dann das<br />
PREP-Paket wieder beim urspünglichen Initiator<br />
des Requests ankommt, steht die komplette<br />
Route bidirektional zur Verfügung, der<br />
Knoten kann sofort mit der Übertragung der<br />
Daten beginnen.<br />
Wenn RREQ-Paket mit denselben Ziel- und<br />
Quellknoten kurze Zeit später über einen anderen<br />
Weg an einer Zwischenstation oder<br />
der Zielstation ankommt, wird dieses verworfen.<br />
Das hat zugleich den Effekt, dass nur die<br />
schnellsten Routen sich durchsetzen.<br />
Pflege der Routing-Tabellen<br />
AODV benutzt ein verhältnismäßig komplexes<br />
System von Sequenznummern, um neue<br />
von alten Routen zu unterscheiden und um<br />
zirkuläre Routen zu vermeiden. Jeder Kno-<br />
74<br />
ten hat eine lokale Sequenznummer, die er<br />
zum Beispiel erhöht, wenn er einen RREQ<br />
beginnt. Anhand der Adresse des Senders<br />
und der Sender-Sequenznummer kann ein<br />
RREQ damit eindeutig identifiziert werden.<br />
Erhält ein Knoten einen RREQ oder eine<br />
RREP, dann wird der entsprechende Eintrag<br />
in der Routing-Tabelle geändert, wenn die<br />
Destination Sequence Number höher ist, als<br />
die bisher im Eintrag gespeicherte, oder bei<br />
gleicher Destination Sequence Number, aber<br />
geringerer Anzahl von Hops, beziehungsweise,<br />
wenn die Destination Sequence Number<br />
unbekannt ist, weil das Ziel noch nicht in der<br />
Tabelle vorkommt. Die Destination Sequence<br />
Number entspricht der Sequence Number<br />
des Ziels, die dem Sender als letzte bekannt<br />
ist.<br />
Reaktion auf Topologieänderungen<br />
Die Knoten müssen ihre Umgebung überwachen,<br />
um möglichst stets auf dem aktuellsten<br />
Stand zu sein, welche Nachbarn erreichbar<br />
sind. Bricht eine Verbindung zu einem Nachbar<br />
zusammen, muss ein Knoten mittels der<br />
Routing-Tabelle feststellen, ob es aktive Routen<br />
gibt, bei denen dieser Nachbar der „Next<br />
Hop“ wäre. Ist das der Fall, sendet der Knoten<br />
an alle Nachbarn, die in der sogenannten<br />
„Precursor List“ für betroffene Routen<br />
stehen, eine Route Error-Nachricht (RERR).<br />
Die Precursor List enthält alle benachbarten<br />
Knoten, für die der betrachtete Knoten der<br />
„Next Hop“ in den betroffenen Routen darstellt.<br />
Die betroffenen Routen werden dann<br />
vorläufig als ungültig markiert.<br />
Die andere Möglichkeit besteht darin, dass<br />
ein Knoten Daten auf eine Route schickt, bei<br />
der zwischenzeitlich aber eine Verbindung<br />
abgebrochen ist. Wenn die Daten dann bei<br />
dem Knoten ankommen, der den entsprechenden<br />
Next Hop nicht mehr erreicht, sendet<br />
dieser ebenfalls eine RERR-Nachricht<br />
zurück. Die RERR-Nachricht enthält dabei<br />
alle Ziele, die durch den Verlust der Einzel-<br />
Verbindung auf der speziellen Route nicht<br />
mehr erreichbar sind.<br />
Wenn ein Knoten nicht selber senden will<br />
und nicht Teil einer aktiven Route ist, müssen<br />
für AODV keinerlei Aufgaben erfüllt werden,
und der Knoten kann sich beispielsweise in<br />
einen Energiesparmodus versetzen.<br />
DSR<br />
„Dynamic Source Routing“ ist wie AODV ein<br />
reaktives Verfahren, das Routen on-demand<br />
ermittelt. Im Gegensatz zu AODV benötigt<br />
DSR aber grundsätzlich keine periodische<br />
Aktivität, wie beispielsweise die kontinuierliche<br />
Überwachung der Verbindungen eines<br />
Knotens zu seinen Nachbarn. Zudem ist das<br />
zentrale Prinzip - der Name verrät es - das<br />
„Source Routing“: bei Versenden eines Pakets<br />
wird vom Sender die gesamte Route des<br />
Pakets bis zum Ziel vorgegeben. Ein Knoten<br />
benötigt also nicht nur Informationen über<br />
seine Nachbarn, sondern hält Routen im gesamten<br />
Netz vor.<br />
Nach Aussagen im IETF-DRAFT [Jet02], in<br />
dem DSR spezifiziert wird, ist DSR für MA-<br />
NETs mit bis zu zweihundert Knoten bei „relativ<br />
hoher Mobilitätsrate“ ausgelegt. Die angenommende,<br />
durchschnittliche Größe eines<br />
Netzwerks wird mit einem „Durchmesser“ im<br />
Bereich von fünf bis zehn Hops Entfernung<br />
der äußersten Knoten angegeben.<br />
Die zwei unabhängigen Hauptmechanismen<br />
in DSR sind die Route Discovery und die<br />
Route Maintainance:<br />
Route Discovery<br />
Die Wegfindung verläuft bei DSR prinzipiell<br />
relativ ähnlich wie bei AODV. Will ein Knoten<br />
eine Nachricht senden, prüft er zunächst<br />
seinen Cache, der für bestimmte Ziele komplette<br />
Routen mit allen Zwischenstationen<br />
bereithält. Bei DSR ist bewußt vorgesehen,<br />
dass pro Ziel auch mehrere, verschiedene<br />
Routen im Cache abgelegt sein dürfen. Ist eine<br />
Route zum gesuchten Ziel „vorrätig“, kann<br />
der Knoten sofort mit dem Senden beginnen.<br />
Das Hauptprinzip bei DSR ist dabei, dass jedes<br />
Paket im Header eine Kopie der Route,<br />
die das Paket nehmen soll, beinhaltet. Durch<br />
dieses Verfahren ist es trivial, zirkuläre Routen<br />
zu verhindern.<br />
5.4 Routing in mobilen Ad-Hoc-Netzen<br />
1<br />
Sender<br />
1<br />
1<br />
1 2<br />
3<br />
2<br />
1 3<br />
1 3<br />
1 2<br />
4<br />
5<br />
1 2 4<br />
Empfänger<br />
Abbildung 64: DSR Route Request<br />
Steht dem sendewilligen Knoten lokal keine<br />
entsprechende Route zur Verfügung, initiiert<br />
er einen Route Request (RREQ). Die RREQ-<br />
Pakete werden per Broadcast an alle Nachbarn<br />
in der Empfangsreichweite gesendet.<br />
Bei Empfang eines RREQ-Paketes kommt es<br />
wieder darauf an, ob es sich um den Zielknoten<br />
oder andere Knoten handelt. Ist der<br />
Zielknoten erreicht, sendet dieser eine Route<br />
Reply (RREP) zurück an den Empfänger.<br />
Die RREP enthält dabei den gesamten Weg,<br />
der durch den Lauf des RREQ angesammelt<br />
worden ist. Wenn ein Knoten einen RREQ<br />
empfängt, der nicht selbst der Zielknoten ist,<br />
prüft dieser zunächst seinen Cache. Verfügt<br />
er lokal über eine Route zum Ziel, antwortet<br />
er dem Initiator des RREQ mit einem RREP-<br />
Paket, das eine Fusion der Liste der bisher<br />
angesammelten Zwischenstationen und der<br />
im lokalen Cache befindlichen Liste der Stationen<br />
bis zum Ziel enthält. Hat der Empfänger<br />
eines RREQ ebenfalls keinen Weg zum<br />
gewünschten Ziel im Cache, sendet er seinerseits<br />
das RREQ-Paket weiter, nachdem<br />
er sich in die darin enthaltene Liste der Zwischenstationen<br />
eingetragen hat.<br />
1<br />
Sender<br />
1 3<br />
3<br />
2<br />
1 3<br />
Abbildung 65: DSR Route Reply<br />
4<br />
5<br />
Empfänger<br />
Der Rückweg eines RREP-Paketes ist mit<br />
DSR prinzipiell auf zwei Arten möglich, ab-<br />
75
Elmar Schoch<br />
hängig von der Art der benutzten Funktechnologie.<br />
Wird beispielsweise der WLAN-<br />
Standard IEEE 802.11 benutzt, kann der Absender<br />
einer RREP einfach die darin enthaltene<br />
Route umkehren und so das RREP<br />
auf den Weg schicken. Das ist deswegen<br />
möglich, weil ja in IEEE 802.11 ein Acknowledge<br />
auf MAC-Ebene implementiert ist, so<br />
dass grundsätzlich nur bidirektionale Verbindungen<br />
zustande kommen.<br />
Falls die zugrundeliegende Technik auch unidirektionale<br />
Verbindungen erlaubt, muss der<br />
antwortende Knoten die RREP wie normale<br />
Daten behandeln. Das bedeutet, dass er zunächst<br />
seinen lokalen Cache auf eine Route<br />
zurück zum Initiator überprüft und gegebenenfalls<br />
auch eine Route Discovery beginnt.<br />
Das RREQ-Paket muss in diesem Fall dann<br />
allerdings auch das RREP-Paket mit enthalten,<br />
da sonst die Route Discoveries unendlich<br />
hin- und her gehen würden.<br />
Als „Nebeneffekt“ lernen alle Zwischenstationen<br />
Routen permanent mit, wenn sie Route<br />
Requests und Route Replies empfangen<br />
oder auch einfach, wenn sie Daten weiterleiten,<br />
indem sie sich die fertige Route kopieren.<br />
Pflege der Routen<br />
Die Pflege von Routen geschieht in DSR<br />
vollkommen passiv. Einmal gefundene Wege<br />
werden so lange benutzt, bis eine Einzelverbindung<br />
auf dem Weg eines Pakets abgebrochen<br />
ist. Dann sendet der letzte Knoten<br />
vor der abgebrochenen Verbindung ein<br />
RERR an die Quelle zurück.<br />
1<br />
Sender<br />
1 3<br />
Data<br />
RERR<br />
3<br />
2<br />
Abbildung 66: DSR Route Error<br />
4<br />
5<br />
Empfänger<br />
Empfängt ein Knoten ein RERR-Paket,<br />
löscht er alle Routen über den abgebrochenen<br />
Link aus seinem Cache. Auf dieser Wei-<br />
11 „groß“ bezieht sich hier auf die Anzahl der Knoten<br />
76<br />
se werden ungültige Routen wieder aus dem<br />
System entfernt. Zusätzlich sollte ein Knoten<br />
für jeden Eintrag in der Route Timeouts verwalten,<br />
und Einträge entfernen, die eine gewisse<br />
Zeit nicht mehr benutzt worden sind.<br />
Der Entwurf verlangt das aber nicht zwangsweise.<br />
Hat ein Knoten eine Route benutzt<br />
und bekommt ein RERR zurück, kann er zunächst<br />
andere Einträge aus dem Cache versuchen<br />
oder eine neue Route Discovery starten.<br />
Topologieänderungen<br />
Änderungen an der Struktur des Netzwerkes<br />
bleiben bei DSR zunächst ohne Folge, wenn<br />
keine aktive Route betroffen ist. Eine Reaktion<br />
erfolgt erst, wenn eine Verbindung auf<br />
einer aktiven Route abbricht, also ein Knoten<br />
Daten über eine unterbrochene Route<br />
weiterleiten soll. Dieser sendert dann RERR-<br />
Paket an die Quelle zurück.<br />
Bei stabiler Topologie und vielen etablierten<br />
Routen geht der Aufwand für das Protokoll<br />
gegen Null.<br />
Weitere Ansätze<br />
Optimized Link-State Routing (OLSR)<br />
[Vie01] versucht, wie der Name schon sagt,<br />
das Link-State-Verfahren für MANETs zu optimieren.<br />
Eine Grundlage dazu ist die Hierarchisierung<br />
des Netzes. Sogenannte „Multipoint<br />
Relay Nodes“ (MPR) übernehmen die<br />
Weiterleitung für eine bestimmte Menge ihrer<br />
Nachbarn. Das eigentliche Routing findet nur<br />
zwischen diesen MPRs nach normalem Link-<br />
State statt. Die von einem MPR „verwalteten“<br />
Knoten müssen keine Routingaufgaben<br />
übernehmen und werden bei der Kommunikation<br />
auch über „ihren“ MPR adressiert.<br />
Auf diese Weise reduziert sich der Aufwand<br />
für das Fluten zur Verbreitung der Topologie<br />
im Netzwerk drastisch, da nur ein relativ<br />
kleiner Prozentsatz der Knoten zu MPRs<br />
werden. OLSR eignet sich vor allem für dicht<br />
zusammenhängende, große 11 MANETs, da<br />
hier das Konzept am besten greift.
2<br />
1<br />
3<br />
5<br />
4<br />
7<br />
6<br />
Sender Empfänger<br />
Abbildung 67: Multipoint Relay - System in<br />
OLSR<br />
Wie man sieht hat das hierarchische Routing<br />
aber den Nachteil, dass unter Umständen<br />
auch Knoten, die sich in gegenseitiger Reichweite<br />
befinden, aufgrund des Protokolls nicht<br />
direkt Verbindung aufnehmen können.<br />
Fisheye State Routing (FSR) [Pei02] ist ein<br />
proaktives Link-State-Verfahren. Jeder Knoten<br />
verwaltet seine eigene Netzwerktopologie,<br />
anhand der eine Route bestimmt wird. Im<br />
Gegensatz zum allgemeinen Link-State werden<br />
die Topologieinformationen aber nicht<br />
bei jeder Änderung geflutet, sondern lediglich<br />
in periodischen Intervallen und nur an<br />
alle direkten Nachbarn übermittelt. Zusätzlich<br />
werden die Einträge in verschiedene Entfernungsbereiche<br />
eingeteilt und dementsprechend<br />
häufig beziehungsweise selten propagiert.<br />
Einträge im Nahbereich von wenigen<br />
Hops werden häufig ausgetauscht, entfernte<br />
Stationen nur selten. Wenn ein Paket<br />
geroutet werden muss, besteht die Möglichkeit,<br />
dass sich die Topologie in einiger Entfernung<br />
schon wieder geändert hat. Je näher<br />
ein Paket aber dem Ziel kommt, umso<br />
akkurater sind die Informationen der weiterleitenden<br />
Knoten über die Topologie in ihrem<br />
Umfeld, und so findet ein Paket zum Ziel.<br />
Jeder Knoten blickt gewissermaßen mit einem<br />
„Fischauge“ auf die Gesamtstruktur. Auf<br />
diese Weise läßt sich der Aufwand für den<br />
Austausch der Topologieinformationen überschaubar<br />
halten.<br />
Der Entwurf von FSR zielt insbesondere auf<br />
große MANETs mit hoher Mobilität.<br />
8<br />
9<br />
5.5 Anwendung im Ubiquitous Computing<br />
5.5 Anwendung im Ubiquitous<br />
Computing<br />
5.5.1 Einsatz-Szenarien<br />
Die Vorteile mobiler Ad-hoc-Netzwerke eröffnen<br />
viele Möglichkeiten für Anwendungen. In<br />
manchen Fällen wird es zwar vielleicht trotzdem<br />
ökonomischer und sinnvoller sein, eine<br />
feste, leistungsstarke Infrastruktur aufzubauen.<br />
In vielen Fällen aber, wo statische Netzwerke<br />
nicht flexibel genug, zu wartungsintensiv<br />
oder aufgrund äußerer Einflüsse nicht geeignet<br />
sind, bietet sich der Einsatz von MA-<br />
NETs an. Das gilt zum Beispiel für spontane<br />
Treffen oder in öffentlichen Netzen, bei<br />
der Notwenigkeit eines schnellen Netzaufbaus,<br />
oder wenn der Aufbau einer Infrastruktur<br />
nicht oder nur schwer realisierbar wäre<br />
[Bei02] [Bee02].<br />
CSCW (Konferenzen, Unterricht,<br />
Meetings), Ausstellungen<br />
Mit Hilfe von Ad-hoc-Netzwerken ließen<br />
sich im Bereich Computer Supported<br />
Cooperative Work sehr einfach<br />
Daten austauschen, gemeinsame Aufgaben<br />
erledigen oder auch nur Informationen<br />
verbreiten. In Ausstellungen<br />
oder Messen stellt man sich vor, dass<br />
man zu bestimmten Objekten ganz<br />
einfach weitere Informationen abrufen<br />
könnte.<br />
Rettungs- und Katastropheneinsatz<br />
Beim Einsatz von Geräten im Rettungswesen<br />
oder im Katastrophenfall<br />
kommt es darauf an, möglichst schnell<br />
möglichst zuverlässige Kommunikationssysteme<br />
aufzubauen, die von den<br />
Rettungskräften zur Koordination benutzt<br />
werden können. Im Rettungswesen<br />
könnte man sich beispielsweise<br />
vorstellen, dass der Rettungswagen<br />
die Vitaldaten eines Patienten schon<br />
im Voraus an das Krankenhaus übermittelt,<br />
und dass angekoppelte Verkehrsregelungsanlagen<br />
für freie Fahrt<br />
77
Elmar Schoch<br />
78<br />
der Helfer sorgen. Im Katastropheneinsatz<br />
ist sehr wichtig, dass die<br />
Rettungs- und Bergungsmannschaften<br />
koordiniert und schnell vorgehen. Möglicherweise<br />
könnten über das Netz<br />
dann auch leichter Spezialisten hinzugezogen<br />
werden.<br />
Spontane Vernetzung von Städten,<br />
Überbrückung der „letzten Meile“<br />
Es wäre in Städten, wo die Enfernungen<br />
kleiner sind, prinzipiell sehr einfach,<br />
Ad-hoc-Netze auf Funktechnik-<br />
Basis zu bilden, die dann irgendwo ein<br />
Gateway zum Internet haben. Auf diese<br />
Weise ließen sich ganze Stadtteile<br />
ohne kabelgebundene Infrastruktur<br />
vernetzen. Es gibt auch bereits kommerzielle<br />
Beispiele für dieses Szenario.<br />
Fahrzeug-Kommunikation<br />
(Telematik)<br />
Ein sehr spannendes Gebiet<br />
für MANETs bietet sich im Bereich<br />
der Fahrzeug-zu-Fahrzeug-<br />
Kommunikation. Man kann unterscheiden<br />
zwischen Diensten zur Gefahrenvermeidung<br />
und zum sicheren Fahren,<br />
zu Telematik und Navigation, zu Unterhaltung<br />
und Information und zu Verkehrslenkung.<br />
Wenn Fahrzeuge untereinander kommunizieren,<br />
können nachfolgende<br />
Fahrzeuge auf Gefahrsituationen, wie<br />
beispielsweise ein Stau hinter einer<br />
Kurve, Glatteis auf der Fahrbahn, oder<br />
einen Unfall hingewiesen werden. Ein<br />
Auto, auf der Autobahn wegen eines<br />
Defekts liegengeblieben, könnte herannahende<br />
Fahrzeuge vor der potentiellen<br />
Gefahr warnen (sofern das noch<br />
geht). Genauso könnten sich die Fahrzeuge<br />
aber auch bei Spurwechseln<br />
oder an Autobahnauffahrten gegenseitig<br />
abstimmen, um gefährliche Situationen<br />
und Kollisionen zu vermeiden.<br />
Ebenso denkbar wären Dienste, die<br />
aufgrund von Daten der Fahrzeuge die<br />
Verkehrsdichte auf Streckenabschnitten<br />
ermitteln, die dann für Navigationssysteme<br />
zur Verfügung stehen, welche<br />
so flexibel darauf reagieren können.<br />
Ein weiterer Ansatz ist der, Gateways<br />
am Straßenrand aufzustellen, die beispielsweise<br />
Internetzugang ermöglichen<br />
oder Informationen über Städte<br />
liefern. Auf längeren Reisen könnten<br />
Mitfahrende mit anderen Autos in Verbindung<br />
treten.<br />
Eine vierte Kategorie wäre die virtuelle<br />
Kopplung von Fahrzeugen, so dass<br />
Abstand und Geschwindigkeit, unter<br />
Umständen auch Lenkung, durch ein<br />
System geregelt werden. Dadurch wird<br />
das Fahren auf langen Strecken sicherer<br />
und energiesparender. Wichtig ist<br />
dabei, dass nicht nur eine Verbindung<br />
von Vordermann zu Hintermann etc.<br />
besteht, sondern mehrere Fahrzeuge<br />
vorausschauend geplant wird.<br />
Soziale Kontakte<br />
In den Mobilfunknetzen hat die SMS-<br />
Flut ungeahnte Größenordnungen erreicht<br />
- das beweist das enorme Potential<br />
derartiger Systeme. Anwendungen<br />
für MANETs wären zum Beispiel in<br />
Form von intelligenten Sensoren denkbar,<br />
in die man seine Eigenschaften<br />
und Interessen eingeben kann, und die<br />
dann eine Meldung auslösen, wenn<br />
sich Personen mit ähnlichem <strong>Prof</strong>il in<br />
der Nähe befinden.<br />
Personal Area Networks<br />
Die Vision von Netzwerken rund um eine<br />
Person herum malen im Endeffekt<br />
meist die Dekomposition des heutigen<br />
Handys in mehrere Teilgeräte mit insgesamt<br />
wesentlich erweiterten Funktionen<br />
[Mat02]. Die Thematik wird öfters<br />
auch als „Wearable Computing“<br />
bezeichnet: der Lautsprecher befindet<br />
sich im Ohrring, das Mikrofon in einer<br />
Halskette oder in einem Hemdknopf,<br />
die eigentliche Kommunikationseinheit<br />
am Gürtel oder am Arm, und das Display,<br />
reduziert auf ein minimales Gewicht,<br />
befindet sich in der Hosentasche.<br />
Dies reicht möglicherweise bis
hin zu Brillen, in die in fremder Umgebung<br />
der Weg als eine Art roter Teppich<br />
einprojiziert wird. Alle Komponenten<br />
stehen durch ein drahtloses Adhoc-Netzwerk<br />
in Verbindung.<br />
Erweiterung bestehender Funknetze<br />
oder zellulärer Systeme (GSM,<br />
UMTS)<br />
Ein weiteres, scheinbar banales Szenario<br />
ist die Erweiterung von bestehenden<br />
Funknetzen mit beschränkter<br />
Reichweite. Auf diese Weise ließen<br />
sich Ausbaumaßnahmen kostengünstiger<br />
gestalten, weil eine Vollversorgung<br />
auch indirekt über solche mobile Knoten<br />
gewährleistet werden kann, die sich<br />
im Empfangsbereich der statischen Systeme<br />
befinden [Weg02].<br />
Home Improvement<br />
Für die Verwendung im Haushalt beziehungsweise<br />
in Häusern gibt es eine<br />
Vielzahl möglicher Anwendungen.<br />
Das beginnt natürlich ganz im Sinne<br />
des Ubiquitous Computing, dass viele<br />
Gegenstände und Geräte kleine Prozessoren<br />
beinhalten, die so die Benutzung<br />
vereinfachen. Die Kaffeemaschine<br />
könnte sich jeweils den individuellen<br />
Wünschen der Kaffeetrinker anpassen.<br />
Mit Vernetzung aber sind noch einige<br />
interessante Erweiterungen denkbar.<br />
So könnte beispielsweise der Wecker<br />
der Kaffeemaschine fünf Minuten vor<br />
dem Wecken eine Nachricht übermitteln,<br />
so dass bereits kurz nach dem<br />
Aufstehen der Kaffee fertig ist. Sollte<br />
der Wecker die Kaffeemaschine nicht<br />
erreichen, den Kühlschrank dagegen<br />
schon, könnte er auch über den Kühlschrank<br />
in der Küche der Kaffeemaschine<br />
Nachrichten zukommen lassen.<br />
Damit diese Dinge auch so praktisch<br />
bleiben, wie sie klingen, ist es aber nötig,<br />
dass keinerlei Aufwand für die Einrichtung<br />
und Wartung solcher transparenten<br />
Systeme nötig ist.<br />
Eine andere Anwendung wäre beispielsweise<br />
der Rasensprenger, der<br />
5.5 Anwendung im Ubiquitous Computing<br />
mit verteilten Sensoren die Feuchtigkeit<br />
des Bodens mißt und sich aus dem<br />
Internet die Wettervorhersage holt, um<br />
die notwendige Wassermenge genauer<br />
dosieren zu können [Mat02].<br />
Vernetzung von Sensoren, Smart<br />
Dust<br />
Die Sammlung von sensorischen Daten<br />
zur Erstellung von Modellen zum<br />
Beispiel in der Seismologie oder der<br />
Meteorologie ist essentiell wichtig. Je<br />
mehr Daten, umso differenziertere Beobachtungen<br />
können gemacht werden.<br />
Die Anbindung und Vernetzung von<br />
Sensoren, insbesondere auch in abgelegenen<br />
Gebieten, würde durch MA-<br />
NETs wesentlich erleichtert.<br />
In diesem Zusammenhang spricht man<br />
auch von sogenanntem „Smart Dust“.<br />
Dabei handelt es sich um winzigste,<br />
elektronische Elemente, die Sensoren<br />
beinhalten und, so die Idee, zu tausenden<br />
ausgesetzt werden sollen. Aufgrund<br />
der extrem geringen Ausmaße<br />
ist die Energie sehr beschränkt und damit<br />
auch die Ausstattung mit Kommunikationseinrichtungen<br />
schwierig. Wie<br />
man sieht, könnten aber auch hier<br />
MANET-Techniken sinnvoll sein.<br />
Militärische Anwendungen<br />
Militärische Labors forschen ebenfalls<br />
schon längere Zeit an mobilen, leicht<br />
transportablen, autonomen Geräten.<br />
Weitere wichtige Eigenschaften sind<br />
Zuverlässigkeit und Ausfallsicherheit.<br />
Der „vernetzte Soldat“ kann mit Hilfe<br />
solcher Netzwerke ständig auf dem aktuellsten<br />
Stand sein und jederzeit Anweisungen<br />
entgegennehmen, während<br />
gleichzeitig auch noch die dezentrale<br />
Infrastruktur unempfindlicher und robuster<br />
gegenüber Angriffen wird. Die strategischen<br />
und exekutiven Aktionen lassen<br />
sich so noch besser abstimmen,<br />
insbesondere eben dort, wo der explizite<br />
Aufbau von Kommunikationsverbindungen<br />
hinderlich oder nicht möglich<br />
ist.<br />
79
Elmar Schoch<br />
5.5.2 Projekte<br />
FleetNet<br />
„FleetNet -<br />
Internet on<br />
the Road“<br />
ist ein Forschungsprojekt<br />
der Unternehmen DaimlerChrysler,<br />
Fraunhofer-Gesellschaft, NEC,<br />
Bosch, Siemens und TEMIC sowie einiger<br />
<strong>Universität</strong>en. Das Ziel des Projekts ist<br />
die Entwicklung und Standardisierung einer<br />
Kommunikationsplattform für ein Ad-hoc-<br />
Netzwerk zwischen Fahrzeugen. Die Applikationen,<br />
die FleetNet bieten soll, gliedern<br />
sich in die drei Kategorien kooperative<br />
Fahrerassistenzsysteme, dezentrale<br />
Floating Car Data Anwendungen und<br />
Kommunikations- und Informationsdienste<br />
[Dai02].<br />
Kooperative Fahrerassistenzsysteme<br />
Die wesentliche Zielsetzung besteht darin,<br />
die Wahrnehmung des Fahrers zu erweitern,<br />
in dem andere, vorausfahrende Fahrzeuge<br />
Daten zum Fahrbahnzustand übermitteln.<br />
Durch Parameter wie Geschwindigkeit,<br />
Bremsverhalten oder ABS-Einsatz kann auf<br />
Stauungen, Unfälle oder andere Gefahrensituationen<br />
geschlossen werden.<br />
Dezentrale Floating Car Data Anwendungen<br />
Bisher genutzte Telematik-Dienste zur Stau-<br />
Warnung etc. beruhen auf Fahrzeugfluss-<br />
Sensorik und zentraler Verarbeitung. Die Information<br />
über Verkehrsaufkommen auf einzelnen<br />
Strecken gelangt dann in der Regel<br />
per Mobilfunk zum abrufenden Fahrzeug.<br />
Dieses etwas kostspielige Verfahren<br />
könnte auch durch Fahrzeug-zu-Fahrzeug-<br />
Kommunikation bewerkstelligt werden, so<br />
dass nachfolgende Fahrzeuge stets aktuelle<br />
Verkehrsinformationen über vorausliegende<br />
Streckenabschnitte vorliegen würden.<br />
Kommunikations- und Informationsdienste<br />
Dieser Ansatz besteht darin, dass Mitfahrende<br />
Informationen zu und mit anderen<br />
Fahrzeugen austauschen können oder mit<br />
80<br />
anderen Fahrzeugen chatten oder online-<br />
Spiele austragen können. Zudem soll durch<br />
das Konzept des FleetNet-Gateways dem<br />
Fahrzeug-Ad-hoc-Netz ein Internet-Zugang<br />
geboten werden. Zusätzlich sollen beispielsweise<br />
lokale Angebote der Stadt, der Region<br />
oder einfach einer Raststätte abgerufen werden<br />
können.<br />
Technik<br />
Als Anforderungen an die Funkhardware<br />
wurde eine Mindestbandbreite von 1 MBit,<br />
eine Mindestreichweite von 500 Metern,<br />
die Benutzung eines lizenzfreien Frequenzbands<br />
und offene Schnittstellen für die Implementierung<br />
der Kommunikationsprotokolle<br />
angesetzt. Zur Auswahl standen unter anderem<br />
IEEE 802.11 und HIPERLAN, letztendlich<br />
bevorzugt wurde aber UTRA-TDD,<br />
ein UTMS-Hardwaresystem von Entwicklungspartner<br />
Siemens. UTRA-TDD ermöglicht<br />
Reichweiten von 1 km und Datenraten<br />
von 348 kBit/s bis 2 MBit/s, etwas problematisch<br />
ist aber wohl die Realisierung der Ad-<br />
Hoc-Kommunkation in dem für zentrale, zelluläre<br />
Infrastruktur entwickelten System.<br />
Routing<br />
Im Anwendungsfeld der Fahrzeug-Fahrzeug-<br />
Kommunikation ist beispielsweise eine<br />
Adressierung nach Position (z.B. an alle<br />
nachfolgenden Fahrzeuge) wichtig und das<br />
Protokoll muss hohen Anforderungen an Dynamik<br />
und Skalierbarkeit genügen. Deswegen<br />
wurde ein positionsbasiertes Routingverfahren<br />
ausgewählt; jeder Teilnehmer wird<br />
mit einer eindeutigen Adresse und seiner Position<br />
adressiert. Das eigentliche Routing beruht<br />
nur auf den Positionsdaten, jeder weiterleitende<br />
Teilnehmer bestimmt für jedes Paket<br />
einzeln „on the fly“ die Richtung, in die Daten<br />
gesendet werden müssen. Im Zielgebiet der<br />
Position bewirkt dann die eindeutige ID des<br />
Teilnehmers die endgültige Zustellung.<br />
Die Ermittlung der Positiondaten erfolgt mittels<br />
GPS.<br />
Weitere Aufgaben des Projekts haben<br />
den Entwurf einer Mensch-Maschine-<br />
Schnittstelle im Auto, die Integration des Systems<br />
in Demonstrationsfahrzeuge und die
Entwicklung von Markteinführungstrategien<br />
zum Ziel.<br />
MeshNetworks<br />
Die Firma MeshNetworks [Mes] aus Florida<br />
hat ein klassisches Ad-Hoc-Netzwerk, allerdings<br />
mit proprietärer Technik entwickelt. In<br />
Maitland, Florida, wird ein Gebiet von knapp<br />
20 Quadratkilometern mit einem drahtlosen<br />
Ad-hoc-Netzwerk versorgt. Als Knoten stehen<br />
spezielle Sender an Laternenmasten,<br />
aber auch jeder „Subscriber“, also jedes teilnehmende<br />
Endgerät für die Weiterleitung<br />
von Daten zur Verfügung. Für den Zugang<br />
zum Internet sorgt ein über das Ad-hoc-Netz<br />
erreichbarer Zugangsknoten. Die verwendete<br />
Technik macht es möglich, dass die Verbindung<br />
zum Netzwerk auch in mobilen Einheiten<br />
steht - zur Zeit bringt MeshNetworks<br />
das Internet zum Beispiel in die Busse des<br />
Städtchens. Zusätzlich zur Datenübermittlung<br />
bietet der Verbund von MeshNetworks<br />
auch Positionsbestimmung als Alternative zu<br />
GPS.<br />
5.6 Zusammenfassung und Ausblick<br />
5.6 Zusammenfassung und Ausblick<br />
Marc Weiser, der „Vater“ des Ubiquitous<br />
Computing, sieht die Zukunft in allgegenwärtigen,<br />
kleinen, meist unsichtbaren und teilweise<br />
mobilen Geräten, die in den Hintergrund<br />
treten und den Mensch in den Mittelpunkt<br />
stellen. Dabei ist es für diese verteilten<br />
Geräte sehr wichtig, unkompliziert untereinander<br />
kommunizieren zu können. Zu diesem<br />
Zweck ist eine fest installierte, statische Infrastruktur<br />
zu kompliziert und viel zu unflexibel.<br />
Die SmartDevices, SmartSensors und<br />
dergleichen müssen sich ohne vorher Kabel<br />
zu verlegen, und auch ohne vorher Konfigurationsarbeit<br />
leisten zu müssen, unterhalten<br />
können. Deshalb sind drahtlose Kommunikationstechniken,<br />
insbesondere auch ohne jegliche,<br />
vorgegebene Infrastruktur, eine unverzichtbare<br />
Grundlage für die meisten Ubiquitous<br />
Computing-Anwendungen. Mobile Adhoc<br />
Netzwerke sind dazu die Lösung.<br />
81
Literatur<br />
Literatur<br />
[Bee02] M. Gottwald; M. Beetz: Ad-hoc-Netzwerke und Routing in Ad-hoc-Netzwerken,<br />
2002.<br />
[Bei02] <strong>Prof</strong>. <strong>Dr</strong>. Lars Wolf; Michael Beigl: Ubiquitous Computing. http://www.teco.<br />
uni-karlsruhe.de, 2002.<br />
Vorlesung an der <strong>Universität</strong> Karlsruhe, WS 2001/2002<br />
[Dai02] DaimlerChrysler: FleetNet - Internet on the Road. http://www.fleetnet.de,<br />
5 2002.<br />
Projektübersicht<br />
[Das02] C.E. Perkins; E.M. Belding-Royer; S.R. Das: IETF <strong>Dr</strong>aft - Ad hoc On-Demand Distance<br />
Vector (AODV) Routing, 6 2002.<br />
[Jet02] D.B. Johnson; D.A. Maltz; Y. Hu; J.G. Jetcheva: IETF <strong>Dr</strong>aft - The Dynamic Source<br />
Routing Protocol for Mobile Ad Hoc Networks (DSR), 2 2002.<br />
[Kar01] F. Kargl: Mobile Ad hoc Networks. http://www.ulm.ccc.de/chaosseminar/manet/,<br />
2001.<br />
Vortrag beim CCC <strong>Ulm</strong><br />
[Mac99] M.S. Corson; J. Macker: IETF RFC 2501 - Mobile Ad hoc Networking: Routing<br />
Protocol Performance Issues and Evaluation Considerations, 1 1999.<br />
[Mat02] F. Mattern. E-Merging Media - Digitalisierung der Medienwirtschaft, chapter Ubiquitous<br />
Computing: Szenarien einer informatisierten Welt. Springer-Verlag, 2002.<br />
[Mes] MeshNetworks: http://www.meshnetworks.com.<br />
[Pei02] M. Gerla; X. Hong; G. Pei: IETF <strong>Dr</strong>aft - Fisheye State Routing Protocol (FSR) for<br />
Ad Hoc Networks, 6 2002.<br />
[Sch02] <strong>Prof</strong>. <strong>Dr</strong>. A. Schill: Mobile Kommunikation und Mobile Computing. http://www.<br />
rn.inf.tu-dresden.de, 2002.<br />
Vorlesung an der TU <strong>Dr</strong>esden, WS 2001/2002<br />
[Vie01] T. Clausen; P. Jacquet; A. Laouiti; P. Minet; P. Muhlethaler; A. Qayyum; L. Viennot:<br />
IETF <strong>Dr</strong>aft - Optimized Link State Routing Protocol, 9 2001.<br />
[Weg02] Jochen Wegner: Reparaturdienst für UMTS. Focus, 36/2002, S. .<br />
82
6 Location Models<br />
Zusammenfassung<br />
Location Models sind theoretische Modelle<br />
zur Positionsbestimmung von mobilen<br />
Geräten.<br />
Die Bestimmung der Position ist für kontextbezogene<br />
Anwendungen eine wichtiger<br />
Aspekt, welcher die Qualität und die<br />
Möglichkeiten der Entwicklung solcher<br />
Anwendungen entscheidend beeinflusst.<br />
In dieser Ausarbeitung werden die Basismodelle<br />
und die Umsetzung dieser in<br />
der Praxis vorgestellt. Außerdem wird auf<br />
zwei Modelltypen eingegangen, die sich<br />
zum momentanen Zeitpunkt noch in der<br />
Entwicklung befinden, jedoch eine Vielzahl<br />
von Möglichkeiten offenbaren, kontextbezogene<br />
Informationen anzubieten.<br />
6.1 Einleitung<br />
Location Modeling wurde unlängst zu einem<br />
wichtigen Thema auf dem Gebiet der<br />
Ubiquitous-Computing-Systeme. Für Systementwickler,<br />
die kontextbezogene Informationen<br />
nutzen wollen, ist bereits eine große<br />
Auswahl verschiedenster Technologien verfügbar,<br />
um einerseits dem Benutzer einen<br />
guten Service zu bieten oder ihm seine aktuelle<br />
Position mitzuteilen. Die Umgebung,<br />
in der sich der Benutzer aufhält ist im<br />
Zusammenhang mit Ubiquitous-Computing-<br />
Anwendungen ein wichtiger Faktor, besonders<br />
für die Positionsbestimmung, die Navigation,<br />
das Routing, die Streckenberechnung,<br />
die Logistik und vieles mehr.<br />
Der Erfolg eines Systems hängt im wesentlichen<br />
von einem guten Entwurf ab. Deshalb<br />
ist es für alle Anwendungen sehr wichtig ein<br />
gewisses ’Positionsbewußtsein’ zu besitzen<br />
Benjamin Bender<br />
<strong>Universität</strong> <strong>Ulm</strong><br />
89081 <strong>Ulm</strong><br />
benjamin.bender@informatik.uni-ulm.de<br />
um sicher zu stellen, dass das darunterliegende<br />
Location Model zu den angestrebten<br />
Funktionen passt. Für einen Menschen ist es<br />
zum Beispiel schwierig ein Haus an der Posi-<br />
tion 47<br />
24’Nord, 8<br />
18’Ost zu finden. Ebenso<br />
schwierig könnte es für ein System sein die<br />
Entfernung zwischen ’dem Auto’ und ’der<br />
nächsten Tankstelle’, als symbolische Bezeichnungen,<br />
zu bestimmen.<br />
Die Positionsabhängigkeit ist einer der<br />
Hauptunterschiede zwischen Ubiquitous-<br />
Computing-Konzepten und bisherigen Computersystemen<br />
und stellt eine weitere Herausforderung<br />
dar, denn mobile Computer<br />
werden mehr und mehr zu Alltagsgeräten.<br />
Deshalb sollten die mobilen Geräte in der<br />
Lage sein weiterhin als Computer zu dienen,<br />
aber auch in verständlicher Art und Weise<br />
mit dem Benutzer zu kommunizieren.<br />
Ein weiterer Aspekt der Positionsbestimmung<br />
ist die Genauigkeit der Informationen,<br />
die zwischen verschiedenen Einsatzgebieten<br />
variieren kann.<br />
Der dritte Punkt, der in Betracht gezogen<br />
werden sollte ist, dass Positionsinformationen<br />
oft von verschiedenen Sensortypen bestimmt<br />
werden. In diesem Fall sollte das System<br />
in der Lage sein mit verschiedenen<br />
Datenformaten zu arbeiten. Außerdem liegt<br />
noch eine große Bedeutung auf der Entfernungsbestimmung,<br />
die wie all die anderen<br />
erwähnten Aspekte, nicht ohne die Verwendung<br />
von Location Models realisiert werden<br />
kann. [Dom02]<br />
83
Benjamin Bender<br />
6.1.1 Möglichkeiten der Positionsangabe<br />
Die Idee der Ortsrepräsentation ist nicht<br />
wirklich neu. Wahrscheinlich war die Landkarte<br />
der allererste mobile Repräsentant eines<br />
Positionsmodells. Ein altes Gebiet der<br />
Kartographie ist die Katasterkartierung, die<br />
eine sehr unsystematische Raumunterteilung<br />
in Flächen und Grenzen betrieb. Später<br />
wurden Kartierungen mit Längengrad<br />
und Breitengrad eingeführt um exaktere Positionsbeschreibungen<br />
zu ermöglichen. Ursprünglich<br />
wurden die meisten Objekte auf<br />
der Karte jedoch mit historischen Ereignissen<br />
und nach und nach mit ortsspezifischen<br />
Eigenschaften, wie Sehenswürdigkeiten, Klima,<br />
Ressourcen, Bevölkerung, usw. verbunden.<br />
Somit wurde das Positionsbild als Referenz<br />
für die symbolische Bezeichnung genutzt.<br />
Die heutigen Mittel der Positionsrepräsentation<br />
sind viel flexibler als Karten, denn sie erlauben<br />
nicht nur Visualisierung und Referenzen,<br />
sondern auch komplexe Hierarchien von<br />
Orten und Objekten, Anfragemechanismen<br />
und Verhaltensanalysen. Die meisten dieser<br />
Verfahren nutzen die euklidische und analytische<br />
Geometrie, aber auch die Mengentheorie,<br />
die Graphentheorie und die Wahrscheinlichkeitstheorie.<br />
Man kann die Repräsentation der Position<br />
allgemein in zwei allseits bekannte Gebiete<br />
aufteilen, die von den Menschen seit Langem<br />
genutzt werden und damit einen historischen<br />
Hintergrund haben. Es handelt sich dabei um<br />
die sogenannte physikalische Position und<br />
die geographische Position. Beide sind absolute<br />
Spezifikationen, da sie mit einem universell<br />
gültigem Koordinatensystem, geographischen<br />
Namen oder einem Referenzsystem<br />
arbeiten.<br />
Die physikalische Position basiert auf einem<br />
globalen geographischen Koordinatensystem<br />
und liefert eine absolut akkurate,<br />
netzbasierte Position in Form eines Tupels<br />
von Längengrad und Breitengrad. Dieses Tupel<br />
kann gegebenenfalls noch durch Hinzunahme<br />
der geographischen Höhe zu einem<br />
Koordinatentripel von geographischer Länge,<br />
84<br />
Breite und Höhe erweitert werden.<br />
Die geographische Position hingegen wird<br />
durch natürliche geographische Objekte bestimmt,<br />
wie zum Beispiel Länder, Städte oder<br />
auch Postleitzahlenbereiche, Adressen, usw.<br />
Eine bemerkenswerte Eigenschaft solcher<br />
Objekte ist ihre meist klare hierarchische Organisation.<br />
Diese Art der Positionsbeschreibung<br />
ist für den Menschen eine vorstellbare<br />
Beschreibung der räumlichen Position und<br />
nicht wie bei der physikalischen Position eine<br />
Kombination von numerischen Koordinaten.<br />
[Dom02]<br />
6.1.2 Objektanordnung und<br />
Messgenauigkeit<br />
Anhand der im vorherigen Abschnitt definierten<br />
physikalischen und geographischen Position<br />
gibt es generell zwei Möglichkeiten das<br />
Verhältnis zwischen einem Objekt und dem<br />
Ort an dem es sich befindet auszudrücken.<br />
Die erste Möglichkeit, welche in direktem Zusammenhang<br />
mit der physikalischen Position<br />
steht, ist das Positioning.<br />
Hierbei ist jedes Objekt nur durch seine<br />
aktuelle absolute Position bestimmt, welche<br />
sich genau im entsprechenden Koordinatensystem<br />
ermitteln lässt. Beziehungen<br />
zwischen verschiedenen Orten können hier<br />
durch die Entfernung, die zwischen ihnen liegen,<br />
definiert werden. Die Auflösungsgenauigkeit<br />
des Positioning ist durch den Gitternetzabstand<br />
des zu Grunde liegenden Koordinatensystems<br />
spezifiziert. Im Kapitel 6.2.1
wird später erklärt, dass auch das Geometrische<br />
Modell das Positioning nutzt, indem<br />
es Orte durch eindimensionale Koordinatentupel<br />
bzw. -tripel, also als Punkte im Koordinatensystem<br />
repräsentiert.<br />
Die zweite Möglichkeit, eine Objekt-Ort-<br />
Beziehung zu beschreiben, ist das Containment.<br />
Hier verhält es sich wie bei der geographischen<br />
Position, d.h. ein Ort umschließt<br />
untergeordnete Objekte wie ein<br />
Container. Beispielsweise ist der Ort Frankfurt.Flughafen.Terminal2<br />
ein Container für<br />
die Personen, Gegenstände und Räume,<br />
die sich dort befinden. Untergeordneten Objekte<br />
können wiederum einen Container<br />
für andere Objekte darstellen (z.B. Frankfurt.Flughafen.Terminal2.Gate3).<br />
Sie können,<br />
müssen aber nicht zwingend in einer<br />
hierarchischen Beziehung zueinander stehen.<br />
Bei dieser Möglichkeit wird die Auflösung<br />
der Ortsbestimmung durch die Größe<br />
des entsprechenden Containers bestimmt,<br />
somit führt eine Verkleinerung der Containergröße<br />
zu einer Erhöhung der Auflösungsgenauigkeit.<br />
Typischerweise verbindet man das<br />
Containment mit dem Symbolischen Modell<br />
(siehe Kapitel 6.2.2). Es kann sich jedoch<br />
auch auf das Geometrische Modell beziehen,<br />
wenn die Position durch ein n-Tupel (mit<br />
n>2) definiert wird. [Dom02]<br />
6.1.3 Der Entfernungsaspekt<br />
6.1 Einleitung<br />
Die Entfernung ist einer der wichtigsten Begriffe<br />
des Location Modelings. Sie legt Beziehungen<br />
zwischen zwei oder mehreren beliebigen<br />
Objekten, unabhängig von ihrer hierarchischen<br />
Position fest und lässt die Verarbeitung<br />
von Anfragen der Art ’Wo ist der nächstgelegene<br />
Bahnhof?’ zu.<br />
Wie im Kapitel 6.2 erklärt wird, verwenden<br />
unterschiedliche Modelle verschiedene Definitionen<br />
der Entfernung. Das Physikalische<br />
Modell zum Beispiel, nutzt im Allgemeinen<br />
die euklidische Entfernung, wobei die Entfernung<br />
beim Geometrischen Modell nicht vordefiniert<br />
ist. Sie ist jedoch durch die Aneinanderreihung<br />
von Teilfolgen von Entfernungswerten<br />
und durch die Abhängigkeit zwischen<br />
einer Wegstrecke und dem mobilen Objekt,<br />
das sich auf diesem Weg von A nach B<br />
befindet, beschränkt. Folglich hat in diesem<br />
Fall die Entfernung zwischen zwei Punkten<br />
keinen festen Wert sondern variiert mit jeder<br />
Messung, falls sie mit verschiedenen Geräten,<br />
welche ein unterschiedliches Bewegungsverhalten<br />
aufweisen, gemacht werden.<br />
So ist zum Beispiel die Entfernung von Europa<br />
nach Australien für ein Flugzeug eine<br />
andere als sie es für ein Schiff ist.<br />
Der Begriff der Entfernung ist auch sehr<br />
stark mit dem Begriff der Nähe verbunden,<br />
welcher unter dem Aspekt der Privacy bei<br />
Ubiquitous-Computing-Systemen von großer<br />
Bedeutung ist. [Dom02]<br />
85
Benjamin Bender<br />
6.2 Basic Location Models<br />
Die heute verwendeten Location Models basieren<br />
auf den, in Kapitel 6.1.1 erwähnten,<br />
intuitiven Positionsangaben, der physikalischen<br />
und der geographischen Position.<br />
Die sogenannten Basic Location Models<br />
sind jedoch abstrakter und deshalb leichter<br />
an automatische Prozesse anzupassen. Sie<br />
gliedern sich in das Geometrische Modell<br />
und das Symbolische Modell, die im folgenden<br />
vorgestellt und anhand einer Umsetzung<br />
in der Praxis verdeutlicht werden. Anschließend<br />
wird das Hybridmodell, eine Kombination<br />
aus dem Geometrischen und dem Symbolischen<br />
Modell, und dessen Realisierung,<br />
die Probability Density Functions, vorgestellt.<br />
6.2.1 Geometrisches Modell<br />
Das Geometrische Modell stellt sowohl die<br />
Orte als auch die Position der Objekte durch<br />
ein bzw. mehrere Koordinatentupel dar; konkreter<br />
ausgedrückt durch Punkte, Flächen<br />
und Räume. Dieses Modell basiert auf einem<br />
oder mehreren Referenzkoordinatensystemen,<br />
wobei es sich um globale Navigationssatellitensysteme,<br />
wie zum Beispiel<br />
das WGS-84, handelt. Diese Positionsbeschreibung<br />
hat den Vorteil, dass die Positionsgenauigkeit<br />
sehr hoch und eine einfache<br />
Kommunikationsschnittstelle gegeben<br />
ist. Diese Kommunikationschnittstelle (zwischen<br />
den Sensoren und den Anwendungen)<br />
braucht nur zu wissen, welches Referenzkoordinatensystem<br />
zugrunde liegt und<br />
kann dann Daten austauschen. Es wird jedoch<br />
ein separates Positionsverzeichnis und<br />
ein passendes Abbildungsverfahren benötigt,<br />
sobald das System dem Benutzer Informationen<br />
über seine Position veranschaulichen<br />
will, anstatt nur das Koordinatentupel<br />
auszugeben.<br />
Der größte Nachteil an diesem Modell ist<br />
die Vielzahl an Daten und Berechnungen,<br />
die schwache Geräte überlasten können, da<br />
diese in Speichergröße und Rechenleistung<br />
stark eingeschränkt sind. [Dom02]<br />
86<br />
Die wohl bekannteste praktische Anwendung<br />
dieses Modells ist das Global Positioning<br />
System (GPS). Dieses System besteht<br />
aus drei Teilbereichen, wobei der erste Teil<br />
die Satelliten umfasst. Das GPS arbeitet mit<br />
21 aktiven und drei Reservesatelliten, die in<br />
einer Höhe von 20.200 km um die Erde kreisen.<br />
Die Satelliten sind auf sechs Bahnen angeordnet,<br />
auf denen sich je vier Satelliten befinden.<br />
Die Bahnen sind zueinander um 60<br />
versetzt und um 55 zur Äquatorebene geneigt.<br />
Abbildung 68: GPS-Satelliten-Konfiguration<br />
Außerdem gibt es auf der Erde fünf gleichmäßig<br />
verteilte Kontrollstationen, die den Betrieb<br />
der Satelliten kontrollieren und steuern,<br />
wobei sich die Hauptkontrollstation in<br />
Colorado Springs (USA) befindet. Der dritte<br />
Bereich, der zu dem globalen Positionsbestimmungssystem<br />
gehört, sind die GPS-<br />
Empfänger, die sich meist in mobilen Endgeräten<br />
wie Handhelds, Mobiltelefonen oder<br />
auch Autos befinden.<br />
Jeder der 24 Satelliten benötigt 12 Stunden<br />
um die Erde zu umkreisen und somit überfliegt<br />
ein Satellit mindestens eine der fünf<br />
Kontrollstationen zweimal täglich. Die Stationen<br />
haben dadurch eine dauernde Funkverbindung<br />
zu den Satelliten und verfügen über<br />
alle Betriebsdaten einschließlich der Positionen.<br />
Die Positionen der GPS-Satelliten sind<br />
in einem Masterplan vorgegeben und werden<br />
entsprechend überwacht. Durch diesen<br />
Plan ist sichergestellt, dass an jeder Stelle
auf der Erde zu jeder Zeit wenigstens vier<br />
Satelliten empfangen werden können.<br />
Ein GPS-Empfänger besteht aus einem<br />
Funkempfänger, einer Uhr, einem Speicher<br />
mit dem GPS-Masterplan der die Position aller<br />
24 Satelliten zu jedem Zeitpunkt enthält,<br />
einer gespeicherten Weltkarte und der entsprechenden<br />
Logik. Das globale Positionsbestimmungssystem<br />
misst die Zeit, die ein<br />
Funksignal von dem Satelliten bis zum Empfänger<br />
braucht. Nachdem Funksignale eine<br />
konstante Ausbreitungsgeschwindigkeit von<br />
etwa 300.000 km/s (dies entspricht der Lichtgeschwindigkeit)<br />
haben, kann der Empfänger<br />
anhand der Laufzeit die Entfernung zu<br />
jedem Satellit in seiner Umgebung berechnen<br />
(Entfernung = Zeitdifferenz x Lichtgeschwindigkeit).<br />
Die Berechnung der Position<br />
ist dann nur noch einfache Trigonometrie.<br />
Man berechnet die Längen- und Breitengrade<br />
zunächst nur mit drei Satelliten, was für<br />
einige Empfänger ausreichend ist. Geometrisch<br />
kann man sich die Position wie folgt<br />
6.2 Basic Location Models<br />
konstruieren: Der Empfänger bestimmt über<br />
die Signallaufzeit die Entfernung zu den Satelliten<br />
in seiner Umgebung. Zieht man nun<br />
einen Kreis mit Radius der Entfernung um jeden<br />
der Satelliten, so können zwei Kreise jeweils<br />
zwei Schnittpunkte besitzen. Die wahre<br />
und die falsche Position sind jedoch meist einige<br />
tausend Kilometer voneinander entfernt.<br />
Der Empfänger löscht den unwahrscheinlichen<br />
Punkt und kann anhand der Zeit, zu der<br />
die Entfernung gemessen wurde, und dem<br />
GPS-Masterplan den richtigen Längen- und<br />
Breitengrad ausgeben. Bei der Positionsbestimmung<br />
mit vier Satelliten kann zusätzlich<br />
die Höhe über dem Meeresspiegel berechnet<br />
und die Bestimmungsgenauigkeit erhöht<br />
werden. Deshalb arbeiten die meisten neuen<br />
GPS-Empfänger mit den Entfernungsdaten<br />
von vier Satelliten. Die Bestimmung der Position<br />
erfolgt jedoch nicht geometrisch, sondern<br />
erfolgt durch eine analytische Berechnung,<br />
auf die hier nicht näher eingegangen<br />
wird. [EA02]<br />
Abbildung 69: Positionsbestimmung mit drei Satelliten<br />
87
Benjamin Bender<br />
6.2.2 Symbolisches Modell<br />
Das Symbolische Modell bezieht die Position<br />
aus abstrakten Symbolen. Die Beschreibung<br />
des Ortes und die Objektposition sind in diesem<br />
Fall verschieden, da die Position des Ortes<br />
durch eine Zone und die Position der Objekte<br />
als Mitglieder dieser Zone dargestellt<br />
werden. Diese Repräsentation der Position<br />
lässt eine Verbindung zu einem Ort einfach<br />
durch eine abstraktes Symbol oder einen Namen<br />
zu, wodurch eine sehr praktische Interaktion<br />
mit dem Benutzer entsteht. Die Ortsnamen<br />
können, wie auch bei der geographischen<br />
Position einfach hierarchisch organisiert<br />
werden. Um eine semantisch höhere<br />
Flexibilität zu erreichen, könnte man über<br />
dieses Modell noch ein zweites, zusätzliches<br />
Modell legen.<br />
Ein Schwachpunkt dieses Modells ist die unvermeidliche<br />
Beschreibung und Verwaltung<br />
der Ortsnamen. Außerdem ist die Genauigkeit<br />
dieses Modells beschränkt, da man den<br />
Raum nicht in unendlich viele Zellen zerlegen<br />
kann. [Dom02]<br />
Der GSM-Standard (Global System for<br />
Mobile Communications) und der IEEE<br />
802.11b-Standard (Wireless LAN) sind zur<br />
Zeit die bekanntesten Repräsentanten dieses<br />
Modells. Im folgenden wird allerdings nur<br />
auf den GSM-Standard eingegangen.<br />
Das GSM-Netz ist ein zellulares Netz, in dem<br />
das Nutzungsgebiet in verschiedene Zellen<br />
unterteilt wird.<br />
88<br />
In jeder dieser Zellen gibt es eine Base Transciever<br />
Station (BTS) mit mehreren Antennen,<br />
welche die digitalen Signale in analoge<br />
Signale umwandelt, einen Base Station Controller<br />
(BSC), der die Übergabe eines Gesprächs<br />
beim Zellenwechsel (Handover) regelt,<br />
und ein Mobile Switching Center (MSC).<br />
Die MSCs vermitteln die Gespräche und<br />
steuern den gesamten Gesprächsablauf. Die<br />
Daten über die Kunden oder genauer über<br />
die Chipkarte des Mobiltelefons sind in dem<br />
Home Location Register (HLR) der ’Heimatzelle’<br />
gespeichert. Die Datenbank des HLR<br />
kennt nicht nur die Kundendaten sondern<br />
weiß auch, ob das betreffende Mobiltelefon<br />
gerade eingebucht ist und wo es sich befindet.<br />
Jede Chipkarte ist eindeutig einem HLR<br />
zugeordnet. Um diese zentrale Datenbank<br />
zu entlasten, übernimmt das Visitor Location<br />
Register (VLR) einige Aufgaben, die lokal<br />
verwaltet werden können. Befindet sich<br />
beispielsweise ein Handy nicht in der Zelle,<br />
in der sich sein HLR befindet, so wird es in<br />
dem VLR der aktuellen Zelle registriert und<br />
der Eintrag des Aufenthaltortes im HLR geändert.<br />
Wird nun das Handy angerufen, so<br />
erfolgt ein gewisses Routing, das im folgenden<br />
verkürzt dargestellt wird. Der Anruf gelangt<br />
zunächst an das Gateway-MSC (GM-<br />
SC), welches sich beim Netzbetreiber befindet.<br />
Dieses kennt wiederum das Home Location<br />
Register des angerufenen Mobiltelefons.<br />
In dem HLR ist die Zelle gespeichert, bei der<br />
das Handy gerade im Visitor Location Register<br />
angemeldet ist. Der Anruf wird an das<br />
MSC dieser Zelle weitergeleitet, welches ein<br />
Paging durchführt, d.h. das Mobiltelefon wird<br />
in der Zelle ausgerufen. Darauf meldet sich<br />
das Handy bei dem MSC und nimmt den Anruf<br />
an. [Tos02]<br />
Es gibt noch weitere interessante Funktionen<br />
des GSM-Netzes, die allerdings nicht mehr<br />
im Zusammenhang mit dem Auffinden eines<br />
Mobiltelefons stehen und deswegen hier<br />
nicht behandelt werden.
6.2.3 Hybridmodell<br />
Die Kombination des Geometrischen und<br />
des Symbolischen Modells ist das sogenannte<br />
Hybridmodell, oder auch kombiniertes Modell<br />
oder halb-symbolisches Modell genannt.<br />
Ein gefundenes Objekt wird hier durch die<br />
Positionskoordinaten, wie im Geometrischen<br />
Modell, und durch die Mitgliedschaft in einer<br />
Zelle, wie im Symbolischen Modell, dargestellt.<br />
Andererseits kann der Ort ein wohldefiniertes,<br />
festes Gebiet oder ein großes, mobiles<br />
Objekt mit veränderlichen Absolutkoordinaten<br />
im Raum sein. Eventuell hat dieses<br />
mobile Objekt, dann noch ein eigenes, relatives<br />
Koordinatensystem.<br />
In diesem Modell ist die Zeit nicht als<br />
Parameter enthalten und es werden auch<br />
keine Veränderungen von Objektposition-<br />
Kompositionen zugelassen. Das heißt, dass<br />
wenn eine Verbindung zwischen zwei Objekten<br />
besteht, wie zum Beispiel die Verbindung<br />
zwischen einem Benutzer und dem Handy in<br />
seiner Tasche oder dem Benutzer und dem<br />
Raum in dem er sich befindet, dann kann diese<br />
Verbindung für diese eine Modellinstanz<br />
nicht mehr verändert werden. [Dom02]<br />
Die Probability Density Functions (<strong>PDF</strong>s)<br />
sind ein Beispiel für die Kombination des<br />
Geometrischen und des Symbolischen Modells.<br />
Sie vereinen die Vorteile beider Modelle<br />
und reduzieren somit die Messungenauigkeit.<br />
Das Geometrische Modell liefert, wie in Abschnitt<br />
6.2.1 bereits erwähnt, einen Vektor<br />
in einem n-dimensionalen Koordinatensystem<br />
als Ergebnis der Positionsbestimmung.<br />
Im einfachsten Fall ist das ein Punkt im<br />
Referenzkoordinatensystem und es ist zum<br />
Beispiel sehr einfach die Entfernung zweier<br />
Punkte im selben Koordinatensystem zu bestimmen.<br />
Falls es sich um verschiedene Koordinatensysteme<br />
handelt, ist es nicht wesentlich<br />
schwieriger, dann müssen nur die<br />
Koordinaten eines Punktes in das <strong>Format</strong><br />
des anderen Koordinatensystems transformiert<br />
werden und die Entfernungsbestimmung<br />
kann leicht durchgeführt werden. Liefern<br />
die Sensoren nicht einen Punkt sondern<br />
6.2 Basic Location Models<br />
eine mehrdimensionale Form die durch mehrere<br />
Vektoren aufgespannt wird, so ist die<br />
Berechnung von überlappenden Regionen,<br />
kürzester Wege, usw. viel komplexer, aber<br />
dennoch mathematisch lösbar.<br />
Bei Sensoren, welche die Position durch<br />
symbolische Bezeichner (vergleiche Kapitel<br />
6.2.2) ausdrücken, ist es ein bisschen komplizierter.<br />
Die Symbole können von einem<br />
Computer nicht einfach als geometrischer<br />
Vektor verarbeitet werden, auch wenn sie<br />
vom Menschen leichter zu verstehen sind<br />
als die geometrischen Koordinaten. Allgemein<br />
lässt sich sagen, dass je selbsterklärender<br />
eine Positionsbeschreibung für einen<br />
Menschen ist, desto schlechter ist sie für<br />
einen Computer als Berechnungsgrundlage<br />
nutzbar. Deshalb ist es dringend erforderlich,<br />
dass die symbolischen Bezeichnungen<br />
auf ein Referenzkoordinatensystem abgebildet<br />
werden, was für gewöhnlich durch große<br />
Datenbanken geschieht.<br />
Wie bereits erwähnt, sind Menschen mehr<br />
an symbolischen Bezeichnungen interessiert,<br />
wenn sie ein elektronisches System<br />
für die Navigation benutzen. Es ist beispielsweise<br />
viel einfacher einer Wegbeschreibung<br />
wie ’den Gang hinunter, die dritten Tür auf<br />
der rechten Seite’ zu folgen, als einen Vektor<br />
für ein bestimmtes Koordinatensystem<br />
zu erhalten. Somit ist die Abbildungsrichtung<br />
von geometrischen Vektoren auf symbolische<br />
Bezeichnungen von großem Interesse.<br />
Ein Anwendungsverfahren ist der Einsatz<br />
des Halbsymbolischen Hierarchischen Location<br />
Models. Diese Methode verwendet sogenannte<br />
SemiSymbolLocator-Objekte, die sowohl<br />
symbolische Informationen, als auch<br />
geometrische Informationen nutzt, um die<br />
Position zu repräsentieren. Das Objekt enthält<br />
außerdem Informationen über die hierarchische<br />
Einstufung (LiegtIn, Enthält, usw.)<br />
seiner Daten. Durch den Einsatz solcher<br />
SemiSymbolLocator-Objekte ist es möglich,<br />
räumliche Beziehungen wie Überlappung,<br />
Einschluß, Nachbarschaft und Entfernung zu<br />
prüfen bzw. zu berechnen.<br />
89
Benjamin Bender<br />
Jedes Navigationssystem nutzt Sensorendaten,<br />
um die aktuelle Position des Benutzers<br />
zu bestimmen und um diese Position<br />
in Relation zu seinem internen Wissen<br />
über die Umgebung zu setzen. Dieses interne<br />
Wissen wird meist durch zweidimensionale<br />
geographische Karten implementiert, welche<br />
in einer festen Verbindung zu einem Referenzsystem<br />
(z.B. WSG84) stehen. Die Abbildung<br />
erfolgt durch die Koordinatenberechnung<br />
des Punktes oder der Fläche im Referenzsystem<br />
und dem Abgleich mit den Koordinatendaten<br />
der Karte. Ein solches System<br />
kann zum einen dadurch stark verbessert<br />
werden, indem verschiedene Charakteristiken<br />
mehrerer Sensortypen in Betracht gezogen<br />
werden, da jeder Sensortyp verschiedene<br />
Stärken und Schwächen hat. Andererseits<br />
kann eine Verbesserung durch die Tatsache<br />
erzielt werden, dass Symbole jeden<br />
Charakters durch eine Superposition einer ndimensionalen<br />
Basisform modelliert werden<br />
können.<br />
Ein Sensor liefert eine Positionsinformation<br />
und einen ’Gültigkeitsbereich’ dieser Information.<br />
Dieser Gültigkeitsbereich ist hauptsächlich<br />
durch die mögliche Informationsungenauigkeit<br />
bestimmt. Der Gültigkeitsbereich<br />
kann einfachheitshalber zunächst durch eine<br />
einfache geometrische Form modelliert werden.<br />
Zum Beispiel kann die Information eines<br />
GSM-Antennen-Sektors einfach durch ein<br />
<strong>Dr</strong>eieck (2D) oder ein Zylinder-’Kuchenstück’<br />
(3D) dargestellt werden. Desweiteren können<br />
GPS-Koordinaten als Punkte und Postleitzahlenbereiche<br />
durch Polygone modelliert<br />
werden. Man kann sagen, dass jeder Sensortyp<br />
seine eigene Charakteristik hinsichtlich<br />
seines Gültigkeitsbereichs hat. Durch<br />
Kombination oder Superpositionierung von<br />
Daten anderer - oder sogar desselben - Sensortyps<br />
mit verschiedenen Charakteristiken<br />
wird die Auflösungsgenauigkeit der Ortsinformation<br />
erhöht, welche in diesem Fall<br />
einen Schnitt aller verfügbaren Sensorendaten<br />
darstellt. Ein Beispiel für die Superpositionierung<br />
verschiedener Charakteristiken<br />
desselben Sensors sind die Ringsegmente<br />
als Ergebnis der Superpositionierung<br />
90<br />
der GSM-Antennensektoren und der GSMtiming-advance-Messungen.<br />
Nicht nur Sensorendaten können durch<br />
einfache geometrische Formen modelliert<br />
werden, sondern vergleichsweise auch der<br />
Raum, der durch Symbole repräsentiert wird<br />
kann so modelliert werden. Die Idee besteht<br />
darin das Volumen des Raumes mit vielen<br />
primitiven Raumelementen von nur wenig<br />
verschiedenen Typen, wie zum Beispiel Würfel,<br />
Kugeln, usw. aufzufüllen. Man nennt dies<br />
eine ’Sammlung von Raumprimitiven’, in der<br />
die Raumelemente virtuell nebeneinander<br />
angeordnet sind, um den Raum auszufüllen.<br />
Offensichtlich nimmt die Präzision der Positionsbestimmung<br />
zu, je kleiner die Raumprimitiven<br />
gewählt werden. Innerhalb einer<br />
solchen Sammlung kann jede Raumprimitive<br />
durch eine kleine Anzahl von Parametern<br />
definiert werden. Die Sammlung ist der Rahmen<br />
für die Raumprimitiven und stellt ein absolutes<br />
Koordinatensystem für sie dar. Falls<br />
nötig, kann eine Implementation der Sammlung<br />
intern ein anderes Koordinatensystem<br />
nutzen, aber sie muss dann eine Abbildungsfunktion<br />
auf das externe Referenzkoordinatensystem<br />
bereitstellen.<br />
Der nächste Schritt, die reale Welt besser<br />
zu modellieren besteht darin, eine Überlappung<br />
der Raumprimitiven zu erlauben. Eine<br />
weitere Verbesserungen ist, die Raumprimitiven<br />
additiv or subtraktiv zu gestalten. Die<br />
Möglichkeit eine Raumprimitive von einer<br />
Sammlung abzuziehen, reduziert die benötigte<br />
Anzahl an kleinen Raumprimitven, aber<br />
die Präzision bleibt unverändert.<br />
Es bleibt jedoch noch ein Nachteil übrig,<br />
denn die Kante einer einzelnen Raumprimitiven<br />
ist scharf, d.h. wenn sie von Navigationssystemen<br />
genutzt werden ist man<br />
entweder innerhalb oder außerhalb des entsprechenden<br />
Gebietes. Deshalb werden sie<br />
auch Hard Primitives genannt. Der Nachteil<br />
wird klar, wenn man sich die Superposition<br />
zweier verschiedener Sensorinformationen<br />
mit scharfen Kanten veranschaulicht.
Abbildung 70: Konfliktsituation bei scharfen<br />
Kanten<br />
Der Empfänger eines Navigationssystems<br />
muss entscheiden, ob er innerhalb oder außerhalb<br />
eines speziellen Sektors ist. Sogar<br />
wenn der Benutzer sehr nahe an, aber dennoch<br />
außerhalb der scharfen Grenze ist, wird<br />
das Ergebnis der Positionsbestimmung unpräzise.<br />
Eine Lösung dafür bieten die sogenannten<br />
Soft Primitives. Soft Primitives werden<br />
durch Probability Density Functions (<strong>PDF</strong>s)<br />
erstellt. Die <strong>PDF</strong>s haben die gleiche Charakteristik<br />
wie die Hard Primitives. Es werden<br />
nur wenige Paramter benötigt um eine <strong>PDF</strong><br />
zu definieren: Superpositionierung ist eine<br />
einfache mathematische Operation und sie<br />
können in einem absoluten Koordinatensystem<br />
positioniert werden. Die wichtigste zusätzliche<br />
Eigenschaft der <strong>PDF</strong>s ist, dass sie<br />
besser in die reale Welt passen als die Hard<br />
Primitives. Es ist nämlich viel präziser einen<br />
Antennensektor durch eine Probability Density<br />
Function zu modellieren als durch ein<br />
<strong>Dr</strong>eieck. Wegen der mathematischen Charakteristik<br />
einer <strong>PDF</strong>, auf die hier nicht genauer<br />
eingegangen wird, existiert die Konfliktsituation<br />
der Zugehörigkeit zu einer bestimmten<br />
Raumprimitiven nicht mehr. Durch<br />
den Einsatz von <strong>PDF</strong>s, hängt jede Positionsinformation<br />
von einer Wahrscheinlichkeit ab<br />
(’Sie befinden sich mit einer Wahrscheinlichkeit<br />
von 95 Prozent im Antennensektor 47’),<br />
allerdings auch alle Verhältnisse zwischen<br />
Standortinformationen (’Das Gebiet mit 96<br />
Prozent Aufenthaltswahrscheinlichkeit ist...’).<br />
Somit muss das Navigationssystem, welches<br />
mit Soft Primitives umgeht passende Schwel-<br />
6.2 Basic Location Models<br />
lenwerte für alle Berechnungen zur Verfügung<br />
stellen.<br />
Im folgenden wird dargestellt, wie die Daten<br />
verschiedener Positionsquellen kombiniert<br />
werden um eine Probability Density<br />
Function zu erzeugen, dazu müssen jedoch<br />
zuerst einige Voraussetzungen festgelegt<br />
werden. Zuerst nimmt man an, dass<br />
die Quellen unabhängig voneinander gestört<br />
werden, d.h. jede Quelle der Positionsbestimmung<br />
wird durch unkorrelierte Fehler beeinflusst.<br />
Als Zweites wird festgelegt, dass<br />
jede individuelle Positionsfunktion oder jeder<br />
Positionssensor eine <strong>PDF</strong> der Position liefert,<br />
wobei die Position als Tripel (x,y,z) im Koordinatensystem<br />
definiert ist. Diese Probability<br />
Density Function wird als genau betrachtet,<br />
wenn sie alle Fehler der Funktion modelliert.<br />
Diese Fehler müssen technische Fehler,<br />
Messungenauigkeiten, gezielte Attacken auf<br />
das System und andere Ergeignisse beinhalten.<br />
Viele dieser Fehler verändern das Ergebnis<br />
der <strong>PDF</strong> nur wenig, aber nicht unbedeutend.<br />
Letztendlich besteht die Funktionsweise der<br />
Probability Density Functions daraus, den<br />
wahrscheinlichen Aufenthaltsort zu modellieren.<br />
Zur Positionsbestimmung modellieren<br />
sie die Daten mehrerer verschiedener Quellen<br />
und anschließend werden diese Ergebnisse<br />
übereinandergelegt.<br />
91
Benjamin Bender<br />
Als Ergebnis dieser Berechnung erhält man<br />
eine sehr genaue Position, mit einer sehr geringen<br />
Abweichung, da die Aufenthaltsmöglichkeiten<br />
vieler unabhängiger Quellen meist<br />
nur eine kleine Schnittmenge haben. Die Ergebnisgenauigkeit<br />
dieser Funktionenkombination<br />
wird durch eine größere Anzahl an<br />
verschiedenen Quellen erhöht. [T.S02]<br />
92
6.3 Modellentwicklungen<br />
Die Location Models sind ein wichtiger Punkt<br />
für kontextbasierte Anwendungen, die sich<br />
in modellbasierte Anwendungsumgebungen<br />
gliedern lassen. Im Folgenden wird diese<br />
Gliederung vorgenommen und zwei Methoden<br />
der Positionsinformationsmodellierung<br />
vorgestellt. Die modellbasierten Anwendungsumgebungen<br />
lassen sich in drei Klassen<br />
gliedern, die Infrastrukturbasierten, die<br />
Ad-hoc-Netzwerk-basierten und die Isolierten<br />
Anwendungsumgebungen. Diese werden<br />
in diesem Kapitel vorgestellt und ihre<br />
Funktionsweise erklärt.<br />
Die Infrastrukturbasierten Anwendungsumgebungen<br />
speichern Umgebungsdaten<br />
in einer global verfügbaren Datenbank, wodurch<br />
es verteilten Anwendungen ermöglicht<br />
wird, in Abhängigkeit von der konkreten Umgebung<br />
und ihrer Position mit der Anwendungsumgebung<br />
zu interagieren.<br />
Abbildung 71: Darstellung einer Infrastrukturbasierten<br />
Umgebung<br />
Mobile Geräte benötigen in diesen Systemen<br />
einen Zugang zur Infrastruktur um auf die gespeicherten<br />
Umgebungsdaten zugreifen zu<br />
können. Solche mobile Knoten müssen ihre<br />
Positionsinformationen der Infrastruktur mitteilen,<br />
damit sie von ihr positionsabhängige<br />
Informationen erhalten können. Deshalb<br />
müssen die mobilen Geräte ihre geometrische<br />
Position über GPS oder ähnliche Sy-<br />
6.3 Modellentwicklungen<br />
steme erhalten. Diese Klasse von Anwendungen<br />
wird durch die zentrale Speicherung<br />
der Umgebungsinformationen charakterisiert<br />
und die verteilten Anwendungen basieren<br />
auf der Konsistenz dieser Informationen. Die<br />
lokale Speicherung von Daten wird hauptsächlich<br />
aus Geschwindigkeitsgründen genutzt<br />
oder um eine Partitionierung des Netzwerks<br />
in gleichberechtigte Teile in Betracht<br />
zu ziehen. Ein Beispiel für dieses Verfahren<br />
ist das NEXUS-System, welches im Abschnitt<br />
6.4.1 näher beschrieben wird.<br />
Die Ad-hoc-basierten Anwendungsumgebungen<br />
setzen, wie der Name schon sagt,<br />
auf mobilen Ad-hoc-Netzwerken (MANETs)<br />
auf. MANETs sind durch mobile Knoten, ohne<br />
festvorgegebene Position, aufgebaut, wodurch<br />
sie hochdynamisch sind. Diese Knoten<br />
sind kleine Computer, wie zum Beispiel<br />
SmartThings, Mobiltelefone oder PDAs.<br />
Abbildung 72: Darstellung einer Ad-hocbasierten<br />
Umgebung<br />
Die Interaktion dieser Geräte hängt von der<br />
Umgebung ab, in der sie sich befinden. Eine<br />
Langstreckenkommunikation ist aus finanziellen<br />
Gründen und auf Grund des Energieverbrauchs<br />
nicht von Interesse. Die Abhängigkeit<br />
von lokal verfügbaren Daten trägt<br />
dazu bei, den Stromverbrauch zu optimieren.<br />
Desweiteren sind solche Geräte typischerweise<br />
mit einem Benutzer festverbunden,<br />
folglich können die verfügbaren Dienste<br />
in seiner Umgebung ihn effizient durch<br />
eine unbekannte Gegend führen oder ihm eine<br />
Vielzahl von Informationen zur Verfügung<br />
93
Benjamin Bender<br />
stellen. Die Speicherung der Informationsdaten<br />
bei den mobilen Ad-hoc-Netzwerken ist<br />
anders als bei der Infrastrukturbasierten Methode.<br />
Bei MANETs ist es, wegen der Partitionierung<br />
des Netzwerks, nicht möglich von<br />
jedem Ort im Netzwerk auf alle Daten zuzugreifen.<br />
Deshalb müssen Anwendungen,<br />
die Umgebungsdaten benötigen, diese Daten<br />
lokal speichern. In dieser Anwendungsumgebung<br />
können verschiedene Anwendungen<br />
auf unterschiedlichen Geräten mit unterschiedlichen<br />
Zuständen derselben Umgebung<br />
arbeiten, d.h. die Daten müssen nicht<br />
konsistent sein. Im Abschnitt 6.4.2 wird das<br />
CANU-Verfahren erklärt, welches eine verteilungsbasierte<br />
Methode zur Aktualisierung<br />
der Positionsinformation verwendet.<br />
Bisher wurden Anwendungen beschrieben,<br />
die sich die selben Umgebungsdaten teilten,<br />
entweder in einem zentralen oder verteilten<br />
Datenspeicher. Bei der Isolierten Anwendungsumgebung<br />
handelt es sich um eine<br />
andere Art von Anwendung, die ihre Umgebungsdaten<br />
nicht teilt, sondern ausschließlich<br />
von ihren eigenen lokalen Daten abhängt.<br />
Inkonsitenzen kommen - zumindest<br />
aus Sicht einer Anwendung - hier nicht vor,<br />
denn Entscheidungen, die auf der Umgebung<br />
basieren, hängen von den lokal gespeicherten<br />
Daten ab. Beispiele für solche<br />
Anwendungen kommen aus dem Gebiet der<br />
Roboter, in dem die Geräte meist autonom<br />
sind. Das Gerät enthält Daten über seine<br />
Umgebung, zum Beispiel einen Fertigungsplan,<br />
und kann nur Aktionen innerhalb dieser<br />
Umgebung ausführen.<br />
Die hier aufgeführten Methoden beschreiben<br />
verschiedene Anwendungsmodelle die<br />
94<br />
auf Umgebungsdaten basieren. Positionsinformationen<br />
sind für viele Anwendungen<br />
des Ubiquitous-Computing entscheidend.<br />
Die Infrastruktur- und Ad-hoc-Verfahren werden<br />
in vielen Programmen gleichzeitig eingesetzt.<br />
Die MANETs können am besten<br />
zur Verbreitung von Informationen eingesetzt<br />
werden, die zu kurzlebig für eine zentrale<br />
Speicherung oder nur für ein kleines Gebiet<br />
von Interesse sind. Die Infrastruktur kann<br />
die Ad-hoc-Netzwerkknoten in verschiedenen<br />
Gebieten mit Modelldaten versorgen, damit<br />
diese genaue Daten über ihre Umgebung<br />
an die mobilen Knoten weitergeben können.<br />
Deshalb ist es erstrebenswert eine Integration<br />
zu erzielen. [K.R02]<br />
6.3.1 Location Models in<br />
infrastrukturbasierten<br />
Anwendungen: Das NEXUS-Modell<br />
Die Aufgabe des NEXUS-Projekts besteht<br />
darin, eine offene Plattform für ortsbezogene<br />
Anwendungen zu schaffen. Das Ziel einer<br />
solchen Allgemeinplattform ist es eine<br />
Grundlage bereitzustellen, welche die Entwicklung<br />
von positionsbasierten Anwendungen<br />
erleichtert und eine bessere Integration<br />
der Anwendungen sowie eine bessere Interaktion<br />
zwischen den Anwendungen ermöglicht.<br />
Im folgenden werden die Gebiete betrachtet,<br />
die für die Modellierung der Position<br />
von Bedeutung sind.<br />
Der Kern der NEXUS-Plattform ist ein gemeinsames<br />
erweitertes Weltmodell (augmented<br />
world model), welches dem kompletten<br />
Positionszusammenhang für kontextbasierte<br />
Anwendungen liefert.
Abbildung 73: Das erweiterte Weltmodell in NEXUS<br />
Dies beinhaltet die Repräsentation von statischen<br />
realen Objekten wie Häuser, Straßen<br />
und Büros, mobilen Objekten wie menschliche<br />
Benutzer, Autos, Züge, aber auch<br />
von virtuellen Objekten (Virtual Information<br />
Towers - VITs), um welche die reale Welt<br />
erweitert wird. Beispiele für virtuelle Objekte<br />
sind virtuelle Reklametafeln, virtuelle Postits<br />
oder virtuelle Kioske, an denen ortsspezifische<br />
Produkte oder Informationen angeboten<br />
werden.<br />
Das Weltmodell wird aufgeteilt und von verschiedenen<br />
Providern angeboten, zum Beispiel<br />
könnte die Stadt <strong>Ulm</strong> ein Modell von<br />
ganz <strong>Ulm</strong> mit einer Genauigkeit von Häusern<br />
und Straßen anbieten. Die <strong>Universität</strong> <strong>Ulm</strong><br />
könnte ein detailliertes Modell mit Informationen<br />
über die Gebäude auf dem Campus<br />
zur Verfügung stellen und die Fakultät für Informatik<br />
einen detaillierten Plan ihres Gebäudes<br />
mit allen Hörsälen und Büros anbieten.<br />
Das erweiterte Weltmodell wird in NEXUS<br />
durch die Augmented World Modeling Language<br />
(AWML) beschrieben und Positionsanfragen<br />
an das Modell können mit der Augmented<br />
World Querying Language (AWQL)<br />
gestellt werden.<br />
Objekte in AWML haben Attribute, die ihre<br />
Position und ihre Form in Relation zu irgend-<br />
6.3 Modellentwicklungen<br />
einem Koordinatensystem angeben. Für diese<br />
Objektbeschreibung wird die Geographic<br />
Markup Language (GML), eine XMLbasierte<br />
Sprache, verwendet. Das GML-<br />
Positionsschema enthält Punkte, Linien und<br />
Polygone als geometrische Basiselemente,<br />
aber auch geometrische Collections, wie<br />
Multipunkte, Multilinien und Multipolygone.<br />
GML definiert kein festes Koordinatensystem,<br />
sondern ein räumliches Referenzsystem,<br />
bezüglich dem die Koordinaten definiert<br />
werden. NEXUS verwendet eine Vielzahl<br />
unterschiedlicher Koordinatensysteme,<br />
wie zum Beispiel WGS84-Koordinaten, die<br />
auch GPS nutzt, aber auch Gauss-Krüger<br />
und UTM-Koordinaten, die hauptsächlich für<br />
Karten verwendet werden und desshalb oft in<br />
geographischen Informationssystemen gefunden<br />
werden. In manchen Fällen kann es<br />
auch nötig sein ein lokales Koordinatensystem<br />
zu benutzen, beispielsweise wenn Positionen<br />
in Objekten, wie zum Beispiel Schiffen,<br />
definiert werden sollen, die sich im globalen<br />
Koordinatensystem bewegen. Die Modellierungssprache<br />
AWML modelliert nicht<br />
nur die geographische Position und die Form<br />
des Objekts, sondern auch symbolische Bezeichner<br />
der Objekte, wie Raumnummern,<br />
und explizite Beziehungen zwischen Objek-<br />
95
Benjamin Bender<br />
ten, wie die IstTeilVon-Beziehung. Dies ist<br />
besonders dann wichtig, wenn verschiedene<br />
Teile des Modells verbunden werden, die von<br />
verschiedenen Providern angeboten werden.<br />
Die Anfragesprache AWQL gestattet Anfragen<br />
an das Weltmodell nach Objekten,<br />
die mit einigen Einschränkungen behaftet<br />
sind. Diese Einschränkungen beinhalten<br />
räumliche Beziehungen zu anderen<br />
Objekten, wie LiegtIn, ÜberlapptMit, Enthält,<br />
SchliesstAus und NächstNäheres. Sie<br />
können jedoch mit booleschen Ausdrücken<br />
kombiniert werden. Zusätzlich unterstützt die<br />
Sprache Generalisierungs- und Aggregationsregeln,<br />
welche das Löschen von kleinen<br />
Details und das Verschmelzen kleiner<br />
Objekte zu größeren Objekten ermöglichen.<br />
Es wäre zum Beispiel viel zu aufwendig<br />
auf einer Karte jedes Haus detailliert einzuzeichnen,<br />
stattdessen werden die Häuser als<br />
Blöcke dargestellt bzw. mehrere Häuser zu<br />
einem großen Block zusammengefasst.<br />
Informationen über die aktuelle Position von<br />
mobilen Objekten erhält man von vielen verschiedenen<br />
Sensorsystemen, diese reichen<br />
von GPS oder Ähnlichem im Freien bis zu<br />
Infrarot- und Funksystemen in Gebäuden.<br />
Auf Grund der verschiedenen Charakteristiken<br />
dieser Sensorsysteme und der Updaterate<br />
muss die NEXUS-Plattform mit vielen<br />
verschiedenen Genauigkeitsstufen arbeiten.<br />
Außerdem muss sie Parameter zur Verfügung<br />
stellen, die es dem Benutzer ermöglichen<br />
die Art und den Umfang des Ergebnisses<br />
auf seine Anfrage zu spezifizieren.<br />
[K.R02]<br />
6.3.2 Location Models in mobilen<br />
Ad-hoc-Netzwerken: Das<br />
CANU-Modell<br />
Das CANU-Projekt (Communication in Ad<br />
Hoc Networks for Ubiquitous Computing)<br />
verfolgt das Ziel Anwendungen in mobilen<br />
Ad-hoc-Netzwerken zu unterstützen. Ähnlich<br />
wie beim NEXUS-Projekt basieren die Anwendungen<br />
bei CANU auf Modelldaten ihrer<br />
96<br />
Umgebung. Die mobilen Netzwerkknoten haben,<br />
wie es für ein Ad-hoc-Netzwerk charakteristisch<br />
ist, keinen Zugriff zu einem zentral<br />
gespeicherten Weltmodell, wie es bei NE-<br />
XUS der Fall ist. Deshalb müssen wichtige<br />
Teile dieses Modells auf jedem Netzwerkknoten<br />
gespeichert werden.<br />
Die CANU-Umgebung besteht aus beweglichen<br />
Netzwerkknoten, die sich in einem<br />
mobilen Ad-hoc-Netzwerk (MANET) befinden.<br />
Dieses Netzwerk wird durch mobile Geräte,<br />
wie Mobiltelefone oder PDAs, welche<br />
die Benutzer bei sich haben, aufgespannt.<br />
Die Geräte verfügen über eine Kurzstreckenfunkeinheit,<br />
wie Bluetooth oder IEEE 802.11<br />
(WLAN) im Peer-to-Peer-Modus und können<br />
zusätzlich ihre Position bestimmen. Einer<br />
der Hauptpunkte von CANU ist, dass sich<br />
die Menschen nicht einfach ziellos bewegen,<br />
sondern ein bestimmtes Ziel haben oder zumindestens<br />
an feste Wege in ihrer Umgebung<br />
gebunden sind. Somit kann diese Information<br />
dazu genutzt werden einen Übertragungsweg<br />
für den Datentransport in MA-<br />
NETs zu finden.<br />
Die CANU-Netzwerkknoten erhalten Modelldaten<br />
aus ihrer Umgebung, und zwar entweder<br />
durch eine feste Infrastruktur, falls eine<br />
vorhanden ist, zum Beispiel beim Betreten<br />
eines Gebäudes, oder von anderen mobilen<br />
Netzwerkknoten. Das Fundament einer<br />
CANU-Anwendungen ist die räumliche Umgebung,<br />
beispielsweise ein Kartenausschnitt<br />
oder ein Gebäudeplan. Man nennt dies auch<br />
das räumliche Weltmodell. Das Modell wird<br />
intern als Graph repräsentiert, wobei die<br />
Knoten den Räumen, Gebäuden oder anderen<br />
Orten entsprechen und die Kanten Verbindungen<br />
zwischen den Orten darstellen.<br />
Dieses Raummodell ist die Grundlage für<br />
alle anderen Informationen die den CANU-<br />
Anwendungen zur Verfügung stehen. Die Information<br />
soll im CANU-Modell mit einem Ort<br />
fest verknüpft sein, d.h. sie ist mit einem Knoten<br />
im Raummodell verbunden. Das Raummodell<br />
dient den Anwendungen als lokales<br />
Weltmodell und nimmt Anfragen über Objekte<br />
entgegen.
Anwendungsspezifische Anfragen können in<br />
Bezug auf das Raummodell auch realisiert<br />
werden. Ein einfaches Beispiel ist eine Navigationsanwendung<br />
für ein Gebäude oder<br />
einen Flur. Wichtige Objekte sind mit einer<br />
Verknüpfung auf ihre Position im Raummodell<br />
gespeichert. Somit sind Positions- bzw.<br />
Relationsanfragen, wie zum Beispiel ’Wo bin<br />
ich?’, ’Wer/Was ist hier?’, ’Wo finde ich...?’<br />
möglich.<br />
Wenn zwei Netwerkknoten aufeinandertreffen,<br />
aktualisieren sie gegenseitig ihre Informationen.<br />
Wie Experimente gezeigt haben<br />
verbreiten sich die Daten, in einem typischen<br />
Szenario eines Gebäudes, durch einen einfachen<br />
Diffusionalgorithmus mit einer vertretbaren<br />
Geschwindigkeit. So verzögert sich<br />
beispielsweise die Aktualisierung der Daten<br />
in einem dreistöckigen Gebäude mit hundert<br />
Netzwerkknoten durchschnittlich um 39 Sekunden.<br />
Dadurch können Anfragen und Daten<br />
gezielt dorthin weitergeleitet werden, wo<br />
die entsprechenden Informationen gespeichert<br />
sind oder benötigt werden.<br />
Letztendlich bietet das Raummodell von CA-<br />
Literatur<br />
6.4 Abschlussbemerkung<br />
NU einen Rahmen für Daten von lokalem<br />
Interesse, welche als Grundlage für anwendungsspezifische<br />
Anfragen in mobilen<br />
Ad-hoc-Netzwerken genutzt werden können.<br />
[K.R02]<br />
6.4 Abschlussbemerkung<br />
Seitdem die Basic Location Models 1997/98<br />
systematisch beschrieben wurden, haben<br />
sich viele ihrer Anwendungen und auch neue<br />
Modellentwicklungen durch die vielen vorhandenen<br />
kleinen, mobilen, allgegenwärtigen<br />
Geräte, in Richtung neuer Anwendungsfelder<br />
bewegt. Die heutigen Location Models<br />
ermöglichen die Darstellung des Raumes,<br />
der Position von Objekten und auch Beziehungen<br />
zwischen ihnen, aber die Genauigkeit<br />
und das Anwendungsangebot muss<br />
noch verbessert bzw. erweitert werden. Es<br />
gibt bereits gute Ansätze dafür, allerdings ist<br />
für diese Ansätze noch nicht sichergestellt,<br />
ob sie sich überhaupt umsetzen lassen und<br />
dann auch entsprechend genutzt werden.<br />
[Bec02] Christian Becker: Weltmodelle zur Unterstützung Kontext-bezogener Systeme.<br />
http://www.ijg.uni-freiburg.de/telematik/lehre/<br />
ringvorlesungen/dozent/% SS02/RingVL_Christian%20Becker.pdf,<br />
2002.<br />
[Dom01] Svetlana Domnitcheva: Basic Location Models - Extentions and Challenges.<br />
http://www.inf.ethz.ch/vs/publ/slides/ubicomp2001-location.<br />
pdf, 2001.<br />
[Dom02] Svetlana Domnitcheva: Location Modeling:State of the Art and Challenges.<br />
http://www.tik.ee.ethz.ch/~beutel/projects/picopositioning/<br />
ubicomp01-l% ocation-modeling.pdf, 2002.<br />
[EA02] E-Agrar: Das Meisterwerk aus Zeit und Weg. http://www.e-agrar.at/<br />
gpsfachwissen/SofunktioniertGPS.htm, 2002.<br />
[Geo02] Michael Schulz Geosoft: Was ist GPS? http://www.geosoft-gps.de/gps_<br />
infos/info_1.html, 2002.<br />
97
Literatur<br />
[K.R01] M.Bauer C.Becker K.Rothermel: Location Models from the Perspective of<br />
Context-Aware Applications and Mobile Ad Hoc Networks. http://www.<br />
informatik.uni-stuttgart.de/ipvr/vs/de/people/mabauer/Prese%<br />
ntations/LocationModels.pdf, 2001.<br />
[K.R02] M.Bauer C.Becker K.Rothermel: Location Models from the Perspective of Context-<br />
Aware Applications and Mobile Ad Hoc Networks. ftp://ftp.informatik.<br />
uni-stuttgart.de/pub/library/ncstrl.ustuttgart_fi% /INPROC-<br />
2001-36/INPROC-2001-36.pdf, 2002.<br />
[P.R02] K.Wendlandt A.Ouhmich M.Angermann P.Robertson: Implementation of Soft Location<br />
on mobile devices. http://www.heywow.com/download/inloc.pdf,<br />
2002.<br />
[Tos02] Toshiba: Teil 2:Im Detail - so funtioniert GSM. http://computer.<br />
toshiba.de/cgi-bin/ToshibaCSG/download_whitepaper.jsp?%<br />
z=90&WHITEPAPER_ID=GPRS2, 2002.<br />
[T.S02] M.Angermann J.Kammann P.Robertson A.Steingaß T.Strang: Software Representation<br />
for Heterogeneous Location Data Sources Using Probability Density Functions.<br />
http://www.heywow.com/download/loce01pa.pdf, 2002.<br />
98
7 Location based services (LBS)<br />
Zusammenfassung<br />
Location based services (LBS) befinden<br />
noch in den Startlöchern und die<br />
Entwicklungsrichtungen sind noch unklar.<br />
Nicht nur die rechtlichen Unsicherheiten<br />
auf Seiten der Anbieter verhindern<br />
eine größere Anzahl Dienste, auch die<br />
zurzeit begrenzte technische Ausstattung<br />
auf Seiten der Kunden lassen noch keine<br />
richtige Freude beim Endanwender für<br />
LBS aufkommen. Heute gestartete Dienste<br />
müssen einen langen Atem beweisen<br />
bis endlich die Erwartungen der Analysten<br />
eintreten. Setzen sich aber LBS<br />
einmal durch, dann besteht die Chance,<br />
dass wenigstens bei mobilen Endgeräten<br />
der Datendschungel durch bessere Personalisierung<br />
kleiner wird. Wobei aber die<br />
Nachrichten Mailbox nicht so enden darf,<br />
wie es zurzeit die all morgendliche E-Mail<br />
Box am Computer tut.<br />
7.1 Motivation<br />
7.1.1 Zukünftige Nutzer<br />
Eine deutsche Online Umfrage zum Thema<br />
LBS ergab, dass ein großer Teil der zukünftigen<br />
Nutzer noch nicht weiß, um was es sich<br />
bei LBS genau handelt. Bei einer abstrakten<br />
Vorstellung des Themas wollen immerhin<br />
schon 40% der Befragten diese Dienste<br />
nutzen. Mehr als 30% können sich darunter<br />
aber nichts vorstellen. Das Blatt wendet<br />
sich schlagartig, wenn konkrete Beispiele<br />
eingeführt werden. Danach wollen dann ganze<br />
80% LBS nutzen. Hier wird deutlich, dass<br />
aufgrund der wenigen Dienste die Verbraucherinformationen<br />
noch gering sind. Der Nutzen<br />
wird für den Kunden aber schnell durch<br />
12 Global Positioning System<br />
<strong>Alexander</strong> Traud<br />
alexander.traud@informatik.uni-ulm.de<br />
Beispiele aus dem Alltagsleben deutlich.<br />
Die zukünftigen Nutzer verknüpfen auch Sorgen<br />
mit den Standort bezogenen Diensten:<br />
77% der Befragten lehnen Werbenachrichten<br />
auf Basis von LBS ab. Dieses Ergebnis<br />
liegt auch nahe, da die Teilnehmer der<br />
Umfrage Internet Nutzer sind und solche Informationen<br />
mit Werbe und Spam E-Mails<br />
gleichsetzen. Um allerdings auch die breite<br />
Mobilfunknutzerschicht nicht zu vergraulen,<br />
muss innerhalb von LBS von Anfang an gewährleistet<br />
sein, dass die Werbenachrichten<br />
nicht zu oft eingesetzt werden und von hohem<br />
Nutzen für den Kunden sind. So kann<br />
man sich zum Beispiel vorstellen, dass in<br />
der Zukunft eine Akzeptanz von Werbenachrichten<br />
die monatliche Grundgebühr sinken<br />
lässt.<br />
40% würden sogar ihr Mobilfunkgerät abschaffen,<br />
falls mittels LBS von anderen der<br />
Aufenthaltsort des Nutzers bestimmbar werde.<br />
Dies ist zwar schon heute ohne LBS gegeben,<br />
zeigt aber wie wichtig dem Nutzer das<br />
Thema Datenschutz ist.<br />
[EMN02]<br />
7.1.2 Marktpotenzial<br />
LBS befindet sich zurzeit noch in den Startlöchern.<br />
GPS 12 gestützte Verkehrsnavigation<br />
wird langsam Standard. Zellen basierte Mobilfunk<br />
Lokalisierung ist erst letztes Jahr eingeführt<br />
worden. Die Dienste sind noch dünn<br />
und nur vereinzelt verfügbar.<br />
Es besteht aber ein großes wirtschaftliches<br />
Potenzial für die Zukunft. So schätzte die<br />
Strategis Group bereits im Jahr 2000 den<br />
Umsatz von LBS im Mobilfunk in Europa bis<br />
zum Jahr 2005 auf über 80 Milliarden Euro.<br />
99
<strong>Alexander</strong> Traud<br />
So soll die Zahl der LBS Nutzer von 2 Millionen<br />
auf über 200 Millionen im Jahr 2005<br />
ansteigen. Fast 100 Millionen - die Hälfte<br />
aller Nutzer - sollen davon sogar Standort<br />
basierte Abrechnungssysteme und Werbenachrichten<br />
akzeptieren.<br />
Aufgrund der veränderten weltwirtschaftlichen<br />
Lage und der zurzeit nur sehr langsamen<br />
Einführung von LBS dürften sich diese<br />
Erwartungen nach hinten korrigieren und erst<br />
fünf Jahre später erreicht werden, was immer<br />
noch ein gewaltiges Wachstum und einen hohen<br />
Umsatz verspricht.<br />
[Gro00]<br />
7.1.3 LBS als Verbindung vorhandener<br />
Informationen<br />
’Unter LBS (deutsch: Standort bezogene<br />
Dienste) sind alle Anwendungen zu verstehen,<br />
welche die Position des Teilnehmers mit<br />
einbeziehen, um ihm spezifische Inhalte zur<br />
Verfügung zu stellen.’<br />
LBS bestehen nicht nur aus den Informationen<br />
über den Standort. LBS zeichnen sich<br />
dadurch aus, dass vorhandene Informationen<br />
und Datenbanken verknüpft, mit den lokalen<br />
Daten personalisierter durchsucht und<br />
präsentiert werden können. Man kann LBS<br />
als aktive Datenfilter ansehen, welche die gesuchten<br />
Informationen schneller liefern. Leidige<br />
Eingaben wie zum Beispiel von Postleitzahlen<br />
oder Stadtnamen entfallen. Die Postleitzahl<br />
des Aufenthaltsortes wäre dem Nutzer<br />
auch meist nicht bekannt und einfache<br />
Tippfehler können dazu führen, dass das System<br />
denkt man halte sich bis zu 500 Kilometer<br />
weiter entfernt auf. Auch der Name der<br />
Lokalität führt zu langen textuellen Eingaben,<br />
die auf vielen mobilen Endgeräten eine gewisse<br />
Kenntnis über das Gerät und dessen<br />
Texteingabe voraussetzen bzw. selbst dann<br />
eine zeitliche Qual darstellen.<br />
Die Information über den Standort des Nutzers<br />
entwickelt sich somit zu einem kritischen<br />
Faktor. Der Benutzer kommt schneller an die<br />
für ihn relevanten Informationen. LBS ist das<br />
Stück im Puzzle, damit neue Nutzerschichten<br />
bestimmte Informationen suchen.<br />
Wenn man heute im Auto fährt, nicht mehr<br />
genau weiß wo es lang geht und den Weg<br />
wissen will, dann liegt es nahe den nächsten<br />
Passanten anzusprechen. Nur manchmal ist<br />
keiner da. LBS kann hier durch genaue Navigationssysteme<br />
dieses Problem lösen. Verbunden<br />
mit anderen Datenbanken und Informationen<br />
ist es auch möglich nicht nur<br />
den kürzesten Weg aufzuzeigen, sondern<br />
den gerade zu diesem Zeitpunkt schnellsten,<br />
wenn zum Beispiel ein Stau oder ein Unfall<br />
auf der ursprünglichen Strecke ist.<br />
M-Commerce (mobiles Einkaufen) wird einfacher.<br />
Man stelle sich ein Verzeichnis in der<br />
Art der Gelben-Seiten vor. Man steht in Mitten<br />
einer fremden Stadt und sucht den nächsten<br />
<strong>Dr</strong>ogeriemarkt. 5-10 Klicks im Handy<br />
und schon erfährt man, dass ein Geschäft<br />
nur 100 Meter entfernt ist. Ohne LBS wäre es<br />
ein elendiges Getippe geworden, oder man<br />
hätte gleich den nächsten Passanten gefragt,<br />
der es vielleicht auch nicht gewusst hätte.<br />
Gezieltere Werbung ist ebenso denkbar. Informationen<br />
werden präsentiert, die man<br />
vielleicht gar nicht von sich ausgesucht hätte.<br />
Diese Nachrichten müssen nicht einmal aufdringlich<br />
sein. Man geht an einem Geschäft<br />
vorbei und eine kleine Werbenachricht informiert<br />
zum Beispiel über den aktuellen Preisnachlass<br />
bei einer Karibikreise - kommt doch<br />
eigentlich ganz gelegen. Information zu kulturellen<br />
Einrichtungen oder Gebäuden werden<br />
angezeigt, wenn man sich in deren Nähe<br />
befindet.<br />
Ganz neue Möglichkeiten ergeben sich im<br />
Bereich Entertainment besonders bei Spielen,<br />
dazu gibt es später ein Fallbeispiel.<br />
Instant Messaging (Chat) werden durch Informationen<br />
über den Standort angereichert.<br />
So wie man sich zum Beispiel in ICQ auf<br />
sichtbar stellt, kann man auch gewissen vertrauenswürdigen<br />
Kontakten erlauben, Einsicht<br />
in den jeweiligen Standort zu geben.<br />
Durch die Verbreitung von Java ME und<br />
GPRS 13 ist es schon heute möglich, einen<br />
13 General Packet Radio Service: relativ schneller Paket-orientierter Übertragungsstandard im GSM Mobilfunk<br />
100
Instant Messaging Klienten im Mobilfunkgerät<br />
zu haben.<br />
Dies kann durchaus Sinn machen. Die erste<br />
Frage am Festnetztelefon lautet meist, wie es<br />
denn dem Gesprächspartner gehe, am Han-<br />
7.2 Überblick<br />
7.2 Überblick<br />
dy ist die erste Frage meist, wo denn der Gesprächsteilnehmer<br />
gerade sei. Der Standort<br />
wird durch mobile Endgeräte und Dienste zu<br />
einem kritischen Faktor.<br />
[Eri01]<br />
Abbildung 74: LBS - das verbindende Stück im Puzzle<br />
Welche Netzwerklösungen werden für welche<br />
Dienste gewünscht?<br />
Nicht alle LBS brauchen die gleiche Auflösung<br />
des Standortes des Benutzers. Es<br />
hängt vom Aufenthaltsort ab, wie genau der<br />
Standort ermittelt werden sollte. Hier hat der<br />
Mobilfunksektor einige Vorteile, denn innerhalb<br />
der Stadtzentren, kann aufgrund des Telefonieraufkommens<br />
und der maximalen Kapazität<br />
von knapp 60 Verbindungen pro GSM<br />
Basisstation, die Genauigkeit der Zellen basierten<br />
Ortung weit genauer sein, als auf<br />
ländlichen Gebieten, wo eine Basis manchmal<br />
Radien bis zu 15 Kilometer abdecken<br />
muss.<br />
Die unten stehende Grafik macht dies deutlich.<br />
Hier sind bereits innerhalb einer Großstadt<br />
erhebliche Unterschiede in der Verkehrsdichte<br />
(Telefonieraufkommen) zu verzeichnen.<br />
Ein Netzbetreiber analysiert solche<br />
Daten und baut seine Basen für eine<br />
adäquate Versorgung auf. In diesem Kölner<br />
Beispiel werden in den Randbereichen der<br />
Stadt weniger Basen aufgestellt womit eine<br />
Zellen basierte Ortung bereits ungenauer<br />
sein wird.<br />
101
<strong>Alexander</strong> Traud<br />
Abbildung 75: Mobilfunk Verkehrsdichte in der Kölner City - Quelle E-Plus<br />
Genauigkeitsverluste geschehen nicht nur<br />
auf Seiten der Datenerhebung sondern auch<br />
bei der Verarbeitung. Hier ist nicht nur<br />
die technische Berechnung in die Lokalisierungshardware<br />
gemeint, sondern auch die<br />
Genauigkeit der Software Datenbank auf der<br />
man aufsetzt. Darüber hinaus muss auch die<br />
Benutzersoftware die vorhandene Hardware<br />
und Datenbank entsprechend voll ausnutzen.<br />
Ein Navigationssystem für das Geschäftsauto<br />
eines Außenmitarbeiters oder für das<br />
Flottenmanagement in einem LKW Fuhrpark<br />
braucht meist sehr genaue Daten über den<br />
aktuellen Aufenthaltsort, um zum Beispiel eine<br />
Weganzeige zu ermöglichen. So möchte<br />
man schon vor einer Kreuzung informiert<br />
werden, ob man nun abbiegen sollte, oder<br />
erst 50 Meter weiter bei der nächsten Kreuzung.<br />
Hier ist GPS optimal. Man befindet sich<br />
im Freien, was eine Sichtverbindung zum<br />
GPS Satellit ermöglicht und somit zu einer<br />
höheren Genauigkeit führt. Auch der Empfang<br />
mehrerer Satelliten erhöht die Genauigkeit,<br />
so dass man durch das heutige GPS<br />
Rauschen auf eine Genauigkeit der Standort<br />
Auflösung von wenigen Meter kommt.<br />
Wenn nun innerhalb des Verkehrsmittels die<br />
Datenbank, welche meist in Form einer CD<br />
im Kofferraum oder Handschuhfach vorliegt,<br />
nicht die aktuellste ist, dann kann die Strecke<br />
nicht optimal berechnet werden. Falls das<br />
Kartenmaterial oder die Software nicht die<br />
Eingabe der Hausnummer optional zur Angabe<br />
der Stadt und dem Straßennamen erlaubt,<br />
dann hilft auch das genauste Navigationssystem<br />
fast nicht mehr, da in Deutschland<br />
nicht wenige Straßen mehrere Kilometer<br />
lang sein können. Straßen ab 500 Meter<br />
sind so schon schlecht navigierbar.<br />
Navigation und Notdienste sind wichtige<br />
Dienste, die auf GPS oder A-GPS 14 angewiesen<br />
sind. Dies ist unabhängig vom Standort,<br />
sei es ländlich (rural), vorstädtisch (suburban),<br />
städtisch (urban) oder das Stadtzentrum<br />
(city).<br />
Alle anderen Mobilfunk LBS können sehr<br />
14 assisted Global Positioning System: GPS mit Berechnung des Standortes in einem Server anstatt dem GPS<br />
102<br />
Terminal selbst
wohl mit E-OTD 15 und CGI-TA 16 auskommen.<br />
Gerade letzteres ist ohne große bauliche<br />
Änderungen in jeder GSM / UMTS Basisstation<br />
nachrüstbar. Ebenso müssen die<br />
Endgeräte - also Handys - nicht erneuert<br />
werden. E-OTD bietet eine relativ genaue<br />
Positionierung, erfordert aber einen gewissen<br />
Aufwand in die Aufrüstung der GSM<br />
Netzinfrastruktur. Weiterer Nachteil besteht<br />
darin, dass dieses System neue Hardware<br />
beim Kunden erfordert und aufgrund des Datenschutzes<br />
kritisch ist, da der Benutzer laufend<br />
vom Netz aus lokalisiert wird. Es muss<br />
hier sichergestellt sein, dass die Daten nicht<br />
missbraucht werden können.<br />
Bei GPS besteht keine grundlegende Datenschutz<br />
Problematik, da GPS den Benutzer<br />
nicht lokalisiert, sondern der Benutzer lokalisiert<br />
sich selbständig durch seinen GPS<br />
Empfänger, welcher dann auf Basis der Abstände<br />
zu den jeweiligen Satelliten die Position<br />
ermittelt. Sollte der Einbau von GPS<br />
7.2 Überblick<br />
Empfängern und die Übermittlung bzw. Speicherung<br />
aber von einem Arbeitgeber vorgeschrieben<br />
sein, dann entsteht doch ein Datenschutz<br />
Problem. Auch die Motivation der<br />
Arbeitnehmer kann sinken, denn es entsteht<br />
höherer Stress immer in Aktion zu sein.<br />
Lokale Wetterinformationen, Gelben-Seiten<br />
(z.B. der nahste McDonalds) und Verkehrsinformationen<br />
(z.B. freie Parkhausplätze) sind<br />
schon heute im GSM Netz umsetzbar und<br />
werden auch bereits angeboten. Aus Kundensicht<br />
ist eine genauere Standorterfassung<br />
angenehmer, denn es besteht die Möglichkeit,<br />
dass die LBS bessere personalisierte<br />
Daten liefern können. Viele neue und<br />
sich noch in der Entwicklung befindliche LBS<br />
brauchen auch sehr genaue Daten über den<br />
Standort des Nutzers. Folglich ist hier eine<br />
Verbesserung der Ausstattung in der Netzinfrastruktur<br />
und beim Kunden anzustreben.<br />
[Eri01]<br />
Abbildung 76: LBS in Abhängigkeit ihrer Genauigkeit<br />
15 enhanced-observed time difference: Ortungsverfahren im GSM Mobilfunk<br />
16 Cell Global Identity + Time Advance: Ortungsverfahren im GSM Mobilfunk<br />
103
<strong>Alexander</strong> Traud<br />
7.3 Applikationen (Fallbeispiele)<br />
Man kann die verschiedenen LBS auf mehrere<br />
Arten unterteilen.<br />
Zum einen nach dem Beweggrund, warum<br />
man LBS in Anspruch nimmt. Diese Art<br />
ist unterteilt in die Kategorien ’Zeit vertreibend’<br />
und ’Zeit sparend’. Bei Zeit vertreibenden<br />
LBS handelt es sich meist um<br />
(Gesellschafts-) Spiele, bei Zeit sparenden<br />
LBS steht die Organisation von Daten um effizienter<br />
Arbeiten zu können im Vordergrund.<br />
Eine andere Art der Unterteilung der LBS besteht<br />
darin, die Geschäftsbeziehung näher<br />
zu untersuchen:<br />
Business to Consumer LBS<br />
basieren hauptsächlich auf Standort<br />
bezogene Werbenachrichten, wo zum<br />
Beispiel ein Restaurant beim Vorbeigehen<br />
auf das heutige Mittagsmenü aufmerksam<br />
macht. Dies sind meist auch<br />
’Push Dienste’, d.h. der Benutzer bekommt<br />
die Daten direkt zugesandt, ohne<br />
diese explizit in diesen Moment abgefragt<br />
zu haben.<br />
Consumer to Business LBS<br />
sind meist ’Pull Dienste’, d.h. der Kunde<br />
fragt gezielt nach einer Information<br />
bei einem Unternehmen an. So<br />
sucht der Endanwender zum Beispiel<br />
das nächst gelegene Restaurant.<br />
Consumer to Consumer LBS<br />
sind eher Fun oder Community Anwendungen,<br />
d.h. ein Endanwender sucht<br />
über sein mobiles Endgerät Gleichgesinnte,<br />
um mit diesen zu spielen, Daten<br />
auszutauschen oder einfach nur miteinander<br />
zu reden.<br />
Im weiteren folgt zu jeder Kategorie ein bereits<br />
im Markt vorhandenes Fallbeispiel:<br />
7.3.1 Zeitvertreiben (Spiele)<br />
BattleMachine von E-Plus<br />
Erobern von Land an realen Schauplätzen<br />
104<br />
Im Unterschied zu bisherigen Handy-Spielen<br />
handelt es sich bei Battle-Machine über imode<br />
um ein Spiel, das den derzeitigen Aufenthaltsort<br />
des Spielers in die Handlung einbezieht.<br />
Das heißt, die Eroberungen finden<br />
an realen Schauplätzen statt. BattleMachine<br />
teilt Deutschland in Zonen auf, die es zu erobern<br />
gilt. Der Spieler wird über sein eingeschaltetes<br />
Handy lokalisiert und kann nur um<br />
das Gebiet streiten, in dem er sich gerade<br />
befindet. Wer zum Beispiel am Düsseldorfer<br />
Hauptbahnhof auf den Zug wartet, kann eine<br />
Attacke auf den Bereich Düsseldorf - Köln<br />
starten.<br />
Neben deutschlandweiten Wettkämpfen hat<br />
der Spieler ebenfalls die Möglichkeit, gemeinsam<br />
mit Freunden eigene Eroberungen<br />
zu arrangieren. Austragungsort ist in diesem<br />
Fall nicht ganz Deutschland, sondern ein<br />
kleines Gebiet rund um die geografische Position<br />
des Angreifers. Sieger ist der Spieler,<br />
der an einem vorher festgelegten Datum die<br />
meisten Zonen erobert hat.<br />
[EP02]<br />
7.3.2 Zeitsparen (neue Organisation)<br />
Parkinfo von BMW<br />
Parkinfo reduziert überflüssigen Parkplatzsuchverkehr<br />
Mit der Integration von parkinfo.com in BMW<br />
Online stehen Informationen wie Öffnungszeiten,<br />
Preise oder freie Parkplätze von<br />
Parkhäusern bereit. Durch einfachen <strong>Dr</strong>uck<br />
auf den Controller im Auto werden die<br />
umliegenden Parkhäuser angezeigt und eine<br />
automatische Zielnavigation ermöglicht.<br />
Ca. 1.800 Parkeinrichtungen sind mit fast<br />
600.000 Stellplätzen in etwa 70 deutschen<br />
Großstädten und an 20 Flughäfen vernetzt.<br />
Nach dem Aufruf unter BMW Online können<br />
Parkinformationen um den eigenen Standort,<br />
für den im Navigationssystem eingestellten<br />
Zielort oder bezüglich einer anderen deutschen<br />
Großstadt abgerufen werden.<br />
[BMW01]
7.3.3 Business to Consumer (B2C)<br />
Ortsgebundene Werbung<br />
Der SMS-Anbieter Mobileway hat mit Celph<br />
und dem Juron Point Shoppingcenter in Singapur<br />
eine Mobile Shopping-Aktion in einem<br />
Einkaufszentrum in Singapur umgesetzt.<br />
Die Besucher erhalten zunächst eine<br />
Begrüßungs-SMS mit Informationen und einer<br />
Aufforderung zur Teilnahme. Wenn Sie<br />
zugestimmt haben, erhalten sie von Zeit zu<br />
Zeit Kurznachrichten mit Hinweisen zum Beispiel<br />
auf besonders attraktive Verkaufsangebote,<br />
jedoch nur solange der Kunde sich vor<br />
Ort aufhält und teilnehmen möchte.<br />
Aufgrund der unzähligen Shopping Center in<br />
Singapur, dient dieser neue Nachrichtenkanal<br />
zum Kunden, als sehr gutes Hervorhebungsmerkmal,<br />
um sich von anderen sehr<br />
ähnlichen Einrichtungen absetzen zu können.<br />
[Wit02]<br />
7.3.4 Consumer to Business (C2B)<br />
Herz Handy von Vitaphone<br />
Dieses Gerät verbindet die Funktionalität eines<br />
handelsüblichen GSM-Mobilfunktelefons<br />
mit der Verlässlichkeit eines technologisch<br />
ausgereiften Instruments zur ärztlichen Diagnostik:<br />
Die Aufzeichnung von EKGs: jederzeit<br />
- an jedem Ort.<br />
Die Übertragung von EKGs an das Vitaphone<br />
Service Center - mit nur einem<br />
Knopfdruck.<br />
Die Direktwahl - sie verbindet den Anrufer<br />
schnell und einfach direkt mit dem<br />
Vitaphone Service Center.<br />
Die Bestimmung des Aufenthaltsorts:<br />
Über GPS kann der Aufenthaltsort des<br />
Anrufers genau bestimmt werden.<br />
Dieses Produkt erhöht mit dieser Funktionalität<br />
die Lebensqualität, denn es ist nun auch<br />
7.4 Datenschutz Limitationen<br />
für akut Herzkranke Menschen möglich, wieder<br />
am Alltagsleben teil haben zu können.<br />
[Vit02]<br />
7.3.5 Consumer to Consumer (C2C)<br />
MobiChat von Alcatel<br />
Diese Anwendung erlaubt einer jugendlichen<br />
Zielgruppe von 12-20 Jahren Listen der bevorzugten<br />
Clubs zu erstellen bzw. eigene<br />
Clubs zu erstellen. Ein Club ist in diesem<br />
Fall eine Art kleine Community - also ein<br />
Forum zu einem bestimmten Thema. Jede<br />
Nachricht, die innerhalb dieser Clubs versandt<br />
wird, enthält über die reine Information<br />
hinaus auch Informationen bzgl. des Standortes,<br />
welche aber nur der MobiChat Server<br />
empfängt. Dieser leitet dann die Information<br />
nur an die Mitglieder des Clubs weiter, die<br />
sich in einem gewissen geographischen Radius<br />
aufhalten.<br />
Auf diese Weise ist es möglich, dass man<br />
sich aufgrund ähnlicher Neigungen treffen<br />
kann. Zum Beispiel kann man einfach einen<br />
Club eröffnen und alle Freunde und Bekannte,<br />
die gerade in der Stadt sind, werden dann<br />
automatisch zu eigenen Party am Abend eingeladen.<br />
[MAD01]<br />
7.4 Datenschutz Limitationen<br />
7.4.1 Grundlegende Bedenken<br />
Bezüglich der rechtlichen Bedenken müssen<br />
die verschiedenen Formen von LBS unterschieden<br />
werden. Zum einen gibt es die<br />
’Pull Dienste’, bei welchen der Nutzer aktiv<br />
eine gewünschte Information anfragt und<br />
gleichzeitig die Einverständniserklärung für<br />
die kurzzeitige Nutzung seiner Standortinformationen<br />
geben kann. Sehr viel interessanter<br />
sind die ’Push Dienste’. Hierbei kann<br />
es sich um das Abonnement eines Mehrwertdienstes<br />
handeln oder Standort bezogene<br />
Werbung. Push Dienste sind daher die<br />
105
<strong>Alexander</strong> Traud<br />
wirtschaftlich Gewinn bringenden Dienste,<br />
aber bergen erhebliche Datenschutzproblematiken.<br />
Die verschiedenen LBS Formen der Netzwerkoperatoren<br />
sind für die Service Angebote<br />
von <strong>Dr</strong>ittanbietern wichtig: Wird ein<br />
’Tracking’ benötigt, welches den Endanwender<br />
mit seinen Standortwechseln laufend mitprotokolliert<br />
und diese Daten weiter gibt,<br />
oder einfaches ’Routing’, wobei der Endanwender<br />
beim Aufrufen eines Dienstes einmalig<br />
seinen Standort durchgibt und daraufhin<br />
lokalisierte Daten erhält.<br />
Die Risiken von LBS sind bei allen vier Formen<br />
gegeben. So können Bewegungsprofile<br />
von Benutzern über sein Mobilfunkgerät erfasst<br />
werden. Die Abfrage der lokalisierten<br />
Informationen und das abonnieren bestimmter<br />
Dienste erlauben auch das Erstellen eines<br />
Nutzerprofils über den persönlichen Lebensstil<br />
und das Kaufverhalten. Auch kann<br />
der Eindruck des Überwachungsstaates entstehen,<br />
wenn die gesetzlichen Bedarfsträger<br />
die Daten übermäßig zur inneren Sicherheit<br />
gebrauchen. Zwar ist die innere Sicherheit<br />
heute wichtiger denn je, es müssen<br />
aber demokratische Maße eingehalten werden,<br />
besonders in Hinblick auf Freiheit und<br />
der grundsätzlichen Annahme der Unschuld<br />
des Bürgers.<br />
7.4.2 Deutschland / EU<br />
Die Rechtsgrundlagen für LBS sind in<br />
Deutschland noch nicht eindeutig geregelt<br />
und machen viele zu bezahlende Dienste<br />
noch unmöglich. Die anzuwendenden Gesetze<br />
hängen stark von Vertragspartner ab, ob<br />
es nun der Netzwerkanbieter oder ein Mehrwertdiensteanbieter<br />
ist (Service Provider).<br />
Das Hauptproblem ist die Abrechnung und<br />
Tariffierung. Standortdaten sind nach der Telekommunikations<br />
- Datenschutzverordnung<br />
(TDSV) Verbindungsdaten (§6) und es ist<br />
nicht erforderlich beim Aufbau einer Verbindung<br />
diese zu übermitteln. Auch zur normalen<br />
monatlichen Handy Abrechnung mit<br />
dem Netzwerkanbieter sind keine Standort-<br />
106<br />
informationen erforderlich. Bei einem Mehrwertdiensteanbieter<br />
sind diese Fragen schon<br />
nicht mehr so einfach zu beantworten (§7 Absatz<br />
6), da aber der Netzwerkprovider immer<br />
dazwischen geschaltet ist, entscheidet dieser,<br />
welche Daten weiter gegeben werden.<br />
Die Verarbeitung der gesamten Nutzungsdaten,<br />
also die Speicherung für interne Auswertungen<br />
sind dagegen durch das Teledienstedatenschutzgesetz<br />
(TDDSG) erlaubt, wobei<br />
hier aber Standortdaten nicht explizit erwähnt<br />
sind. Es ist damit möglich den Nutzer<br />
mit dem Umfang und den Zeitraum der LBS<br />
Nutzung zu identifizieren.<br />
Es ist daher nötig vor jeder LBS Nutzung<br />
vom Endanwender eine elektronische Einwilligung<br />
anzufordern, in der er auch über<br />
die Verarbeitungsmöglichkeiten seiner Nutzungsdaten<br />
aufgeklärt wird (§3 Absatz 5).<br />
Die Vorraussetzungen dafür sind im Telekommunikationsgesetz<br />
(TKG) §89 Absatz 10<br />
und TDSV §4 gegeben. Im §4 Nr.4 ist aber<br />
auch eine Rücknahmemöglichkeit dieser Einwilligung<br />
gegeben, welche dazu führt, dass<br />
der LBS Anbieter erst nach einer Woche eine<br />
rechtliche Grundlage erhält die Daten weiterhin<br />
zu nutzen.<br />
Somit sind viele kostenpflichtige Dienste für<br />
die Anbieter noch nicht interessant, da man<br />
keine Rechtssicherheit bei der Erbringung<br />
hat. Hier ist eine Neureglung im deutschen<br />
Recht nötig.<br />
Dieses Problem besteht in der Rechtsprechung<br />
weltweit. Da Mobilfunk Netze weltweit<br />
in hunderten von Staaten existieren, haben<br />
die Netzinfrastruktur Anbieter aufgrund der<br />
vielen unterschiedlichen Rechtslagen auch<br />
noch keine einheitliche Lösungen und Angebote,<br />
was die Verbreitung von LBS stark behindert.<br />
Hier hat die EU mit der Richtlinie 2002/58/EG<br />
vom 12. Juli 2002 die Notwendigkeit nationaler<br />
Änderungen in der Rechtsprechung noch<br />
erhöht. Artikel 9 regelt die für LBS wichtige<br />
Frage der ’Verarbeitung von Daten für die Bereitstellung<br />
von Diensten mit Zusatznutzen’.<br />
Wichtige Forderungen sind:<br />
Einwilligung durch den Nutzer erforder-
lich<br />
Vorherige Mitteilung, für welche<br />
Zwecke und wie lange Daten verarbeitet<br />
werden und ob eine Weitergabe<br />
an <strong>Dr</strong>itte erfolgt<br />
Jederzeitige Rücknahmemöglichkeit<br />
der Einwilligung<br />
Eine zeitweise Untersagung der Übertragung<br />
der Daten muss auf einfache<br />
Weise und jederzeit möglich sein<br />
Beschränkung der Verarbeitung der<br />
Standortdaten auf das erforderliche<br />
Maß.<br />
Ausgehend von diesen Unzulänglichkeiten<br />
im deutschen Recht und der Notwendigkeit<br />
von besonderen Regelungen für LBS empfiehlt<br />
der Bundesbeauftragte für den Datenschutz<br />
folgende Punkte bei der Umsetzung<br />
in ein Gesetz aufzunehmen:<br />
Literatur<br />
Keine Unterscheidung zwischen Anbieter<br />
der Mehrwertdienste und dem Netzbetreiber<br />
Ausführliche Unterrichtung und Einwilligung<br />
einmalig vor erster Inanspruchnahme<br />
eines bestimmten Dienstes<br />
Nicht eine Einwilligung für alle denkbaren<br />
möglichen Angebote<br />
Zeitweise Untersagung der Verarbeitung<br />
der Lokalisierungsdaten<br />
Rücknahme der Einwilligung (für die<br />
Zukunft).<br />
Erst wenn diese rechtlichen Problematiken<br />
im Sinne des Kunden als auch des Dienstsanbieters<br />
gelöst sind, werden sich LBS<br />
überhaupt erst durchsetzen können.<br />
[LI02]<br />
[BMW01] BMW: Telematik: Service: News: Parkinfo. http://www.bmw-telematik.de/<br />
frame/kom_03a.htm, 2001.<br />
[EMN02] TNS EMNID: Hier geht‘s lang mit den Location - based Services. http://<br />
www.emind.emnid.de/downloads/studien/20028201CT_LBS_20-08-<br />
02.pd% f, 2002.<br />
[EP02] E-Plus: Pressemitteilung BattleMachine. http://www2.eplus.de/presse/<br />
1/1_1/1_1_r2.asp?id=455, 2002.<br />
[Eri01] Ericsson: LOCATION BASED SERVICES - Motor für viele MMS-Lösungen.<br />
http://www.ericsson.de/upload/download/lbs.pdf, 2001.<br />
[Gro00] Strategis Group: Marktanalyse LBS. http://www.prnewswire.com/<br />
cgi-bin/stories.pl?ACCT=104&STORY=/www/story% /04-03-2000/<br />
0001180822, 2000.<br />
[Lev00] Sami Levijoki: Privacy vs Location Awareness. http://www.tcm.hut.fi/<br />
Opinnot/Tik-110.501/2000/papers/levijoki.pdf, 2000.<br />
[LI02] Gabriele Löwnau-Iqbal: Datenschutzrechtliche Aspekte bei Location Based Services.<br />
http://www.bfd.bund.de/aktuelles/Vortrag_Loewnau/, 2002.<br />
107
Literatur<br />
[MAD01] S. Saada M-A. <strong>Dr</strong>u: Location-based mobile services: the essentials. http://<br />
www.alcatel.com/doctypes/articlepaperlibrary/pdf/ATR2001Q1/<br />
gb/1% 4drugb.pdf, 2001.<br />
[Nok01] Nokia: White Paper: Mobile Location Services. http://www.nokia.com/pc_<br />
files_wb2/mposition_mobile_location_services.p% df, 2001.<br />
[Vit02] Vitaphone: Das Herz Handy. http://www.vitaphone.de/daskanns.htm,<br />
2002.<br />
[Wit02] Axel Witzki: Location Based Services. http://www.funkschau.de/<br />
heftarchiv/pdf/2002/fs0502/fs0205046.pdf, 2002.<br />
108
8 Privacy und Security in mobilen Endgeräten und im Mobilfunk<br />
Zusammenfassung<br />
In diesem Abschnitt wird auf verschiedene<br />
Aspekte von Privacy und Security<br />
in mobilen Endgeräten und im Mobilfunk<br />
eingegangen. Es werden die Bereiche angesprochen,<br />
in denen Privacy und Security<br />
eine wichtige Rolle spielen. Außerdem<br />
sollen Anwendungen des M-Commerce<br />
zur Sprache kommen, wie zum Beispiel<br />
Bezahlsysteme. Des weiteren wird auf Gefahrenpotenziale<br />
eingegangen mit denen<br />
man in Zukunft konfrontiert sein wird, wie<br />
beispielsweise Viren. Die Sicherheit der<br />
Datenübertragung über die Luftschnittstelle<br />
wird am weit verbreiteten GSM-<br />
Mobilfunknetz analysiert.<br />
8.1 Einleitung<br />
Mobile und ubiquitous computing finden immer<br />
mehr Einzug sowohl im Geschäftsleben<br />
als auch im privaten Alltag. Mitarbeiter<br />
können mit ihrem Handheld flexibel auf Firmendaten<br />
zugreifen. Man kann Aktiendepots<br />
einsehen und sogar per mobilem Endgerät<br />
Waren oder Dienstleistungen bezahlen. Um<br />
auch das Vertrauen in diese neuen Technologien<br />
zu bestärken ist es notwendig, sichere<br />
Konzepte zu haben, um die größtmögliche<br />
Privacy und Security zu garantieren.<br />
8.1.1 Was versteht man unter den<br />
Begriffen Privacy und Security?<br />
Zuerst einmal sollen die beiden Schlagwörter<br />
„Privacy“ und „Security“ erläutert werden.<br />
Beide Begriffe können analog zur DIN 44300<br />
wie folgt definiert werden[eKvPDHJO02]:<br />
Patrick Frey<br />
Tegelbergstr. 3<br />
73329 Kuchen<br />
patrick.frey@informatik.uni-ulm.de<br />
Definition Datensicherheit:<br />
Sachlage, bei der Daten unmittelbar oder<br />
mittelbar so weit wie möglich vor Beeinträchtigung<br />
oder Missbrauch bewahrt sind. Beeinträchtigung<br />
von Daten umfasst dabei u.a.<br />
den Verlust, die Zerstörung oder die Verfälschung.<br />
Datensicherung bezeichnet dann<br />
ein Bündel von Maßnahmen und Einrichtungen,<br />
die Datensicherheit herbeiführen oder<br />
aufrecht erhalten.<br />
Definition Datenschutz:<br />
Sachlage, bei der die schutzwürdigen Belange<br />
Betroffener vor Beeinträchtigung, die<br />
von der Verarbeitung von Daten ausgeht,<br />
bewahrt sind. Betroffene können natürliche<br />
oder juristische Personen oder Personenvereinigungen<br />
sein.<br />
Datensicherheit betrifft also primär den<br />
Schutz der Daten. Im Gegensatz dazu bezeichnet<br />
der Begriff Datenschutz primär den<br />
Schutz von Personen.<br />
Im angelsächsischen Sprachraum werden<br />
die beiden Begriffe Datensicherheit und Datenschutz<br />
nicht so verwirrend verwendet, wie<br />
im deutschen; dort spricht man statt von Datensicherheit<br />
von data security (kurz: security)<br />
und statt von Datenschutz von privacy<br />
protection (kurz privacy).<br />
8.1.2 Warum sind Privacy und Security<br />
wichtig?<br />
Bedenken bezüglich der Sicherheit stellen eine<br />
der größten Hürden dar, die Unternehmen<br />
davon abhalten, am E-Commerce teilzunehmen.<br />
Da M-Commerce ein Teil des<br />
E-Commerce ist lassen sich die Gefahrenpotentiale,<br />
die für Unternehmen im E-<br />
Commerce bestehen, auf den M-Commerce<br />
109
Patrick Frey<br />
übertragen. Gegenüber den neu eröffneten<br />
Kommunikationswegen gibt es begründete<br />
Bedenken: Sabotage von Daten (Schwindel),<br />
Überwachung von Datenverkehr (Spionage),<br />
Rückverfolgung von Mobilfunkzellen<br />
zur Standortbestimmung sind nur einige kritische<br />
Aspekte. Es gibt mehrere Wege, um<br />
solche (illegale) Zwecke zu verfolgen. Durch<br />
die Definition von offenen Plattformen und<br />
Betriebssystemen auf mobilen Endgeräten 17<br />
wird zwar sowohl die Möglichkeit gegeben,<br />
individuelle Anwendungen zu implementieren<br />
bzw. Anwendungen von <strong>Dr</strong>ittanbietern<br />
zu integrieren; jedoch besteht dort auch die<br />
Möglichkeit des Missbrauchs.<br />
Die Hersteller von Mobilfunkgeräten sind im<br />
Begriff eine weitere Plattform in ihre Geräte<br />
zu integrieren: J2ME mit MIDP 1.0. So bieten<br />
diverse Hersteller wie Nokia, Siemens, Motorola<br />
usw. bereits Mobiltelefone an, die so<br />
genannte MIDlets ausführen können. Neben<br />
der Portabilität dieser Anwendungen zwischen<br />
verschiedenen mobilen Endgeräten ist<br />
die Implementation mittels der Programmiersprache<br />
Java jedoch auch ein Nachteil: durch<br />
Decompilen kann der ursprüngliche Quellcode<br />
wiederhergestellt werden und anschließend<br />
modifiziert werden. Es bedarf also auch<br />
hier eines Schutzmechanismusses.<br />
Durch den Einsatz mobiler Endgeräte steigt<br />
auch die „Mobilität“ sensibler Daten. Sobald<br />
die mobilen Endgeräte außerhalb einer Firma<br />
eingesetzt werden können sie auch nicht<br />
mehr durch traditionelle interne Sicherheitsanwendungen,<br />
wie zum Beispiel Firewalls,<br />
geschützt werden. Deshalb muss jeder PDA,<br />
Handy oder Smartphone einzeln geschützt<br />
sein. Dabei wird sowohl ein Schutzmechanismus<br />
für die Datenübertragung benötigt<br />
als auch einer der die gespeicherten Daten<br />
schützt.<br />
Die Ausmaße, die Privacy und Security auf<br />
dem jeweiligen mobilen Endgerät annehmen,<br />
steigen mit deren Funktionalitäten. Der Übergang<br />
von reinem Mobiltelefon über Smartphones<br />
zum PDA ist jedoch fließend.<br />
Mobiltelefon Smartphone<br />
Handheld<br />
17 die bekanntesten sind Symbian OS, Windows CE oder Palm OS<br />
110
8.2 Privacy und Security betreffende Bereiche<br />
Abbildung 77: Fließender Übergang von Handy zu PDA<br />
8.2 Privacy und Security betreffende<br />
Bereiche<br />
8.2.1 Anwendungen<br />
1. M-Commerce<br />
M-Commerce ist eine Unterkategorie<br />
des E-Commerce, der sich bei der<br />
Übertragung von Daten auf Telekommunikationsnetz<br />
für mobile Endgeräte<br />
stützt. Dazu gehören sowohl Anwendungen<br />
aus dem Bereich business-tobusiness<br />
(B2B) als auch aus dem Bereich<br />
business-to-consumer. Anwendungen<br />
sind hier hauptsächlich in Bereichen<br />
zu finden, in denen Mitarbeiter<br />
mobil auf Firmendaten zurückgreifen<br />
bzw. aktualisieren. Dabei hilft<br />
ein mobiles Endgerät in vielen Belangen:<br />
Verwalten von Adressen und<br />
Terminen, Vor-Ort Service direkt beim<br />
Kunden (z.B. das Auskunftsystem des<br />
Schaffners im Zug, Empfangsbestätigung<br />
beim Paketdienst), usw. Durch die<br />
elektronische Verfügbarkeit und Weiterverarbeitung<br />
werden Arbeitsabläufe<br />
unterstützt und optimiert. Es ist klar,<br />
dass die Daten nicht für <strong>Dr</strong>itte (im<br />
schlechtesten Fall die Konkurrenz) bestimmt<br />
sind. Neben erheblichen Vorteilen<br />
bringt die Mobilität also auch eine<br />
sicherheitstechnische Herausforderung<br />
mit sich.<br />
2. M-Banking<br />
Bei Anwendungen, die direkt mit Transaktionen<br />
von Geldbeträgen zusammenhängen,<br />
bedarf es dem größtmöglichen<br />
Schutz. Denn ein eventueller<br />
Schaden ist unmittelbar (in<br />
Geld) messbar. Programme, die solche<br />
Transaktionen durchführen, sind deshalb<br />
auch so gut wie nicht vorhanden.<br />
Das Angebot der verschiedenen Banken<br />
ist heute noch überschaubar: Einige<br />
Banken bieten nur Abfragen von<br />
18 Eine Anleitung hierfür findet unter www.dabmobile.com, [Dir02]<br />
nicht-sensiblen Daten an, wie unverbindlichen<br />
Watchlisten und Musterdepots,<br />
zusätzlich eventuell Kurse<br />
/ Charts und News. Informationen<br />
werden entweder per SMS an<br />
das Handy des Kunden übertragen,<br />
oder per Spezialsoftware auf den PDA<br />
(z.B. Direktanlagebank) 18 . Außerdem<br />
bieten verschiedene Banken WAP-<br />
Pages zur interaktiven Information ihrer<br />
Kunden an (z.B. Deutsche Bank<br />
(www.maxblue.de)). Für den Nokia<br />
Communicator 9210i gibt es eine Anwendung<br />
zur Einsicht von Portfolios<br />
(http://www.softwaremarket.nokia.com/<br />
DRHM/servlet/ControllerServlet?Action<br />
=DisplayProductDetailsPage&SiteID=no<br />
kia&Locale=fi_FI&productID=535600).<br />
Da die meisten Banken jedoch Online-<br />
Banking mittels HTML-basiertem Webinterface<br />
anbieten, und es Smartphones<br />
und PDAs mit Internet Browser<br />
gibt, ist M-Banking im Prinzip möglich.<br />
Allerdings muss noch für einen sicheren<br />
Datentransport garantiert werden.<br />
3. Individuallösungen vs. Massentauglichkeit<br />
Individuallösungen bedürfen eines Entwicklungsprozesses,<br />
in dem auch eine<br />
bestimmte Programmiersprache<br />
zur Realisierung zum Einsatz kommt.<br />
Aspekte, die Privacy und Security betreffen,<br />
hängen auch davon maßgeblich<br />
ab. Bisherige Anwendungen waren<br />
jeweils auf den Gerätetyp bzw. ihr<br />
Betriebssystem beschränkt: so waren<br />
Programme für Geräte mit Palm OS<br />
nicht auf Geräten mit Windows CE oder<br />
Symbian OS lauffähig, dh. eine übergreifende<br />
„Schnittstelle“ zwischen gab<br />
es bisher nicht.<br />
Viele Hersteller mobiler Endgeräte haben<br />
sich deshalb auf einen Quasi-<br />
Standard geeinigt, nämlich J2ME mit<br />
111
Patrick Frey<br />
MIDP 1.0 und MIDP 2.0. Dabei müssen<br />
sie sich nicht mit einem fertigen Endprodukt<br />
zufrieden geben, sondern können<br />
aufgrund des JCP 19 sich aktiv an<br />
der Weiterentwicklung beteiligen. Sun<br />
Microsystems stellt dabei nur die Rahmenbedingungen,<br />
den eigentliche Entwicklungsprozess<br />
tragen die beteiligten<br />
Firmen in Kooperation. Dies führt dazu,<br />
dass Programme nicht mehr für einen<br />
speziellen Geräte-Typ entwickelt werden,<br />
sondern prinzipiell auf allen Geräten,<br />
die J2ME und MIDP 1.0/2.0 konform<br />
sind, lauffähig sind. Doch gerade<br />
diese Interportabilität von Anwendungen<br />
zwischen verschiedenen Gerätetypen<br />
bedarf neuer Sicherheitskonzepte,<br />
um Privacy und Security zu garantieren<br />
Anmerkung: Individuallösungen können<br />
aber auch ganz anders gestrickt<br />
sein. Die finnische Firma Sonera zum<br />
Beispiel verschickt die Gehaltsabrechnung<br />
elektronisch, wahlweise sogar als<br />
SMS aufs Handy. Privacy spielt natürlich<br />
bei der Übermittlung solcher sensiblen<br />
Daten eine wichtige Rolle.<br />
4. Location Based Services<br />
Ein bekannter Location Based Service<br />
basiert auf dem bestehenden GSM-<br />
Netz: dies sind so genannte CellBroadcasting<br />
Dienste. Bei CellBroadcasting<br />
werden Mitteilungen von einem Absender<br />
nicht an einen bestimmten Empfänger,<br />
sondern an alle empfangsbereiten<br />
Mobiltelefone innerhalb eines Ausstrahlungsgebiets<br />
versendet. So erhalten<br />
alle Empfänger, innerhalb eines bestimmten<br />
Gebiets die gleiche Nachricht.<br />
Deshalb sind diese Dienste meist<br />
providerabhängig und kostenlos. Privacy<br />
ist in diesem Bereich nicht relevant,<br />
da alle die gleichen Daten übermittelt<br />
bekommen, und vom Benutzer selbst<br />
keine Daten ausgehen.<br />
Dem JCP liegt diesbezüglich auch<br />
schon ein JSR vor: JSR-179, Location<br />
API for J2ME(TM)<br />
19 JCP = Java Community Process, www.jcp.org<br />
112<br />
This specification will define<br />
an Optional Package that will<br />
enable developers to write<br />
mobile location-based applications<br />
for resource limited<br />
devices. The purpose is to<br />
provide a compact and generic<br />
API that produces information<br />
about the device’s<br />
present physical location to<br />
Java applications.<br />
Auf die Gefahren einer solchen<br />
API wird im Abschnitt<br />
8.3, Viren, noch eingegangen.<br />
Anmerkung: Location Based<br />
Services werden in Kapitel 7<br />
besprochen.<br />
8.2.2 Einfache Bezahlsysteme<br />
Einfache Bezahlsysteme sollen auch mit den<br />
einfachsten mobilen Endgeräten funktionieren,<br />
dh. solche, die nur sehr geringe Funktionalität<br />
besitzen. Darunter gehören vor allem<br />
ältere Mobiltelefone, mit denen man „nur“ telefonieren<br />
und SMS-Dienste nutzen kann. Es<br />
wird auf bereits existierende Bezahlsysteme<br />
eingegangen und erläutert, wie sie funktionieren;<br />
ein spezieller Augenmerk liegt auf<br />
den Aspekten Security und Privacy.<br />
1. PayBox<br />
Abbildung 78: Shops mit diesem Logo<br />
akzeptieren Paybox als Bezahlsystem<br />
Wie funktioniert Paybox?<br />
Paybox ist ein Bezahlsystem, das auf<br />
dem Übermitteln von Daten via GSMfähigen<br />
Endgerät basiert, wobei es sich
eigentlich ausschließlich um Mobiltelefone<br />
handelt. Der Bezahlvorgang bei<br />
Paybox ist relativ einfach. Sowohl der<br />
Benutzer als auch die Akzeptanzstelle<br />
20 müssen bei Paybox registriert sein.<br />
Der Kunde nennt seinem Gegenüber<br />
seine Mobilfunknummer bzw. Paybox-<br />
Nummer. Diese wird samt dem zu bezahlenden<br />
Betrag an Paybox übermittelt.<br />
Paybox ruft anschließend auf dem<br />
mobilen Endgerät des Kunden an; ihm<br />
wird der zu bezahlende Betrag und die<br />
Akzeptanzstelle genannt, und er bestätigt<br />
die Bezahlung mit seinem persönlichem<br />
Paybox-Pin. Paybox tätigt sowohl<br />
für Kunden als auch Akzeptanzstelle die<br />
notwendigen Banküberweisungen.<br />
Privacy<br />
Paybox nutzt schon vorhandene Infrastrukturen,<br />
die die Privacy gewährleisten:<br />
Der Geldtransfer wird von der<br />
Deutschen Bank AG geregelt. Als Kommunikationsmittel<br />
dient wie schon erwähnt<br />
das GSM-Netz, das allgemein als<br />
sicher gilt. Daten sowohl vom Kunden<br />
als auch der Akzeptanzstelle sind bei<br />
Paybox hinterlegt.<br />
Security<br />
Paybox ist vom Prinzip her sehr sicher.<br />
Selbst wenn das Mobiltelefon<br />
durch Diebstahl in falsche Hände gerät<br />
kann kein Bezahlvorgang getätigt werden,<br />
solange der persönliche Paybox-<br />
Pin nicht bekannt ist. Des weiteren werden<br />
die echten Transaktionen von Paybox<br />
im Hintergrund vorgenommen; im<br />
Notfall kann man seinen Account auch<br />
sperren lassen. Das System ähnelt insgesamt<br />
sehr stark dem Bezahlen mit<br />
der Kreditkarte.<br />
Weitere Informationen erhält man bei<br />
Paybox selbst. 21<br />
Verbreitung und Akzeptanz<br />
Paybox hat nach eigenen Angaben<br />
in Europa 750.000 registrierte Kunden<br />
8.2 Privacy und Security betreffende Bereiche<br />
(Stand: März 2002); außerdem gibt es<br />
10.000 Akzeptanzstellen, bei denen mit<br />
Paybox bezahlt werden kann. 22<br />
Zukunft<br />
Paybox ist Vorreiter auf dem Markt der<br />
Bezahlsysteme für mobile Endgeräte,<br />
und will diese weiter ausbauen. Das zeigen<br />
unter anderem angekündigte Kooperationen,<br />
z.B. mit IBM 23 .<br />
2. Vodafone m-pay<br />
Laut Vodafone ist m-pay ein Bezahlsystem,<br />
um „einfach und sicher kleine<br />
Beträge in Web- und WAP-Shops von<br />
angeschlossenen Händlern“ zu bezahlen.<br />
Voraussetzung ist (lediglich) eine<br />
Vodafone-D2 SIM-Karte.<br />
Wie funktioniert Vodafone m-pay?<br />
Der Kunde entscheidet sich beim Surfen<br />
per WAP für ein Produkt oder eine<br />
Dienstleistung (z.B. Handy-Logo). Er<br />
bestätigt den angegebenen Betrag ohne<br />
zusätzliche PIN-Nummer. Anschließend<br />
erhält er eine Bestätigung für die<br />
Transaktion auf seinem Display. Nachdem<br />
das Produkt oder die Dienstleistung<br />
ausgeliefert wurde wird der entsprechende<br />
Betrag abgebucht.<br />
Privacy<br />
Privacy ist durch die SIM-Karte gewährleistet.<br />
Die Kommunikation läuft ausschließlich<br />
über den Provider, der auch<br />
die Abbuchungen vom hinterlegten Konto<br />
des Benutzers tätigt bzw. direkt von<br />
der Prepaid-Karte (bei Vodafone CallYa)<br />
abbucht.<br />
Security<br />
20 Akzeptanzstelle kann sowohl ein reales Geschäft, ein eShop oder ein anderer Paybox-Nutzer sein<br />
21 z.B. http://www.paybox.de/merchants/information_2968.html<br />
22 ausgewählte Paybox Partner sortiert nach Rubriken: http://www.paybox.de/shopping.html<br />
23 siehe Presseinformation vom 15 Aug 02 , http://www.paybox.de/press/press_2002_3166.html<br />
113
Patrick Frey<br />
Die Abrechnung erfolgt übers Vodafone-<br />
Konto, wodurch eine Registrierung<br />
überflüssig wird. Einen großen Nachteil<br />
hat das System jedoch: Jeder<br />
Vodafone-D2 Kunde ist automatisch berechtigt,<br />
per m-pay zu bezahlen. Wird<br />
ihm das Handy nun gestohlen, so kann<br />
der Dieb automatisch auch damit bezahlen,<br />
da eine zusätzliche Sicherung<br />
durch eine PIN wie bei Paybox fehlt.<br />
(Man kann spekulieren, dass das System<br />
aus diesem Grund auf kleine Beträge<br />
begrenzt ist.) Auch das Bezahlen<br />
im Internet ist möglich: zusätzlich<br />
zur Vodafone-D2 Nummer ist ein einmal<br />
gültiger Bezahlcode nötig, den man per<br />
SMS aufs Handy bekommt.<br />
Verbreitung und Akzeptanz Vodafone<br />
m-pay ist rein für den kleinen m-<br />
Commerce gedacht, um das Bezahlen<br />
von Dienstleistungen wie das Herunterladen<br />
von Logos oder Klingeltönen,<br />
oder dem Aufladen der Prepaid-Karte<br />
zu vereinfachen. Dabei wird es meiner<br />
Meinung nach auch bleiben.<br />
8.3 Gefahrenpotentiale<br />
8.3.1 Viren<br />
Die Hersteller setzen mehr und mehr auf<br />
offene Plattformen und geben <strong>Dr</strong>ittanbietern<br />
die Möglichkeit, zusätzliche Funktionalität<br />
auf die mobilen Endgeräte zu portieren.<br />
Dabei kann es aber auch zum Missbrauch<br />
kommen, indem z.B. fremder Code in bestehende<br />
Programme eingebaut wird, mit<br />
dem Zweck, Schaden anzurichten. Dieser<br />
kann z.B. das Zerstören oder Ausspionieren<br />
von privaten oder geschäftlichen Daten sein,<br />
oder das Zerstören des mobilen Endgeräts<br />
selbst. 24<br />
Die Hersteller sind gerade im Begriff die<br />
J2ME Plattform in ihre mobilen Endgeräte zu<br />
integrieren. Deshalb soll hier vor allem auf<br />
Java als Programmiersprache und die Spezifikationen<br />
in MIDP 1.0 25 eingegangen werden.<br />
Die Integration von Java bringt neben den<br />
Vorteilen (z.B. neue Spiele, individuelle Anwendungen,<br />
usw.) auch einen Nachteil mit<br />
sich: Es muss besonders auf die Privacy<br />
und Security geachtet werden. Aus diesem<br />
Grund läuft die Virtuelle Maschine (VM), die<br />
den Bytecode interpretiert, in einer sogenannten<br />
„Sandbox“. Diese kapselt die VM innerhalb<br />
des mobilen Endgeräts, so dass keine<br />
Zugriffe auf gerätespezifische Funktionen<br />
erfolgen können, die nicht ausdrücklich vom<br />
Hersteller in APIs 26 freigegeben werden. So<br />
ist z.B. ein Zugriff auf das Telefonbuch nur<br />
möglich, wenn der Hersteller eine eigene Implementierung<br />
bereitstellt.<br />
Gefahren durch J2ME und MIDP 1.0<br />
1. Automatische Anwahl fremder Telefonnummern<br />
Eine Anwahl von z.B. kostenpflichtigen<br />
0190-Nummern 27 oder anderen kostenpflichtigen<br />
Nummern ist ohne Zutun<br />
des Benutzers im Prinzip nicht möglich.<br />
Die Kommunikation von MIDlets 28 ist<br />
in MIDP1.0 [JCP02a] im Wesentlichen<br />
auf die Handhabung der Datenstreams<br />
reduziert 29 . Wie dabei die physische<br />
Kommunikation zwischen mobilem Endgerät<br />
und Mobilfunknetz geregelt ist, inkl.<br />
Anwahlnummer, wird im Gerät selbst<br />
eingestellt. Da, wie schon erwähnt, die<br />
VM in einer „Sandbox“ gekapselt ist,<br />
sollte ein Zugriff auf solche Geräteeinstellungen<br />
auch nicht möglich sein.<br />
24In [Cor02] wird erwähnt, dass Viren wie Trojaner schon aufgetreten sind.<br />
25MIDP 1.0 = Mobile Information Device <strong>Prof</strong>ile, Specification 1.0<br />
26API = Application Programmable Interface<br />
27vgl. diverse Dialer-Programme bei Windows PCs<br />
28Als MIDlet wird eine Applikation für mobile Endgeräte bezeichnet, die mittels J2ME und MIDP 1.0/2.0 erstellt<br />
wurde<br />
29vgl. javax.microedition.io in [MIDP1.0Spec]<br />
114
2. Ausspieonieren privater oder geschäftlicher<br />
Daten<br />
Bei der Kommunikation von MIDlets mit<br />
Web Applications muss im MIDlet die<br />
URL angegeben, mit der verbunden<br />
werden soll. Eine Schwäche von Java<br />
ist die Rückgewinnung von Quellcode<br />
mittels Decompilen. So ist also diese<br />
URL zugänglich und abänderbar. Mit<br />
relativ wenig Aufwand können also die<br />
von mobilen Endgerät gesendeten und<br />
empfangenen Datenströme auf eine andere<br />
URL umgeleitet bzw. „dupliziert“<br />
werden. So können <strong>Dr</strong>itte die (eventuell<br />
unverschlüsselten) Daten mitprotokollieren.<br />
Die in Abschnitt 8.2 erwähnte API<br />
zur Standortlokalisation (vgl. [JSR-179])<br />
könnte dazu missbraucht werden um<br />
den Standort eines Benutzers zu bestimmen,<br />
ihn zu speichern und sofort<br />
oder zu einem späteren Zeitpunkt zu<br />
übermitteln. So könnten Mitarbeiter unbemerkt<br />
überwacht werden, ob sie zu<br />
einem bestimmten Zeitpunkt auch an einem<br />
bestimmten Ort sind, wenn sie mit<br />
ihrem mobilen Endgerät auf Firmendaten<br />
zurückgreifen.<br />
Auf im Gerät gespeicherte Daten (z.B.<br />
im Terminkalender) ist kein Zugriff möglich<br />
(Stichwort Sandbox), solange dies<br />
vom Hersteller nicht durch eine eigene<br />
API unterstützt wird. Selbst MIDlets<br />
können untereinander keine Daten<br />
austauschen, da nur auf Daten im<br />
eigenen RMS 30 -Speicherbereich zugegriffen<br />
werden kann.<br />
In MIDP 2.0 [Mic02d] kommen zwar<br />
neue Sicherheitsmechanismen hinzu,<br />
vor nachträglichem abändern von Quellcode<br />
bieten sie aber auch nur unzureichenden<br />
Schutz.<br />
3. Lahmlegen von Netzdiensten durch<br />
Missbrauch / Massennutzung<br />
Dem JCP 31 liegt mit JSR-120 32<br />
[JCP02b] eine Anfrage vor, die vor-<br />
30 RMS = Record Management System<br />
31 JCP = Java Community Process<br />
32 JSR = Java Specification Request<br />
8.3 Gefahrenpotentiale<br />
schlägt, eine Wireless Messaging API<br />
zu implementieren. Somit könnten Anwendungen<br />
entwickelt werden, die SMS<br />
verschicken und empfangen können,<br />
oder Cellbroadcasting-Dienste nutzen<br />
können. Ohne Sicherheitsmechanismen<br />
könnten jedoch auch SMS-Bomber<br />
oder SMS-Flooder implementiert werden.<br />
8.3.2 Diebstahl des mobilen Endgerätes<br />
Je kleiner das Gerät, desto „mobiler“ ist es<br />
und desto leichter geht es verloren oder wird<br />
es gestohlen. Die Gefahren beim Diebstahl<br />
des mobilen Endgeräts werden jedoch oft unterschätzt:<br />
Abgesehen vom materiellen Verlust<br />
sind oft auch Terminkalender und/oder<br />
geschäftliche Daten unwiederbringlich verloren.<br />
Falls diese Daten der Konkurrenz in die<br />
Hände fallen kann dies erhebliche Auswirkungen<br />
für das betroffene Unternehmen haben.<br />
(Außerdem kann es natürlich auch zu<br />
Ausfällen im Geschäftsbetrieb kommen.) Es<br />
gibt Firmen die spezielle Sicherheitslösungen<br />
für diese Fälle anbieten. (siehe Abschnitt<br />
8.3.4)<br />
8.3.3 Sicherheit von Mobilfunknetzen<br />
Bei der Übertragung von Daten per Kabel<br />
(z.B. in einem Netzwerk) hat es meist genügt,<br />
diese Verbindung physisch unzugänglich zu<br />
machen (dh. die Kabel für <strong>Dr</strong>itte unzugänglich<br />
verlegen). Bei der drahtlosen Datenübertragung<br />
über die Luftschnittstelle ist eine solche<br />
Sicherung nicht möglich. Bei funkbasierten<br />
Geräten (z.B. einfache CB Handyfunkgeräte),<br />
die alle auf derselben Frequenz<br />
senden, können <strong>Dr</strong>itte einfach und unbemerkt<br />
mithören. Deshalb ist bei der drahtlosen<br />
Verbindung normalerweise eine Verschlüsselung<br />
unumgänglich. [Bea02]<br />
C-Netz<br />
115
Patrick Frey<br />
Das bereits abgeschaffte C-Netz basierte<br />
noch auf analoger Technologie und war<br />
extrem unsicher. Mittels einfachem Scanner<br />
konnten Gespräche abgehört werden.<br />
Der einzige Schutzmechanismus („Scrambeln“<br />
der Sprache, eine Art systematisches<br />
Zerhacken) war auch nicht wirkungsvoll.<br />
Aus diesem Grund wurde von der GSM<br />
(Groupe Spécial Mobile) ein Standard entwickelt,<br />
der in vielen Ländern übernommen<br />
wurde.<br />
GSM<br />
Wie authentifiziert sich ein Benutzer? Wie<br />
werden seine Daten verschlüsselt?<br />
Beim Einschalten seines mobilen Endgeräts<br />
muss sich der Benutzer für den Nutzung<br />
seiner SIM-Karte mittels einem 4-stelligen<br />
PIN 33 authentifizieren. Nach mehrfacher<br />
Falscheingabe wird die SIM-Karte gesperrt<br />
und kann nur noch mittels dem PUK 34 entsperrt<br />
werden.<br />
Anschließend authentifiziert sich das mobile<br />
Endgerät beim Netzbetreiber wie folgt: Jeder<br />
Teilnehmer hat eine Mobilteilnehmerkennung<br />
IMSI 35 , eine bis zu 15 Ziffern lange,<br />
weltweit eindeutige Zahlenkombination.<br />
Sie setzt sich aus einem Ländercodeteil, einer<br />
Netz- und einer Teilnehmerkennung zusammen<br />
und wird vom Netzbetreiber der<br />
SIM-Karte fest zugeordnet. (Analog existiert<br />
übrigens für jedes Handy eine Mobilgerätekennung<br />
IMEI (International Mobilstation<br />
Equipment Number), welche ebenfalls weltweit<br />
eindeutig ist. Hierüber kann das Handy<br />
bei Diebstahl identifiziert und evtl. lokalisiert<br />
werden.). Weiterhin ist in einem „einbruchsicheren“<br />
Register auf der SIM-Karte noch der<br />
„Individual Subscriber Authentifikation Key“,<br />
kurz Ki, ein bis zu 128 Bit langer Schlüssel<br />
gespeichert. IMSI und Ki sind auch in der Datenbank<br />
„Authority Center“ (AuC) des Mobilfunknetzbetreiber<br />
gespeichert.<br />
Die Authentifizierung des Teilnehmers gegenüber<br />
dem Betreiber wird durch ein<br />
33 PIN = Personal Identity Number<br />
34 PUK = Personal Unlocking Key<br />
35 IMSI = International Mobile Subscriber Identity<br />
116<br />
Challange-and-Response-Protokoll gewährleistet.<br />
Das Mobilfunksystem erzeugt eine<br />
128 Bit lange Zufallszahl RAND und sendet<br />
sie an den Teilnehmer. Mit Hilfe des Authentifizierungsalgorithmus<br />
A3 und dem individuellen<br />
Schlüssel Ki berechnet der Teilnehmer<br />
die 32 Bit lange Antwort SRES („signed response“)<br />
und sendet diese an die anfragende<br />
Basisstation.<br />
SRES:= A3(RAND,Ki)<br />
Der Netzbetreiber wiederum liest den Teilnehmerschlüssel<br />
aus der AuC-Datenbank<br />
und berechnet selbst A3(RAND,Ki). Wenn<br />
der berechnete und der empfangene Wert<br />
übereinstimmen wird der Sender als berechtigt<br />
anerkannt und erhält Zugang zum Netz.<br />
Als Identitätsbeweis wird also die Kenntnis<br />
von Ki anerkannt. Hierbei wird vorausgesetzt,<br />
dass keine Möglichkeit existiert SRES<br />
aus RAND ohne Kenntnis des Schlüssels zu<br />
errechnen.<br />
Der geheime Schlüssel Ki selbst wird niemals<br />
über die Luftschnittstelle übertragen.<br />
Mit Hilfe der übermittelten Zufallszahl RAND<br />
und des individuellen Schlüssels Ki wird mit<br />
dem Schlüsselgenerierungs-Algorithmus A8<br />
der 64 Bit lange Sitzungsschlüssel Kc („ciphering<br />
key“) erzeugt.<br />
Kc:= A8(RAND,Ki)<br />
Diese Schlüsselgenerierung wird wiederum<br />
unabhängig von der Chipkarte im Teilnehmerhandy<br />
und beim Netzbetreiber vorgenommen.<br />
Mit dem so erzeugten Schlüssel werden<br />
dann die zu sendenden Gesprächsdaten<br />
verschlüsselt. Hierbei findet das in Frankreich<br />
entwickelte „Stromverschlüsselungsverfahren<br />
A5“ Verwendung.<br />
Abhörsicherheit des GSM-Netzes<br />
Das „Stromverschlüsselungsverfahren A5“<br />
ist zwar geheim entwickelt worden ist,<br />
aber inzwischen mit einem handelsüblichen
schnellen PC in Echtzeit entschlüsselbar<br />
(Verfahren nach Biryukow, Schamir, Wagner).<br />
Damit können alle von einem Handy gesendeten<br />
und empfangenen Gespräche abgehört<br />
werden.<br />
Nach der Authentifizierung des mobilen Endgeräts<br />
beim Netzbetreiber erhält es von der<br />
Basisstation eine Frequenztabelle alternativer<br />
Frequenzen, die die Frequenzen benachbarter<br />
Basisstationen enthält. Jedes eingeschaltete<br />
mobile Endgerät bucht sich automatisch<br />
bei der nächstgelegenen stärkste)<br />
Basisstation des Mobilfunknetzes ein. Um<br />
Daten abzuhören wird ein tragbarer Mobilfunktransponder<br />
(IMSI-Catcher) in die Nähe<br />
des abzuhörenden mobilen Endgeräts gebracht;<br />
dieser erzeugt ein starkes Funksignal,<br />
dessen Frequenz einer Alternativfrequenz<br />
entspricht. Dies wird vom mobilen<br />
Endgerät erkannt, und es wird ein Kanalwechsel<br />
auf die neue Frequenz durchgeführt.<br />
Der IMSI-Catcher simuliert also gegenüber<br />
den in seiner Nähe befindlichen Teilnehmern<br />
die Basisstation: Er fängt alle Gespräche<br />
ab und leitet sie - vom Abgehörten<br />
unbemerkt - sogleich auf der alten Frequenz<br />
an die „echte“ Basisstation weiter. Das<br />
abzuhörende Gerät kann dann über seine<br />
Kennung (IMSI) eindeutig identifiziert werden.<br />
Mittels eines Steuerkommandos, der im<br />
GSM-Standard enthalten ist, kann die Verschlüsselung<br />
ausgeschaltet werden, und alle<br />
Gespräche bzw. Daten können unmittelbar<br />
vor Ort und/oder über eine weitere Verbindung<br />
mitgehört bzw. mitprotokolliert werden.<br />
Weder der abgehörte Benutzer noch<br />
das Mobilfunksystem bekommen so von der<br />
Manipulation etwas mit. Mittels eines speziellen<br />
„Monitor-Geräts“ könnte man zwar vor<br />
Ort die Manipulation anhand der Betriebsdaten<br />
(z.B. Zeitschlitz, Arbeitskanal, Timing-<br />
Advance, etc.) ekennen, aber nicht verhindern.<br />
Anmerkung: Da das abzuhörende mobile<br />
Endgerät bewegt werden kann muss der Mobilfunktransponder<br />
immer in dessen Nähe<br />
bleiben.<br />
36 PDA = Personal Digital Assistant<br />
Fazit<br />
8.3 Gefahrenpotentiale<br />
Die Abhörsicherheit ist im GSM-Netz trotz<br />
aufwendiger Verschlüsselungsverfahren<br />
nicht gegeben. IMSI-Catcher haben allerdings<br />
keine Betriebsgenehmigung durch das<br />
Bundesamt für Post und Telekommunikation<br />
(BAPT). Da es sich bei dem Gerät aber<br />
im weitesten Sinne um ein Messgerät handelt,<br />
sind jedoch sowohl die Produktion als<br />
auch der Export zulässig und somit die Geräte<br />
für jedermann käuflich zu erwerben. Im<br />
Zuge von polizeilichen Ermittlungen kommt<br />
ein solches Gerät auch zum Einsatz (Genehmigungsverfahren<br />
notwendig). Allerdings<br />
kann so ein Gerät auch zur (Wirtschafts-<br />
)Spionage missbraucht werden.<br />
8.3.4 Anbieter von Sicherheitslösungen<br />
Es gibt verschiedene Arten von Sicherheitslösungen,<br />
bei denen mobile Endgeräte eine<br />
Rolle spielen.<br />
F-Secure<br />
F-Secure schildert in einem WhitePaper<br />
[Cor02] die grundlegenden Sicherheitsbedürfnisse.<br />
Die beiden wichtigsten sind die Sicherheit<br />
des Inhalts (content-security) und<br />
die Sicherheit bei der Datenübertragung<br />
(channel-security). Das eine ist ohne das andere<br />
aber wirkungslos: Eine eMail, die zwar<br />
verschlüsselt und sicher auf das Gerät gelangt,<br />
und dort unverschlüsselt gespeichert<br />
wird, ist nicht vollständig geschützt.<br />
F-Secure FileCrypto<br />
Sinn und Zweck der Sicherheitslösung von F-<br />
Secure ist es, alle Daten, die in einem mobilen<br />
Endgerät gespeichert sind für <strong>Dr</strong>itte unzugänglich<br />
zu machen. Dies betrifft hauptsächlich<br />
PDAs 36 , in zunehmenden Maße<br />
aber auch Handys bzw. SmartPhones. Die<br />
Daten werden bei jedem Speichervorgang<br />
automatisch mittels einem 128-Bit Kodierungsverfahren<br />
verschlüsselt. Für den Zugriff<br />
auf die Daten muss der Benutzer sich mittels<br />
Passwort authentifizieren. Selbst Daten<br />
117
Patrick Frey<br />
auf austauschbaren Speichermedien (memory<br />
cards) können so geschützt werden.<br />
F-Secure Anti-Virus<br />
Für Palm OS Systeme sind sowohl Viren<br />
als auch Trojanische Pferde bekannt. Beide<br />
können erheblichen Schaden anrichten und<br />
zeigen die Wichtigkeit von Antivirenprogrammen<br />
für mobile Endgeräte. F-Secure bietet<br />
für mobile Endgeräte, die auf Windows CE<br />
(bzw. Pocket PC), Symbian OS und Palm OS<br />
basieren speziell zugeschnittene Programme<br />
an.<br />
Aufgrund der unsicheren GSM - Verschlüsselung<br />
und der ungeschützten Übertragung<br />
der Daten durch das Internet bietet F-Secure<br />
auch eine Sicherheitslösung an, die auf<br />
VPN 37 aufbaut. Dadurch wird eine abhörsichere<br />
end-zu-end Verbindung garantiert.<br />
RSA<br />
Des weiteren gibt es Sicherheitslösungen um<br />
den Zugang zu Web Applikationen im B2B<br />
oder B2C zu schützen. Dabei soll nur berechtigten<br />
Benutzern, also solche, die sich<br />
eindeutig authentifizieren können Zugang zu<br />
den sensiblen Daten gestattet werden.<br />
Die amerikanische Firma „RSA Secure“ 38 ist<br />
Anbieter eines solchen Konzepts. Um Zugang<br />
zu einer Web Applications zu bekommen<br />
gibt der Benutzer seine persönliche userID<br />
und seinen PIN im Browser ein und verschickt<br />
beides an die durch RSA Mobile geschützte<br />
Web Application. Diese reicht beide<br />
weiter an den RSA Web Server, der einen<br />
einmaligen Access Code generiert. Dieser<br />
Access Code wird per SMS oder eMail an<br />
den Benutzer geschickt, der dadurch Zugang<br />
zur Web Application erhält.<br />
Abbildung 79: Ablauf des Authentifizierungsprozesses bei einer durch RSA mobile geschützten<br />
Web Application<br />
37 VPN = Virtual Private Network<br />
38 http://www.rsasecurity.com/products/mobile/index.html<br />
118
8.3.5 J2ME: Sicherheitskonzepte von<br />
MIDP 1.0 und MIDP 2.0<br />
In [Mic02d], Kapitel 3, Security for MIDP<br />
Applications, werden die Sicherheitskonzepte<br />
des MIDP 1.0, als auch des Nachfolgers<br />
MIDP 2.0, wie folgt beschrieben:<br />
The MIDP 1.0 specification<br />
constrained each MIDlet suite to<br />
operate in a sandbox wherein all of<br />
the APIs available to the MIDlets<br />
would prevent access to sensitive<br />
APIs or functions of the device.<br />
That sandbox concept is used in<br />
this specification and all untrusted<br />
MIDlet suites are subject to its limitations.<br />
Every implementation of<br />
this specification MUST support<br />
running untrusted MIDlet suites.<br />
MIDP 2.0 introduces the concept<br />
of trusted applications that may be<br />
permitted to use APIs that are considered<br />
sensitive and are restricted.<br />
If and when a device determines<br />
that a MIDlet suite can be trusted<br />
then access is allowed as indicated<br />
by the domain policy. (...)<br />
Any MIDlet suite that is not trusted<br />
by the device MUST be run as untrusted.<br />
If errors occur in the process<br />
of verifying that a MIDlet suite<br />
is trusted then the MIDlet suite<br />
MUST be rejected.<br />
MIDP 1.0<br />
In MIDP 1.0 hatten also alle MIDlets die<br />
gleichen Vorraussetzungen. Die definierten<br />
APIs konnten auf jeden Fall, wenn implementiert,<br />
benutzt werden. Ein Zugriff auf andere<br />
gerätespezifische Funktionen, die nicht<br />
in den APIs definiert sind, wurde durch<br />
das „Sandbox“-Prinzip ausgeschlossen: Jedes<br />
MIDlet wird in einem ausbruchsicheren<br />
Käfig betrieben. Selbst in MIDlet Suites 39<br />
sind lokal gespeicherte Daten vor gegenseitigem<br />
Zugriff geschützt.<br />
39 Paket, das mehrere MIDlets in einem zusammenfasst<br />
40 TLS = Transport Layer Security<br />
41 SSL = Secure Sockets Layer<br />
8.3 Gefahrenpotentiale<br />
JSR 118: Mobile Information Device <strong>Prof</strong>ile<br />
2.0, (MIDP 2.0) [Mic02c]<br />
Zunächst einmal ist zu erwähnen, dass das<br />
„Sandbox“-Prinzip aus MIDP 1.0 auch weiterhin<br />
besteht. In MIDP 2.0 kann jedoch die Benutzung<br />
kritischer APIs beschränkt werden:<br />
Nur zertifizierte Applikationen erhalten Zugriff<br />
auf bestimmte gerätespezifische Funktionalitäten.<br />
So könnte z.B. der Zugriff auf<br />
das Telefonbuch mittels Zertifikat durch die<br />
Hersteller beschränkt werden. Vor Viren sind<br />
solche Applikationen jedoch auch nicht geschützt:<br />
durch Decompilen kann aus Bytecode<br />
lesbarer Quellcode erzeugt werden, der<br />
anschließend verändert werden kann. Ein<br />
endgültiges Lösungskonzept gibt es für Java-<br />
Anwendungen diesbezüglich noch nicht. Es<br />
gibt lediglich verschiedene Techniken, um es<br />
„Crackern“ zu erschweren, sich : Mittels eines<br />
Obfuscators werden z.B. Variablennamen<br />
systematisch in kryptische Zeichenfolgen<br />
umbenannt. Das Programm bleibt ausführbar,<br />
aber nach dem Decompilen nur<br />
schwer lesbar.<br />
Um eine sichere Datenübertragung zu garantieren<br />
können in MIDP 2.0 Verbindungen<br />
mit den Protokollen TLS 40 bzw. SSL 41 hergestellt<br />
werden. TLS wird als Schicht zwischen<br />
TCP/IP und höher liegenden Netzwekprotokollen<br />
wie Http, SMTP und NNTP implementiert.<br />
Wie schon erwähnt können ab MIDP 2.0<br />
MIDlet Suites zertifiziert werden um die Authentizität<br />
der kommunizierenden Partner zu<br />
garantieren. Eine ausführliche Beschreibung<br />
findet sich unter den Quellen [Mic02a] und<br />
[Mic02b], da eine ausführliche Diskussion<br />
den Rahmen sprengen würde. Weitere Artikel<br />
sind schon angekündigt, allerdings noch<br />
nicht verfügbar. Sie werden sich jedoch konkret<br />
auf MIDP 2.0 beziehen und sich mit den<br />
Themen „Authentication in MIDP“ und „Encryption<br />
in MIDP“ befassen.<br />
119
Patrick Frey<br />
Secure Networking<br />
Since the MIDP 2.0 release additional interfaces are available for secure communication with<br />
WWW network services. Secure interfaces are provided by HTTPS and SSL/TLS protocol<br />
access over the IP network. Refer to the package documentation of javax.microedition.pki<br />
for the details of certificate profile that applies to secure connections. An HttpsConnection is<br />
returned from Connector.open() when an „https://“ connection string is accessed. A Secure-<br />
Connection is returned from Connector.open() when an „ssl://“ connection string is accessed.<br />
javax.microedition.io.HttpsConnection<br />
javax.microedition.io.SecureConnection<br />
javax.microedition.io.SecurityInfo<br />
javax.microedition.pki.Certificate<br />
javax.microedition.pki.CertificateException<br />
Abbildung 80: MIDP 2.0: Neue Klassen / Interfaces in MIDP 2.0 für Secure Networking<br />
8.3.6 Ausblicke<br />
JSR 177: Security and Trust Services API<br />
for J2ME<br />
Doch selbst MIDP 2.0 ist in Bezug auf Privacy<br />
(und Security) immer noch unzureichend.<br />
Deshalb liegt beim Java Community Process<br />
(JCP) ein Java Specification Request (JSR)<br />
vor um MIDP 2.0 weiter zu ergänzen. Da<br />
JSR-118 zeitlich schon viel früher in Gang<br />
gesetzt wurde, sind die Forderungen von<br />
JSR-177 in der Spezifikation von MIDP 2.0<br />
noch nicht berücksichtigt.<br />
This specification will provide<br />
J2ME applications with APIs for<br />
security and trust services through<br />
the integration of a Security Element.<br />
[JCP02c]<br />
Der Zweck dieser JSR ist es also eine Kollektion<br />
von APIs zu definieren, damit J2MEfähigen<br />
mobile Endgeräten sensible Daten<br />
auf einem Security Element 42 speichern können.<br />
Ein Security Element unterstützt dabei<br />
die sichere Speicherung, dh. sensible<br />
Daten von Benutzern werden geschützt,<br />
42 Ein Beispiel für ein Security Element ist die SIM-Card in Handys.<br />
120<br />
wie z.B. private PINs, Zertifikate, persönliche<br />
Informationen usw.<br />
die sichere Ausführbarkeit, dh. kryptographische<br />
Berechnungen und Bezahlprotokolle<br />
werden unterstützt, sowie<br />
Datenintegrität und Datengeheimhaltung<br />
gewährleistet<br />
individuelle Security Features und Securtity<br />
Features, auf die J2ME Anwendungen<br />
aufbauen können um viele datengebundene<br />
Services „handeln“ können,<br />
wie Benutzeridentifikation und -<br />
authentifizierung, Banking, Bezahlung,<br />
Ticketbuchung,<br />
8.4 Abschließende Bemerkung<br />
In allen Bereiche, in denen mobile Endgeräte<br />
zum Einsatz kommen, spielen Privacy<br />
und Security eine wichtige Rolle. Trotz<br />
aufwendiger Konzepte und Techniken ist eine<br />
totale Privacy und Security nie möglich.<br />
Das beste Beispiel hierfür ist beschriebene<br />
Sicherheitslücke im GSM-Standard, die<br />
sowohl Sprach- als auch Datenübertragungen<br />
betrifft. Doch man kann es potenziellen<br />
Hackern und Crackern so schwer wie möglich<br />
machen. Das Ziel dabei ist es, dass die<br />
Kosten und der Aufwand zum Erlangen der
sensiblen Daten den Nutzen, den diese Da- ten dem Hacker bringen, weit übersteigen.<br />
Literatur<br />
[Bea02] Beaucom: Sichere Kommunikation in unsicheren Netzen. http://www.<br />
beaucom.de/html/faq.html, 2002.<br />
[Cor02] F-Secure Corporation: Content Security at Handheld. http://www.fsecure.de/products/white-papers/hhsecurity020215.pdf,<br />
2002.<br />
[Dir02] Direktanlagebank: Hier finden sie Informationen und Tipps zu den mobilen<br />
Informationsmöglichkeiten Ihrer DAB bank. www.dabmobile.com, 2002.<br />
[eKvPDHJO02] eBusiness-Kompendium von <strong>Prof</strong>. <strong>Dr</strong>. Hans Jürgen Ott: Grundlagen<br />
der Daten- und Rechtssicherheit. http://www.kecos.de/script/<br />
31grundldsich.htm, 2002.<br />
[JCP02a] JSR-037 Java Community Process: Mobile Information Device <strong>Prof</strong>ile<br />
(MIDP) Final Specification 1.0a. http://jcp.org/aboutJava/<br />
communityprocess/final/jsr037/index.html, 2002.<br />
[JCP02b] JSR-120 Java Community Process: Wireless Messaging API. http://<br />
jcp.org/en/jsr/detail?id=120, 2002.<br />
[JCP02c] JSR-177 Java Community Process: Security and Trust Services API for<br />
J2ME (TM). http://www.jcp.org/en/jsr/detail?id=177, 2002.<br />
[Mic02a] Sun Microsystems: MIDP Application Security 1, Design Concerns and<br />
Cryptography. http://wireless.java.sun.com/midp/articles/<br />
security1/, 2002.<br />
[Mic02b] Sun Microsystems: MIDP Application Security 2, Understanding SSL<br />
and TLS. http://wireless.java.sun.com/midp/articles/<br />
security2/, 2002.<br />
[Mic02c] Sun Microsystems: Mobile Information Device <strong>Prof</strong>ile 2.0. http://jcp.<br />
org/en/jsr/detail?id=118, 2002.<br />
[Mic02d] Sun Microsystems: Mobile Information Device <strong>Prof</strong>ile 2.0 Specification.<br />
http://www.jcp.org/aboutJava/communityprocess/<br />
review/jsr118/, 2002.<br />
121
9 Security and Privacy - Anonymität<br />
Zusammenfassung<br />
Der Wunsch nach Anonymität ist in vielen<br />
Bereichen des täglichen Lebens in<br />
unserer Gesellschaft sehr verbreitet. Immer<br />
häufiger wird Anonymität sogar gefordert.<br />
Diese Forderung geht auf ein intuitives<br />
Bedürfnis zurück, nicht nur die eigene<br />
Privatsphäre zu schützen, sondern<br />
auch über die Informationen selbst zu<br />
bestimmen, die über die eigene Identität<br />
bekannt werden. Die folgenden Ausführungen<br />
sollen einen Überblick über den<br />
Aspekt der Anonymität hinsichtlich der<br />
Benutzung der Mobilnetze, des Festnetzes<br />
und der Benutzung des Internet geben.<br />
9.1 Einleitung<br />
9.1.1 Definition<br />
Allgemein beschreibt der Begriff Anonymität<br />
Namenslosigkeit oder Nichtbekanntsein. Auf<br />
der Grundlage dieser allgemeinen Bedeutung,<br />
ist eine Definition möglich, die das Thema<br />
im Sinne dieses Seminars spezifischer<br />
beschreibt. Die Gründe, wann eine an einem<br />
anonymen Vorgang beteiligte Identität nicht<br />
näher bestimmbar wird, sind schnell nachzuvollziehen.<br />
Wenn diese Identität den anderen<br />
innerhalb dieses anonymen Vorgangs<br />
beteiligten Identitäten nicht bekannt ist oder<br />
gegenüber den anderen Identitäten nicht aktiv<br />
wird oder gar ohne erkennbaren Namen<br />
agiert, dann wird diese Identität nicht bestimmbar.<br />
Thomas Jakob<br />
thomas.jakob@informatik.uni-ulm.de<br />
9.1.2 Motivation<br />
Die verständliche Forderung nach Anonymität,<br />
die sogar auf dem Grundrecht der informationellen<br />
Selbstbestimmung 43 beruht,<br />
ist nicht nur durch den Wunsch die eigene<br />
Privatsphäre zu schützen motiviert. Direkte,<br />
aber auch indirekte Angriffe auf die Identität,<br />
die durch den Besitz personenbezogener<br />
Daten möglich werden, können in der heutigen<br />
Gesellschaft verheerende Folgen haben.<br />
Um dem entgegen zu wirken, wurde<br />
schon früh das Thema Datenschutz 44 diskutiert.<br />
Die Basis des Datenschutzes beruht auf<br />
der Annahme, dass die Verarbeitung personenbezogener<br />
Daten nur zulässig ist, wenn<br />
der Betroffene eingewilligt hat oder ein Gesetz<br />
die Verarbeitung erlaubt [fDSH02]. Dieser<br />
Schutz ist nun bei weitem nicht umfassend.<br />
Besonders im Internet, das hier nur<br />
kurz als erklärendes Beispiel dienen soll,<br />
kann ein unerfahrener Nutzer kaum abschätzen,<br />
welche Daten über seine Person bekannt<br />
werden, die Rückschlüsse auf seine<br />
reale Identität möglich machen. Gerade im<br />
Bereich des Internet ist das Recht der informationellen<br />
Selbstbestimmung stark eingeschränkt,<br />
da der Nutzer kaum Einfluss auf die<br />
Verwendung seiner Daten hat. Als einleuchtender<br />
Grund mag hier der Aspekt der unterschiedlichen<br />
Gesetzgebungen in den einzelnen<br />
verschiedenen Ländern zu diesem Thema<br />
sein. Im Gegensatz dazu kann ein Anruf<br />
von einer öffentlichen Telefonzelle als anonyme<br />
Aktivität bezeichnet werden, da hier<br />
kaum Verbindungen zur Identität des Anrufers<br />
hergestellt werden können.<br />
43 Nach [Ott02] läßt sich dieses Grundrecht auf ein Urteil des Bundesverfassungsgerichtes von 1965 aus Artikel 2<br />
Absatz 1 des Grundgesetzes, nämlich dem allgemeinen Persönlichkeitsrecht, zurückführen<br />
44 Definition siehe [Ott02]<br />
122
9.1.3 Abstufungen von Anonymität<br />
Nach [fSidI01] werden innerhalb eines Kommunikationsvorgangs<br />
die Sender- und Empfängeranonymität<br />
folgendermaßen definiert.<br />
Senderanonymität bedeutet, dass <strong>Dr</strong>itten die<br />
Senderidentität nicht zugänglich und damit<br />
nicht bestimmbar ist, während die Empfängeridentität<br />
und der Kommunikationskontext<br />
aber bekannt sein können.<br />
Abbildung 1.1 Senderanonymität [fSidI01]<br />
Empfängeranonymität definiert sich analog<br />
hinsichtlich der Empfängeridentität und ist insofern<br />
ein relativer Begriff, als der Sender<br />
durch die Beobachtung der Verteilung nicht<br />
über das bereits bekannte Wissen über die<br />
Identität des Empfängers hinaus neue Informationen<br />
in Erfahrung bringen kann.<br />
Abbildung 1.2 Empfängeranonymität [fSidI01]<br />
Ist es nicht möglich etwaige Beziehungen<br />
zwischen der Sender- und Empfängeridentität<br />
festzustellen, dann handelt es sich hierbei<br />
um sogenannte Unverkettbarkeit.<br />
Abbildung 1.3 Unverkettbarkeit [fSidI01]<br />
In diesem Sinne setzt sich die Anonymität<br />
aus dem Schutz des Empfängers, des<br />
Senders und dem Schutz der Kommunikationsverbindung<br />
zwischen diesen beiden Instanzen<br />
zusammen. Pseudonymität ermöglicht<br />
einen hohen Grad von anonymer Nutzung,<br />
da hier die Identität nicht bestimmbar<br />
ist. Erreicht wird das durch die Verwendung<br />
9.1 Einleitung<br />
von digitalen Pseudonymen als Identifikator<br />
[?]. Diese Arten von Anonymität lassen eine<br />
mehr oder weniger starke Abstufung in<br />
Bezug auf ihre Anwendung zu. Zusätzlich<br />
ist diese Einteilung sehr nützlich bei der Bewertung<br />
der in dieser Ausarbeitung noch folgenden<br />
Anonymisierungsverfahren. Folgende<br />
Abstufungen werden nach [fSidI01] unterschieden:<br />
(1) unmöglich zuzuordnen<br />
(2) nicht zuzuordnen<br />
(3) möglicherweise zuzuordnen<br />
(4) wahrscheinlich zuzuordnen<br />
(5) zuzuordnen<br />
(6) sicher zuzuordnen<br />
9.1.4 Einführende Beispiele<br />
Anonymität betrifft nicht nur Bereiche unseres<br />
Lebens wie die Benutzung des Internet<br />
oder die Nutzung mobiler situationsabhängiger<br />
Dienste. Auch die als selbstverständlich<br />
angesehenen Tätigkeiten haben sehr viel mit<br />
dem Thema Anonymität zu tun. Ein sehr<br />
einfaches Beispiel, das auch schon im vorherigen<br />
Abschnitt kurz angeführt wurde, ist<br />
die Benutzung einer öffentlichen Telefonzelle.<br />
Die eigene reale Identität kann kaum mit<br />
dem geführten Gespräch in Verbindung gebracht<br />
werden. In diesem Fall erfüllt dieses<br />
Beispiel die Definition der Unverkettbarkeit<br />
und der erreichte Grad der Anonymität könnte<br />
man als nicht zuzuordnen einstufen. Sollte<br />
die Telefonzelle aber in einer durch Kameras<br />
berwachten Umgebung befindlich sein<br />
und könnte in diesem Fall eine Verbindung<br />
zwischen der äußeren Erscheinung dieser<br />
Person, der Uhrzeit und dem Tag hergestellt<br />
werden, könnte anhand der Daten der betreibenden<br />
Telefongesellschaft und der festgehaltenen<br />
Daten der Kamera zu diesem Zeitpunkt,<br />
die Identität und die zugrundeliegende<br />
Intention des Anrufes fast vollständig bestimmt<br />
werden. Zugegeben dieses Szenario<br />
scheint sehr konstruiert, aber in diesem geschilderten<br />
Fall wäre der Grad der erreichten<br />
Anonymität mit zuzuordnen zu klassifizieren.<br />
Ein anderes einfaches Beispiel ist<br />
der Einkauf in einem beliebigen Geschäft.<br />
123
Thomas Jakob<br />
Unter der Voraussetzung, dass der Konsument<br />
mit Bargeld zahlt, kann der erreichte<br />
Grad der Anonymität hier mit möglicherweise<br />
zuzuordnen eingestuft werden. Innerhalb<br />
eines gewissen Zeitraumes kann der Verkäufer<br />
den Konsumenten durch seine persönliche<br />
Erinnerung zu einem gewissen Grad<br />
identifizieren. Unter dem Aspekt betrachtet,<br />
dass der Verkäufer den Konsumenten namentlich<br />
kennt, wäre auch hier die Identität<br />
bestimmbar. Unter normalen Umständen,<br />
beispielsweise in einem Supermarkt, ist es<br />
kaum möglich den einzelnen Konsumenten<br />
direkt zu identifizieren. Dann kann der erreichte<br />
Grad der Anonymität mit nicht zuzuordnen<br />
beschrieben werden. Schon diese<br />
einfachen Beispiele zeigen, wie schnell die<br />
eigene als selbstverständlich vorausgesetzte<br />
Anonymität neutralisierbar ist, auch wenn<br />
es sich in diesen Fällen nicht um sehr wichtige<br />
persönliche Daten, wie beispielsweise<br />
die Kreditkartennummer oder andere sensible<br />
zur Privatsphäre gehörenden Informationen<br />
handelt und dadurch sich der Schaden<br />
in kleinen Grenzen hält. Ein etwas komplexeres<br />
Beispiel stellt das Szenario des Einkaufens<br />
in einem Onlineshop dar. Anders als<br />
in einem Geschäft, wie im oberen Beispiel,<br />
werden hier direkt Daten wie Name, Adresse<br />
und Zahlung miteinander verknüpft. Aufgrund<br />
der Tatsache, dass man immer Datenspuren,<br />
und seien es nur sogenannte Cookies,<br />
die auf der Festplatte des Nutzers gespeichert<br />
werden, bei der Nutzung des Internet<br />
hinterlässt, kann der erreichte Grad hier<br />
nur mit zuzuordnen beschrieben werden.<br />
9.2 Anonymität im Festnetz<br />
Ein Großteil der heutigen modernen Kommunikation<br />
wird durch ein Netzwerk ermöglicht,<br />
das schon seit Jahrzehnten für die Sprachkommunikation<br />
genutzt wird. Seit Mitte der<br />
1990er Jahre stellt es auch die Basis für die<br />
kommerzielle Nutzung, aber besonders für<br />
die Nutzung durch die breite Öffentlichkeit<br />
des Internet dar. Innerhalb dieses bekannten<br />
öffentlichen Telefonnetzes fallen Inhaltsdaten,<br />
Kontextdaten, Verkehrsdaten, Bestandsdaten,<br />
Verbindungsdaten und Rechnungsdaten<br />
45 an. Den Bestandsdaten, Verbindungsdaten<br />
und Rechnungsdaten über die beteiligten<br />
Kommunikationspartner soll hier bezüglich<br />
des Themas eine größere Aufmerksamkeit<br />
gelten.<br />
9.2.1 Anonymisierungsverfahren<br />
innerhalb des Festnetzes<br />
Durch die Einrichtung der digitalen Sprachkommunikation<br />
46 in den 1990er Jahren, wurde<br />
es beispielsweise möglich, direkt die Telefonnummer<br />
des anrufenden Teilnehmers<br />
noch vor der Etablierung einer Sprachkommunikation<br />
an den angerufenen Teilnehmer<br />
zu übermitteln. Um diesem Problem in Bezug<br />
auf Anonymität zu begegnen, wurde die<br />
sogenannte Rufnummernunterdrückung eingeführt.<br />
Sollte also der anrufende Teilnehmer<br />
aufgrund der Anonymitätswahrung eine<br />
solche Unterdrückung seiner Rufnummer<br />
wollen, kann dieser das durch den Netzbetreiber<br />
veranlassen 47 . Eine Senderanonymität<br />
ist aber in diesem Fall trotzdem nicht<br />
gegeben, da der Netzbetreiber anhand der<br />
schon angeführten Bestandsdaten, Verbindungsdaten<br />
und Rechnungsdaten die spezifischen<br />
Informationen des gesamten Kommunikationsvorgangs<br />
ermitteln kann. Damit<br />
ist es möglich festzustellen, zu welchem Zeitpunkt<br />
Kommunikationsbeziehungen bestanden.<br />
Allein durch die Gefährdung der Sicherheit<br />
der Kommunikationsverbindung zwischen<br />
Sender und Empfänger ist hier die<br />
Bedingung für den Anonymitätsgrad sicher<br />
zuzuordnen erfüllt. Nach [fSidI01] funktioniert<br />
aber ausgehend vom benutzten Kom-<br />
45 Weitere Informationen siehe [MKea97]<br />
46 Einführung von Integrated Services Digital Network innerhalb des Public Switched Telephone Network [fSidI01]<br />
47 Aus diesem Grund gehört diese Verfahrensweise zu den betreiberabhängigen Anonymisierungsverfahren<br />
124<br />
[fSidI01]
munikationsprotokoll 48 die Rufnummernunterdrückung<br />
nicht. Der Grund für dieses Problem<br />
ist in Realisierung der Rufnummernunterdrückung<br />
zu suchen. Bei Benutzung des<br />
ISDN Protokolls wird die Signatur des anrufenden<br />
Teilnehmers bis zur letzten Vermittlungsstelle<br />
innerhalb des Netzes weitergeleitet<br />
und erst dort für den angerufenen Teilnehmer<br />
unkenntlich gemacht wird. Im Gegensatz<br />
dazu wird bei Verwendung des Zeichengabesystems<br />
#7 die Kommunikationsanlage<br />
des angerufenen Teilnehmers als Teil des<br />
Gesamtnetzes angesehen. In diesem Fall<br />
kann dieser Teilnehmer eigenständig über<br />
die Identifizierung des anrufenden Teilnehmers<br />
entscheiden.<br />
Nachdem sich gezeigt hat, dass die betreiberabhängigenAnonymisierungsverfahren<br />
völlig unzureichend sind, besonders weil<br />
die Kommunikationsbeziehungen gegenüber<br />
dem Netzbetreiber absolut nachvollziehbar<br />
sind und damit wiederum die Bedingungen<br />
der Anonymität nicht erfüllt werden können,<br />
stellt sich die Frage nach von den Netzbetreibern<br />
unabhängigen Methoden einer Anonymisierung.<br />
Die Etablierung eines sogenannten<br />
Relaissystems ist nach [fSidI01] ein einfaches<br />
und wirkungsvolles Konzept, um anonyme<br />
Kommunikationsvorgänge zu ermöglichen.<br />
Der Einsatz ist aber weitestgehend in<br />
der Realität nicht verfügbar. Dieses Relaissystem<br />
setzt sich aus mehreren Kommunikationsanlagen<br />
zusammen, so dass ein anrufender<br />
Teilnehmer nicht direkt seinen Kommunikationspartner<br />
anwählt, sondern die nächste<br />
verfügbare Relaisanlage. In diesem Zustand<br />
ermöglicht die Relaisanlage dem anrufenden<br />
Teilnehmer eine neue Kommunikationsbeziehung,<br />
indem dieser mittels der Signatur<br />
des ausgewählten Kommunikationspartners<br />
die Verbindung etabliert. Schon durch<br />
den Einsatz nur einer Relaisanlage wird der<br />
Nachweis einer Verbindung zwischen diesen<br />
Teilnehmern sehr erschwert, denn die Verbindung<br />
bestand im eigentlichen Sinne zwischen<br />
dem angerufenen Teilnehmer und der<br />
Relaisanlage. Um nachzuvollziehen, wer zu<br />
9.2 Anonymität im Festnetz<br />
diesem Zeitpunkt mit der Relaisanlage verbunden<br />
war und damit eine Kommunikationsverbindung<br />
zu dem angerufenen Teilnehmer<br />
hatte, könnte beispielsweise der Netzbetreiber<br />
alle bestandenen Verbindungen verfolgen.<br />
Dies ist aber mit einem doch sehr erheblichen<br />
Aufwand verbunden und beweist<br />
nicht einmal die Verbindung zwischen beiden<br />
Teilnehmern, da der angerufene Teilnehmer<br />
auch mit einem anderen Teilnehmer innerhalb<br />
des Relaissystems verbunden gewesen<br />
sein könnte. Nach [fSidI01] ist unter<br />
dem Aspekt, dass die Verbindungsdaten<br />
nicht durch den Netzbetreiber gespeichert<br />
werden, dieses Verfahren in Bezug auf<br />
den erreichten Grad der Anonymität mit zuzuordnen<br />
einzustufen. Aufbauend auf diesen<br />
Ausführungen lässt sich leicht erklären,<br />
dass die Wirksamkeit durch eine Vielzahl solchen<br />
Relaisanlagen innerhalb einer Relaiskette<br />
oder sogar innerhalb eines Relaisnetzes<br />
noch gesteigert werden kann. Der Grund<br />
hierfür ist der immer größer werdende Aufwand<br />
für den Netzbetreiber die Unverkettbarkeit<br />
zwischen den Kommunikationsteilnehmern<br />
des Relaissystems aufzuheben, da er<br />
die temporäre Verbindung zwischen den einzelnen<br />
Relaisanlagen, besonders innerhalb<br />
eines Relaisnetzes, kaum bestimmen kann.<br />
Bei der Verwendung der einzelnen Ausprägungen<br />
dieses Anonymisierungsverfahrens<br />
ist der erreichte Grad der Anonymisierung,<br />
der stark mit der Anzahl der verwendeten Relaisanlagen<br />
korreliert, zwischen wahrscheinlich<br />
zuzuordnen und zuzuordnen einzustufen.<br />
Zusammenfassend ist festzustellen, dass der<br />
bei der Kommunikation im Festnetz erreichte<br />
Grad der Anonymität, bei Verwendung<br />
eines Relaisnetzes mit einer größeren Anzahl<br />
von Relaisanlagen, höchstens mit wahrscheinlich<br />
zuzuordnen zu bezeichnen ist. Als<br />
untauglich in Bezug auf die Anonymisierung<br />
der Kommunikation innerhalb des Festnetzes<br />
haben sich die betreiberabhängigen Verfahren<br />
erwiesen, da diese zu einem gewissen<br />
Grad die Anonymität zwischen den Kommu-<br />
48 ISDN Protokoll für Teilnehmeranschlüsse EDSS1 oder das von Vermittlungsstellen genutzte Protokoll des Zei-<br />
chengabesystems #7<br />
125
Thomas Jakob<br />
nikationspartnern wahrt, aber letztendlich die<br />
Kommunikationsbeziehungen von Seiten der<br />
Netzbetreiber bestimmbar werden und damit<br />
die Unverkettbarkeit gefährdet ist. Unabhängige<br />
Anonymitätsverfahren wie die Verwendung<br />
des MIX-Modells innerhalb des Festnetzes<br />
49 , ermöglichen das Erreichen eines<br />
höheren Grades an Anonymität.<br />
9.3 Anonymität im Internet<br />
Das Internet ist die Gesamtheit aller weltweit<br />
über verschiedenste Kommunikationsmedien<br />
50 zusammengeschlossenen Computernetzwerke,<br />
die nach einem standardisierten<br />
Verfahren, dem TCP IP 51 , miteinander<br />
kommunizieren 52 [?]. Zur eindeutigen Identifizierung<br />
dieser Computer innerhalb des Netzes<br />
wurden sogenannte IP-Adressen eingeführt,<br />
die durch eine 32 Bit lange Zahl 53<br />
repräsentiert wird. Zur besseren Lesbarkeit<br />
wird diese Zahl durch vier Punkte, die wiederum<br />
vier Zahlen von 0 bis 255 voneinander<br />
trennen, dargestellt. Durch die schnell zunehmende<br />
Größe und Komplexität des Internet<br />
war es nicht mehr möglich, jedem Computer<br />
innerhalb des Netzes eine dauerhafte<br />
eindeutige Adresse zu geben. Aus diesem<br />
Grund wurden statische IP-Adressen für<br />
große Institutionen oder Einzelpersonen und<br />
dynamische IP-Adressen für Privatpersonen,<br />
die nur gelegentlich das Internet nutzen, eingeführt.<br />
Die dynamischen IP-Adressen werden<br />
von einem ISP 54 zu Beginn der Internetnutzung<br />
vergeben und können auch während<br />
einer Sitzung verändert werden [fSidI01]. Es<br />
wird schnell klar, dass bei Verwendung dynamischer<br />
IP-Adressen die mit dem Netzwerk<br />
verbundene Identität nur schwer zu bestimmen<br />
ist, während bei Verwendung von statischen<br />
IP-Adressen, aufgrund ihrer eindeutigen<br />
Bindung an eine Identität, diese prin-<br />
49 Siehe Abschnitt Anonymisierungsverfahren im Internet und [Cla01]<br />
50 Kommunkationsmedien wie Funk, PSTN<br />
51 Transmission Control Protocol¡ Internet Protocol<br />
52 www.internet4jurists.at/interntoa.htm<br />
53 Darstellung bezieht sich auf IPv4 [?]<br />
54 Internet Service Provider<br />
55 Internet Service Provider<br />
126<br />
zipiell verkettbar sind. Häufig identifiziert eine<br />
solche IP-Adresse nicht direkt den abrufenden<br />
Computer, sondern einen sogenannten<br />
Proxy-Computer, der vor den abrufenden<br />
Computer geschaltet wird, um beispielsweise<br />
durch Zwischenspeichern der Abrufergebnisse<br />
Bandbreite bei gleichartigen Anfragen zu<br />
sparen. Eine andere wichtige Anwendung ergibt<br />
sich durch den entstehenden Schutz des<br />
dahinter befindlichen Computers gegenüber<br />
direkten Angriffen [?].<br />
9.3.1 Datenkollektion bei der Nutzung<br />
des Internet<br />
Ähnlich wie bei den Kommunikationsvorgängen<br />
im Festnetz fallen auch beim Zugriff auf<br />
das Internet eine große Menge Daten an, die<br />
gespeichert und verarbeitet werden. Wichtig<br />
in Bezug auf die Anonymität ist der Aspekt<br />
der Mehrfachnutzung eines lokalen Rechners.<br />
Vor der eigentlichen Nutzung des Internet<br />
steht die Kommunikation mit dem Zugangsanbieter<br />
bzw. -vermittler, dem ISP 55<br />
oder auch Access Provider, bei dem sich<br />
der Teilnehmer beispielsweise über das Festnetz,<br />
zuerst einwählen muss, um danach die<br />
Dienste eines Providers in Anspruch nehmen<br />
zu können. Hier ist auch zu beachten,<br />
dass hier eventuell auch zusätzliche Zugangsvermittler,<br />
die aus einem lokalen Netz<br />
die Schnittstelle zu weiteren Providern bereitstellen,<br />
eine Instanz dieses Kommunikationsvorgangs<br />
bilden können. Weitere wichtige<br />
Rollen in diesem komplexen Netzwerk<br />
übernehmen die Diensteanbieter, die sogenannten<br />
Presence Provider und Service Provider,<br />
die beispielsweise Speicherplatz und<br />
Bandbreite bereitstellen, um die Möglichkeit<br />
der Präsentation von Inhalten im Internet zu<br />
bieten, und die Inhaltsanbieter, die Content
Provider, die für die eigentlichen Inhalte verantwortlich<br />
sind. In Hinblick auf das Thema<br />
der Anonymität im Internet ist es wichtig,<br />
welche Informationen typischerweise an<br />
welchen Stellen gesammelt werden. Diese<br />
werden ähnlich wie bei der Benutzung des<br />
Festnetzes in Bestandsdaten, Verbindungsdaten<br />
und Inhaltsdaten eingeteilt. Bestandsdaten<br />
werden bei den Anbietern der Dienste,<br />
wie Netzbetreiber, Access Provider und Service<br />
Provider, in einem vertraglichen Rahmen<br />
gespeichert. Verbindungsdaten ermög-<br />
Abbildung 1.3 Schema des Internet [?]<br />
Sowohl bei der Einwahl beim Telekommunikationsbetreiber<br />
56 als auch durch Einträge<br />
in der Logdatei des Terminal Servers 57 ,<br />
entstehen verwertbare Daten. Diese Einträge<br />
enthalten Informationen wie den Login-<br />
Namen, das Datum und die Uhrzeit der Anmeldung<br />
sowie die dem Client zugewiesene<br />
IP-Adresse. Der Proxy, wenn vorhanden,<br />
speichert dann die Anfragen des Teilnehmers,<br />
die durch den Browser übermittelt werden,<br />
und schickt dann die zugehörige Antwort<br />
des Web Servers wieder zurück. Während<br />
dieses Vorgangs wird die ankommende<br />
IP-Adresse beim Proxy registriert, um<br />
9.3 Anonymität im Internet<br />
lichen die Beschreibung der Umstände des<br />
Kommunikationsvorgangs durch Informationen<br />
wie Absender, Empfänger, Datum und<br />
Dienst, während die Inhaltsdaten die eigentlichen<br />
Nachrichten wie E-Mail, News oder Internetanfragen<br />
beinhalten. Zusätzlich ist natürlich<br />
auch wichtig, wer die Möglichkeit eines<br />
Zugriffs auf diese Daten hat, der generell<br />
bei den einzelnen Betreibern innerhalb ihres<br />
Bereichs umfassend ist, und wie lange diese<br />
gespeichert werden [?].<br />
diese dann durch eine eigene interne IP-<br />
Adresse zu ersetzen. Der Web Server erkennt<br />
dann nur diese IP-Adresse und bekommt<br />
so keine Kenntnis über die originale<br />
IP-Adresse des Clients. Beim Web Server<br />
wird die Anfrage des Clients mit weiteren Informationen<br />
wiederum in einer Logdatei gespeichert<br />
[MKea97], welche über ihren Umfang<br />
durch das World Wide Web Consortium<br />
im Common Logfile <strong>Format</strong> definiert sind 58 .<br />
Das CLF 59 beinhaltet Informationen in folgender<br />
<strong>Format</strong>ierung:<br />
remotehost rfc931 authuser [date]<br />
56 Weitere Informationen über die Art der Daten besonders bei Nutzung von ISDN siehe [MKea97]<br />
57 Zugangsrechner des Access Providers [?]<br />
58 siehe www.w3.org/Daemon/User/Config/Logging.html#common-logfile-format<br />
59 Common Logfile <strong>Format</strong><br />
127
Thomas Jakob<br />
request status bytes<br />
remotehost<br />
Name bzw. IP-Adresse des Clients<br />
rfc931<br />
Logname des Nutzers<br />
authuser<br />
Username, mit dem sich der Nutzer<br />
authentifiziert<br />
[date]<br />
Datum und Zeit der Anfrage<br />
request<br />
Anfragezeile, wie vom Client angegeben<br />
status<br />
Anfragestatus, wie an den Client übermittelt<br />
(http status code)<br />
bytes<br />
Länge der übermittelten Webseite<br />
Zusätzlich kommen noch Daten über die<br />
Computerkonfiguration des Clients, wie Plug-<br />
Ins, Informationen über die Aktivierung von<br />
Cookies, ActiveX Elemente oder Java bzw.<br />
Java Script innerhalb der Browserkonfiguration<br />
und weiterhin sogar die Bildschirmauflösung<br />
hinzu. Die Dauer der Datenhaltung ist<br />
auf Web Servern von der Auswertungszeit<br />
abhängig. Danach werden häufig diese Daten<br />
wieder gelöscht. Weiterhin werden in erweiterten<br />
Logdateien Informationen über den<br />
Referer, über die verwendete Browserversion<br />
und meist auch Informationen über Sprache<br />
und Betriebssystem gespeichert.<br />
Nach [?] ist die Übertragung des sogenannten<br />
Referer-Feldes, das Informationen über<br />
die angewählte URL der Webseite und über<br />
den Link enthält, durch den der Zugriff erfolgte,<br />
an den Web Server sehr kritisch zu<br />
betrachten. Web Server nutzen diese Informationen<br />
nicht nur um Zugriffe abzulehnen,<br />
die über Links von Webseiten der gegebenen<br />
Konkurrenz kommen, sondern auch um Informationen<br />
über Interessen und Nutzungsverhalten<br />
des Clients über den Bereich des<br />
60 siehe Beispiel in [?]<br />
128<br />
eigenen Web Server hinaus zu gewinnen.<br />
Bei der Verwendung von Suchmaschinen<br />
wird auch die Anfrage selbst über den Referer<br />
übermittelt. Besonders heikel wird dieses<br />
Problem bei sicherheitsrelevanten Informationen<br />
wie beispielsweise der Kreditkartennummer,<br />
wenn diese im Referer-Eintrag<br />
auftaucht 60 . Um diesem Problem zu begegnen,<br />
ist Zusatzsoftware, wie beispielsweise<br />
diverse Firewalls nötig, da die Standardbrowser<br />
keinerlei Möglichkeiten bieten, die Übertragung<br />
von Informationen über den Referer<br />
zu kontrollieren bzw. zu unterbinden.<br />
Nachdem die Anfrage des Client über den<br />
Proxy beim Web Server nun verarbeitet wurde,<br />
wird die angeforderte Seite auf gleichem<br />
Wege zurück an den Client übermittelt. Dabei<br />
werden Informationen über die Inhalte dieser<br />
Seite beim Proxy gespeichert, um spätere<br />
Zugriffe schneller zu gestalten. Natürlich<br />
fallen auch im Bereich des Client Daten<br />
an, denn die abgerufenen Informationen<br />
über die angeforderte Seite werden nicht nur<br />
kurzfristig im Hauptspeicher abgelegt, sondern<br />
auch innerhalb des angelegten Cache<br />
des Browsers zwischengespeichert. Häufig<br />
bleiben auch Überreste der zuletzt besuchten<br />
Adressen, wie beispielsweise Bilder, Animationen,<br />
Textelemente oder auch Multimediadateien,<br />
in dem durch das Betriebssystem<br />
vorgesehenen Ordner zurück. Über diese Informationen<br />
können besonders bei Mehrbenutzersystemen<br />
ohne Zugriffseinschränkungen<br />
Unberechtigte einen Einblick in die Nutzungsgewohnheiten<br />
bekommen. Das ist ohne<br />
Frage eine immense Verletzung der Anonymität<br />
und folglich ein Eindringen in die<br />
Privatsphäre des Nutzers. Die angesprochenen<br />
Informationen, die durch den Browser<br />
beim Client gespeichert werden, sollen eigentlich<br />
dem Nutzer helfen das Internet effizienter<br />
zu nutzen, aber besonders Web Server<br />
haben ein großes Interesse, durch die Ermittlung<br />
der Gewohnheiten des Nutzers ihr<br />
Angebot beispielsweise durch Benutzerprofile<br />
zu verbessern. Um diese Gewohnheiten<br />
zu verfolgen, gibt es unterschiedliche Mechanismen.<br />
Sogenannte Cookies sind vom
Server generierte Einträge in einer Datei namens<br />
Cookies.txt oder einem Verzeichnis namens<br />
Cookies, die während der Benutzung<br />
auf dem Computer des Client gespeichert<br />
werden und zu einem späteren Zeitpunkt<br />
beim nächsten Zugriff auf den Server wieder<br />
an diesen übermittelt werden [?]. Diese enthalten<br />
folgende Informationen:<br />
Domain, die den Cookie gesetzt hat<br />
und lesen kann<br />
Information, ob alle Computer der<br />
Domain Zugriff auf den Cookie haben<br />
Domainpfad, in der der Cookie gültig ist<br />
Abbildung 1.3 Beipiele für Cookies 62 [?]<br />
Was den Aspekt der Anonymität des Client<br />
angeht, sind im Gegensatz zu den Cookies,<br />
die bei Beendigung des Browsers gelöscht<br />
werden, besonders die persistenten, also<br />
dauerhaft abgespeicherten Cookies aus folgenden<br />
Gründen kritisch. Die Standardkonfiguration<br />
der häufig genutzten Browser bietet<br />
hinsichtlich der Funktionsweise der Cookies<br />
wenig Transparenz, da der Client nicht über<br />
Inhalte, Zweck, Umfang und Speicherdauer<br />
oder Zugriffsmöglichkeiten hinsichtlich der<br />
Cookie-Datei informiert wird. Cookies können<br />
die Erstellung von <strong>Prof</strong>ilen über den Client<br />
ermöglichen. Sollte sich der Client auf einem<br />
Web Server identifizieren, können diese<br />
Informationen dem <strong>Prof</strong>il zugeordnet werden.<br />
Insbesondere sind Cookies durch keinerlei<br />
Zugriffsrechte auf der Festplatte des<br />
Client geschützt und durch die Aufzeichnung<br />
in Form von ASCII-Dateien sehr leicht zugänglich.<br />
Der Client kann sich gegen diese<br />
61 verschlüsselte Abfrage<br />
62 Weitere Beispiele siehe [fSidI01]<br />
9.3 Anonymität im Internet<br />
Information, ob Cookie-Zugriff nur bei<br />
SSL Verbindung 61 möglich ist<br />
Zeitangabe für die Lebensdauer des<br />
Cookies<br />
Name des Cookies<br />
Wert des Cookies<br />
(häufig eine Identifikationsnummer)<br />
Die folgende Abbildung zeigt beispielhaft<br />
Cookie-Einträge, generiert durch den Microsoft<br />
Internet Explorer, in eine solche ASCII-<br />
Datei. Hierbei stellt jede Spalte ein Cookie<br />
dar.<br />
Vorgehensweisen nur schützen, in dem er<br />
die Cookies nur kontrolliert zulässt oder die<br />
Speicherung absolut deaktiviert. Eine andere<br />
Möglichkeit bietet die manuelle Löschung<br />
oder die ASCII Dateien vor Schreibzugriffen<br />
zu schützen.<br />
Ein weiterer Mechanismus den Weg des Teilnehmers<br />
auf einem Web Server zu verfolgen,<br />
ist die Zuweisung einer Session-ID. Diese<br />
ist in ihrer Funktionsweise mit temporären<br />
Cookies vergleichbar. Diese Zuweisung erfolgt<br />
beim Zugriff auf einen Web Server und<br />
wird als Teil der Adresse während der gesamten<br />
Bewegung auf diesem Web Server<br />
mitgeführt. Die Gültigkeit dieser Nummern<br />
sind durch die Verwendung eines Zeitstempels<br />
bei der Generierung zeitlich begrenzt<br />
und durch Verwendung einer Hashfunktion<br />
mit einer Zufallszahl nicht vorhersagbar [?].<br />
Im folgenden Beispiel ergab der einfache<br />
129
Thomas Jakob<br />
Aufruf der Hauptseite von Amazon.de die folgende<br />
Adressenanzeige, wobei der markierte<br />
Teil eine Session-ID darstellt:<br />
http://www.amazon.de/exec/obidos/<br />
tg/browse/-/301128/<br />
028-5679630-3343701<br />
?siteredirect= de 63<br />
Die sogenannten Web-Bugs oder auch<br />
Clear GIFs sind transparente 1x1 Pixel große<br />
GIF-Bilder. Das Besondere an dieser Vorgehensweise<br />
ist der Aspekt, dass diese Bilder<br />
weder vom Computer des Client noch von<br />
dem des Anbieters geladen werden, sondern<br />
von einem weiteren dritten Server. Bei einem<br />
Zugriff auf die Seite des Anbieters wird<br />
auch das Bild vom dritten Server vom Computer<br />
des Client geladen und ermöglicht so<br />
einen Eintrag in der Logdatei des dritten Servers.<br />
Dieser Eintrag enthält wichtige Informationen<br />
wie den Referer, User-Agent, IP-<br />
Adresse, Uhrzeit und Cookies. Der Web-Bug<br />
ist sogar in der Lage selbst Cookies zu setzen,<br />
die dann natürlich auch direkt zum dritten<br />
Server übermittelt werden. Das Erkennen<br />
solcher Bilder ist nur durch die Untersuchung<br />
des HTML Quellcodes der abgerufenen Seite<br />
möglich, also für einen Laien absolut unmöglich<br />
zu erkennen.<br />
Weitere Mechanismen sind der Einsatz von<br />
Lesezeichen beim Microsoft Internet Explorer<br />
und sogenannter Bannerwerbung. Die<br />
Verwendung von Lesezeichen die ab der<br />
Browser-Version 5.0 möglich wurde, ermöglicht<br />
lediglich, dass ein Web Server, der das<br />
Lesezeichen generiert hat, feststellen kann,<br />
ob der Nutzer seine Seite in der Liste der<br />
Lesezeichen hat. Bei Bannerwerbungen etabliert<br />
der verwendete Browser eine zusätzliche<br />
HTTP-Verbindung, über die der Anbieter,<br />
direkt über den Referer und über den<br />
Banner verteilte Cookies, Informationen über<br />
den Client erhält. Aufgrund der über viele<br />
Webseiten verteilten Bannerwerbungen können<br />
Firmen wie beispielsweise DoubleClick<br />
umfassende <strong>Prof</strong>ile über die Nutzer erstellen<br />
63 Weitere Beispiele zu diesem Thema siehe [?]<br />
64 Processor Serial Number<br />
65 Media Access Control<br />
130<br />
[fSidI01].<br />
Durch die sogenannten Globally Unique<br />
Identifiers (GUID), die in Hardware, in Software<br />
oder in Diensten implementiert sein<br />
können, wird eine eindeutige Kennung der<br />
einzelnen Computer innerhalb des komplexen<br />
Internet möglich. Schon 1999 setzte Intel<br />
im Prozessor Pentium III eine solche Kennung<br />
ein. Diese PSN 64 kann durch spezielle<br />
Software abgefragt werden und ermöglicht<br />
somit eine eindeutige Identifizierung.<br />
Bekanntestes Beispiel für die Verwendung<br />
einer GUID dürfte die Onlineregistrierung<br />
von Windows 98 von Microsoft sein. In diesem<br />
Fall wird über die eindeutige MAC 65 -<br />
Adresse der Netzwerkkarte dem Nutzer eine<br />
GUID zugewiesen. Mit einer solchen eindeutigen<br />
Nummer arbeitet beispielsweise auch<br />
der Windows Media Player von Microsoft.<br />
Das neue IP-Protokoll IPv6 sieht im jetzigen<br />
Planungsstadium vor, dass in allen Datenpaketen<br />
Informationen über die eindeutigen<br />
Netzkarten-Adressen (MAC) eingebaut werden.<br />
Dann würden alle Teilnehmer, die das<br />
Internet über ein lokales Netz nutzen, entsprechende<br />
Spuren hinterlassen [?].<br />
Zusammenfassend zeigt sich deutlich, dass<br />
der Client bzw. Teilnehmer einer Vielzahl von<br />
direkten und indirekten Angriffen hinsichtlich<br />
seiner Anonymität während der Nutzung des<br />
Internet ausgesetzt ist. Aufgrund der Tatsache,<br />
dass die einzelnen Provider der Internetdienste<br />
zumeist auf sehr verschiedenen<br />
gesetzlichen Grundlagen zu diesem Thema<br />
arbeiten, ist eine Kontrolle der Datenkollektion<br />
und die Verwendung dieser Daten kaum<br />
möglich. Letztendlich ist jeder Teilnehmer<br />
selbst für den Schutz seiner persönlichen<br />
Daten verantwortlich. Die daraus resultierenden<br />
Maßnahmen erfordern aber ein gewisses<br />
Maß an Wissen in welcher Form und<br />
von welchen Instanzen Informationen über<br />
seine Identität gesammelt und verarbeitet<br />
werden. Einen interessanten Einblick in die<br />
durch einen Aufruf einer Webseite übermit-
telten Daten erhält man beispielsweise unter<br />
http://privacy.net/analyze/.<br />
9.3.2 Anonymisierungsverfahren im<br />
Internet<br />
Das MIX-Konzept<br />
Die Möglichkeiten eine Anonymität zu wahren,<br />
liegt im Schutz der schon angeführten<br />
Daten 66 über die einzelnen Instanzen eines<br />
Kommunikationsvorgangs und natürlich<br />
im Schutz der Daten der Kommunikationsverbindung<br />
selbst. Das MIX-Konzept setzt<br />
zum Schutz dieser Daten genau an diesem<br />
Punkt an. Grund- und Hauptanforderung an<br />
das MIX-Konzept ist aus diesem Grunde die<br />
Nichtzuordenbarkeit der einlaufenden zu den<br />
auslaufenden Nachrichten, also der Unverkettbarkeit<br />
zwischen dem Empfänger und<br />
dem Sender einer Nachricht [Cla01].<br />
Abbildung 1.3 Teilnehmer im MIX [Cla01]<br />
Funktionsweise eines MIX<br />
Zwei Teilnehmer eines Netzes, ein Sender<br />
und ein Empfänger, möchten miteinander anonym<br />
kommunizieren. Der Sender schickt<br />
dazu eine Nachricht an den Mix, der anhand<br />
der Nachricht die Adresse des Empfängers<br />
ermittelt, um dann diese Nachricht an den<br />
angegebenen Empfänger zu übermitteln. Die<br />
Nutzung des Mix macht bezüglich der Anonymität<br />
der Kommunikationsbeziehung nur<br />
9.3 Anonymität im Internet<br />
dann Sinn, wenn die Zuordnung der vom MIX<br />
empfangenen und gesendeten Nachrichten<br />
nicht möglich ist. Der Einsatz einer MIX-Kette<br />
oder sogar eines MIX-Netzes erlaubt den Zustand,<br />
dass der erste MIX die Adresse des<br />
Sender kennt und der letzte MIX die Adresse<br />
des Empfängers [Cla01]. Innerhalb des<br />
Netzes oder der Kette ist den eingesetzten<br />
MIXes keinerlei Daten über den Empfänger<br />
oder den Sender bekannt. Bei einer einfachen<br />
Verbindung mit einem Sender, Empfänger<br />
und einem Verbindungsrechner M, ist die<br />
Anonymität sofort gefährdet, wenn die Verbindung<br />
zwischen dem Sender und dem Verbindungsrechner<br />
abgehört wird. Aus diesem<br />
Grunde müssen die Kommunikationsverbindungen<br />
verschlüsselt werden. Nach [fSidI01]<br />
erfolgt diese Kodierung durch ein asymmetrisches<br />
Verfahren. Dabei wird die Nachricht<br />
durch einen öffentlichen Schlüssel des Empfängers<br />
kodiert und danach nochmals durch<br />
den öffentlichen Schlüssel des MIX inklusive<br />
der Enpfängeradresse kodiert. Der Sender<br />
sendet diese verschlüsselte Nachricht<br />
an den MIX. Vor der Verschlüsselung werden<br />
Nachrichten mit sich wiederholendem Inhalt<br />
mit einer zufälligen Zeichenkette versehen,<br />
so dass diese nicht immer gleich kodiert<br />
werden. Der MIX entschlüsselt mittels<br />
seinem Schlüssel die Nachricht, trennt diese<br />
von der überflüssigen Bitfolge und übermittelt<br />
die Nachricht dann an den Empfänger.<br />
Dieser dekodiert dann mittels seines privaten<br />
Schlüssels die Nachricht [fSidI01].<br />
Schwachstellen im MIX-Konzept<br />
Ein außenstehender Angreifer könnte durch<br />
die Verfolgung der einzelnen Nachrichten in<br />
und aus dem MIX die Kommunikationsvorgänge<br />
aufdecken. Ein großer Nachteil wäre<br />
hier der Aspekt, dass die Nachrichten anhand<br />
ihrer Größe und Reihenfolge identifiziert<br />
und dekodiert werden könnten. Durch<br />
die zufällige Bitfolge, die vor der eigentlichen<br />
Verschlüsselung in die Nachricht eingebracht<br />
werden, wird eine solchen Identifizierung<br />
sehr erschwert. Zusätzlich kann<br />
66 Daten wie Bestandsdaten, Verbindungsdaten, Rechnungsdaten ... weitere Informationen siehe [MKea97]<br />
131
Thomas Jakob<br />
durch die Einhaltung einer konstanten Nachrichtenlänge<br />
durch Neuverteilung der Daten<br />
auf mehrere Nachrichten eine Verkettung<br />
der Kommunikationsinstanzen verhindert<br />
werden. Die Offenlegung durch die<br />
Verfolgung der Reihenfolge der Nachrichten<br />
kann durch einfache zeitlich verzögerte<br />
Weiterleitung der Nachrichten verhindert<br />
werden. Einen aktiven Angriff stellt das Abfangen<br />
einzelner Nachrichten und wiederholtes<br />
Einspeisen dieser Nachrichten zum<br />
Zwecke der Offenlegung der Arbeitsweise<br />
des MIX dar. Um einem Aufdecken der Kommunkationsbeziehungen<br />
zu begegnen gibt<br />
es die Möglichkeit anhand von Aufzeichnungen<br />
über schon versendete Nachrichten Duplikate<br />
sofort zu eliminieren. Eine andere<br />
Möglichkeit ist die Einführung einer Art Zeitstempel,<br />
der die Gültigkeit einer Nachricht<br />
innerhalb des Netzes beschränkt. Die Wahl<br />
des gültigen Zeitraums ist bei der Methode<br />
natürlich sehr heikel [fSidI01].<br />
Einsatz von Kaskaden und Netzen<br />
Die Sicherheit hinsichtlich der Kommunikationsbeziehungen<br />
erhöht sich dich durch den<br />
Einsatz von MIX-Kaskaden oder MIX-Netzen<br />
beträchtlich. Bei diesem Verfahren kennt nur<br />
der erste MIX direkt die Adresse des Senders<br />
und der letzte MIX in der Verbindung direkt<br />
die Adresse des Empfängers. Die Verbindungsdaten<br />
innerhalb der Kaskade oder des<br />
Netzes sind über die unabhängigen MIXe innerhalb<br />
der Verbindung mit der Verwendung<br />
des Verschlüsselungsverfahren kaum zu bestimmen.<br />
Problematisch ist hier noch die Be-<br />
132<br />
stimmbarkeit des Weges, den die Nachricht<br />
bei der Übermittlung genommen hat. Unter<br />
diesem Gesichtspunkt betrachtet stellen<br />
die MIX-Kaskaden bzw. MIX-Ketten wiederum<br />
ein Sicherheitsrisiko dar, da in einer Kaskade<br />
die Nachrichten immer gleich verarbeitet<br />
werden und damit nachvollziehbar werden.<br />
Ein Netz aus einer Vielzahl von MIXen<br />
hat den offensichtlichen Vorteil, das der Weg,<br />
den die Nachricht während der Übermittlung<br />
durch das Netz nimmt, kaum bestimmbar ist.<br />
[Cla01] [fSidI01]<br />
Bewertung<br />
Das MIX-Konzept stellt aufgrund des Aufbaus<br />
dieses Verfahrens Sendeanonymität<br />
und Unverkettbarkeit dar. Der erreichte Grad<br />
der Anonymität liegt im Bereich nicht zuzuordnen,<br />
da alle Teilnehmer mit gleicher<br />
Wahrscheinlichkeit Sender wie Empfänger<br />
sein können. Das Maß an Anonymität, das<br />
diese Methode erreicht, ist aber auch stark<br />
von der Menge der Teilnehmer abhängig.<br />
Um so mehr Teilnehmer vorhanden sind, um<br />
so mehr potentielle Empfänger einer Nachricht<br />
sind möglich. Der Einsatz dieses Verfahrens<br />
beschränkt sich aber dennoch aufgrund<br />
der Vorbeugung gegenüber Angriffen auf das<br />
Verfahren auf asynchrone Dienste wie E-Mail<br />
[fSidI01].<br />
Das Crowd-Konzept<br />
Dieses Vefahren wurde 1997 von Michael<br />
Reiter und Aviel Rubin bei AT&T unter<br />
dem Gesichtspunkt der Anonymisierung von<br />
Web-Zugriffen entwickelt [fSidI01].
Abbildung 1.3 Teilnehmer in einer Crowd [fSidI01]<br />
Funktionsweise des Verfahrens<br />
Eine Crowd ist als eine Menge von Teilnehmern<br />
innerhalb des Internet anzusehen. Innerhalb<br />
dieser Menge wird jeder Teilnehmer<br />
durch einen Prozess auf seinem Computer<br />
identifiziert. Dieser Prozess wird jondo genannt.<br />
Nach der Initialisierung des jondo kontaktiert<br />
dieser einen Server, der blender genannt<br />
wird, um sich in dieser Menge zu etablieren.<br />
Der Teilnehmer muss auf diesem<br />
Server einen Account besitzen, den er durch<br />
die korrekte Authentifizierung nutzen kann.<br />
Der Server wiederum speichert die Teilnehmerdaten<br />
wie Accountname, IP-Adresse und<br />
Portnummer in einem Verzeichnis über alle<br />
teilnehmenden Prozesse innerhalb der<br />
Crowd und macht diese dem neu angemeldeten<br />
Prozess bekannt. Dies geschieht unter<br />
der Verwendung eines vom Server generierten<br />
Schlüssels für ein symmetrisches Verschlüsselungsverfahren,<br />
den der Server nun<br />
mit dem jeweiligen Passwort der einzelnen<br />
Teilnehmer kodiert und an alle angemeldeten<br />
Prozesse versendet. Der jondo wird nach<br />
9.3 Anonymität im Internet<br />
der Aufnahme in die Crowd vom Teilnehmer<br />
als Proxy in seiner Konfiguration genutzt.<br />
Dieser schaltet sich vor den Teilnehmer und<br />
bearbeitet somit die Anfragen des verwendeten<br />
Browsers. Bei einer Kontaktierung initialisiert<br />
der Proxy den Pfad zwischen dem<br />
Browser und dem Zielserver. Dies geschieht<br />
unter Verwendung eines anderen innerhalb<br />
der Menge verfügbaren jondo, der die Anfrage<br />
des Teilnehmers nun bearbeitet oder die<br />
Anfrage nochmals an eine andere Relaisstelle<br />
weiterleitet. In diesem Fall kann die Anfrage<br />
entweder wiederum an einen neuen Prozess<br />
weitergeleitet werden oder direkt an den<br />
Zielserver übermittelt werden. Der ursprünglichen<br />
Prozess, von dem der Impuls für die<br />
Etablierung des Pfades stammt, kann sogar<br />
anhand der durch den blender übermittelten<br />
Teilnehmerliste entscheiden, welche anderen<br />
Teilnehmer bzw. Prozesse bei der Generierung<br />
des Pfades mit einbezogen werden<br />
sollen. Jeder Teil des festgelegten Pfades<br />
wird nun bidirektional genutzt bis ein<br />
neuer Zielserver benannt wird und ein neu-<br />
133
Thomas Jakob<br />
er Pfad aufgebaut werden muss. Die Sicherung<br />
der Kommunikation entlang des festgelegten<br />
Pfades wird durch den schon erwähnten<br />
Schlüssel unter zusätzlicher Verwendung<br />
eines symmetrischen Kodieralgorithmus gewährleistet<br />
[fSidI01].<br />
Bewertung<br />
Ein großer Vorteil dieses Verfahrens ist<br />
die durch die angewendete symmetrische<br />
Verschlüsselung erreichte Performanz gegenüber<br />
vergleichbaren Verfahren, die eine<br />
asymmetrische Kodierung nutzen 67 . Das<br />
ganze System zeichnet sich gegenüber dem<br />
MIX-Konzept durch eine hohe Anpassungsfähigkeit<br />
hinsichtlich der Skalierung der Anzahl<br />
der beteiligten Prozesse aus. Durch die<br />
Komplexität des Internet sind die einzelnen<br />
an der Kommunikation beteiligten Prozesse<br />
auf viele Domänen verteilt, was die verbindenden<br />
Pfade vor einem Angriff schützt.<br />
Der absolute Angriffspunkt und damit ein<br />
großer Nachteil an diesem Verfahren ist die<br />
Existenz des blenders. Da dieser Kenntnis<br />
über die Teilnehmerdaten der an der Kommunikation<br />
beteiligten Prozesse hat, würde<br />
eine Korrumpierung dieser Instanz eine Offenlegung<br />
aller Kommunikationswege und Instanzen<br />
des Systems bewirken. Auch sehr<br />
bedenklich ist der Aspekt, dass der sich anmeldende<br />
Prozess direkt mit dem blender in<br />
Kontakt tritt und dabei seine Teilnehmerdaten<br />
übermittelt, also dadurch seine Anonymität<br />
gegenüber dem Server aufgibt. Der angesprochene<br />
Vorteil der über viele Domänen<br />
verteilten Prozesse kann auch insofern ein<br />
Nachteil sein, als die Teilnehmer leichter zu<br />
enttarnen wären, wenn die Menge der teilnehmenden<br />
Prozesse zu klein ist [fSidI01].<br />
67 Verfahren wie das MIX-Konzept<br />
68 Mobile Switching Center<br />
69 Global System Mobile<br />
134<br />
9.4 Anonymität in zelluaren<br />
Mobilfunknetzen<br />
9.4.1 Definition und Entwicklungen<br />
Mobilfunknetze sind Telekommunikations-<br />
Netze, die eine drahtlose Kommunikation<br />
zwischen beweglichen Teilnehmern und<br />
Übergänge zu festen Netzen unterstützen.<br />
Sie werden heute für unterschiedliche<br />
Zwecke, wie beispielsweise Sprache, Daten,<br />
Kurznachrichten und Funkruf benutzt.<br />
Wesentlicher Bestandteil von Mobilfunknetzen<br />
ist eine Netztechnik, die eine automatische<br />
Vermittlung, eine Gebührenaufzeichnung<br />
und einen Anschluß an das öffentliche<br />
Festnetz ermöglicht. Modulare großflächige<br />
Netze sind zellular strukturiert. Das Prinzip<br />
besteht darin, dass das zu versorgende Gebiet<br />
in eine Vielzahl kleiner Zellen eingeteilt<br />
wird. In jeder Zelle wird eine Funkfeststation<br />
als Basisstation installiert. Mehrere Basisstationen<br />
werden über eine Funkvermittlungsstelle,<br />
dem MSC 68 , mit dem öffentlichen Telekommunikationsnetz<br />
verbunden. Die Steuerung<br />
im Netz muß dafür sorgen, daß zu jedem<br />
Zeitpunkt dem System bekannt ist, in<br />
welcher Zelle sich der mobile Teilnehmer befindet<br />
[MKea97].<br />
Das im Jahre 1986 in Deutschland eingeführte<br />
C-Netz hatte den großen Nachteil einer<br />
analogen Sprachübertragung, was eine<br />
leichte Korrumpierung des Systems möglich<br />
machte. Die nächste Entwicklung war das digitale<br />
GSM 69 -Netz, welches in Deutschland<br />
beispielsweise in Form des D1-Netzes, D2-<br />
Netzes und E-Plus-Netzes eingeführt wurde<br />
[MKea97].<br />
9.4.2 Datenkollektion innerhalb des<br />
GSM-Mobilfunknetzes<br />
Die Datensammlung erfolgt prinzipiell in allen<br />
Mobilfunknetzen auf die gleiche Weise.<br />
Die Art der anfallenden Daten ist mit
der Datenkollektion innerhalb des Festnetzes<br />
vergleichbar. Lediglich im Umfang der<br />
Daten, die gespeichert und verarbeitet werden,<br />
unterscheiden sich diese Netze. Angelehnt<br />
an das Datenmodell, wie es schon im<br />
Abschnitt Anonymität im Festnetz vorgestellt<br />
wurde, fallen in Bezug auf Anonymität nach<br />
[MKea97] folgende Daten an:<br />
Inhaltsdaten<br />
Eine Speicherung dieser Daten erfolgt nur<br />
bei erweiterten Diensten wie beispielsweise<br />
der Mailbox. Ansonsten erfolgt die Übertragung<br />
transparent und der Teilnehmer kann<br />
absolut kontrollieren, welche Daten er übermittelt.<br />
Bestandsdaten<br />
Diese unterliegen auch hier in Bezug auf den<br />
Umfang und der Art den gesetzlichen und<br />
vertraglichen Rahmenbedingungen und werden<br />
bei der einmaligen Erstellung der SIM 70 -<br />
Karte, des zugehörigen symmetrischen geheimen<br />
Schlüssels, der Erstellung des Benutzerprofils<br />
IMSI 71 , sowie bei Bearbeitung<br />
der Abrechnungsdaten benötigt. Teile der<br />
Bestandsdaten werden zusätzlich in jedem<br />
MSC in den Bereichen der HLR 72 und VLR 73<br />
gespeichert und genutzt. Das OMS 74 bildet<br />
und verwaltet die Bestandsdaten über das<br />
Telefonverzeichnis und die Chipkarten.<br />
Verbindungsdaten<br />
In der Mobilkommunikation ist auf Grund der<br />
Flexibilität der Endgeräte ein umfangreicher<br />
Datenbestand und eine dynamische Verwaltung<br />
und Verteilung dieser Daten erforderlich.<br />
Informationen zum Aufbau und zur Aufrechterhaltung<br />
einer Kommunikationsverbindung<br />
müssen an die beteiligten Stellen gelangen.<br />
Bei jeder Nutzung des Dienstes muß<br />
eine virtuelle Verknüpfung zwischen den be-<br />
9.4 Anonymität in zelluaren Mobilfunknetzen<br />
teiligten Instanzen gewährleistet sein. Hierzu<br />
sind die erforderlichen Verbindungs-/ Lokalisationsdaten<br />
von den Vermittlungskomponenten<br />
(MSC) zu erstellen, zwischenzuspeichern<br />
und an die Datennachverarbeitung<br />
weiterzuleiten. Hierzu muß eine Zuordnung<br />
der Teilnehmerprofile zu den Verbindungsdaten<br />
hergestellt werden.<br />
Rechnungsdaten<br />
Die erforderliche Datenzusammenstellung,<br />
die sich aus den Bestandsdaten, Informationen<br />
aus den Verbindungsvorbereitungsdaten<br />
sowie aus den Verbindungsdaten zusammensetzen,<br />
für die Erstellung der Rechnungsdaten<br />
kann nur durch eine zentrale<br />
Bearbeitung erfolgen. Dafür ist der Datenaustausch<br />
aller hierzu erforderlichen Inhalte<br />
über das Netzwerk notwendig. Als Datenquellen<br />
dienen Informationen aus den Kommunikationskomponenten<br />
des Kernsystems,<br />
in diesem Falle AC 75 , MSC und OMC, der<br />
Mobilfunknetze.<br />
Bei der Konzipierung und Entwicklung des<br />
Systems der Mobilfunknetze wurde mehr<br />
Wert auf die zuverlässige Funktion der einzelnen<br />
Dienste gelegt, als auf Aspekte der<br />
Anonymität der beteiligten Kommunikationsinstanzen.<br />
Aus diesem Grunde ist der Umfang<br />
der Verbindungsdaten auch sehr groß.<br />
Alle entwickelten Sicherheitskonzepte beruhen<br />
auf dem unbedingten Schutz der Funktionen<br />
des Netzes. Die IMSI soll beispielsweise<br />
einen unberechtigten Einbruch über<br />
SIM-Karten in das System unmöglich machen.<br />
Über diese Identifikation wird beim Anmelden<br />
in das Netz aufgrund der eindeutigen<br />
Kennung 76 der SIM-Karte eine nur dem<br />
System bekannte Kodierung 77 generiert, die<br />
den entgültigen Zugang zum Netz ermöglicht.<br />
Nach [MKea97] existieren folgende etablierte<br />
Schutzmaßnahmen:<br />
70 Subscriber Identity Module<br />
71 International Mobile Subscriber Identification<br />
72 Home Location Register<br />
73 Visitors Location Register<br />
74 Operating and Maintenance System<br />
75 Authentication Center<br />
76 Teilnehmerauthentisierungsschlüssel siehe [fSidI01]<br />
77 Die temporäre Teilnehmeridentität TMSI, die lokal von der VLR vergeben wird [fSidI01]<br />
135
Literatur<br />
Zugangsschutz auf Rechner, Datenbanken,<br />
Vermittlungsknoten<br />
Verschlüsselte Übertragung von<br />
Nutzdaten vom Endgerät zur<br />
Basisstation<br />
Verbindungsdaten<br />
(bekannt vom D1-Netz)<br />
Abrechnungsdaten<br />
(bekannt vom D1-Netz)<br />
Persönliche Identifikationsnummer (PIN)<br />
für die Benutzung des Endgerätes<br />
Gerätebezogene Kennummer mit<br />
Kontrolle im AC.<br />
Es ist zusammenfassend festzuhalten, dass<br />
innerhalb des GSM-Mobilfunknetzes eine<br />
umfassende Datenkollektion stattfindet. Zum<br />
Teil ist das auf die mobile Architektur zurückzuführen,<br />
bei der der Umfang der Verbindungsdaten<br />
sehr umfassend ist. Ähnlich wie<br />
bei den Betreibern im Festnetz haben die Betreiber<br />
der Mobilfunknetze jederzeit umfassenden<br />
Zugriff auf die im Netz befindlichen<br />
Identitäten. Vor allem ist es möglich, den<br />
Aufenthaltsort dieser Identität zu bestimmen.<br />
Die Genauigkeit dieser Ortsbestimmung beschränkt<br />
sich dabei aber grundsätzlich auf<br />
die Bestimmung des Standortes der Funkzelle.<br />
Im Gegensatz dazu haben unberechtigte<br />
<strong>Dr</strong>itte kaum die Möglichkeit die Identität<br />
und den Aufenthaltsort eines Teilnehmers innerhalb<br />
des Mobilnetzes zu ermitteln. Durch<br />
die Generierung der temporären Teilnehmeridentität<br />
TMSI sind von Seiten der Mobilfunknetze<br />
ein ausreichender Schutz entwickelt<br />
worden.<br />
Literatur<br />
9.5 Abschließende Bemerkung<br />
Das Thema Anonymität ist ein teilweise sehr<br />
unterschätztes Problem. Jeder versucht seine<br />
Privatsphäre zu schützen und hat auch<br />
ein Recht darauf. Neben den Gesetzen,<br />
die leider nur den Umgang mit den Daten<br />
und nicht den Umfang der Datensammlung<br />
aus dem persönlichen Umfeld definieren,<br />
ist aber dennoch jeder selbst für den<br />
Schutz seiner Privatsphäre verantwortlich.<br />
Das gilt für das tägliche Leben, wie auch<br />
für die Nutzung technologischer Entwicklungen,<br />
die einen mobilen Zugang zu kommunikativen<br />
Diensten ermöglichen. Es gibt viele<br />
Möglichkeiten sich vor direkten und indirekten<br />
Angriffen besonders im Internet zu<br />
schützen. Allein durch die richtige Konfiguration<br />
des benutzten Browsers und der besonnene<br />
Umgang mit dem Internet kann<br />
schon helfen zum großen Teil einer Anonymität<br />
nahe zu kommen. In der Zukunft wird<br />
es durch den vermehrten Einsatz von Internetprotokollen<br />
78 oder den Einsatz von GUID,<br />
die eine eindeutige Identifikation des Nutzers<br />
unter dem Deckmantel des Schutzes<br />
von Daten- und Softwarekriminalität immer<br />
einfacher machen [?]. Im Festnetz und dem<br />
mobilen Netzen haben zwar die Betreiber<br />
einen unbeschränkten Zugriff auf die Daten<br />
der Teilnehmer, aber unberechtigte <strong>Dr</strong>itte<br />
haben kaum Möglichkeiten in diese Bereiche<br />
vorzudringen. Beim zusätzlichen Einsatz<br />
der vorhandenen Anonymisierungsverfahren<br />
wird auch den Netzbetreibern die vollständige<br />
Verfolgung der Kommunikation erschwert.<br />
[Cha81] David L. Chaum: Untraceable electronic Mail, return adresses and digital pseudonyms,<br />
Communications of the ACM. http://world.std.com/~franl/<br />
crypto/chaum-acm-1981.html, 1981.<br />
[Cla01] S. Clauß: Das MIX-Netz. http://dud.inf.tu-dresden.de/~sc2/v7_<br />
doku.pdf, 2001.<br />
78 Entwicklung von IPv6, siehe [?]<br />
136
Literatur<br />
[fDSH02] Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein: Sicherheit<br />
im Internet durch Anonymität. http://www.datenschutzzentrum.de/<br />
download/anonheft.pdf, 2002.<br />
[fSidI01] Bundesamt für Sicherheit in der Informationstechnik: Was ist Anonymität ? http:<br />
//www.bsi.de, 2001.<br />
[MKea97] T. Jandach M. Köhntopp et al.: Datenschutzfreundliche Technologien in der<br />
Telekommunikation. http://www.datenschutz-berlin.de/to/tk/ds_<br />
tk123.htm, 1997.<br />
[Ott02] <strong>Prof</strong>. <strong>Dr</strong>. Hans Jürgen Ott: Grundlage der Daten- und Rechnersicherheit. http:<br />
//www.kecos.de/script/31grundldsich.htm, 2002.<br />
137
10 Java-2 Micro Edition<br />
Zusammenfassung<br />
Dieses Kapitel beschäftigt sich mit der<br />
Java-2 Micro Edition und ihrer Struktur.<br />
Darüberhinaus wird ein kurzer Einblick in<br />
die Entwicklung eines MIDlets mit dem<br />
Wireless Toolkit von Sun gegeben. Anschließend<br />
werden aktuelle Entwicklungen<br />
betrachtet, wie zum Beispiel die Version<br />
2.0 des Mobile Information Device<br />
<strong>Prof</strong>iles und die Version 2.5 des Java<br />
Community Process, aus dem die Micro<br />
Edition hauptsächlich entstanden ist.<br />
10.1 Java-2 Editionen<br />
Die Java 2 Plattform unterteilt sich zur Zeit in<br />
drei Editionen:<br />
1. Enterprise Edition (J2EE)<br />
2. Standard Edition (J2SE)<br />
3. Micro Edition (J2ME)<br />
Die Enterprise Edition gibt Richtlinien zur<br />
Entwicklung von vielschichtigen Geschäftsanwendungen<br />
vor. Der Schwerpunkt liegt<br />
dabei auf der Nutzung des Internets und<br />
den Möglichkeiten von Servern und Workstations<br />
in einer vernetzten Unternehmenswelt.<br />
Neben diesen Richtlinien stehen dem<br />
Entwickler Orientierungsmodelle, Testmöglichkeiten<br />
und eine Vielzahl anderer Hilfsmittel<br />
zur Verfügung. Dazu zählen Technologien,<br />
wie zum Beispiel Java Server Pages<br />
(JSP), Servlets, Enterprise Java Beans<br />
(EJB) und die XML Verwendung. Die Standard<br />
Edition stellt die Basis der Java Technologie<br />
dar. In ihr finden sich alle Grundlagen<br />
zur Anwendungsentwicklung. Diese Grundlagen<br />
werden auch von der Enterprise Edition<br />
benötigt und verwendet. Dazu zählen<br />
138<br />
Michael Kain<br />
Mathias-Gerung-Str.1<br />
89415 Lauingen<br />
mk18@informatik.uni-ulm.de<br />
der Übersetzer, Hilfsprogramme, die Classic<br />
Virtual Machine (Classic VM) und eine<br />
große Anzahl von Klassenbibliotheken und<br />
Application Programming Interfaces (API’s).<br />
Der Schwerpunkt liegt dabei aber auf dem<br />
Desktop Umfeld. Die Micro Edition versucht<br />
Java und seine wachsenden Möglichkeiten<br />
auf eine fast nicht mehr zu überblickende Variation<br />
von Geräten zu integrieren, die mehr<br />
oder weniger nicht mehr viel mit dem klassischen<br />
Computer zu tun haben. Als Vertreter<br />
dieser Kategorie gelten Handys, alle<br />
Arten von Organizern, Personal Digital Assitants<br />
(PDA’s), Chipkarten, Unterhaltungselektronikgeräte,<br />
wie zum Beispiel Set-Top<br />
Boxen, und andere stark integrierte Geräte,<br />
wie zum Beispiel ein Navigationssystem.<br />
10.2 Struktur der Java-2 Micro Edition<br />
Um die Struktur der J2ME Plattform verstehen<br />
zu lernen, muss man wissen, dass ihre<br />
Entwickler eine Trennung der mobilen Geräte<br />
in zwei Bereiche vornahmen. Dies geschah<br />
natürlich mit dem Wissen, dass diese Separation<br />
nicht absolut sein würde und dass<br />
es bei einem so breiten Spektrum an Produkten<br />
Überschneidungen und Grenzbereiche<br />
geben würde. Dennoch fasste man auf<br />
der einen Seite die festinstallierten und ständig<br />
verbundenen Informationsgeräte zusammen,<br />
wie zum Beispiel Set-Top Boxen, Internet<br />
TV’s, Navigationssysteme in Fahrzeugen<br />
und internetverbundene Haustelefone<br />
mit Bildübertragung. Man meinte also jene<br />
Geräte mit besseren Möglichkeiten in punkto<br />
graphischer Darstellung, Speicher und Datenübertragungsraten,<br />
sowie einer eventuellen<br />
Verwendung von TCP/IP. Auf der anderen<br />
Seite gruppierte man die persönlichen,
mobilen und nur temporär verbundenen Informationsgeräte,<br />
wie zum Beispiel Mobiltelefone,<br />
Two-Way Pager, PDA’s und Organizer,<br />
also jene Geräte mit begrenzteren<br />
Ressourcen[SM02b]. Aus dieser Zweiteilung<br />
leiten sich die zwei J2ME Konfigurationen<br />
ab, wobei Konfiguration neben <strong>Prof</strong>il zu den<br />
zentralen Strukturbegriffen der J2ME gehört.<br />
Da auf die <strong>Prof</strong>ile und ihren Zusammenhang<br />
zu den Konfigurationen an späterer Stelle<br />
eingegangen wird, wenden wir uns zuerst<br />
den Konfigurationen zu.<br />
Eine Konfiguration legt eine minimale Java<br />
Ausgangsplattform fest, was sich wiederum<br />
in der verwendeten Virtual Machine<br />
ausdrückt. Die festinstallierten und ständig<br />
verbundenen Informationsgeräte werden<br />
durch die Connected Device Configuration<br />
(CDC) repräsentiert. Wohingegen die persönlichen,<br />
mobilen und nur temporär verbundenen<br />
Informationsgeräte sich in der<br />
Connected Limited Device Configuration<br />
(CLDC) zusammengefasst finden.<br />
Bei genauerer Betrachtung unterscheiden<br />
sich beide Konfigurationen im Wesentlichen<br />
durch drei Kriterien. Erstens sind unterschiedliche<br />
Hardwarevoraussetzungen gegeben,<br />
was aus dem oberen Teil zwar schon<br />
hervorgeht, worauf aber an dieser Stelle<br />
noch genauer eingegangen wird. Zweitens<br />
werden von beiden unterschiedliche VM’s<br />
verwendet und somit unterschiedliche Java<br />
Programmiersprachenfähigkeiten zur Verfügung<br />
gestellt. <strong>Dr</strong>ittens weisen die bereitgestellten<br />
Klassenbibliotheken deutliche Diffe-<br />
renzen auf.<br />
10.2 Struktur der Java-2 Micro Edition<br />
10.2.1 Connected Device Configuration<br />
(CDC)<br />
Als Hardwaregrundlage für das CDC gelten<br />
im Allgemeinen 512 KB ROM, mindestens<br />
256 KB RAM und eine Datenübertragungsrate<br />
von 9600 pbs [SM01]. So beläuft sich je<br />
nach Anwendungsituation der Speicher auf<br />
2 bis 10 MB. Außerdem kann von einer permanenten<br />
Internetverbindung ausgegangen<br />
werden. Der CDC liegt als Laufzeitumgebung<br />
die Compact Virtual Machine (CVM)<br />
zugrunde. Diese stellt sehr ähnliche technischen<br />
Möglichkeiten wie die J2SE Virtual<br />
Machine bereit, wurde aber speziell entwickelt.<br />
Zu den Vorteilen gehören zum Beispiel:<br />
geringere Durchschnittszeiten der Pausen<br />
des Garbage Collectors<br />
hinzufügbare Garbage Collectors<br />
das Mappen von Java Threads auf Native<br />
Threads<br />
das Starten von Java Klassen aus dem<br />
ROM, also ROMable classes<br />
einen kleineren Speicherverbrauch für<br />
Klassen, bis zu 40% im Verhältnis zur<br />
klassischen VM<br />
Die Klassenbibliothek besteht aus folgenden<br />
Paketen:<br />
CDC Paket Name Beschreibung<br />
java.io Standard IO Klassen und Interfaces<br />
java.lang VM Klassen<br />
java.lang.ref Referenzen Klassen<br />
java.lang.reflect Reflection Klassen und Interfaces<br />
java.math Mathematik Paket<br />
java.net Netzwerk Klassen und Interfaces<br />
Tabelle 2: CDC Pakete 1.Teil<br />
139
Michael Kain<br />
CDC Paket Name Beschreibung<br />
java.security Sicherheits Klassen und Interfaces<br />
java.security.cert Sicherheits Zertifikats Klassen und Interfaces<br />
java.text Text Paket<br />
java.util Standard Hilfsmittel Klassen<br />
java.util.jar Java Archive (JAR) Hilfsmittel Klassen<br />
java.util.zip ZIP Hilfsmittel Klassen<br />
javax.microedition.io CDC Generic Connection Framework Klassen<br />
10.2.2 Connected Limited Device<br />
Configuration (CLDC)<br />
Die CLDC setzt noch geringere Hardwareressourcen<br />
voraus als die CDC. So variert<br />
die benötigte Speichergröße zwischen 160<br />
und 512 KB[SM00]. Wie der Speicher sich<br />
dabei in flüchtigen Speicher, wie zum Beispiel<br />
in DRAM, und in nicht-flüchtigen Speicher,<br />
wie zum Beispiel ROM oder Flash aufteilt,<br />
ist von Gerät zu Gerät unterschiedlich.<br />
Der Prozessor ist in der Regel ein 16- bzw.<br />
32-bit CISC/RISC Mikroprozessor mit 12-32<br />
MHz. Außerdem liegt eine begrenzte Stromversorgung<br />
vor, wie zum Beispiel Batteriebetrieb.<br />
Analog zur CDC liegt auch der CLDC<br />
eine VM zugrunde. Ursprünglich gab es nur<br />
die Kilobyte Virtual Machine (KVM). Diese<br />
ist je nach Compiler Optionen zwischen 40<br />
und 80 KB groß. Sie wurde speziell mit dem<br />
Ziel entwickelt „komplett“, übertragbar und<br />
schnell zu sein. Mittlerweile gibt es alternativ<br />
für leistungsfähigere Geräte die Hotspot<br />
CLDC VM [SM02a]. So ist die KVM für die<br />
erste Generation und die Hotspot CLDC VM<br />
für die zweite Generation einer Gruppe von<br />
mobilen Geräten gedacht.Die zweite Generation<br />
soll mehr im Multimediabereich leisten<br />
können und höhere Datenübertragungsraten<br />
zwischen 384 Kbits und 2 Mbits in der Sekunde<br />
bereitstellen. Man orientiert sich an 32-bit<br />
ARM Prozessoren mit 30-400 MHz, Onboard<br />
RAM zwischen 128 und 384 KB, RAM von<br />
1-4 MB und nicht-flüchtigem Speicher von 8-<br />
24 MB. Die Neuerungen wurden hauptsächlich<br />
von der schon länger verwendeten - seit<br />
1999 - J2SE Hotspot VM übernommen. Aus<br />
dieser Vorbildfunktion resultiert auch die Na-<br />
140<br />
Tabelle 3: CDC Pakete 2.Teil<br />
mesgebung. Zu den Verbesserungen gehören<br />
hauptsächlich:<br />
Dynamisches Kompilieren<br />
2 Generationen Garbage Collection<br />
Vereinheitlichtes Ressourcenmanagement<br />
Kompaktes Objektlayout<br />
Unter dynamischem Kompilieren versteht<br />
man, dass es neben dem Interpreter einen<br />
Compiler in der VM gibt, der Bytecode in nativen<br />
Code übersetzt. Dieser native Code ist<br />
natürlich schneller, braucht aber 4 bis 8 mal<br />
so viel Speicher wie der Bytecode. Um diesen<br />
negativen Effekt einzugrenzen, gibt es<br />
einen statistischen <strong>Prof</strong>iler, der sogenannte<br />
„Hotspots“ erkennt. Nur diese häufig gebrauchten<br />
Teile der Applikation werden dann<br />
kompiliert. Zusätzlich zu diesem System wird<br />
der Interpreter so optimiert, dass er die seltener<br />
aufgerufenen Methoden schneller ausführt.<br />
Diese Architektur läßt sie sich auf folgende<br />
Weise graphisch darstellen:<br />
Abbildung 81: CLDC Hotspot Architektur<br />
Unter Verwendung der 2 Generationen Garbage<br />
Collection wird der Objekt Heap in drei
Bereiche unterteilt, nämlich in einen der alten<br />
und einen der neuen Generation, sowie<br />
den noch freien Speicherbereich. Der alte<br />
Generationsbereich enthält dabei schon<br />
einmal „entsorgte“ und komprimierte Objekte,<br />
wohingegen der neue Generationsbereich<br />
in Verbindung mit dem noch freien Speicher<br />
die neuer angelegten Objekte enthält und erhält.<br />
Erst wenn kein Speicher mehr frei ist,<br />
wird einmal über den ganzen Heap gelaufen<br />
und alle Objekte in eine „neue“ alte Generation<br />
gepackt. Nur in dieser Phase gibt es<br />
eine wahrnehmbare Pause, die aber unregelmäßig<br />
auftritt. Dieses System hat Vorteile,<br />
wenn die Mehrheit der Objekte nur kurzzeitig<br />
benötigt wird. Mit vereinheitlichtem Ressourcenmanagement<br />
ist gemeint, dass alle verwendeten<br />
Daten sich im Objekt Heap befin-<br />
10.2 Struktur der Java-2 Micro Edition<br />
den. Dazu gehören Java Level Objekte, reflexive<br />
Objekte, sowie Methoden und Klassen,<br />
vom Compiler erzeugter Code und interne<br />
Datenstrukturen der VM. Auf diese Weise<br />
kann sich die Garbage Collection einheitlich<br />
um alle verwendeten Ressourcen kümmern,<br />
sogar den kompilierten Code. Dadurch wird<br />
jegliche Art von Speicherfragmentierung vermieden.<br />
Durch das kompaktere Objektlayout<br />
wird ebenfalls der Speicherverbrauch reduziert,<br />
indem die Größe des Objekt Headers<br />
halbiert wird (von zwei Wort auf ein Wort),<br />
was wiederum bei vielen kleineren Objekten<br />
zu einer geringeren Speicherfragmentierung<br />
führt.<br />
Die Klassenbibliothek besteht unabhängig<br />
von der VM aus folgenden Paketen:<br />
CLDC Paket Name Beschreibung<br />
java.io Standard IO Klassen und Interfaces<br />
java.lang VM Klassen<br />
java.util Standard Hilfsmittel Klassen<br />
javax.microedition.io CLDC Generic Connection Framework Klassen<br />
Betrachtet man die Klassenbibliotheken und<br />
die Möglichkeiten der Programmiersprache<br />
Java im CLDC in den Details, wurden einige<br />
Einschränkungen im Vergleich zu den analogen<br />
Paketen der Standard Edition gemacht.<br />
Dies bezeichnet man auch als das „Sandbox“<br />
Modell der CLDC[Mer01]. So fehlen zum Beispiel:<br />
Überladen und Ersetzen der Systemklassen<br />
Verwendung von benutzerdefinierten<br />
Klassenladern<br />
Gleitkommazahlen und Gleitkommaoperationen,<br />
sowie die Klasse java.lang.Float<br />
Objekt Finalisierung (d.h. es gibt keine<br />
Object.finalize() Methode)<br />
Fehlerbehandlungshierarchie (d.h. es<br />
werden nur java.lang. VirtualMachi-<br />
Tabelle 4: CLDC Pakete<br />
neError und java.lang. OutOfMemoryError<br />
unterstützt)<br />
Thread Groups und Thread Daemons<br />
Reflection (d.h. keine Unterstützung von<br />
RMI oder Objektserialisierung)<br />
Ein J2ME <strong>Prof</strong>il baut immer auf einer Konfiguration<br />
auf und ist mit dieser verbunden.<br />
Außerdem spezifiziert es ein API, mit dessen<br />
Hilfe konkrete Anwendungen entwickelt<br />
werden können. Der Entwickler arbeitet im<br />
Allgemeinen nur auf der <strong>Prof</strong>ilebene. So besteht<br />
eine Laufzeitumgebung aus der Konfiguration,<br />
die aus ihrer VM und einer Grundklassenbibliothek<br />
besteht, und aus dem <strong>Prof</strong>il,<br />
das die eigentliche Klassenbibliothek darstellt.<br />
<strong>Prof</strong>ile können generell aufeinander<br />
aufbauen, wohingegen Konfigurationen nur<br />
singulär verwendet werden können.<br />
141
Michael Kain<br />
10.2.3 Foundation <strong>Prof</strong>ile (FP)<br />
Das Foundation <strong>Prof</strong>ile (FP) wurde von<br />
der Unterhaltungselektronik-Industrie im Zeichen<br />
des Java Community Process (JCP)<br />
entwickelt. Firmen wie zum Beispiel die<br />
Nokia Corporation, Symbian Ltd., Liberate<br />
Technologies und Windriver Systems waren<br />
an dem mit der Nummer 46 bezeichneten<br />
Java Specification Request (JSR) beteiligt.<br />
Aus der Liste der Entwickler kann man schon<br />
auf die Gruppe der Geräte schließen, näm-<br />
lich Unterhaltungselektronik und eingebettete<br />
Systeme. So hat zwar das FP die CDC<br />
als Grundlage und ist auf die CVM abgestimmt,<br />
aber zur Anwendung kommen die<br />
CDC und das FP eigentlich immer als eine<br />
Einheit [SM01]. Daher wurde wohl auch<br />
der Name Foundation <strong>Prof</strong>ile gewählt, was ja<br />
Fundamental <strong>Prof</strong>il heißt. Was bietet nun das<br />
FP? Es bietet einen modifizierten Ausbau der<br />
CDC in Richtung J2SE der Version 1.3. Einzig<br />
das Paket java.awt wurde noch komplett<br />
weggelassen. Die CDC Modifizierung kann<br />
man folgender Tabelle entnehmen:<br />
Foundation <strong>Prof</strong>ile Paket Name Beschreibung<br />
java.lang volle java.lang.* J2SE Unterstützung<br />
java.util vollständige ZIP J2SE Hilfsmittel (z.B. Timer) Unterstützung<br />
java.net fügt TCP/IP Sockets und HTTP Verbindung hinzu<br />
java.io volle java.io.* J2SE Unterstützung<br />
java.text volle java.text.* J2SE Unterstützung(Annotation, Collator, Iterator)<br />
java.security fügt Code Unterzeichnung und Zertifikate hinzu<br />
10.2.4 Mobile Information Device <strong>Prof</strong>ile<br />
(MIDP) 1.0<br />
Das Mobile Information Device <strong>Prof</strong>il<br />
(MIDP) in der Version 1.0 ist das bekannteste<br />
und am weitesten verbreitete <strong>Prof</strong>il der<br />
J2ME. Es wurde unter dem JSR mit der<br />
Nummer 37 entwickelt. Zu den beteiligten<br />
Firmen gehörten unter anderen die Nokia<br />
Corporation, Motorola, Samsung Electronics<br />
Corporation, Ericsson Inc., J-Phone Tokyo<br />
und America Online (AOL). Es basiert auf<br />
der CLDC und wurde speziell auf Mobiltelefone<br />
oder sehr ähnliche Produkte abgestimmt.<br />
Die Möglichkeiten der graphischen Darstellung<br />
sind deshalb sehr begrenzt, weil von folgenden<br />
Standardvoraussetzungen der Hard-<br />
142<br />
Tabelle 5: Foundation <strong>Prof</strong>ile Pakete<br />
ware ausgegangen wurde:<br />
Bildschirmgröße von mindestens 96x54<br />
Pixel<br />
Displaytiefe von 1 Bit Monochrom oder<br />
Farbe<br />
ein- bzw. zweihändig bedienbare Tastatur<br />
oder einem Touchscreen<br />
Speicher (zusätzlich zur CLDC): 128 KB<br />
ROM/Flash und 32 KB RAM<br />
drahtlose Netzwerkverbindung<br />
Die API, mit der schon viele Entwickler arbeiten,<br />
enthält folgende Pakete, wobei die<br />
CLDC ergänzenden Pakete fett dargestellt<br />
sind [Pro01]:
10.2 Struktur der Java-2 Micro Edition<br />
MIDP 1.0 Paket Name Beschreibung<br />
java.io Standard IO Klassen und Interfaces<br />
java.lang VM Klassen<br />
java.util Standard Hilfsmittel Klassen<br />
javax.microedition.io MIDP Generic Connection Framework Klassen<br />
javax.microedition.lcdui Graphische Benutzerschnittstelle Klassen und Interfaces<br />
javax.microedition.rms Klassen zur persistenten Datenspeicherung<br />
javax.microedition.midlet MIDP Anwendungsklasse<br />
Tabelle 6: Mobile Information Device <strong>Prof</strong>ile (MIDP) 1.0 Pakete<br />
Dem letzten Paket in dieser Tabelle, nämlich<br />
java.microedition.midlet, kommt eine besondere<br />
Bedeutung zu. Denn jede Anwendung,<br />
die man mit dem MIDP realisiert, muss von<br />
der Klasse java.microedition.midlet.MIDlet<br />
geerbt werden. Deshalb heißen die Applikationen,<br />
die mit dem MIDP entwickelt<br />
werden auch MIDlets. Wer einmal die Java<br />
Applet Technologie betrachtet hat oder<br />
selbst ein Applet geschrieben hat, dem wird<br />
dies bereits vertraut sein. Wem dies noch<br />
nicht vertraut ist, dem wird es im nachfolgenden<br />
Beispiel in Abschnitt 1.3 klar werden.<br />
Die anderen zwei Pakete, die neben<br />
java.microedition.midlet im MIDP hinzugekommen<br />
sind, erfüllen ebenfalls grundlegende<br />
Funktionen. Durch das Paket java.microedition.rms<br />
wird die dauerhafte Datenspeicherung<br />
ermöglicht. Ihre Funktionalität<br />
entspricht einer Record-orientierten Datenbank<br />
bzw. einem Record Management<br />
System (RMS). Es gibt nur eine Klasse RecordStore,<br />
mit deren Hilfe man durch ihre<br />
Klassenmethoden einen RecordStore über<br />
seinen eindeutigen Bezeichner anlegt, öffnet<br />
bzw. schließt oder löscht. Hat man dann<br />
über die Klassenmethoden ein Objekt vom<br />
Typ RecordStore zurückbekommen und somit<br />
Zugriff auf den Store, kann man mit<br />
diesem einzelne Records hinzufügen, auslesen<br />
oder löschen. Die einzelnen Records<br />
werden dabei als Byte Arrays mit beliebi-<br />
ger Länge gehandhabt und über ihre eindeutige<br />
ID Nummer identifiziert. Das Paket<br />
java.microedition.lcdui enthält alle Klassen<br />
der graphischen Benutzerschnittstelle. Innerhalb<br />
des Pakets werden dem Entwickler jedoch<br />
zwei unterschiedliche Abstraktionsebenen<br />
angeboten. Entweder er verwendet die<br />
„High Level API“ oder die „Low Level API“.<br />
Was bedeutet dies konkret? In der „High Level<br />
API“ hat der Entwickler einen Satz von<br />
Fenstern, die von der Klasse Screen erben.<br />
Dazu gehören ein Alarmfenster, eine Fenster,<br />
in dem man eine Liste speichern kann,<br />
und andere Fenster. In diese Fenster wiederum<br />
kann man eine Zahl von Komponenten<br />
einfügen, die auch vorgegeben sind. In der<br />
„Low Level API“ arbeitet der Entwickler nur<br />
mit der Klasse Canvas, die das Display als<br />
Zeichenfeld betrachtet. Auf diesem, der Bildschirmgröße<br />
entsprechenden, Canvas, kann<br />
man dann über X und Y Koordinaten primitive<br />
Zeichenoperationen ausführen. Zu jenen<br />
Zeichenoperationen zählen zum Beispiel das<br />
Zeichnen von Rechtecken, Linien, Kreisen<br />
und Bögen.<br />
Weil es mittlerweile eine Vielzahl von <strong>Prof</strong>ilen<br />
gibt, die in diesem Abschnitt aber nicht näher<br />
besprochen werden, und weil die einzelnen<br />
Strukturbegriffe nun erläutert sind, soll dieses<br />
Diagramm alles noch einmal zusammenfassen:<br />
143
Michael Kain<br />
10.3 MIDlet Entwicklung<br />
Um eine genauere Vorstellung von der Entwicklung<br />
mit der J2ME Plattform zu bekommen,<br />
wird an dieser Stelle eine konkrete<br />
Beispielanwendung realisiert. Weil das<br />
MIDP 1.0 das am meisten verwendete <strong>Prof</strong>il<br />
ist, wird das Beispiel mit diesem <strong>Prof</strong>il umgesetzt.<br />
Dies geschieht unter Verwendung<br />
des von Sun bereitgestellten Wireless Toolkit<br />
(WTK) der Version 1.0.4. Der erste Teil<br />
144<br />
Abbildung 82: J2ME Strukturüberblick<br />
Abbildung 83: MIDlet Lebenszyklus[Pro01]<br />
dieses Abschnitts beschäftigt sich mit der Implementierung<br />
und der Funktionsweise eines<br />
MIDlets. Der zweite Teil erläutert die Realisierung<br />
und Vorgehensweise im Wireless<br />
Toolkit.<br />
Um ein eigenes MIDlet zu implementieren,<br />
muss man neben der API seinen Lebenszyklus<br />
und sein Interface kennen. Der Lebenszyklus<br />
wird in folgendem Zustandsautomaten<br />
wiedergegeben:
Ein MIDlet stellt folgendes Interface bereit:<br />
10.3 MIDlet Entwicklung<br />
MIDlet Methoden Beschreibung<br />
pauseApp() alle temporären Ressourcen freigeben und pausieren<br />
startApp() alle benötigten Ressourcen festlegen und aktiv werden<br />
destroyApp() benötigte Zustände speichern und alle Ressourcen freigeben<br />
notifyPaused() Signalisierung an AMS: Pausenzustand erreicht<br />
notifyDestroyed() Signalisierung an AMS: Beendenzustand erreicht<br />
resumeRequest() Anfrage an AMS: kann wieder gestartet werden<br />
getAppProperties() Auslesen bestimmter MIDlet Eigenschaften<br />
Unsere Implementierung, die eine einfache<br />
Liste von Bildern und ihren Namen darstellt,<br />
Tabelle 7: MIDlet Interface<br />
// benötigte MIDP und CLDC Pakete einbinden<br />
import java.io.*;<br />
import javax.microedition.midlet.*;<br />
import javax.microedition.lcdui.*;<br />
könnte dann folgendermaßen aussehen:<br />
public class PictureListMIDlet extends MIDlet implements CommandListener {<br />
private Command exitCommand;<br />
private Display display;<br />
private String[] names={„Homer“,„Bart“, „Lisa“, „Maggie“, „Moe“};<br />
private List pictureList;<br />
public PictureListMIDlet() {<br />
// Referenz auf aktuell angezeigtes Display des MIDlets erhalten<br />
display=Display.getDisplay(this);<br />
exitCommand=new Command(„Exit“, Command.SCREEN, 1);<br />
pictureList=new List(„Simpsons Bilder“, List.IMPLICIT);<br />
}<br />
public void startApp() {<br />
for(int i=0; i
Michael Kain<br />
}<br />
pictureList.addCommand(exitCommand);<br />
pictureList.setCommandListener(this);<br />
// Liste als aktuell angezeigtes Display setzen<br />
display.setCurrent(pictureList);<br />
}<br />
public void pauseApp() {<br />
}<br />
public void destroyApp(boolean unconditional) {<br />
}<br />
// auf Benutzeraktionen reagieren<br />
public void commandAction(Command c, Displayable s) {<br />
// wurde das exit-Kommando Objekt gedrückt?<br />
if (c==exitCommand) {<br />
destroyApp(false);<br />
notifyDestroyed();<br />
}<br />
}<br />
Diesen Quellcode kann man mit jedem beliebigen<br />
Editor, wie zum Beispiel Notepad,<br />
oder in jeder beliebigen IDE niederschreiben<br />
und unter dem Namen PictureListMIDlet.java<br />
speichern. Als IDE kommen der JBuilder, das<br />
Sun One Studio oder eine beliebige andere<br />
Entwicklungsumgebung in Frage. Als Resultat<br />
unserer Bemühungen erhalten wir die<br />
Quellcodedatei „PictureListMIDlet.java“ .<br />
Dies Erläuterungen zum Wireless Toolkit von<br />
Sun gehen nicht auf die Details der Verwendung<br />
des WTK ein, sondern demonstrieren<br />
nur die elementarsten Schritte zur<br />
Entwicklung eigener Anwendungen. Wer<br />
sich über das Programm genaustens kun-<br />
146<br />
Abbildung 84: Wireless Toolkit 1.0.4<br />
dig machen möchte, sei an[SM02c] verwiesen.<br />
Das aktuelle Wireless Toolkit kann unter<br />
der Adresse „http://java.sun.com/products/<br />
j2mewtoolkit/download.html“ heruntergeladen<br />
werden. Das WTK benötigt als Java<br />
Anwendung eine J2SE Runtime Enviroment<br />
(J2SE RE). Diese installiert man entweder<br />
eigenständig oder man installiert ein J2SE<br />
Standard Development Kit (J2SE SDK) der<br />
Version 1.3 oder höher, in dem eine J2SE<br />
Laufzeitumgebung enthalten ist. Hat man<br />
die Installation abgeschlossen, kann man<br />
das WTK über die „ktoolbar.exe“ im bin-<br />
Verzeichnis starten und es öffnet sich folgendes<br />
Fenster:
Will man sogleich ein mitinstalliertes Demo-<br />
MIDlet ausführen, klickt man auf „Open Project“,<br />
öffnet zum Beispiel das MIDlet UI-<br />
Demo und führt es über den „Run“ Button<br />
aus. In diesem MIDlet werden einem<br />
dann zum Einstieg die unterschiedlichen<br />
graphischen Komponenten des Pakets java.microedition.lcdui<br />
gezeigt. Die Ausführung<br />
wird in dem jeweils gewählten Emula-<br />
Danach stellt uns das WTK unter den Settings<br />
unsere MIDlet Properties, also unsere<br />
MIDlet Eigenschaften vor. Da wir aber dort<br />
Daraufhin legt das WTK einen neuen Unterordner<br />
in seinem Ordner /apps an. Der Unterordner<br />
trägt den gleichen Namen wie unser<br />
Projektname, also /PictureListMIDlet. Betrachten<br />
wir nun die Verzeichnisstruktur unseres<br />
neu angelegten Projektordners. In den<br />
Ordner /src legen wir unser Datei „Picture-<br />
ListMIDlet.java“. In den Ordner /res legen wir<br />
fünf Bilder, die genau den gleichen Namen<br />
wie die Bezeichner im Quellcode haben müssen.<br />
Außerdem sollten sie vom <strong>Format</strong> PNG<br />
(Portable Network Graphics) sein. Um un-<br />
Abbildung 85: WTK 1.0.4: New Project<br />
Abbildung 86: WTK 1.0.4: Settings<br />
10.3 MIDlet Entwicklung<br />
tor - einem simulierten Handy - dargestellt,<br />
den man bei „Device:“ festlegen kann. Als<br />
Voreinstellung ist hier der DefaultGrayPhone-<br />
Emulator festgelegt.<br />
Wollen wir unser eigenes PictureListMIDlet<br />
testen, beginnen wir mit „New Project“. Dort<br />
tragen wir unseren Projektnamen und den<br />
Klassennamen unseres MIDlets ein und erzeugen<br />
ein neues Projekt:<br />
in unserem einfachen Beispiel nichts ändern<br />
brauchen, bestätigen wir mit dem „Ok“ Button:<br />
ser MIDlet zu testen, kann man sich einen<br />
Emulator wählen und auf den „Run“ Button<br />
klicken. Die Simpsons Bilder können über<br />
die Scrolltasten betrachtet werden. Wir können<br />
uns jetzt davon überzeugen, dass unser<br />
MIDlet im Emulator funktioniert und haben<br />
mit dem WTK eine Testumgebung. Welche<br />
Schritte fehlen uns noch bis das MIDlet<br />
auf einem javafähigem Mobiltelefon lauffähig<br />
ist? Man muss wissen, dass ein MIDlet immer<br />
in Form von zwei Dateien auf das Zielgerät<br />
geladen wird. Dies geschieht mit der<br />
147
Michael Kain<br />
jeweils herstellerabhängigen Software. Zum<br />
einen braucht man eine „.jad“ Datei, die man<br />
in dem Unterordner /bin seines Projekts bereits<br />
nach der Projekterstellung findet. In unserem<br />
Fall wäre dies die „PictureListMIDlet.jad“,<br />
die folgenden Inhalt hat:<br />
MIDlet-1:PictureListMIDlet,<br />
PictureListMIDlet.png,<br />
PictureListMIDlet<br />
MIDlet-Jar-Size: 100<br />
MIDlet-Jar-URL: PictureListMIDlet.jar<br />
MIDlet-Name: PictureListMIDlet<br />
MIDlet-Vendor: Michael Kain<br />
Lädt man diese beiden Dateien z.B. auf ein<br />
Mobiltelefon, so ist auch dort unser MIDlet<br />
lauffähig. Obwohl in dem vorhergehenden<br />
Abschnitt demonstriert wurde, wie man<br />
ein MIDlet für ein MIDP Gerät mit dem WTK<br />
148<br />
MIDlet-Version: 1.0<br />
Abbildung 87: WTK 1.0.4: Create Package<br />
In dieser Datei werden die MIDlet Properties<br />
gespeichert. Diese Eigenschaften werden einem<br />
bei Projekterzeugung und im WTK unter<br />
den „Settings“ dargestellt und editierbar gemacht.<br />
Zum anderen braucht man eine „.jar“<br />
Datei, also eine Java Archiv Datei, welche<br />
die eigenlichen Klassen, Zusatzpakete und<br />
Zusatzdateien, wie z.B. unsere Bilder enthält.<br />
Diese erhält man im Projekt Unterordner<br />
/bin, wenn man wie in Abbildung 7 unter<br />
„Project“->“Package“ die Option “Create<br />
Package“ auswählt:<br />
übersetzt, wird in diesem Abschnitt noch auf<br />
die Übersetzungsvorgänge eingegangen, die<br />
das WTK intern vornimmt. Verdeutlicht wird<br />
dies durch folgendes Diagramm:
10.4 Aktuelles<br />
10.4.1 Java Community Process (JCP)<br />
Das Ziel des Java Community Process<br />
(JCP) ist es Firmen, Organisationen oder<br />
einzelnen Personen einen Einfluss auf die<br />
Weiterentwicklung der Java Technologie zu<br />
geben[Pro02a]. Momentan befindet sich der<br />
JCP in der Version 2.5, vom 29. Oktober<br />
2002, da auch der JCP von seinen Mitgliedern<br />
weiterentwickelt wird. Zum JCP gehören<br />
momentan 500 Organisationen und Personen.<br />
Firmen zahlen für ihre Mitgliedschaft<br />
im Jahr 5000$, private Personen hingegen<br />
nur 100$. Der JCP umfasst zur Zeit ungefähr<br />
220 Java Specification Requests (JSR),<br />
wobei es sich bei einem JSR um ein Dokument<br />
handelt, in dem eines oder mehrere<br />
Mitglieder den Vorschlag einer neuen Spezifikation<br />
machen. Unter besonderen Umständen<br />
kann in einem JSR auch die komplette<br />
Überarbeitung einer alten Spezifikation vorgeschlagen<br />
werden. In diesen Spezifikationen<br />
werden meist die VM, die Plattform, das<br />
<strong>Prof</strong>il, die Programmiersprache und die API’s<br />
festgehalten. Außerdem besteht der JCP aus<br />
zwei leitenden Gremien, den sogenannten<br />
Executive Commitees (EC). Es gibt ein EC<br />
für den Desktop/Server Bereich, also für die<br />
J2SE und die J2EE, und ein EC für den<br />
Abbildung 88: MIDlet Übersetzungsprozess<br />
10.4 Aktuelles<br />
Unterhaltungs/Eingebettete-Geräte Bereich.<br />
Den Prozess an sich, der dann zu einer neuen<br />
Spezifikation führt, muss man in einzelne<br />
Phasen unterteilen. Zur Zeit gibt es vier<br />
Phasen. Die erste Phase wird als Initiation<br />
bezeichnet, also als Initiierungsphase, in der<br />
ein oder mehrere Community Mitglieder eine<br />
Spezifikation einreichen. Das EC entscheidet,<br />
ob diese angenommen oder abgelehnt<br />
wird. Die zweite Phase nennt sich Community<br />
<strong>Dr</strong>aft, in der eine Expertengruppe geformt<br />
wird, die dann eine erste Version der<br />
Spezifikation verfasst. Diese kann von allen<br />
Mitgliedern eingesehen und kommentiert<br />
werden. Woraufhin das EC dann wieder abstimmt,<br />
ob diese bereit für die nächste Phase<br />
ist. Die dritte Phase heißt Public <strong>Dr</strong>aft.<br />
In dieser hat jeder, also die gesamte Öffentlichkeit,<br />
Zugang zur Spezifikation und kann<br />
seine Meinung einbringen. Dieses Feedback<br />
nutzt die Expertengruppe, um noch Änderungen<br />
an der Spezifikation vorzunehmen, während<br />
gleichzeitig die Referenz Implementation<br />
(RI) und das Technology Compatibility<br />
Kit (TCK) bearbeitet wird. Die Referenz Implementation<br />
stellt eine prototypartige Implementierung<br />
der Spezifikation dar. Das TCK<br />
testet Implementierungen auf Übereinstimmung<br />
mit der Spezifikation. Es enthält Testmöglichkeiten,<br />
Hilfsmittel und Dokumentationen.<br />
Sind die Spezifikation, das TCK und<br />
149
Literatur<br />
die Referenzimplementierung aus der Sicht<br />
der Experten fertig, entscheidet wieder das<br />
EC, inwiefern die letzte Phase erreicht ist. Ist<br />
das EC zufrieden, liegt ein Final Release vor.<br />
Die letzte und vierte Phase nennt man dann<br />
Maintenance, also Wartungsphase. In ihr ist<br />
nur noch ein Teil der Expertengruppe als<br />
Wartungsleiter eingesetzt. Außerdem werden<br />
Feinabstimmungen zwischen der Spezifikation<br />
und mit dem TCK und der Referenzimplementation<br />
vorgenommen. Auch auf<br />
gemeldete Fehler wird eingegangen und versucht<br />
zu reagieren.<br />
10.4.2 Mobile Information Device <strong>Prof</strong>ile<br />
(MIDP) 2.0<br />
Der MIDP 2.0 JSR, der sich zur Zeit am Ende<br />
der Community <strong>Dr</strong>aft befindet und kurz vor<br />
seinem Final Release steht, hält eine Vielzahl<br />
an Neuerungen bereit, die hier kurz dargestellt<br />
werden sollen. Die API enthält zusätlich<br />
jetzt folgende Pakete, die hier fett dargestellt<br />
sind, um sich von den MIDP 1.0 Pakete<br />
abzuheben[Pro02b]:<br />
MIDP 2.0 Paket Name Beschreibung<br />
java.io Standard IO Klassen und Interfaces<br />
java.lang VM Klassen<br />
java.util Standard Hilfsmittel Klassen<br />
javax.microedition.io MIDP Generic Connection Framework Klassen<br />
javax.microedition.lcdui Graphische Benutzerschnittstelle Klassen und Interfaces<br />
javax.microedition.lcdui.game Klassen mit verstärkten graphische Möglichkeiten für Spiele<br />
javax.microedition.rms Klassen zur persistenten Datenspeicherung<br />
javax.microedition.midlet MIDP Anwendungsklasse<br />
javax.microedition.media Klassen für spezielle akustische Möglichkeiten<br />
javax.microedition.media.control Klassen für Arten von Tonerzeugung<br />
javax.microedition.pki Klassen zum Einsatz von Zertifikaten<br />
Tabelle 8: Mobile Information Device <strong>Prof</strong>ile (MIDP) 2.0 Pakete<br />
Wer jetzt schon mit MIDP 2.0 entwickeln<br />
möchte, der kann sich bei Sun unter folgendem<br />
Link „http://java.sun.com/j2me“ die Version<br />
2 des Wireless Toolkit herunterladen<br />
Literatur<br />
und testen. Vorher muss man sich allerdings<br />
in der Java Developer Connection registrieren.<br />
[Mer01] <strong>Dr</strong>. Martin Merck: J2ME - Die Basis für Wireless Geräte. http://www.sun.de/<br />
Downloads/Praesentationen/Wireless/Vortraege/1/Merck% .pdf,<br />
2001.<br />
[Pro01] Java Communtiy Process: Mobile Information Device <strong>Prof</strong>ile (1.0) Specification.<br />
http://jcp.org/aboutJava/communityprocess/final/jsr037/<br />
index.html, 2001.<br />
[Pro02a] Java Communtiy Process: Java Community Process. http://www.jcp.org/<br />
en/procedures/jcp2, 2002.<br />
150
Literatur<br />
[Pro02b] Java Communtiy Process: Mobile Information Device <strong>Prof</strong>ile (2.0) Specification.<br />
http://www.jcp.org/en/jsr/detail?id=118, 2002.<br />
[SM00] Inc. Sun Microsystems: J2ME Technology for Creating Mobile Devices - Whitepaper.<br />
http://java.sun.com/products/cldc/wp/KVMwp.pdf, 2000.<br />
[SM01] Inc. Sun Microsystems: Connected Device Configuration (CDC) and the Foundation<br />
<strong>Prof</strong>ile - Technical Whitepaper. http://java.sun.com/products/cdc/<br />
wp/CDCwp.pdf, 2001.<br />
[SM02a] Inc. Sun Microsystems: The CLDC Hotspot Implementation Virtual Machine.<br />
http://java.sun.com/products/cldc/wp/CLDC_HI_WhitePaper.<br />
pdf, 2002.<br />
[SM02b] Inc. Sun Microsystems: Homepage für J2ME Plattform. http://java.sun.<br />
com/j2me/, 2002.<br />
[SM02c] Inc. Sun Microsystems: User’s Guide für WTK 1.0.4. http://java.sun.com/<br />
products/j2mewtoolkit/, 2002.<br />
151
11 Wearable Computing<br />
Zusammenfassung<br />
Bisher gab es eigentlich keine Computer,<br />
die die Bezeichnung „Personal Computer“<br />
wirklich verdient hätten. Ein Computer<br />
sollte nämlich, um wirklich „persönlich“<br />
zu sein, die ganze Zeit bei seinem<br />
Benutzer verweilen, was sich im Prinzip<br />
nur durch die völlige Integration in dessen<br />
Kleidung verwirklichen lässt. Die Aufgaben<br />
solch eines „Wearable Computers“<br />
wären dann seinen Träger bei dessen Tätigkeit<br />
so gut wie möglich zu unterstützen<br />
- sei es als eine Art intelligenter Assistent,<br />
Erinnerungsstütze oder persönliche Datenbank.<br />
Er sollte quasi als Erweiterung<br />
des Gedächtnisses und der menschlichen<br />
„Sensoren“ verstanden werden.<br />
Die potentiellen Einsatzgebiete reichen<br />
vom beruflichen und militärischen Umfeld<br />
bis in den persönlichen Bereich. Das<br />
technische Design sollte dabei sich dem<br />
entsprechenden Umfeld anpassen.<br />
Der noch vor einigen Jahren als utopisch<br />
erschienene Siegeszug von Wearables<br />
ist mit der zunehmenden Verbreitung<br />
von Handys, PDAs (Personal Digital Assistant)<br />
und Embedded PCs aus heutiger<br />
Sicht gar nicht einmal mehr so unwahrscheinlich.<br />
11.1 Einleitung<br />
Ein „Wearable PC“ ist im wörtlichen Sinn „am<br />
Körper getragene Technik“ bzw. „Intelligente<br />
Kleidung“ und sollte sich im Idealfall auch<br />
genauso anfühlen sowie den gleichen Tragekomfort<br />
besitzen wie normale Kleidung. Dies<br />
kann man nur durch konsequente Miniaturisierung<br />
der Komponenten wie Headset, Display,<br />
Computer, Stromversorgung u.ä. errei-<br />
152<br />
Oliver Hagel<br />
<strong>Universität</strong> <strong>Ulm</strong><br />
Fakultät für Informatik<br />
oh2@informatik.uni-ulm.de<br />
chen. Das technische Ziel ist also, den Computer<br />
für den Träger bis auf die nötigsten<br />
Interaktionsschnittstellen unsichtbar zu machen.<br />
Hier gibt es die verschiedensten Ansätze,<br />
die von leitenden Fasern, Funkvernetzung,<br />
Stromerzeugung durch die Bewegungen<br />
des Trägers bis zum Computer in den<br />
Schuhsohlen reichen.<br />
Der eigentliche Sinn eines Wearables sollte<br />
aber die Erweiterung der Fähigkeiten seines<br />
Trägers sein und so Aktionen zu ermöglichen,<br />
die ohne ihn unmöglich wären. Ebenso<br />
ist es denkbar, durch einen Wearable dem<br />
Besitzer völlig neue Fähigkeiten zu verleihen<br />
z.B. Zugriff auf Wissensdatenbanken oder<br />
neue Sinne wie Nachtsicht.<br />
11.1.1 Geschichte<br />
Man könnte meinen, daß Wearables erst seit<br />
dem Aufkommen von Handys und PDAs zunehmend<br />
ins Bewußtsein gerückt sind. Im<br />
Prinzip gibt es Geräte, die der Definition eines<br />
Wearables entsprechen, aber schon seit<br />
mehr als 300 Jahren [SD02] !<br />
Wearables waren ihrer Funktion nach schon<br />
die ersten Rechenschieber, die seit 1650 benutzt<br />
wurden. Sie waren mobile (analoge)<br />
Geräte, die die geistigen Fähigkeiten des<br />
Benutzers enorm erweitert haben - ein wesentliches<br />
Merkmal aller Wearables.<br />
1768 kam dann der Taschen-Chronometer,<br />
später folgten Armbanduhren - eine Erweiterung<br />
der menschlichen Fähigkeit, die Zeit<br />
exakt zu „fühlen“.<br />
1947 gab es dann die „Curta“, eine kom-
pakte 79 mechanische Rechenmaschine, die<br />
schon sehr komplexe Rechenoperationen<br />
ausführen konnte.<br />
Abbildung 89: Die Curta von 1947<br />
In den 60er und 70er Jahren tauchten die<br />
ersten tragbaren Computer mit Mikrochips<br />
(z.B. in Schuhen) zur unbemerkten Vorhersage<br />
von Roulettespielen auf.<br />
Der erste alltägliche Wearable im Sinne von<br />
„am Körper getragene Technik“ tauchte in<br />
den 80ern auf und verbreitete sich rasant: Mit<br />
dem kompakten Walkman von Sony konnte<br />
man überall und jederzeit seine Musik hören,<br />
ohne andere zu stören.<br />
In den 80ern und 90ern verbreiteten sich<br />
dann jene mobile (Kommunikations-) Assistenten,<br />
ohne die sich viele ein Leben in der<br />
heutigen Zeit kaum noch vorstellen können<br />
- dazu gehören Handys, PDAs, Laptops, Pager<br />
und Pocket PCs.<br />
Die ersten wirklich anziehbaren und am Körper<br />
verteilten Wearables kamen aber von<br />
Steve Mann [Can02], dem Pionier des „Wea-<br />
11.1 Einleitung<br />
rable Computing“, von der <strong>Universität</strong> von Toronto.<br />
Unter anderem entwickelte und trug 80<br />
er am Ende seiner Studienzeit in der ersten<br />
Hälfte der 90er die sogenannte „WearCam“ -<br />
einen Wearable Computer, der mittels einer<br />
Helm-Kamera am Kopf aufgenommene Bilder<br />
aus Steve Mann’s Umgebung in Echtzeit<br />
auf seine Internetseite übertrug. Zusätzlich<br />
konnten die Besucher ihm Nachrichten direkt<br />
in ein Display an seinem Helm schreiben,<br />
was häufig zu einem „Location Based<br />
Service“ der etwas anderen Art geführt hat.<br />
Abbildung 90: Steve Mann in einem seiner<br />
Wearables aus den frühen<br />
90ern<br />
11.1.2 Design-Aspekte<br />
Ein Wearable kann seinen Träger auf vielfältige<br />
Weise unterstützen. Diese Unterstützung<br />
kann von einfachen Terminplanungen<br />
79Das Aussehene glich übrigens mehr einer Pfeffermühle als einem Taschenrechner, wie man auch auf dem Bild<br />
sehen kann.<br />
80Insgesamt lief Steve Mann in seiner damals noch eher an einen Cyborg erinnernden Montur 2 Jahre lang herum<br />
und war somit lange Zeit der Mensch, der die meiste Zeit mit einem Wearable verbracht hatte. Er hat übrigens<br />
schon in den 80ern Wearables entwickelt !<br />
153
Oliver Hagel<br />
über persönliches Wissensmanagement bis<br />
zu „Location Based Services“ (LBS) reichen.<br />
Am komfortabelsten ist dies natürlich für den<br />
Träger, wenn der Wearable sowohl für ihn<br />
selbst als auch für Außenstehende so unsichtbar<br />
wie möglich bleibt - er also praktisch<br />
mit seinem Träger verschmilzt. Dies<br />
lässt sich nur durch intelligente Bauweise<br />
und konsequente Nutzung der immer weiter<br />
voranschreitenden Miniaturisierung erreichen.<br />
Den hierzu passenden Design-Aspekt<br />
kann man unter dem Begriff „Wearability“ zusammenfassen<br />
- dem Tragegefühl. Die meisten<br />
aktuellen Wearables sind leider eher<br />
noch am Körper getragene behindernde und<br />
unhandliche Hardware als wirklich dafür entwickelte<br />
Technik; dabei sollte der menschliche<br />
Körper mehr als Unterstützung und nicht<br />
als einschränkendes Hindernis verstanden<br />
werden [Bab99]. Da man die Komponenten<br />
bis auf wenige Ausnahmen (Headset, Head<br />
Mounted Display) prinzipiell über den ganzen<br />
Körper verteilen kann, sind hier die vielfältigsten<br />
Modelle denkbar. Dazu passende<br />
Aspekte, die bei der Entwicklung eines Wearables<br />
eine besondere Rolle spielen sollten<br />
sind: Platzierung, Form, menschliche Bewegung<br />
und Wahrnehmung, Größe, Gewicht,<br />
Zugänglichkeit (z.B. zur Wartung), Anbringung<br />
und Langzeitwirkung.<br />
Einen Wearable kann man durch seine physische<br />
Nähe zum Benutzer und seine Aufgabenbereiche<br />
quasi als Erweiterung des<br />
menschlichen Körpers und seiner Sinne sehen.<br />
Es sollte sich also auch wie diese<br />
verhalten und somit ständig betriebsbereit<br />
sein, was natürlich besondere Anforderungen<br />
an die energieliefernden bzw. erzeugenden<br />
Komponenten stellt. Natürlich sollte ein<br />
Wearable niemals zu wörtlich als „Körperergänzung“<br />
verstanden werden - dies würde<br />
nur zu viel zu großen Abhängigkeiten führen.<br />
Allerdings ist es unwahrscheinlich, daß sich<br />
ein Benutzer wirklich wie ein hilfloses Kind<br />
fühlen wird, falls sein Wearable eines Tages<br />
ausfallen sollte; die Gefahr ist hier aber trotzdem<br />
wesentlich größer als bei den bisher gewohnten<br />
mobilen Lösungen und sollte nicht<br />
unterschätzt werden.<br />
154<br />
Wearable Computing ist Technologie, mit der<br />
man leben muss und die somit flexibel und<br />
anpassungsfähig sein muss. Das schließt eine<br />
gewisse Robustheit mit ein. Wenn man an<br />
die meisten akutell verfügbaren mobilen Lösungen<br />
wie Pocket PCs denkt, die meistens<br />
nicht einmal einen kräftigen Stoß verkraften,<br />
ist es also nicht einfach damit getan, solch<br />
ein Gerät nur zu verkleinern und in die Kleidung<br />
einzubauen.<br />
Einen weiteren Design-Aspekt stellt die Kontextsensitivität<br />
dar. Nur ein Gerät, das den<br />
vollen Überblick über die Tätigkeiten seines<br />
Besitzers hat, kann diesem ein wirklicher Assistent<br />
sein. Im Idealfall sollte solch ein Wearable<br />
also selbstständig erkennen, wie er<br />
sich wann am nützlichsten verhalten kann.<br />
Es erkennt dann semi-autonom, wenn sein<br />
Benutzer nicht gestört werden will oder Informationen<br />
braucht und meldet sich dann<br />
entsprechend bei diesem. So macht es z.B.<br />
keinen Sinn, beim Rennen oder Gehen Informationen<br />
über Displays anzuzeigen, da dies<br />
zu großer Ablenkung führen würde; stattdessen<br />
könnte man aber Audioinformationen<br />
über das Headset abspielen. So kann die Interaktion<br />
mit dem Wearable auf das nötigste<br />
verringert werden, was sowohl der Benutzerfreundlichkeit<br />
dient als auch die Batterien<br />
schont. Technisch ließe sich Kontextsensitivität<br />
schon durch Kreiselsensoren zur<br />
Bewegungserkennung und intelligente Stoffe,<br />
die <strong>Dr</strong>uck und <strong>Dr</strong>uckstärke (z.B. vom Sitzen)<br />
messen, verwirklichen.<br />
All dies sind generell gültige Grundsätze.<br />
Das konkrete Modell muss dann natürlich bei<br />
der Gestaltung der Ein- und Ausgabemöglichkeiten<br />
sowie der Technik die späteren<br />
Einsatzbereiche der Zielgruppe berücksichtigen<br />
(siehe 11.2).<br />
Um die genannten Aspekte in einem Satz zusammenzufassen:<br />
Der Träger sollte den maximalen<br />
Nutzen aus der Aufmerksamkeit, die<br />
er seinem Wearable schenkt, ziehen !
11.2 Einsatzgebiete<br />
Die Funktionen und das Design eines Wearable<br />
richten sich sehr stark nach dessen vorgesehenem<br />
Einsatzgebiet. Diese - zum Teil<br />
noch theoretischen Bereiche - sollen nun jeweils<br />
kurz vorgstellt werden.<br />
11.2.1 Berufliches Umfeld<br />
Die meisten derzeit auf dem Markt erhältlichen<br />
Wearables (siehe 11.4) sind im industriellen<br />
und beruflichen Umfeld im Einsatz. Man<br />
kann sich vorstellen, daß leichte am Körper<br />
zu tragende Systeme die Arbeitseffizienz bei<br />
Tätigkeiten ungemein erhöhen, in denen der<br />
Zugriff und die Hilfe eines Computers nötig<br />
wären, Pocket PCs oder Laptops aber einfach<br />
zu unhandlich oder empfindlich sind.<br />
Wearables sind hier teilweise schon länger<br />
im Einsatz, z.B. bei Lieferdiensten 81 wie UPS<br />
oder FedEx sowie bei Technikern auf Ölplattformen<br />
oder in der Flugzeugwartung.<br />
Die Hauptaufgaben von Wearables in der<br />
Industrie, vornehmlich im Bereich Wartung<br />
und Konstruktion, sind Daten zu protokollieren,<br />
Zugriffe auf technische Datenbanken mit<br />
Plänen oder Fehlerbeschreibungen zu bieten<br />
und bei Problemen die Kommunikation<br />
mit Spezialisten in der Zentrale zu ermöglichen;<br />
nach Möglichkeit sollte der Träger dabei<br />
natürlich seine Hände für die Arbeit frei<br />
haben. Zusätzlich könnte man noch wichtige<br />
Daten auf ein Head Mounted Display (HMD)<br />
einblenden. Ein Techniker könnte so z.B. direkt<br />
über den Kabeln oder Rohren in seinem<br />
Sichtfeld die zugehörigen Daten abzulesen<br />
(Augmented Reality) oder ein Architekt<br />
direkt vor Ort die Wirkungsweise der geplanten<br />
Bauten begutachten, die so für ihn in voller<br />
Größe halbdurchsichtig an exakt dem geplanten<br />
Orten stehen würden.<br />
In diesen Umfeldern stellt der Wearable eine<br />
ungemeine Erhöhung der Arbeitseffizienz<br />
dar und scheint sich auch weiterhin auszubreiten,<br />
da es hier abgesehen von der Einarbeitungszeit<br />
keine gewichtigen Nachteile<br />
11.2 Einsatzgebiete<br />
gibt. Der „Return of Investment“-Wert ist dabei<br />
häufig das Hauptüberzeugungsargument<br />
für Firmen, die nach einer Testphase Wearables<br />
weiterhin benutzen.<br />
11.2.2 Ziviles Umfeld<br />
Im zivilen Umfeld würden speziell angepasste<br />
Wearables besonders die Arbeit von Rettungskräften<br />
erleichtern. Diesen könnte direkt<br />
in ihr HMD der Weg zum Einsatzort bzw.<br />
zu der Hilfe benötigenden Person 82 eingeblendet<br />
werden.<br />
Für Feuerwehrleute wäre es denkbar, über<br />
Displays in ihrem (geschlossenen) Helm<br />
wichtige Punkte und Fluchtpläne der Gebäude<br />
einzublenden, in denen sie gerade ihren<br />
Einsatz haben, sowie Warnmeldungen über<br />
Chemikalien in der Luft, ihren Sauerstoffvorrat<br />
oder die Umgebungstemperaturen. Die<br />
Wearables müssten in solch einem extremen<br />
Umfeld natürlich besondere Anforderungen<br />
erfüllen.<br />
Polizisten könnten ebenfalls Wearables tragen,<br />
über die sie ständig Zugriff auf die Datenbanken<br />
der gesuchten Personen hätten.<br />
Kameras an ihren HMDs würden dann vor<br />
Ort z.B. Bilder von Verdächtigen aufnehmen<br />
und mit der Liste der Gesuchten vergleichen.<br />
Im medizinischen Bereich erscheint es allerdings<br />
wahrscheinlicher, daß sich Wearables<br />
verglichen mit den bisher genannten Bereichen<br />
wesentlich schneller durchsetzen, da<br />
man in diesem Umfeld neuen Techniken gegenüber<br />
viel offener ist. Hier wird es Wearables<br />
auf beiden Seiten geben:<br />
Dem Arzt helfen sie bei seiner Arbeit z.B.<br />
durch Zugriff auf umfangreiche Datenbanken,<br />
als Monitorersatz bei Operationen oder<br />
bei der Planung seiner komplexen täglichen<br />
Aufgaben.<br />
Auf Patientenseite könnten Wearables ebenfalls<br />
enorme Verbreitung finden, speziell<br />
durch ihre Fähigkeit Sinne zu verbessern<br />
81 Vornehmlich in Form von ums Handgelenk getragener Scanner.<br />
82 Deren Aufenthaltsort man wiederum durch ihren eigenen Wearable mittels GPS feststellen könnte.<br />
155
Oliver Hagel<br />
oder zu ersetzen:<br />
Bei Sehbehinderten könnte man so mittels<br />
Kameras und fokusierenden HMDs (siehe<br />
auch 11.3.1) Bilder verstärken oder bearbeiten<br />
und danach ins Auge spiegeln. Blinde<br />
wiederum hätten den perfekten Blindenführer<br />
in einem Wearable mit Headset und LBS.<br />
Sie könnten sich so völlig eigenständig auch<br />
in unbekannten Gebieten bewegen und sich<br />
trotzdem sicher fühlen. Bei Gehörlosen wäre<br />
es z.B. möglich, akustische Informationen<br />
(Rufe, Durchsagen oder sogar Gespräche) in<br />
visuelle Daten umzuwandeln und auf ihrem<br />
HMD zu präsentieren.<br />
Bei agnostischen Störungen 83 würde der<br />
Wearable den defekten Teil des Gehirns ersetzen,<br />
der sich sonst um die Einordnung<br />
und Erkennung kümmern würde. Gedächtnis<br />
und Erinnerungsprobleme (z.B. Verlust des<br />
Kurzzeitgedächtnisses) wären duch den Einsatz<br />
von Wearables ebenfalls recht einfach<br />
zu lösen. Dieser würde dabei quasi als „2.<br />
Gehirn“ dienen, indem er sich wichtige Dinge<br />
für seinen Träger merkt und ihn daran erinnert.<br />
Natürlich sind in alle diesen Bereichen auch<br />
spezielle User Interfaces notwendig, die optimal<br />
auf den Träger und seine Behinderung<br />
abgestimmt sein sollten.<br />
11.2.3 Privater Bereich<br />
An Wearables für den privaten Bereich werden<br />
wohl die vielfältigesten Anforderungen<br />
gestellt, schon allein, weil hier so unzählige<br />
Anwendugsmöglichkeiten denkbar sind.<br />
So könnte es eines Tages möglich sein, wirklich<br />
das gesamte Menschheiteswissen ständig<br />
bei sich zu haben z.B. in Form eines<br />
überall verfügbaren Internetzugangs oder einer<br />
Enzyklopädie auf der Festplatte des<br />
Wearable PCs. Würden diese Informationen<br />
über ein HMD eingeblendet, wäre es für<br />
einen Außenstehenden nicht unterscheidbar,<br />
woher der Träger seine Informationen bezieht<br />
- der Wearable wäre also in diesem<br />
Fall tatsächlich eine immense Erweiterung<br />
der geistigen Fähigkeiten seines Trägers.<br />
Ein Wearable könnte auch bei Bedarf mittels<br />
LBS sämtliche Karten der aktuellen Umgebung<br />
laden und zusätzlich Informationen<br />
zum Aufenthaltsort, interessanten Gebäuden<br />
u.ä. einblenden bzw. mittels Headset abspielen.<br />
So wäre es beispielsweise denkbar im<br />
Urlaub ständig seinen privaten Reiseführer<br />
dabei zu haben. In Großstädten und bei Sehenswürdigkeiten<br />
erscheint ein solches Szenario<br />
mit der zunehmenden Verbreitung von<br />
WLAN-HotSpots schon fast absehbar. Die<br />
Wearables könnte man zu diesem Zweck zunächst<br />
als Leihgeräte zur Verfügung stellen<br />
bis diese größere Verbreitung gefunden haben.<br />
Ein Wearable würde natürlich auch die ganzen<br />
„Gadgets“ überflüssig machen, die man<br />
z.T. heute mit sich herumschleppt. Mit einer<br />
Echtzeituhr, die sich ständig mit der<br />
UTC abgleicht, einem GPS-/UMTS-Modul<br />
und natürlich Terminplaner-Fähigkeiten versehen,<br />
bräuchte der moderen Mensch dann<br />
weder Armbanduhr, Handy, PDA noch GPS-<br />
Empfänger. Die Kommunikationsfähigkeiten<br />
wären einem Handy natürlich weit überlegen<br />
mit denkbaren Services wie „LBS-<br />
InstantMessaging“ oder spontanen lokalen<br />
Communities, die sich über LBS und ihre<br />
in den Wearable eingegebenen Informationen<br />
zusammenfinden würden. Sprachbarrieren<br />
würden ebenfalls der Vergangenheit angehören:<br />
Der Wearable wird in absehbarer<br />
Zeit Echtzeitübersetzung mittels Sprach- und<br />
Schrifterkennung ermöglichen. Die Ausgabe<br />
geschieht dann mittels synthetisierter Sprache<br />
via Headset oder als Überblendung im<br />
HMD.<br />
11.2.4 Militär<br />
83 Erkennungsprobleme von Formen und Objekten, vor allem aber von Gesichtern.<br />
156<br />
Die Wearables für den militärischen Bereich -<br />
von denen die meisten allerdings nur als Prototypen<br />
existieren - sind sicherlich die fortschrittlichsten,<br />
da hier natürlich wesentlich<br />
mehr Geld fließt, als in den wissenschaftlichen<br />
Entwicklungslaboren. So werden z.B.
in das „Landwarrior“ 84 -Programm[oD02] der<br />
U.S. Army jährlich 2 Milliarden Dollar investiert<br />
und auch bei der Bundeswehr sind<br />
Wearables in Planung. Durch die zunehmende<br />
Änderung der Struktur der Kriege (präzise<br />
Teameinsätze statt Massenkämpfe), bieten<br />
sich hier Wearables natürlich besonders<br />
an. Spezielle Anforderungen an diese sind<br />
dabei Flexibilität, Mobilität und Zuverlässigkeit<br />
auch in extremen Situationen. Das Interface<br />
sollte dabei Informationen vor allem<br />
als „Augmented Reality“ anzeigen, da Soldaten<br />
zum eigenen Schutz den Blick möglichst<br />
ständig auf dem Schlachtfeld lassen sollten.<br />
Denkbare Features, die zum größten Teil<br />
auch im Landwarrior-Projekt geplant sind,<br />
wären:<br />
Anzeige bzw. Markierung der Positionen<br />
von Missionszielen, Landschaftspunkten<br />
und Teammitgliedern zur Vermeidung<br />
von „Friendly Fire“ und zur<br />
besseren Koordination,<br />
HMDs mit Nachtsicht und Infrarotsicht,<br />
integriert in den Helm, für optimale Sicht<br />
in jeder Situation<br />
Helmkameras, die das Gesehene z.B.<br />
an die Einsatzzentrale weiterleiten um<br />
dort eine optimale Koordination zu ermöglichen<br />
verbesserte Kommunikationsfähigkeiten<br />
durch Funk und Headsets<br />
effiziente Energieversorgung z.B. mittels<br />
Solar, Hochleistungsbatterien oder<br />
völlig neuen Energieerzeugern wie<br />
kompakten Brennstoffzellen um auch<br />
längere Einsätze bewältigen zu können<br />
Daß das Militär in diesem Bereich Vorreiter in<br />
Sachen Technik ist zeigen auch utopisch anmutende<br />
aber durchaus ernstgemeinte Pläne,<br />
wie die des Chamäleon-Kampfanzugs<br />
[Sch02]: Dieser tastet durch einen Scanner<br />
ständig die Umgebung ab; spezielle lichtleitende<br />
Hohlfasern in dessen Gewebe werden<br />
11.3 Technik<br />
dann mit entsprechend angepasstem Licht<br />
gespeist, so daß der Träger immer optimal<br />
getarnt ist. Eine weitere in diese Kategorie<br />
fallende Vision, ist die des aktivierbaren<br />
„Exoskeletts“: Hier ist der Körper des Soldaten<br />
mit Hartplastikplatten bedeckt, die bei<br />
Bedarf über hydraulisch verbundene Gelenke<br />
versteift werden können und so den Träger<br />
unterstützen und schützen.<br />
Platz für die Aufnahme des Wearables wäre<br />
in den kugelsicheren Westen und Helmen<br />
eines Soldaten ebenfalls genug vorhanden<br />
[Onl01]. In Planung sind auch klimatisierte<br />
Kampfanzüge 85 mit verschiedensten Sensoren,<br />
die z.B. ständig die Lebensfunktionen<br />
des Trägers überprüfen und sogar medizinsche<br />
Versorgung gewährleisten können.<br />
Auch die Erkennung von chemischen, atomaren<br />
und biologischen Bedrohungen ließe<br />
sich durch eingebaute Sensoren verwirklichen.<br />
11.3 Technik<br />
In diesem Abschnitt soll kurz auf die einzelnen<br />
Komponenten und die dahintersteckende<br />
Technik eingegangen sowie konkrete Modelle<br />
vorgestellt werden, die entweder aus<br />
der Forschung stammen oder schon auf dem<br />
Markt erhätlich sind.<br />
11.3.1 Ausgabe<br />
Die Ausgabe von Audiodaten kann nur über<br />
Kopfhörer oder winzige „Knöpfe im Ohr“, die<br />
z.B. via Bluetooth ihre Daten vom Wearable<br />
beziehen, erfolgen. Die Technik unterscheidet<br />
sich dabei, abgesehen von der Größe,<br />
nicht von den bekannten Realisierungen.<br />
Vielfältiger gestaltet sich schon die Ausgabe<br />
von visuellen Daten. Diese erfolgt je nach<br />
Anforderungen entweder über an den Unterarmen<br />
oder Handgelenken angebrachte<br />
84 Andere Länder haben übrigens ähnliche Programme: In Großbritannien heißt es „FIST“(Future Infantry Soldier<br />
Technology“), in Australien „Soldier Fight System“, in Frankreich „Felin“ und in Deutschland „Soldier System“.<br />
85 Die Klimatisierung wird mittels in der Kleidung verwobener Kunststoffröhrchen erreicht, durch die Wasser zirku-<br />
liert.<br />
157
Oliver Hagel<br />
Displays oder über „Head Mounted Displays“<br />
(HMD) [Bun02] , die von Monitoren gewohnte<br />
Darstellungsgrößen bieten. Faltbare Displays,<br />
die sich aber alle noch in der Entwicklungsphase<br />
befinden, lassen auf bessere Integration<br />
in die Kleidung hoffen 86 . Generelle<br />
Probleme bei Displays für Wearables sind<br />
Gewicht, Kontrast, Helligkeit, Auflösung und<br />
bei HMDs die Fokussierung (s.u.).<br />
Die einfachsten HMDs bestehen aus LCD-<br />
Displays bzw. LCoS-Displays 87 , die vor die<br />
Augen gehängt und durch Linsen vergrößert<br />
sowie von hinten beleuchtet werden.<br />
Der große Nachteil bei diesen ist natürlich,<br />
daß sie entweder gar nicht oder nur gering<br />
transparent sind 88 , der Träger also auf einem<br />
oder beiden Augen quasi blind ist. Verwirklicht<br />
wurden solche Displays z.B. in den<br />
Sony „Glasstron“ Modellen, die vornehmlich<br />
für den mobilen DVD-Genuss entwickelt wurden.<br />
Geschickter aber auch komplizierter ist die<br />
direkte Spiegelung der darzustellenden Bilder<br />
auf die Netzhaut. Die einfachen Varianten<br />
verwenden dabei eine feste Fokussierung,<br />
d.h. bei einer bestimmten Sehweite, ist<br />
das Bild scharf und fast undurchsichtig, ansonsten<br />
ist es prinzipiell durchsichtig; geplant<br />
sind aber auch Techniken, die ständig die Fokussierung<br />
des Auges überwachen und die<br />
Bilder immer in der optimalen Schärfe darstellen,<br />
so daß eine Fokussierung des Auges<br />
darauf entfällt. Dies ist natürlich extrem<br />
aufwändig, da ständig die Pupillenöffnung<br />
gefilmt bzw. gescannt und analysiert werden<br />
muss.<br />
Mit festem Fokus gibt es kommerzielle Modelle<br />
hauptsächlich von der „Micro Optical<br />
Corp.“ [Cor02c]. Diese setzen auf sehr kleine<br />
Projektoren, die in Brillengestelle eingebaut<br />
sind und über eine Linse auf dem Brillenglas<br />
das Bild ins Auge spiegeln. Micro Optical<br />
stellt durch dieses Verfahren übrigens die<br />
weltweit kleinsten und leichtesten Displays<br />
dieser Art her.<br />
Das aktuelle Spitzenmodell „SV-3“ 89 hat z.B.<br />
eine Auflösung von 640x480, 6 Bit Farbtiefe,<br />
60Hz Wiederholrate, einen Standard VGA-<br />
Input und wiegt 35g. Zur Stromversorgung<br />
dient ein 950 mW - 7.2 V LiIon-Akku.<br />
Abbildung 91: Arbeiter mit dem SV-3 von Micro<br />
Optical<br />
Ein weiterer Anbieter von HMDs ist „Virtual<br />
Vision Inc.“ [VV02], die mit dem „eGlass<br />
II“ ein mono-okulares aber undurchsichtiges<br />
HMD mit Headset herstellen. Die Auflösung<br />
beträgt 800x600 und der Verbrauch weniger<br />
als 0.6 W. Das Bild macht laut Hersteller den<br />
Eindruck eines normalen 19 Zoll Monitors.<br />
11.3.2 Eingabe<br />
Die Eingabemöglichkeiten stellen wohl den<br />
Aspekt eines Wearable dar, der dem Träger -<br />
abgesehen vom Gewicht - bei falschem Design<br />
am meisten auffallen wird. Sie sind die<br />
Hauptschnittstelle zwischen Wearable und<br />
Benutzer und sollten speziell an dessen Anforderungen<br />
angepasst werden.<br />
Die von der Realisierung in Hardware sicherlich<br />
einfachste Eingabemöglichkeit stellt ein<br />
Mikrofon dar. Allerdings gibt es bis heute keine<br />
Software zur Spracherkennung, die als<br />
alleinige Eingabemöglichkeit dienen könnte.<br />
Hier sind aber sicherlich mittelfristig große<br />
Fortschritte zu erwarten, so daß es durchaus<br />
86Der aktuelle Entwicklungsstand sind Displays, die vergleichbar gewohntem Papier sind, aber nur schwarz-weiße<br />
Pixel bieten.<br />
87LCoS ist der Nachfolger der LCD-Technik und dieser in jeder Hinsicht, vor allem aber dem Gewicht, überlegen.<br />
88Der Grund sind die lichtundurchlässigen Transistoren hinter der LCD-Schicht.<br />
89 Der Preis beträgt zur Zeit um die 1000$.<br />
158
in absehbarer Zeit möglich sein wird, einen<br />
Wearable vollständig per Sprache ohne weitere<br />
Eingabemöglichkeiten zu bedienen.<br />
Eher klassische Eingabemöglichkeiten stellen<br />
Tastaturen dar. Diese gibt es für Wearables<br />
in den unterschiedlichsten Ausprägungen,<br />
die von Ärmel- über Einhand- bis<br />
zu Fingerspitzentastaturen reichen. Durch<br />
die Miniaturisierung von technischen Komponenten<br />
ist auch hier eines der Hauptprobleme<br />
aus früheren Zeiten, das Gewicht, verschwunden;<br />
aber das optimale Eingabegerät<br />
für die jeweiligen Benutzeranforderungen zu<br />
finden, ist immer noch eine der zu lösenden<br />
Aufgaben.<br />
Kommerziell erhältlich ist z.B. von der „Handykey<br />
Corp.“ der „Twiddler“ [Cor02a], eine<br />
Mischung aus Maus und Keyboard: Er hat 6<br />
Tasten und einem IBM Trackpoint; der Nachteil<br />
ist hier aber, daß das Gerät bei der Eingabe<br />
fest in einer Hand gehalten werden<br />
muss. Bei den meisten Wearables auf dem<br />
Markt finden sich wahrscheinlich deshalb fast<br />
nur „Ärmelkeyboards“, also kleine Tastaturen,<br />
die man sich um den Unterarm oder<br />
das Handgelenk schnallen kann und die die<br />
Eingabe mit der gegenüberliegenden Hand<br />
ermöglichen.<br />
Abbildung 92: Das Twiddler2-Keyboard von<br />
Handykey<br />
11.3.3 Batterien und Energie<br />
11.3 Technik<br />
Ein immer noch großes Problem bei dem<br />
Entwurf eines komfortablen Wearables stellt<br />
allerdings die Batterielaufzeit dar. Zu versorgen<br />
ist ja nicht nur die Recheneinheit an sich,<br />
sondern auch alle Sensoren und Komponenten<br />
wie Mikrofone, Kameras, HMDs, Displays<br />
und Eingabegeräte. Diese könnnen schon<br />
wegen der geforderten ständigen Verfügbarkeit<br />
nicht komplett abgeschaltet werden. Hier<br />
lässt sich ohne spezielles Design nur eine<br />
Laufzeit von wenigen Stunden erreichen, wodurch<br />
der Wearable natürlich nicht wirklich<br />
zum täglichen Begleiter werden kann. Daß<br />
es kompakte leistungsstarke Batterien nocht<br />
nicht zu erschwinglichen Preisen auf dem<br />
Markt gibt, sieht man beispielsweise daran,<br />
daß viele der Wearables aus der Forschung,<br />
die ja meistens auf Standardkomponenten<br />
zurückgreifen, noch relativ schwere<br />
Gürtel mit (Standard-)Batteriepacks dem Träger<br />
aufbürden.<br />
Einen Ansatz zur Verlängerung der Batterielaufzeiten<br />
stellen z.B. Kontextsensitivität und<br />
intelligentes StandBy-Management der einzelnen<br />
Komponenten dar. Der Wearable erkennt<br />
dabei selbstständig, welche Komponenten<br />
gerade nicht gebraucht werden und<br />
schaltet diese einstweilig ab - ein HMD stört<br />
z.B. beim Kinobesuch und die Netzwerkkomponenten<br />
brauchen nur mit Strom versorgt<br />
werden, wenn auch ein WLAN erkannt wird.<br />
Die Komponenten sollten idealerweise auch<br />
nur global mit Strom versorgt werden, da<br />
man so die Batterie leichter überwachen und<br />
aufladen kann, als wenn jede Komponente<br />
ihre eigenen Batterien hat.<br />
Es gibt aber auch viele Ansätze zur Energiegewinnung<br />
für „Unterwegs“, die von klassischen<br />
Modellen mit auf der Kleidung verteilten<br />
Solarzellen bis zu ungewöhnlicheren wie<br />
Energiegewinnung über Körperhitze, Atem,<br />
Blutdruck oder der normalen Bewegung reichen.<br />
Die meisten sind dabei aber mit den<br />
bisherigen Mitteln von der Ausbeute her einfach<br />
zu gering oder schwierig zu verwirklichen.<br />
Energiegewinnung mittels Blutdruck<br />
159
Oliver Hagel<br />
wäre z.B. nur eine Lösung für Implantate. Am<br />
vielversprechendsten von den genannten Lösungen<br />
ist dabei die Energiegewinnung mittels<br />
Solar oder Körperbewegung, die ja beispielsweise<br />
schon in den Armbanduhren von<br />
Seiko seit längerer Zeit eingesetzt wird. So<br />
könnte man laut einer Studie von IBM [Sta96]<br />
durch die Bewegung der Beine beim Laufen<br />
mittels mechanischer Teile wie Federn<br />
oder Rotationsgeneratoren im Fersenbereich<br />
bis zu 4 W erzeugen. Piezoelektrische Elemente<br />
in den Schuhsohlen kämen ebenfalls<br />
auf bis zu 5W pro Sekunde. Auch das Tippen<br />
der Finger könnte die zugehörige kabellose<br />
Tastatur laut den Berechnungen komplett<br />
mit Strom versorgen. Allerdings gibt es<br />
bei der Speicherung dieser unregelmäßigen<br />
Stromzufuhren natürlich wieder Probleme,<br />
aber auch hier sind zumindest schon theoretische<br />
Lösungen vorhanden. Solche eher ungewöhnlichen<br />
Arten der Energieversorgung<br />
bieten sich natürlich speziell für längere Einsatzgebiete<br />
im Freien an, wo der Benutzer<br />
keine Möglichkeit zum Aufladen über eine<br />
Steckdose hat, ständig unter freiem Himmel<br />
und in Bewegung ist - also z.B. bei militärischen<br />
Einsätzen.<br />
11.3.4 Vernetzung<br />
Bei der Venetzung gibt es eigentlich drei Ausprägungen:<br />
160<br />
1. Da wäre zum einen die Vernetzung der<br />
einzelnen Komponenten eines Wearable<br />
untereinander. Ist das HMD z.B. in<br />
der Brille integriert, wäre es recht unpraktisch,<br />
wenn Kabel aus den Bügeln<br />
am Hals entlang zur Hauptkomponente<br />
führen würden. Hier würde sich z.B.<br />
Kurzstreckenfunk wie Bluetooth oder<br />
Infrarotlösungen anbieten. Ein Vorteil<br />
wären dann die dadurch leicht austauschbaren<br />
und flexiblen Komponenten.<br />
Bei der Vernetzung von Komponenten<br />
innerhalb desselben Kleidungsstückes<br />
(z.B. Tastatur und Wearable in<br />
der Jacke), wären aber auch leitende<br />
Fasern im Kleidungsgewebe, die dann<br />
praktisch einen Bus darstellen würden,<br />
eine Möglichkeit.<br />
2. Für die Vernetzung der Wearables untereinander,<br />
also von Träger zu Träger,<br />
spielt natürlich die Reichweite eine<br />
Rolle. Befinden sich beide im gleichen<br />
Gebäude oder Raum bietet sich<br />
ebenfalls Bluetooth an, das ja eine<br />
Reichweite bis zu 100 m haben kann.<br />
Allerdings kommt im Moment wegen<br />
des Stormverbrauchs wohl nur die Lösung<br />
bis 10 m Reichweite in Frage.<br />
Hier sind aber prinzipiell alle Ansätze<br />
von Ad-Hoc-Netzwerken denkbar. Sollte<br />
die Entfernung mehr betragen bietet<br />
sich, falls vorhanden, WLAN an<br />
oder eben die klassischen bzw. zukünftigen<br />
Handy-Kommunikationsprotokolle<br />
wie GPRS oder UMTS.<br />
3. Die dritte Art der Vernetzung ist die<br />
der Basisstation (z.B. des Mobilfunkanbieters)<br />
mit dem Wearable um diesem<br />
Dienste wie LBS, Zugriff auf Datenbanken<br />
oder einen ganz normalen Internetzugang<br />
zu bieten. Auch hier kämen wiederum<br />
WLAN oder GPRS bzw. UMTS in<br />
Betracht.<br />
Bei all diesen Vernetzungsmöglichkeiten ist<br />
aber ein besonderes Augenmerk auf die Sicherheit<br />
zu richten. So ist es ohne ausreichende<br />
Vorkehrungen relativ leicht möglich<br />
bei der Vernetzung über die Luft nicht<br />
nur den kompletten Datenverkehr eines Benutzers<br />
abzufangen sondern auch auf alle<br />
in dessen Wearable gespeicherten persönlichen<br />
Daten zugreifen. Sollten sich hier<br />
Sicherheitslücken auftun, wären solche Abhörversuche<br />
umso einfacher, da ein anderer<br />
Wearable-Träger dann seinen eigenen nur<br />
entsprechend zu modifizieren bräuchte.<br />
11.3.5 Prozessoren<br />
Das Herz eines Wearable bildet der Mikroprozessor.<br />
Die Anforderungen an diesen
sind kleine Abmessungen, geringer Stromverbrauch,<br />
Robustheit und geringe Wärmeabstrahlung,<br />
da man natürlich keine herkömmlichen<br />
Kühlmöglichkeiten wie Lüfter<br />
oder Kühlkörper verwenden kann. Denkbar<br />
wären auch bei erhöhtem Rechenbedarf der<br />
Einsatz mehrerer über den Träger verteilter<br />
Prozessoren, die parallel arbeiten. So könnte<br />
man im Endeffekt bei gleicher oder mehr Rechenkraft<br />
mehr Strom sparen und würde weniger<br />
Abwärme erzeugen. Außerdem könnten<br />
die Prozessoren relativ autonom arbeiten<br />
und bei Nichtgebrauch in den Stand-By Modus<br />
wechseln.<br />
Der Markt bietet schon jetzt aufgrund der<br />
zahlreichen PDAs eine große Auswahl an<br />
einsetzbaren Prozessoren. Aktuelle Beispiele<br />
sind Intel’s „XScale“ und „StrongARM“ sowie<br />
Motorola’s „<strong>Dr</strong>agonball“ oder Texas Instrument’s<br />
„OMAP“.<br />
11.3.6 Speichermedien<br />
Speichermedien für Wearables sollten möglichst<br />
robust sein und auch kräftige Stöße<br />
abfangen können; ideal wäre auch leichte<br />
Austauschbarkeit. Hier bieten sich alle kompakten<br />
derzeit auf dem Markt erhältlichen<br />
Speichermedien an, die ohne mechanische<br />
Teile auskommen bzw. speziell für den mobilen<br />
Bereich entwickelt wurden. Beispiele sind<br />
„SmartMedia“,„Compact Flash“ oder IBM’s<br />
„Micro<strong>Dr</strong>ive“ 90 , die alle mittlerweile Kapazitäten<br />
bis zum Gigabyte-Bereich bieten.<br />
11.3 Technik<br />
Abbildung 93: Größenvergleich und Innenansicht<br />
des Micro<strong>Dr</strong>ive von<br />
IBM<br />
11.3.7 Sensoren<br />
Soll ein Wearable wirkliche Kontextsensitivität<br />
bieten muss dieser über diverse Sensoren<br />
natürlich jederzeit ein volles Verständnis<br />
davon haben, was der Träger gerade macht<br />
und was in dessen Umgebung geschieht.<br />
Zur Erkennung der Aktionen des Trägers<br />
werden in den meisten Modellen Bewegungssensoren<br />
oder Kreiselsensoren verwendet.<br />
Diese unterscheiden mit Hilfe der<br />
richtigen Software dann, ob der Benutzer<br />
gerade läuft oder sitzt; drucksensitive Stoffe<br />
der Kleidung könnten dabei weitere Anhaltspunkte<br />
liefern. Über die körperliche Verfassung<br />
des Trägers würden Sensoren Auskunft<br />
geben, die den Pulsschlag und die Körpertemperatur<br />
messen. Der Wearable kann<br />
so erkennen, wann er z.B. das Display ausschalten<br />
kann oder der Träger einfach seine<br />
Ruhe haben will.<br />
An externen Sensoren wären kleine Kameras,<br />
Thermometer, Mikrophone, GPS-<br />
Empfänger (problematisch in Gebäuden !)<br />
und natürlich Funk-Uhren denkbar. Diese<br />
würden Aufschluß über die äußeren Umstände<br />
des Trägers geben und zu entsprechendem<br />
adaptiven Verhalten des Wearables<br />
weiter beitragen, also z.B. im Theater<br />
den StandBy-Modus veranlassen.<br />
90 Das Microdrive ist ein Festplattenlaufwerk für „Compact Flash II“-Slots. Es ist allerdings wegen seiner beweglichen<br />
Teile nur bedingt für den mobilen Einsatz geeignet.<br />
161
Oliver Hagel<br />
11.4 Konkrete Modelle<br />
Im folgenden Abschnitt sollen kurz Komplettsysteme<br />
vorgestellt werden, die entweder<br />
schon auf dem Markt erhältlich, visionäre<br />
Modelle aus der Forschung oder interessante<br />
Prototypen sind.<br />
BARS Das „BARS“ (Battlefield Augmented<br />
Reality System) [oNRYB00, Ros00] ist ein<br />
noch weitgehend in der Planungsphase befindlicher<br />
Wearable der US-Army, über den<br />
es allerdings seit 2000 keine offiziellen Neuigkeiten<br />
mehr gibt. Die Entwicklung kam aus<br />
dem Bedürfnis auch in komplexen Szenarios<br />
(z.B. Einsätzen in Städten mit Hochhäusern,<br />
Kanalisation und Trümmern) dem Soldaten<br />
eine ausreichende Übersicht zu geben und<br />
Teameinsätze besser abstimmen zu können;<br />
auch die verbesserte Kommunikation mit der<br />
Einsatzzentrale spielte eine Rolle.<br />
Die Daten werden dabei als „Augmented<br />
Reality“ (AR) mittels eines HMD im Helm<br />
des Soldaten für ihn direkt über den betrachteten<br />
Objekten eingeblendet. Vorstellbar<br />
sind Informationen über die Umgebung,<br />
Aufenthaltsorte der Teammitglieder, Zielobjekte,<br />
Stadtpläne oder Gebäudepläne, Routinginformationen,<br />
Übersetzungen von Schildern<br />
und Warnungen (z.B. über mögliche<br />
Scharfschützenpositionen). Auch Daten oder<br />
Modelle von nicht sichtbaren Objekten könnten<br />
eingeblendet werden; so wäre es z.B.<br />
möglich, dem Soldaten quasi einen Röntgenblick<br />
zu verschaffen, indem man den Verlauf<br />
der Kanalisation unter seinen Füßen als<br />
<strong>Dr</strong>ahtgittermodell einblendet.<br />
Das System hat 2 Seiten: Zum einen<br />
das „Wearable Augmented Reality System“<br />
(WARS) auf Seite des Soldaten und zum anderen<br />
das „3D Interactive Command Center“<br />
(3Dice) auf Seite des Kommandostabs. Dieses<br />
soll eine dreidimensionale Abbildung der<br />
Einsatzsituation ermöglichen, um dem Commander<br />
eine optimale Übersicht und Entscheidungshilfe<br />
zu geben. Auch der Einsatz<br />
von CAVE-Systemen 91 wurde in die Überlegungen<br />
mit einbezogen. Als technische<br />
Grundlage für die ersten Schirtte diente ein<br />
Wearable aus dem akademischen Umfeld,<br />
die „Virtual Touring-Maschine“ [Höl97] der<br />
Columbia <strong>Universität</strong>. Mit dieser war es z.B.<br />
möglich auf dem Campus spazieren zu gehen<br />
und sich AR-Daten zu den betrachteten<br />
Gebäuden einblenden zu lassen. Auch<br />
zerstörte Gebäude konnte man durch diese<br />
Technik für den Träger auferstehen lassen.<br />
Als Programmiersprache wurden hierbei Java<br />
und Java3D verwendet.<br />
Der erste Prototyp des BARS verwendete als<br />
Hardware einen Pentium II 366 MHz Laptop,<br />
Dual-GPS (US Navstar + russische GLO-<br />
NASS) mit Basisstation um Zentimetergenauigkeit<br />
zu erreichen, Bewegungssensoren,<br />
Funkmodem (115kbit/s auch über 20 Meilen<br />
im Freien bzw. auf mehrere 100m aus dem<br />
Inneren eines Gebäudes) und ein halbdurchsichtiges<br />
Sony Glasstron HMD.<br />
FAST Der FAST (Factory Automation<br />
Support Technology) ist ein Test-<br />
Modell des Georgia Reasearch Institute<br />
[OJJNLJTJCTCJA96] aus Atlanta, das ca.<br />
1000 Beschäftigte hat. Es ist ein Wearable in<br />
der mittlerweile 3. Generation, der zur Optimierung<br />
und Kontrolle von typischen Fabrikabläufen<br />
dienen soll. Er wurde zu Testläufen<br />
auch schon erfolgreich in einer Nahrungsmittelfabrik<br />
eingesetzt, wo er vornehmlich zur<br />
komfortablen Überwachung von Solldaten<br />
diente.<br />
Er besteht aus einem PC-Card-großen Mainboard<br />
mit einem 486er 75 MHz CPU, 16<br />
MB RAM, 500 MB Festplatte, einem monochromen<br />
VGA-HMD, Win 95 und Ni-Mh-<br />
Batteriepacks, die eine Laufzeit von bis zu 8<br />
Stunden ermöglichen. Zusätzliche Merkmale<br />
sind Spracherkennung und eine Kopfkamera,<br />
um Bilder zur Zentrale zu übermitteln.<br />
91 Würfel auf dessen Seiten von außen Bilder projeziert werden und in dessen Zentrum der Benutzer steht. Dieser<br />
hat mit Hilfe einer 3D-Brille einen dreidimensionalen Eindruck der Situation; wird vornehmlich im Automobilbau<br />
verwendet.<br />
162
Xybernaut „Xybernaut“ [Cor02b] ist der<br />
Marktführer bei anziehbarer Computer-<br />
Hardware 92 . Das aktuelle Spitzenmodell ist<br />
der „Mobila Assistant V“ (MA V), der an einem<br />
Gürtel getragen wird. Er läuft mit den<br />
meisten aktuell verfügbaren Betriebssystemen,<br />
besitzt einen 500 MHz Intel Celeron<br />
Prozessor, 128 MB SDRAM, Soundkarte, eine<br />
5 GB Festplatte, Compact Flash, USB,<br />
Firewire, Li-Ion-Akku, PC Card Steckplätze<br />
und ein kompaktes Flat-Panel-Display. Die<br />
Eingabe erfolgt entweder mittles Mikrofon<br />
und Spracherkennung oder über das 60-<br />
Tasten-Keyboard am Handgelenk.<br />
Ein weiteres Modell ist der „poma“: Er besitzt<br />
einen Hitachi SH-4 128 MHz RISC Prozessor,<br />
ein mono-okulares 640x480 HMD,<br />
32 MB ROM/RAM, Compact Flash 2, Windows<br />
CE 3.0, USB, Kopfhörer, Li-Ion-Akku<br />
und wiegt 310g. Er unterstützt auch WLAN<br />
und ein Modem (über den CF-Slot). Die Eingabe<br />
erfolgt per Handeingabe über ein per<br />
USB angeschlossenes blau schimmerndes<br />
kompaktes Touchpad; es sind aber auch andere<br />
tragbare Keyboards anschließbar. Dieses<br />
Modell gibt es auch von Hitachi unter<br />
dem Namen „Wearable Internet Appliance“<br />
[Hit01] mit teilweise anderen Komponenten<br />
(z.B. ein 800x600, 18-bit HMD).<br />
Abbildung 94: Headset, Hauptkomponente<br />
und Touchpad des poma<br />
Die Wearables von Xybernaut werden schon<br />
längere Zeit erfolgreich in der Industrie eingesetzt.<br />
Sie finden z.B. Verwendung bei „Bell<br />
Kanada“, einem großen Kommunikationsunternehmen,<br />
das sie zur Unterstützung von<br />
11.4 Konkrete Modelle<br />
Feldtechnikern verwendet: Über eingebaute<br />
Handys erfolgt die Kommunikation mit der<br />
Zentrale, Pläne sind über den „MA V“ anzeigbar<br />
und neue Daten können direkt ins<br />
Zentral-System eingeben werden - auch unter<br />
schwierigen Bedingungen (z.B. in engen<br />
Schächten). Auch zur Flugzeugwartung bei<br />
„FedEx“, der Navy und der Air Force werden<br />
wegen der z.T. extrem kurzen Zeitfenster die<br />
Modelle von Xybernaut eingesetzt.<br />
MIThril Der „MIThril“ 93 [Tec02b] ist eine<br />
Forschungsplattform des MIT, die allerdings<br />
wegen der umgebauten Standardkomponenten<br />
noch eher wie am Körper getragene<br />
Hardware aussieht. Sie basiert auf Linux und<br />
hat noch kein kabelloses Bussystem, da man<br />
sich bisher nicht mit Problemen der Abhörsicherheit<br />
befassen wollte und die zentrale<br />
Batterieversorgung im Vordergrund stand.<br />
Als Hardware [Lab02] eingesetzt werden<br />
USB (für den BUS und die Peripherie), eine<br />
Kamera, ein IR-Sender, ein „BrightStar Engineering“<br />
ipEngine1 Board (für das HMD), ein<br />
CERF-Board (an dem das Compact Flash<br />
und ein IBM Micro<strong>Dr</strong>ive hängen), ein Ethernet<br />
HUB (verbindet das CERF und das<br />
BrightStar-Board untereinander und mit einer<br />
802.11b Brücke) sowie ein „MicroOptical“-<br />
HMD in einer Brille. Als Akkus werden Li-Ion<br />
Polymer Akkus eingesetzt.<br />
ViA ViA [ViA02] ist neben Xybernaut eine<br />
der großen Firmen, die Wearables vornehmlich<br />
für das berufliche Umfeld herstellen. Mit<br />
General Electrics, Ford, Northwest Airlines<br />
und McDonalds als Partner hat man auch<br />
schon ein festes Standbein in der Industrie.<br />
Das aktuellste Modell ist der „ViA II PC“<br />
[ViA], ein robuster Wearable der normalerweise<br />
wie ein Gürtel umgeschnallt wird. Er<br />
ist ausgestattet mit Windows 98 (andere Betriebssysteme<br />
sind aber auch möglich), Li-<br />
Ion-Akkus (während dem Betrieb austausch-<br />
92 Die Wearables von Xybernaut werden übrigens von IBM gebaut. Diese haben so ein vielversprechendes zukünftiges<br />
Standbein, müssen aber auch nicht um ihren guten Namen fürchten, wenn das Geschäft floppen sollte.<br />
93 Der Name ist übrigens eine Verschmelzung von MIT und dem Namen für ein elbisches Metall aus „Herr der<br />
Ringe“.<br />
163
Oliver Hagel<br />
bar), Slot für 802.11b PC Card, USB, 6 GB<br />
Festplatte und PS/2-Port. Zur Aus- und Eingabe<br />
dient ein leichtes 640x480 Display mit<br />
Touchscreen, das bei Nichtgebrauch im Gürtel<br />
verstaut wird und auch unter direktem<br />
Sonnenlicht sehr gut lesbar ist. Ein HMD ist<br />
optional, wird aber in den bisherigen Anwendungsgebieten<br />
nicht eingesetzt. Der „ViA II“<br />
ist in 2 Varianten erhältlich: Entweder mit<br />
einem 166 MHz Cyrix Media GSI Prozessor<br />
oder einem 600 MHz Transmeta Crusoe<br />
5600 Prozessor und jeweils zugehörigem<br />
Chipsatz. Das Gewicht des Computers an<br />
sich beträgt 650g. Zur Steuerung kann man<br />
auch Spracherkennung benutzen und sogar<br />
Übersetzungssoftware für gesprochene<br />
Sprache ist lieferbar.<br />
Die Nachteile sind allerdings laut c’t [Zie02],<br />
das nicht unerhebliche Gewicht (quasi ein<br />
ständiger Werkzeuggürtel), der nicht gerade<br />
lautlose Lüfter der Zentraleinheit sowie die<br />
extra am Gürtel zu tragende Batterie.<br />
Eingesetzt wird der „ViA II PC“ neben den<br />
genannten Firmen auch in verschiedenen<br />
Betrieben zum Test. So sparte z.B. ein mit<br />
einer Helmkamera ausgestatteter ViA bis zu<br />
70% der Zeit der Inspekteure auf einer Werft,<br />
da diese die Bilder vor Ort direkt an die Spezialisten<br />
in der Zentrale übertragen bzw. auf<br />
Datenbanken zugreifen konnten.<br />
Abbildung 95: Die Hauptkomponente des<br />
ViA II<br />
164<br />
eSleeve An der <strong>Universität</strong> Bristol entstanden<br />
in Zusammenarbeit mit der HP-<br />
Forschung mehrere Wearables [Ran02] ,<br />
bei denen das außergewöhnlichste wohl das<br />
„eSleeve“ ist, ein komplett am Unterarm zu<br />
tragender Computer.<br />
Als Grundlage dient der „onHandPC“ von<br />
„Matsucom“ [Mat02], ein PC in Armbanduhrform.<br />
Er besitzt 2 MB RAM, eine 16 Bit 3,6<br />
MHz CPU, DOS als Betriebssystem, einen<br />
IR-Port und ein 102x64 Display. Die Eingabe<br />
erfolgt über 3 Tasten und einen kleinen<br />
Joystick. Die Lithium-Batterien sollen 2-3<br />
Monate halten. Außerdem ist er wasserfest<br />
und wiegt nur 52g. An Software reicht das<br />
umfangreiche Angebot vom Browser, über<br />
Bildbetrachter und Organizer bis zu Übersetzern<br />
und es kommt ständig neue hinzu, da<br />
viele Benutzer ihre selbstgeschriebenen C-<br />
Programme dafür veröffentlichen.<br />
Zum „eSleeve“ [CR02] wurde der onHandPC<br />
durch externe Erweiterungen wie GPS oder<br />
Spracherkennung, die natürlich auch ein eigenes<br />
Mainboard (zur Koordination des Polling)<br />
mitbringen, das ebenfalls um den Unterarm<br />
geschnallt wird. Der Prozessor des<br />
onHandPC dient dabei nur noch zur Behandlung<br />
von Ereignissen, die die Datenbank abfragen<br />
sowie zur Darstellung von Daten.<br />
Auch die Kontextsensitivität spielt bei den<br />
Modellen aus Bristol eine Rolle. So kann<br />
man z.B. mittels Beschleunigungssensoren<br />
und neuronalen Netzen feststellen, ob der<br />
Träger sitzt, steht, geht oder rennt und das<br />
immerhin mit einer Genauigkeit von ca. 90%.<br />
Diese Kontextsensitivität nutzten auch schon<br />
zwei Test-Anwendungen: „Pub Crawl“ zeigt<br />
den Weg (mittels Piepstönen) und die Entfernung<br />
zu den nächsten 3 Pubs in Bristol sowie<br />
nähere Details. Ein weiteres Programm zeigt<br />
zur Orientierung, quasi als Augmented Reality,<br />
die Schemen und Namen von bekannten<br />
Gebäuden auf dem kleinen Display an, in deren<br />
Sichtweite sich der Träger befindet.
Abbildung 96: Das eSleeve der <strong>Universität</strong><br />
Bristol<br />
Charmed „Charmed Technology“ [Tec02a]<br />
ist eine aufstrebende Firma, die vornehmlich<br />
Erfahrungen aus der Forschung des MIT Media<br />
Lab in ihre kommerziell erhältlichen Wearables<br />
einfließen lässt. Das Ziel ist es, einen<br />
mobilen Internetzugang über ihre günstigen<br />
Wearables zu bieten.<br />
Das aktuelle Vorzeigeprodukt ist der „CharmIT“,<br />
ein Wearable in einem Aluminiumgehäuse,<br />
der versucht aus Gründen der einfachen<br />
Erweiterbarkeit mit offengelegter Standardhardware<br />
auszukommen. Diese ist deshalb<br />
relativ flexibel und auch austauschbar,<br />
allerdings ist der Wearable dadurch auch etwas<br />
sperrig geraten 94 . Der höchstgetaktete<br />
dafür erhältliche Prozessor ist ein 800 MHz<br />
Transmeta Crusoe TM5800. Speicher ist bis<br />
zu 265 MB SDRAM erhältlich. Weitere Auststattungsmerkmale<br />
sind Stereo Audio, 4 serielle<br />
Ports, 4 USB Ports, 1 paralleler Port<br />
sowie 10/100 Ethernet. Ein 32-bit MiniPCI<br />
Schacht ermöglicht zusätzliche Erweiterungen<br />
und eine 20 GB Festplatte (bis zu 120<br />
GB möglich) ist ebenfalls enthalten. Die Batterielaufzeit<br />
mittels Li-Ion Camcorder Batterien<br />
(ohne Verbrauch des Displays) soll bis zu<br />
12 Stunden betragen.<br />
Der CharmIT ist ab ca. US $2000 in vielen<br />
Kits erhältlich, z.B. mit verschiedenen<br />
Betriebssystemen, HMDs oder Eingabegeräten.<br />
11.5 Fazit und Ausblick<br />
Burton MD Jacket Eines der wenigen auf<br />
dem Markt erhältlichen anziehbaren elektronischen<br />
Kleidungsstücke ist das „Analog Clone<br />
MD Jacket“ [min02] von Burton Snowboards<br />
in Zusammenarbeit mit der britischen<br />
Firma SOFTswitch. Letztere entwarfen das<br />
elektronische Leitungssystem auf Textilbasis<br />
für die Bedienung des in einer Snowboardjacke<br />
verstauten MD-Players. Dieser<br />
lässt sich so auch mit Handschuhen über<br />
eine Bedienleiste im Jackenärmel steuern,<br />
für deren Knöpfe textile „Quantum Tunneling<br />
Composite“-Schalter verwendet wurden,<br />
die nur bei <strong>Dr</strong>uck, elektrischen Strom leiten.<br />
Allerdings muss dieser <strong>Dr</strong>uck leider teilweise<br />
noch sehr hoch sein, was das Ganze<br />
laut c’t [Zie02] wiederum etwas unkomfortabel<br />
macht.<br />
11.5 Fazit und Ausblick<br />
94 Das Gewicht wird dementsprechend auch auf der Internetseite verschwiegen.<br />
Der Erfolg von Wearables erschien vor wenigen<br />
Jahren noch als pure Utopie - zu unhandlich<br />
und sperrig waren die damals noch<br />
eher an Cyborgs erinnernden vorgestellten<br />
Lösungen. Für viele war es nur ein Hype und<br />
technische Spielerei, denn sinnvolle Anwendungen<br />
konnte man sich ebenfalls nicht vorstellen.<br />
Dies alles hat sich aber nun mit der Verfügbarkeit<br />
der nötigen Technik, dem teilweisen<br />
industriellen Einsatz und den aktuellen Prototypen<br />
geändert. Die zunehmende Verbreitung<br />
von PDAs lässt die Hemmschwelle weiter<br />
sinken und auch sinnvolle Anwendungsgebiete<br />
absehen. Hinzu kommt, daß vernünftige<br />
Wearables immer billiger werden: Modelle<br />
wie der ViA II PC kosten in der Zwischenzeit<br />
ungefähr genauso viel wie ein guter<br />
Laptop. Neue Techniken zur einfachen<br />
und schnelleren Vernetzung wie Bluetooth<br />
und UMTS werden weitere Impulse besonders<br />
im privaten Bereich geben.<br />
Trotzdem scheinen sich in den nächsten Jahren<br />
Wearables weniger im privaten Bereich<br />
165
Literatur<br />
als im beruflichen Umfeld weiter durchzusetzen,<br />
weil man hier einfach eher bereit<br />
bzw. gewohnt ist, ein relativ unhandliches<br />
Werkzeug für die Arbeit zu tragen. Mit den<br />
aktuell erhältlichen Wearables und passenden<br />
Headsets würde man im normalen Leben<br />
einfach noch viel zu sehr auffallen, was<br />
natürlich viele potentielle Interessenten abschreckt.<br />
Hier sind aber auch schon Entwicklungen<br />
in Sicht, die dieses Problem beseitigen<br />
dürften: So könnte man sich in nächster<br />
Zeit z.B. durchaus einen PDA in der Jackentasche<br />
vorstellen, der GSM und UMTS Fähigkeiten<br />
hat und auch auf LBS-Dienste zugreifen<br />
kann. Mittels Bluetooth könnte man<br />
ihn mit einem kleinen Headset sowie einem<br />
unauffälligen Brillen-HMD (z.B. einem zukünftigen<br />
Modell von „Micro Optical“) drahtlos<br />
verbinden. Solche Modelle können sich<br />
allerdings schon wegen der LBS- und UMTS-<br />
Fähigkeiten nur durchsetzen, wenn sie von<br />
den Mobilfunkanbietern eingeführt werden,<br />
was allerdings erfahrungsgemäß seine Zeit<br />
dauern kann: Zwar haben sich Handys relativ<br />
schnell durchgesetzt, neue Techniken<br />
wie EMS, UMTS und WAP werden aber nur<br />
sehr zaghaft angenommen, was vor allem an<br />
der Preispolitik der Mobilfunkanbieter selbst<br />
liegt. Diese haben also den Erfolg von Wearables<br />
maßgeblich mit in der Hand !<br />
Realistische Prognosen wie die der „Venture<br />
Development Corporation“ [Zie02] prophezeien<br />
übrigens bis 2006 ein Wachstum<br />
von jährlich 50%. Allerdings hieße das, daß<br />
in 4 Jahren gerade einmal bescheidene 560<br />
Millionen US Dollar für Wearables ausgegeben<br />
würden und dies vornehmlich im beruflichen<br />
Umfeld.<br />
Schaut man in die weitere Zukunft, kann man<br />
Literatur<br />
nur schwer sagen, wie Wearables dann aussehen<br />
werden. Die Menschen, die sie regelmäßg<br />
brauchen, werden sich wahrscheinlich<br />
an sie gewöhnt haben, ähnlich wie an das<br />
Handy heutzutage. Eine Abhängigkeit oder<br />
Diktatur der Wearables ist relativ unwahrscheinlich,<br />
man wird sie wohl eher als nützliche<br />
Accessoires begreifen und akteptieren.<br />
Für zukünftige Techniken gibt es schon heute<br />
Ansätze die wie Utopie wirken, langfristig<br />
aber durchaus vorstellbar wären. So existieren<br />
beispielsweise schon einfache Eingabemöglichkeiten<br />
über die durch entsprechende<br />
Gedanken erzeugten Gehirnwellen<br />
sowie Cursorsteuerungen über die Pupillenbewegung.<br />
Sogar Implantate wurden zu<br />
Testzwecken schon eingesetzt.<br />
Und schließlich haben auch noch die Kleidungshersteller<br />
mitzureden um Wearables<br />
wirklich tragbar zu machen. Ob sich aber<br />
tatsächlich intelligente Fasern und mit der<br />
Kleidung verwobene Elektronik durchsetzen<br />
oder diese nur zunehmend für die Aufnahme<br />
von separaten technischen Geräten vorbereitet<br />
wird, bleibt abzuwarten. Im Moment<br />
kann man nur sagen, daß auch hier<br />
die Hemmschwelle, sich Kleidungsstücke zu<br />
kaufen, die fest eingebaute elektronische Fähigkeiten<br />
haben, viel zu hoch ist. Kleidung<br />
sollte in den Augen der Mehrheit modisch,<br />
robust, beständig und, nicht zu vergessen,<br />
waschbar sein - Eigenschaften, die man allgemein<br />
nicht gerade mit Technik verknüpft.<br />
Wirkliche Vorhersagen kann man in der heutigen<br />
Zeit immer schnellerer technischer Revolutionen<br />
in dieser Hinsicht aber kaum treffen.<br />
Hier bleibt schlicht abzuwarten was die<br />
Zukunft bringt.<br />
[Bab99] Chris Baber: Contrasting paradigms for the development of wearable<br />
computers. http://www.research.ibm.com/journal/sj/<br />
384/baber.html, 1999.<br />
[Bun02] Christoph Bungert: HMD/headset/VR-helmet Comparison Chart.<br />
http://www.stereo3d.com/hmd.htm, 2002.<br />
166
Literatur<br />
[Can02] CBC Radio Canada: Cyberman. http://cbc.ca/cyberman/<br />
AllNEW.htm, 2002.<br />
[Cor02a] Handykey Corp.: Twiddler, Keyboard and Mouse in one Hand. http:<br />
//www.handykey.com/, 2002.<br />
[Cor02b] Xybernaut Corp.: Xybernaut Corporation - Technology that Works<br />
with You. http://www.xybernaut.com, 2002.<br />
[Cor02c] MicroOptical Corporation: MicroOptical - Making Portable Practical.<br />
http://www.microopticalcorp.com/, 2002.<br />
[CR02] Henk L. Muller Cliff Randell. The esleeve: A novel wearable computer<br />
configuration for the discovery of situated information. Technical report,<br />
DepartmentofComputerScience,UniversityofBristol,U.K., 2002.<br />
[Hit01] Hitachi: Wearable Internet Appliance. http://www.hitachi.<br />
com/products/information/multimedia/wia/index.html,<br />
2001.<br />
[Höl97] Tobias Höllerer: MARS - Mobile Augmented Reality Systems.<br />
http://www.cs.columbia.edu/graphics/projects/mars/<br />
mars.html, 1997.<br />
[Lab02] MIT Media Lab: MIThril Construction Page. http://dev-bywater.<br />
media.mit.edu/wiki/borglab/Construction, 2002.<br />
[Mat02] Inc. Matsucom: onHand - Put the Power of Personal Computing on<br />
Your Wrist. http://www.matsucomusa.com/, 2002.<br />
[Mil02] Vito Miliano: Wearforge Wearables Wiki. http://wearforge.<br />
perilith.com/bin/view/Main/WebHome, 2002.<br />
[min02] minidisc.org: Burton Analog Clone MD Snowboarding Jacket.<br />
http://www.minidisc.org/part_Burton_Analog_Clone_<br />
MD_Snowboarding_Jacke% t.html, 2002.<br />
[oD02] U.S. Department of Defense: Army Tests Land Warrior for 21st Century<br />
Soldiers. http://www.defenselink.mil/news/Sep1998/<br />
n09111998_9809117.html, 2002.<br />
[OJJNLJTJCTCJA96] F. D. Ockerman J. J.; Najjar L. J.; Thompson J. C.; Treanor C.<br />
J.; Atkinson: FAST: A Research Paradigm for Educational Performance<br />
Support Systems. http://mime1.gtri.gatech.edu/mime/<br />
papers/edmedia2.html, 1996.<br />
[Onl01] SBCCOM Online: Integration of Computers and Electronics<br />
with Textiles. http://www.sbccom.army.mil/products/cie/<br />
Integrated_Electronics_in_Text% iles.htm, 2001.<br />
[oNRYB00] Office of Naval Research & Yohan Baillot: Battlefield Augmented<br />
Reality System (BARS). http://ait.nrl.navy.mil/vrlab/<br />
projects/BARS/BARS.html, 2000.<br />
[Pfe98] Gregory Martin Pfeil: Wearable Computing FAQ. http://wearcam.<br />
org/wearcompfaq.html, 1998.<br />
[Ran02] Cliff Randell: Bristol Wearable Computing. http://wearables.<br />
cs.bris.ac.uk/, 2002.<br />
[Ros00] Simon Julier; Yohan Baillot;Marco Lanzagorta;Dennis<br />
Brown;Lawrence Rosenblum. Bars: Battlefield augmented<br />
reality system. Technical report, Naval Research Laboratory, 2000.<br />
167
Literatur<br />
[rpm02] rpmc@troi.cc.rochester.edu: Wearables Central - Wearable Computing<br />
Links and News Archive. http://wearables.blu.org/,<br />
2002.<br />
[Sch02] Joseph Scheppach: Soldaten der Zukunft. P.M., 9/2002, S. 88-95.<br />
[SD02] Bradford J. Snow und Richard W. DeVaul: A Short History of Wearable<br />
Computers. http://www.media.mit.edu/wearables/<br />
mithril/history/index.html, 2002.<br />
[Soc02] IEEE Computer Society: International Symposium on Wearable<br />
Computers. http://wearables.gatech.edu/iswcframe.htm,<br />
2002.<br />
[Sta96] Thad Starner: Field mice: Human-powered wearable computing.<br />
http://www.research.ibm.com/journal/sj/353/<br />
sectione/starner.html, 1996.<br />
[Tec02a] Charmed Technology: Charmed Technology ...wireless everywear.<br />
http://www.charmed.com/company.php, 2002.<br />
[Tec02b] Massachusetts Institute For Technology: Wearable Computing at<br />
the MIT Media Lab. http://www.media.mit.edu/wearables/,<br />
2002.<br />
[unb] Autor unbekannt: Wearable Computing. http://home.<br />
earthlink.net/~wearable/.<br />
[ViA] ViA, Inc. ViA II System User’s Guide.<br />
[ViA02] Inc ViA: ViA Wearables - Computers that fit people. http://www.<br />
flexipc.com, 2002.<br />
[VV02] Inc. Virtual Vision: Producer of HMDs. http://www.<br />
virtualvision.com/, 2002.<br />
[Zie02] Peter-Michael Ziegler: PC hautnah. c’t, 21/2002, S. 102-11.<br />
168
12 Einführung Physical-Virtual Integration<br />
Zusammenfassung<br />
Diese Einführung zum Thema Physical-<br />
Virtual Integration befasst sich damit, was<br />
unter dem Begriff zu verstehen ist und<br />
wozu sie dient. Sie gibt außerdem Beispiele<br />
für derzeit mögliche Formen von<br />
Physical-Virtual Integration, behandelt in<br />
Zukunft denkbare Entwicklungen in dieser<br />
Richtung und geht auf das Thema Ubiquitous<br />
Computing im Zusammenhang<br />
mit Physical-Virtual Integration ein.<br />
12.1 Was ist Physical-Virtual Integration?<br />
Physical-Virtual Integration bezeichnet die<br />
Verbindung zweier Welten. Dabei handelt es<br />
sich um die physische, sprich reale Welt, in<br />
der sich sowohl der Benutzer als auch die<br />
Hardware eines Computers befindet, und um<br />
die künstliche, also virtuelle Welt, die im „Innern”<br />
des Computers durch die Ausführung<br />
der Software auf der Hardware entsteht. Mit<br />
Physical-Virtual Integration ist die Anbindung<br />
der physischen an die virtuelle Welt gemeint.<br />
12.2 Wozu dient sie?<br />
Durch Physical-Virtual Integration ist es möglich,<br />
Informationen zwischen den beiden<br />
Welten auszutauschen. Sie erlaubt der realen<br />
Welt, den Zustand der künstlichen Welt<br />
zu beeinflussen. Und sie erlaubt der künstlichen<br />
Welt, sich der realen Welt mitzuteilen<br />
und gegebenenfalls auch auf sie einzuwirken.<br />
Insbesondere für das Feld Ubiquitous<br />
Computing ist Physical-Virtual Integration ein<br />
wichtiger Aspekt. Wenn Rechner allgegenwärtig<br />
sind beziehungsweise ihre Dienste<br />
überall und jederzeit abrufbar sind, dann sollten<br />
sie und ihre Dienstleistungen gut in ih-<br />
Ingo Grüll<br />
ingo.gruell@informatik.uni-ulm.de<br />
re Umwelt, also das jeweilige Anwendungsumfeld,<br />
integriert sein. Ist das nicht der Fall,<br />
artet Ubiquitous Computing für die Benutzer<br />
schnell in Ubiquitous Frustration aus.<br />
12.3 Wesentliche Abstufungen von<br />
Physical-Virtual Integration<br />
Physical-Virtual Integration kann sehr unterschiedlich<br />
ausgeprägt und somit mal eher lose,<br />
mal eher stark vorhanden sein. Es lohnt<br />
sich jedoch, einige ”Trennlinien” zu ziehen,<br />
denn diese markieren unterschiedliche Qualitätsstufen<br />
von Physical-Virtual Integration.<br />
12.3.1 Keinerlei Physical-Virtual<br />
Integration<br />
Absolut gar keine Verbindung zwischen<br />
künstlicher und wirklicher Welt ist unmöglich.<br />
Ohne die wirkliche Welt kann die künstliche<br />
nicht existieren. Erst müssen Hardware und<br />
Software erschaffen werden, bevor sich die<br />
virtuelle Welt entfalten kann - und der Ablauf<br />
der Berechnungen erfolgt in den Schranken,<br />
die die Naturgesetze der realen Welt vorgeben.<br />
Aber selbst wenn man einen Schritt<br />
darüber hinaus geht und einen Rechner mit<br />
fest verdrahtetem Programm ohne Informationsaustausch<br />
zwischen künstlicher und realer<br />
Welt betrachtet, ist dieser allenfalls als<br />
Türstopper, Briefbeschwerer oder ähnliches<br />
von Nutzen. Wenn die reale Welt nicht erfährt,<br />
was sich als Ergebnis der Berechnungen<br />
in der künstlichen Welt ergeben hat, ist<br />
es für sie ohne Belang, ob die Berechnungen<br />
durchgeführt wurden oder nicht.<br />
169
Ingo Grüll<br />
12.3.2 Prinzipielle Physical-Virtual<br />
Integration in Form von Ein- und<br />
Ausgabe<br />
Die ersten Allzweckrechner, die gebaut wurden,<br />
waren recht teuer. Ihr Einsatz als Türstopper<br />
oder Briefbeschwerer war demzufolge<br />
nicht nur wegen ihrer vergleichsweise riesigen<br />
Ausmaße nicht zweckmäßig. Also erhielten<br />
sie eine einfache Form von Physical-<br />
Virtual Integration - und einfach bedeutet in<br />
diesem Zusammenhang definitiv nicht „einfach<br />
zu bedienen” - mit der es möglich war,<br />
Programme und Daten in den Rechner einzugeben<br />
und Rechenergebnisse aus dem<br />
Rechner auszugeben. Der 1943 fertiggestellte<br />
Mark 1 wurde beispielsweise über Lochstreifen<br />
und hunderte von Schaltern mit Programm<br />
und Daten versorgt [TL86].<br />
Abbildung 97: Eingabepanel des Mark 1<br />
[TL86]<br />
Und auch der Computerpionier Charles<br />
Babbage hatte im Entwurf seiner „Analytical<br />
Engine” Eingabemöglichkeiten in Form<br />
von Lochkarten vorgesehen und im Entwurf<br />
seiner „Difference Engine No. 2” findet<br />
sich schon ein <strong>Dr</strong>ucker als Ausgabegerät<br />
[Swa93]. Fast hundert Jahre vor den<br />
ersten funktionsfähigen Rechnern hat sich<br />
Charles Babbage bereits mit dem Thema<br />
Ein- und Ausgabe befasst, um die Verbindung<br />
von Maschine und Umwelt zu errei-<br />
170<br />
chen. Die ursprünglich von Joseph-Marie<br />
Jacquard zur Steuerung automatischer Webstühle<br />
entwickelte Lochkarte wurde später<br />
tatsächlich wie von Babbage vorgesehen<br />
eingesetzt.<br />
Abbildung 98: HighTech des 19. Jahrhunderts<br />
[FS99]<br />
Sehr zur Erleichterung der Benutzer haben<br />
Tastatur und Maus die Lochkarte mittlerweile<br />
als Eingabemedium abgelöst, doch der<br />
<strong>Dr</strong>ucker ist uns in unterschiedlichen Formen<br />
bis heute erhalten geblieben; neben dem<br />
Bildschirm gehört er mit zu den wichtigsten<br />
Ausgabemöglichkeiten [Cle91]. Damit also<br />
ein Computersystem überhaupt als solches<br />
von Nutzen ist, muss es zumindest über<br />
grundlegende Physical-Virtual Integration in<br />
Form von Ein- und Ausgabe verfügen.<br />
12.3.3 Physical-Virtual Integration<br />
mitsamt Weltmodell<br />
Bei rein auf Eingabe und Ausgabe basierenden<br />
Systemen muss der Benutzer oder ein<br />
externes System jede Zustandsveränderung<br />
anstoßen: Das System erhält eine Eingabe,<br />
verarbeitet diese und gibt das Ergebnis aus.<br />
Wenn ein System jedoch den Weltausschnitt<br />
der Realität, der für sein Anwendungsgebiet<br />
wichtig ist, intern in geeigneter Weise repräsentiert,<br />
sprich diesen Weltausschnitt modelliert,<br />
ermöglicht das, die verarbeitbaren Eingaben<br />
besser zu interpretieren und sogar zu<br />
erweitern. Wenn das System Zustandsveränderungen<br />
der realen Welt erkennen kann
12.4 Welche Formen von Physical-Virtual Integration sind derzeit möglich?<br />
und seinen Zustand analog „mitentwickelt”,<br />
können nun auch Daten und Ereignisse als<br />
Eingaben dienen, die nicht vom Benutzer direkt<br />
an das System gerichtet sind - das System<br />
wird in die Lage versetzt, die Umgebung<br />
und die Interaktion des Benutzers mit<br />
der Umgebung in gewissem Umfang zu beobachten<br />
und darauf zu reagieren. Dadurch<br />
wird dem Benutzer Arbeit abgenommen, die<br />
Benutzung des Systems wird für ihn im Idealfall<br />
einfacher, produktiver und zweckgerichteter.<br />
Und auch auf der Ausgabeseite ergeben<br />
sich Verbesserungen. Wenn das System<br />
den Zustand der Welt kennt, kann es seine<br />
Ausgaben dafür maßschneidern, bzw. zwar<br />
grundsätzlich korrekte, aber im Kontext gerade<br />
unpassende Ausgaben unterlassen.<br />
Ein Weltmodell kann implizit oder explizit<br />
sein. Implizite Weltmodelle sind in die Struktur<br />
des Systems eingebaut - um ein Beispiel<br />
abseits der Computertechnologie zu geben:<br />
Ein Hammer repräsentiert ein Weltmodell<br />
für „einschlagbare” Gegenstände durch seine<br />
Form. Solange er für Nägel und Ähnliches<br />
verwendet wird, stimmt das „Weltmodell”.<br />
Wird er für Schrauben benutzt, stimmen<br />
Weltmodell und Welt nicht mehr überein,<br />
worunter die Performance leidet. Explizite<br />
Weltmodelle benutzen ausgeformte Objekte<br />
und Regeln, um die Welt zu repräsentieren.<br />
Um das vorige Beispiel weiterzuführen könnte<br />
man nun das „System” Mensch betrachten.<br />
Der Mensch beobachtet seine Umwelt.<br />
Wenn er eine Schraube eindrehen möchte,<br />
erkennt er, daß es sich um eine Schraube<br />
handelt, d.h. in seinem Denken entsteht eine<br />
Repräsentation für die Schraube, und das<br />
Regelwerk, das sich Erfahrung nennt, führt<br />
dazu, daß der Mensch zum Schraubenzieher<br />
und nicht zum Hammer greift.<br />
Ganz so strikt wie eben beschrieben lässt<br />
sich die Trennung in explizit und implizit in<br />
der Praxis häufig nicht vornehmen, meist<br />
dürfte für Computersysteme und computerisierte<br />
Systeme eine Mischform zweckdienlich<br />
sein. Feststehende Sachverhalte oder<br />
feststehenden Mustern folgende Sachverhalte<br />
kann man in die Struktur des Systems<br />
einfließen lassen, während sich stark wandelnde<br />
Sachverhalte mit vielen verschiede-<br />
nen Zuständen, die komplizierten Gesetzmäßigkeiten<br />
folgen, davon profitieren dürften,<br />
daß ihre Bestandteile explizit im System modelliert<br />
werden. Im Einzelfall mag es schwierig<br />
sein, festzustellen, ob ein System tatsächlich<br />
seine reale Umgebung beziehungsweise<br />
sein Anwendungsgebiet modelliert, denn ein<br />
solches Weltmodell kann beliebig rudimentär<br />
oder unrealistisch sein. Doch die allgemeine<br />
Unterscheidung in „Weltmodell/kein Weltmodell”<br />
ist durchaus sinnvoll, und zwar nicht<br />
nur bei der Analyse von Systemen, sondern<br />
besonders bei der Entwicklung neuer Systeme.<br />
Wenn sich die Entwickler bewusst sind,<br />
daß das zu erstellende System die Realität<br />
nicht nur in dem Maße modellieren soll, wie<br />
sie selbst die Problemstellung untersucht haben,<br />
können sie sorgfältiger festlegen, was<br />
das System beobachten soll, wie es die Beobachtungen<br />
intern repräsentieren und wie<br />
es darauf reagieren soll.<br />
Physical-Virtual Integration mitsamt Weltmodell<br />
setzt die grundlegende Integration mittels<br />
Ein- und Ausgabe voraus, geht aber in<br />
ihren Möglichkeiten über sie hinaus.<br />
12.4 Welche Formen von Physical-Virtual<br />
Integration sind derzeit möglich?<br />
Mehrere Jahrzehnte Entwicklung der Computer<br />
haben dazu geführt, daß das Gebiet<br />
der Ein- und Ausgabe intensiv bearbeitet<br />
wurde und viele Lösungen ausprobiert<br />
und verfeinert oder wieder verworfen<br />
wurden. Und auch der Einsatz von<br />
Weltmodellen ist lange erprobt. Dieser Abschnitt<br />
gibt einige Beispiele, welche Formen<br />
von Physical-Virtual Integration in der Forschung<br />
schon heute möglich beziehungsweise<br />
in der Praxis schon in Gebrauch<br />
sind. Diese Beispiele stellen mitnichten eine<br />
vollständige Bestandsaufnahme des Feldes<br />
Physical-Virtual Integration dar. Dennoch unterstreichen<br />
sie dadurch, daß sie den unterschiedlichsten<br />
Anwendungsgebieten und<br />
Forschungsfeldern entstammen, wie grundlegend<br />
Physical-Virtual Integration für den<br />
Einsatz von Computersystemen ist.<br />
171
Ingo Grüll<br />
12.4.1 Ohne Weltmodell<br />
Im Hinblick auf die Software benötigen viele<br />
Anwendungen kein Weltmodell, für sie reicht<br />
es völlig aus, die Datenformate, die Verarbeitungsverfahren<br />
und die Protokolle für die von<br />
ihnen benötigten Ein- und Ausgabezwecke<br />
zu verstehen und einsetzen zu können. Und<br />
im Bereich der digitalen Computertechnik ist<br />
Hardware ohne Softwareunterstützung nicht<br />
wirklich von Interesse, weshalb in dieser Hinsicht<br />
in Hardware gegossene Weltmodelle<br />
keine Rolle spielen.<br />
Generell steht heute für die Ein- und Ausgabe<br />
von Daten die unterschiedlichste Hardware<br />
zur Verfügung. Per Tastatur lassen sich<br />
Zeichen eingeben, Maus und Touchscreen<br />
dienen als Zeigewerkzeuge, per Grafiktablett<br />
lässt sich zeichnen und malen, digitale Kameras<br />
fangen Bilder und Videos ein, der<br />
Rechner kann per Soundkarte Töne und Geräusche<br />
aufzeichnen, der Datenhandschuh<br />
erlaubt die Erfassung von Handbewegungen,<br />
der Laserscanner die von ganzen Gegenständen<br />
in 3D und, und, und ... grundsätzlich<br />
lässt sich dank Analog-Digital-Wandler alles<br />
digitalisieren, was sich in elektrische Spannung<br />
umwandeln lässt - und das ist bis hin zu<br />
<strong>Dr</strong>uck und Beschleunigung oder radioaktiver<br />
Strahlung eine ganze Menge. Einige Sensoren<br />
beziehungsweise Messgeräte sind ohne<br />
Verarbeitung der von ihnen gelieferten Daten<br />
ziemlich nutzlos - die Teilchenphysiker haben<br />
beispielsweise nahezu hausgroße Messgeräte,<br />
die so viele Daten erfassen, daß die<br />
Auswertung von Hand gar nicht mehr möglich<br />
ist.<br />
Auch die Ausgabe von Rechenergebnissen<br />
gestaltet sich vielfältig, sie erledigen Farbbildschirm<br />
oder Videobeamer, oder auch der<br />
<strong>Dr</strong>ucker, wenn man es Schwarz auf Weiß,<br />
beziehungsweise „Rapid Prototyping”, wenn<br />
man es in 3D braucht (Rapid Prototyping<br />
bezeichnet die Erstellung von Werkstücken<br />
aus am Computer erzeugten Entwürfen ohne<br />
speziell an die Form des Werkstücks angepasste<br />
Werkzeuge und Maschinen). Die Soundkarte<br />
verhilft dem Computer zum Prädikat<br />
„nicht schön, aber laut” (zugegeben, das<br />
172<br />
trifft in zunehmenden Maße auch auf PC-<br />
Lüfter zu, aber außer Geräuschen geben die<br />
hauptsächlich heiße Luft aus). Rechner können<br />
Motoren ansteuern und so weiter und so<br />
fort. Allgemein gestattet der Digital-Analog-<br />
Wandler, alles zu steuern, was sich mit elektrischer<br />
Spannung beeinflussen lässt (der<br />
freundliche E-Techniker oder Maschinenbauer<br />
wird Ihnen bestätigen, daß das einiges ist).<br />
Abbildung 99: Die modernsten Grafiktabletts<br />
kombinieren Ein- und Ausgabe<br />
[Gmb02]<br />
Benutzerschnittstellen, also die Verbindung<br />
zwischen Mensch und Computer, sind natürlich<br />
eine wichtige Form von Physical-Virtual<br />
Integration. Die Bedienung einer grafischen<br />
Benutzeroberfläche mittels Maus und Tastatur<br />
verfügt aber über kein oder zumindest<br />
ein vernachlässigbares Weltmodell. Implizit<br />
„weiß” eine GUI, daß es einen oder mehrere<br />
Benutzer gibt und daß Schreibtische, Abfalleimer<br />
und so fort existieren. Aber im Grunde<br />
handelt es sich dabei nur um Metaphern,<br />
die die Bedienung des Computers für den<br />
Menschen vereinfachen. Der Abfalleimer der<br />
GUI ist ein Abbild des Konzeptes des Abfalleimers,<br />
er ist kein Abbild des realen Abfalleimers<br />
des jeweiligen Benutzers. Und der<br />
Computer beobachtet auch nicht den echten<br />
Schreibtisch seines Benutzers, um das dort<br />
herrschende Chaos im Rechner nachzuvollziehen<br />
(Windows fühlt sich zwar manchmal<br />
so an, als ob es das könnte, aber dennoch<br />
gehört das - zum Glück - noch nicht zu seinen<br />
Features).
12.4 Welche Formen von Physical-Virtual Integration sind derzeit möglich?<br />
Eine ebenfalls sehr bekannte Anwendung,<br />
die zwar sehr viel Ein- und Ausgabe aber<br />
kein Weltmodell aufweist, ist der digitale<br />
Videoschnitt. Selbst wenn die Videoströme<br />
komprimiert sind, werden sehr große Datenmengen<br />
in den Rechner transferiert und<br />
der fertig geschnittene Film paßt normalerweise<br />
auch nicht gerade auf eine Diskette -<br />
wobei anzumerken ist, daß dank Kompressionsverfahren<br />
wie MPEG die Datenmenge<br />
nach Vollendung des Schnitts weit kleiner<br />
sein kann als das Ausgangsmaterial. Für<br />
den Schnitt eingesetzte Programme wie Adobe<br />
Premiere weisen praktisch keinerlei Wissen<br />
über die gefilmte Welt auf, sie haben<br />
„keine Ahnung” WAS in den Filmen zu ist.<br />
Ähnlich wie der Videoschnitt verhalten sich<br />
die meisten digitalen Videokonferenzsysteme.<br />
Bei ihnen dienen Computer nur als Bindeglied,<br />
Videobilder werden aufgenommen,<br />
übertragen und beim Gesprächspartner wiedergegeben.<br />
Die eingesetzten Rechner dienen<br />
zum großen Teil dazu, durch Datenkompression<br />
etc. die Videoübertragung zu optimieren.<br />
Abbildung 100: Videoschnitt stellt große Anforderungen<br />
an Ein- und<br />
Ausgabe [Gmb02]<br />
Virtual Reality stellt unter dem Aspekt Weltmodell<br />
eine Art Zwitter dar. Die Subsysteme,<br />
die die dreidimensionale Darstellung der<br />
virtuellen Realität, die Erfassung der Kopfposition<br />
und -bewegungen etc. übernehmen,<br />
verfügen durchaus über ein Modell der Realität,<br />
nämlich darüber, wie beim Menschen<br />
die dreidimensionale Umwelt durch die Augen<br />
wahrgenommen wird, wie sich die Finger<br />
der Hand bewegen können und so weiter.<br />
Aber die künstliche Welt, die diese Subsysteme<br />
für den Menschen erfahrbar machen,<br />
muss nichts mit der wirklichen Welt und insbesondere<br />
nichts mit dem den Benutzer umgebenden<br />
Ausschnitt der Wirklichkeit zu tun<br />
haben. Ein Vorteil der Virtual Reality ist genau<br />
die Eigenschaft, daß sich Welten modellieren<br />
lassen, die real gar nicht möglich<br />
wären. Demzufolge können die Weltmodelle<br />
für die darzustellenden Welten bei der Virtual<br />
Reality beliebig weit weg von der Realität<br />
sein, solange sie für den Benutzer noch<br />
verständlich und benutzbar sind. Die meisten<br />
immersiven Virtual Reality Systeme beschränken<br />
sich auch darauf, den Benutzer<br />
zu beobachten und ignorieren die Umgebung<br />
des Benutzers, da der Teil ihres Weltmodells,<br />
der die Realität nachbildet, sich größtenteils<br />
auf den Benutzer beschränkt (es empfiehlt<br />
sich daher nicht, mit einem undurchsichtigen<br />
Head-Mounted Display durchs Zimmer<br />
zu hüpfen, man kann sich nämlich dabei sehr<br />
reale blaue Flecken einhandeln - durch Gegenstände,<br />
die im Computer nicht repräsentiert<br />
sind) [Rhe95].<br />
Abbildung 101: VR löst Benutzer häufig aus<br />
173
Ingo Grüll<br />
ihrer Umgebung heraus anstatt<br />
sich in diese zu integrieren<br />
[NAS00]<br />
12.4.2 Mit entsprechendem Weltmodell<br />
Schon ein kleines und abstraktes Weltmodell<br />
kann die Herangehensweise an ein Anwendungsgebiet<br />
sehr verändern. In ihrem Artikel<br />
„Informative Things” beschreiben Rob Barrett<br />
und Paul P. Maglio, daß vielen Menschen<br />
der Zugang zu Daten in einem Computer<br />
oder einem Netzwerk über Verzeichnisbäume<br />
und ähnliche Hilfsmittel fremd ist [BM98].<br />
In der Erfahrungswelt vieler Leute sind Informationen<br />
eher an einen Gegenstand gebunden<br />
als in einem körperlosen Informationsraum<br />
zu finden. Kochrezepte findet man in einem<br />
Buch, Gedichte in einem anderen. Und<br />
wenn man Freunden seine Urlaubsfotos zeigen<br />
möchte, greift man zum Fotoalbum und<br />
nimmt es mit. Man hat den Informationsträger<br />
bei sich, wenn man ihn braucht. Barrett<br />
und Maglio entwarfen ein System, das die Informationen<br />
auf dem Rechner belässt, aber<br />
den Zugang zu ihnen an einen realen Gegenstand<br />
bindet. Das kann z.B. auch eine<br />
Diskette sein. Wenn man also als Homo Sapiens<br />
Digitalis seinen Freunden beim Kaffeetrinken<br />
seine Urlaubsbilder zeigen möchte,<br />
schiebt man die entsprechende Diskette ins<br />
Laufwerk ihres Rechners und der stellt selbständig<br />
den Kontakt zum heimischen Server<br />
her und bringt die Fotos auf den Bildschirm,<br />
man muss nicht von Hand den Server anwählen,<br />
sich einloggen und dann die Bilder<br />
auf der Festplatte suchen - das simple Weltmodell<br />
„Informationen sind an Dinge gebunden”<br />
mit einem geeignet programmierten System<br />
nimmt einem diese Arbeit ab. Die Grenze<br />
zu reinen Ein-/Ausgabe-Szenarien ist jedoch<br />
fließend, da das Weltmodell in diesem<br />
Fall geradezu winzig ist. Systeme für andere<br />
Anwendungsgebiete, die man in Bezug<br />
auf ihre Hauptaufgabe eher als ein- und ausgabebasiert<br />
charakterisieren würde, können<br />
durchaus in Teilsystemen über ausgefeiltere<br />
Weltmodelle verfügen. Und ob die Herangehensweise<br />
von Barrett und Maglio - insbe-<br />
174<br />
sondere bei vielen zu unterscheidenden Informationseinheiten<br />
- wirklich die sinnvollste<br />
ist, sei einmal dahingestellt.<br />
Anwendungen, die heute noch ohne Weltmodell<br />
auskommen, könnten schon bald eines<br />
besitzen: Daß Videoschnittprogramme<br />
die Filme, die sie verarbeiten, nicht verstehen,<br />
bedeutet nicht, daß das derzeit grundsätzlich<br />
nicht machbar ist. Spezialanwendungen<br />
können Bilder und Bildsequenzen auf<br />
ihren Inhalt hin analysieren, das setzt jedoch<br />
ein Weltmodell voraus, um überhaupt<br />
zu funktionieren. Das Weltmodell solcher Anwendungen<br />
ist zwar sehr speziell, aber unbedingt<br />
notwendig, um die Objekte erkennen zu<br />
können, die erkannt werden sollen. So haben<br />
Systeme zur Gesichtserkennung (besser gesagt,<br />
Personenunterscheidung anhand der<br />
Gesichter) eine lange Entwicklung durchlaufen,<br />
die dazu führte, daß ihre Datenbasis und<br />
ihre Algorithmen auf den Teil der Realität zugeschnitten<br />
sind, den wir Gesichter nennen.<br />
Das heißt, daß das Weltmodell nicht unbedingt<br />
explizit vorliegt (das System weiß nicht,<br />
was eine Nase ist), aber es ist zumindest implizit<br />
im Programm enthalten, um verschiedene<br />
Bilder einer Person korrekt zu klassifizieren.<br />
Und derartige Systeme können als<br />
Zugangskontrollen an Pforten direkt auf die<br />
reale Welt zurückwirken.
12.4 Welche Formen von Physical-Virtual Integration sind derzeit möglich?<br />
Abbildung 102: Gesichtsmodelle dieser Art<br />
könnten Videokonferenzsysteme<br />
revolutionieren [RS99]<br />
Videokonferenzsysteme können durch ein<br />
Weltmodell stark verbessert werden. Wenn<br />
ein solches System Mimik und Kopfbewegungen<br />
eines Menschen in Echtzeit erkennen<br />
kann und der Teil des Systems beim<br />
Gesprächspartner über ein Modell des Kopfes<br />
der Person am anderen Ende der Leitung<br />
verfügt, ist es nicht mehr nötig, Videobilder<br />
zu übertragen. Stattdessen werden<br />
die erkannte Mimik/Kopfbewegungen gesendet,<br />
mittels derer beim Gesprächspartner ein<br />
künstliches Bild aus dem Modell des Kopfes<br />
generiert wird. Das System kann dadurch,<br />
daß es seine Umwelt beobachtet und sein<br />
internes Modell diesen Beobachtungen anpasst,<br />
mit vergleichsweise lächerlicher Übertragungskapazität<br />
auskommen.<br />
Sehr hoher Aufwand für die Entwicklung von<br />
Weltmodellen wird im Bereich der Simulation<br />
getrieben, doch die Aspekte der Beobachtung<br />
und Rückwirkung der modellierten Welt<br />
sind oft sehr gering ausgeprägt beziehungsweise<br />
nur indirekt vorhanden. Ein System<br />
zur Simulation von Atombombenexplosionen<br />
mag zwar über ein präzises physikalisches<br />
Modell von spaltbarem Material verfügen, es<br />
beobachtet jedoch seine Umgebung nicht.<br />
Und die Rückwirkungen auf die reale Welt<br />
halten sich ebenfalls in Grenzen (die Simulation<br />
alleine hinterlässt glücklicherweise keine<br />
radioaktiven Krater; allerdings lassen sich<br />
die Ergebnisse zum Bau von Kernwaffen verwenden,<br />
somit kann die Simulation indirekt<br />
doch wieder „landschaftsgestaltend” wirken).<br />
Doch es gibt auch Simulationen, die enger<br />
an die Realität angebunden sind, zum Beispiel<br />
die Simulationen zur Wettervorhersage.<br />
Hier werden relativ aktuelle Daten zumindest<br />
teilweise automatisch erfasst und die Simulationsergebnisse<br />
liegen zeitig genug vor,<br />
um für viele Menschen von Interesse zu sein<br />
und damit auch das Verhalten vieler Menschen<br />
direkt zu beeinflussen. Falsche Wettervorhersagen<br />
belegen aber auch, daß das<br />
Abbild der realen Welt im Rechner von der<br />
Realität ein ganzes Stück weit entfernt sein<br />
kann, und das insbesondere auch gerade in<br />
dem Bereich, für den das System überhaupt<br />
entwickelt wurde.<br />
Abbildung 103: Simulationen modellieren<br />
häufig die Realität, ohne<br />
direkt auf sie zurückzuwirken<br />
[Cor91a]<br />
Das Paradebeispiel für Physical-Virtual Integration<br />
sind Anlagensteuerungen von Fabriken.<br />
Denn solch eine Anlagensteuerung ist<br />
dafür gebaut, einen bestimmten Teil der realen<br />
Welt sehr genau zu beobachten UND auf<br />
ihn einzuwirken. Reaktionen auf Zustandsveränderungen<br />
der Anlage erfolgen notgedrungen<br />
in Echtzeit. Und zumindest ein rudimentäres<br />
Weltmodell ist ebenfalls gegeben.<br />
Ein PC kann einen Pufferüberlauf ignorieren,<br />
aber die Steuerung, die einem <strong>Dr</strong>uckanstieg<br />
in einer chemischen Fabrik tatenlos zusieht,<br />
steuert diese Fabrik nicht mehr lange.<br />
Anders ausgedrückt, eine Anlagensteuerung<br />
sollte nicht nur die Zustände kennen, die erwünscht<br />
sind, sondern auch die, die es zu<br />
vermeiden gilt. Sie sollte darüber hinaus in<br />
der Lage sein, zu erkennen, wenn sich die zu<br />
steuernde Anlage auf einen ungewünschten<br />
Zustand zubewegt, und entsprechende Gegenmaßnahmen<br />
einleiten. Die Weltmodelle<br />
solcher Fabriksteuerungen sind allerdings<br />
noch durchaus verbesserungsfähig. Häufig<br />
175
Ingo Grüll<br />
werden Objekte ignoriert, die weder Werkstück<br />
noch Bestandteil der Maschinen sind<br />
(und es kann für einen Fabrikarbeiter ziemlich<br />
unangenehm werden, wenn ein Industrieroboter<br />
versucht, durch ihn hindurchzugreifen).<br />
In dem Maße, in dem die Weltmodelle<br />
verbessert werden, steigt die Fähigkeit<br />
der Steuerungsanlagen, auf unvorhergesehene<br />
Ereignisse und Zustände zu reagieren.<br />
Abbildung 104: Kein guter Ort für Dinge, die<br />
im System nicht repräsentiert<br />
sind [Lim02]<br />
Vorwiegend passive Systeme können gleichfalls<br />
über ein sehr ausgefeiltes Weltmodell<br />
verfügen. Expertensysteme, deren Weltmodell<br />
meist explizit vorliegt, werden häufig in<br />
Einsatzgebieten verwendet, in denen Fehlentscheidungen<br />
schwerwiegende (z.B. in der<br />
Medizin) oder zumindest kostspielige Folgen<br />
(z.B. in der erdöl- und erdgasfördernden Industrie)<br />
haben. Daher wird von den Entwicklern<br />
solcher Systeme die Integration mit der<br />
Umwelt bewußt auf ein bestimmtes Maß begrenzt,<br />
Expertensysteme werden meist als<br />
„Berater” von menschlichen Experten eingesetzt,<br />
die sowohl die Eingabedaten für das<br />
System aufbereiten als auch die endgültige<br />
Interpretation der verarbeiteten Daten vornehmen.<br />
Augmented Reality und Mixed Reality Systeme<br />
gehen oft über vergleichbare Virtual<br />
Reality Systeme hinaus (vereinfachend betrachtet<br />
kann der Benutzer bei Mixed Reality<br />
seine Umgebung durch die Ausgaben des<br />
Rechners hindurch sehen und bei Augmented<br />
Reality beziehen sich diese Ausgaben<br />
176<br />
auf die Umgebung, die sie überlagern), und<br />
das auch im Bereich ihrer Weltmodelle. Sie<br />
erfassen bevorzugt den Bereich der Realität,<br />
den auch ihr Benutzer beobachtet, und passen<br />
Objekte und Informationen daran an, sowie<br />
die Ausgabe in die Umwelt ein. So ist es<br />
beispielsweise möglich, daß ein solches System<br />
einen realen Gegenstand erkennt und<br />
Veränderungen seiner Position und Ausrichtung<br />
auf virtuelle Gegenstände überträgt. Die<br />
DaimlerChrysler-Forschung in <strong>Ulm</strong> verwendet<br />
ein derartiges System, das virtuelle Motorblöcke<br />
an realen ausrichtet, die über eine<br />
Kamera am Kopf des Benutzers erfasst<br />
werden. Eine Videobrille erlaubt dem Benutzer,<br />
den virtuellen Motorblock in einer realen<br />
Umgebung zu sehen. Ein denkbarer Anwendungsfall<br />
für dieses System wären Reparaturen<br />
am Auto, bei denen Informationen zu den<br />
zu reparierenden Teilen oder dem Reparaturvorgang<br />
selbst vom Computer an passender<br />
Stelle präsentiert wird. Außer DaimlerChrysler<br />
arbeiten auch noch weitere Institutionen,<br />
etwa das amerikanische Militär, an Systemen<br />
für dieses oder ähnliche Anwendungsszenarien.<br />
Ein anderes Beispiel aus der Forschung ist<br />
das von Canon entwickelte „Contact Water”<br />
[Can01]. Ein Benutzer erhält einen Sensor an<br />
seiner Hand als Eingabegerät und als Ausgabegerät<br />
ein Head-Mounted Display, das Bilder<br />
der Umgebung zu den Augen des Benutzers<br />
durchlässt. Das System stellt auf der<br />
nach oben gerichteten Handfläche des Benutzers<br />
eine Wasserfläche dar und ermöglicht<br />
ihm, Tierfiguren im Wasser, wie z.B.<br />
einen Delphin, einen Orca oder einen Beluga,<br />
mit Handbewegungen aus dem Wasser<br />
herauszukatapultieren und wieder einzufangen.<br />
Es lässt sich auch ein feststehendes virtuelles<br />
Wasserbassin über einen realen Gegenstand<br />
in der unmittelbaren Umgebung legen.<br />
Mehrere Benutzer können miteinander<br />
interagieren und sich ihre Tierfiguren gegenseitig<br />
zuwerfen (wenn man mal danebenwirft,<br />
verschwindet das betroffene Tier einfach).<br />
Contact Water verfügt zur Ausübung seiner<br />
Funktion über ein gewisses Weltwissen. Mit<br />
einer normalen Computermaus kann man<br />
zwar auch einen Cursor bewegen (also ein
12.4 Welche Formen von Physical-Virtual Integration sind derzeit möglich?<br />
reales und ein virtuelles Objekt miteinander<br />
koppeln), aber Contact Water geht darüber<br />
hinaus, da es die Bewegungen der<br />
Wasserfläche nicht nur auf einem Bildschirm<br />
mit den Bewegungen der Hand synchronisiert,<br />
sondern über das Head-Mounted Display<br />
das Bild der Wasserfläche an der den<br />
Erfahrungen und den optischen Gesetzen<br />
entsprechenden Position wieder in die reale<br />
Welt einfügt. Außerdem folgt das Verhalten<br />
der Tierfiguren beim Werfen einigermaßen<br />
der Schwerkraft und der Trägheit der<br />
physischen Welt. Die Integration beider Welten<br />
wird durch die Modellierung der virtuellen<br />
Welt nach Gesetzmäßigkeiten der realen<br />
Welt für den Benutzer viel intensiver.<br />
Abbildung 105: Aus der Sicht eines Benutzers<br />
sieht Contact Water in<br />
Aktion so aus [Can01]<br />
Ein interessanter Mixed-Reality-Forschungsprototyp<br />
aus dem Bereich Architektur ist die<br />
Urban Planning Workbench, kurz Urp [UI99].<br />
Ihre virtuelle Welt verfügt über Regeln, um<br />
Effekte wie den Schattenwurf von Gebäuden<br />
oder Luftbewegungen zwischen Gebäuden<br />
und um sie herum zu simulieren. Das<br />
ist jedoch nicht der einzige Ausschnitt der<br />
Realität, der modelliert wurde, auch die Interaktion<br />
der Benutzer mit dem System geht<br />
über herkömmliche Methoden hinaus. Die Simulationsergebnisse<br />
werden auf einen Tisch<br />
projiziert und die Bedienung erfolgt unter anderem<br />
über physische Modelle, die von den<br />
Benutzern auf diesem Tisch, mithin direkt in<br />
der Abbildung des inneren Zustands des Sy-<br />
stems, bewegt werden können. Das System<br />
erkennt diese realen Gegenstände und verschiebt<br />
die durch sie repräsentierten Gebäude<br />
entsprechend innerhalb der simulierten<br />
Welt und startet eine erneute Simulation unter<br />
den veränderten Bedingungen. Hiroshi Ishii,<br />
einer der Entwicklung von Urp beteiligten<br />
Forscher, war ursprünglich auf dem Gebiet<br />
der Virtuellen Realität tätig. Um eine verbesserte<br />
Integration in die Erfahrungswelt und<br />
damit die Umgebung der Benutzer zu erreichen,<br />
beschäftigt er sich aber mittlerweile mit<br />
„Tangible Bits”: Sie sollen die Welt im Rechner<br />
„begreifbar” machen, indem sie sie an<br />
Gegenstände koppeln, die die Benutzer aus<br />
ihrem Alltag kennen [tmg02].<br />
Shinkuro Honda, Hironari Tomioka, Takaaki<br />
Kimura, Takaharu Ohsawa, Kenichi Okada<br />
und Yutaka Matsushita haben ein virtuelles<br />
Büro erdacht, das mehrere real existierende<br />
Arbeitsplätze - dies könnten beispielsweise<br />
Heimarbeitsplätze von Telearbeitern sein - so<br />
über Rechner vereinigt, daß man als Arbeiter<br />
in diesem Büro sich sowohl seiner Mitarbeiter<br />
bewußt sein kann als auch sich auf seine<br />
Arbeit konzentrieren kann, denn das System<br />
überträgt bzw. erzeugt Geräusche und<br />
Bewegtbilder, die anzeigen, was die Mitarbeiter<br />
gerade machen [HTK 97]. Der Clou<br />
ist, daß im System verankert ist, daß auf die<br />
eigene Arbeit konzentrierte Menschen ihre<br />
sonstige Umgebung ignorieren. Es beobachtet<br />
seine Benutzer, um festzustellen, wie bewußt<br />
sie sich ihrer Umgebung im Moment<br />
sind und schwächt die Signale von den Mitarbeitern<br />
entsprechend ab. Erstaunlicherweise<br />
lässt sich an den Mustern, wie ein Benutzer<br />
seinen Stuhl bewegt (besser gesagt,<br />
wie häufig und wie stark er ihn um seine<br />
Mittelsäule dreht), sein Grad an Konzentration<br />
ablesen. Ein Benutzer muss also weder<br />
manuell einstellen, wieviel er aus dem virtuellen<br />
Büro im Moment mitbekommen möchte,<br />
noch muss er irgendwelche störende Eingabehardware<br />
am Körper tragen, um dem<br />
System zu ermöglichen, seinen Konzentrationsgrad<br />
zu bestimmen. Das virtuelle Büro<br />
ist übrigens dreidimensional, Signale von<br />
„weiter entfernten” Mitarbeitern werden stärker<br />
abgeschwächt als die von „näheren” Kol-<br />
177
Ingo Grüll<br />
legen. Und ein Benutzer kann sich anderen<br />
Benutzern zuwenden, wiederum durch <strong>Dr</strong>ehung<br />
seines Stuhles.<br />
Unter dem Stichwort „Affective Computing”<br />
befassen sich die Forscherinnen Rosalind<br />
W. Picard und Jennifer Healey unter anderem<br />
damit, den Gefühlszustand des Benutzers<br />
zu ermitteln [Gro01, Foe97]. Durch<br />
Messung von Hautwiderstand, Anspannung<br />
der Gesichtsmuskulatur, Puls, Blutdruck,<br />
Körpertemperatur und Atmung lässt sich<br />
die Gefühlslage eines Menschen zumindest<br />
im Wesentlichen ermitteln, allerdings sind<br />
die den jeweiligen Emotionen zugeordneten<br />
Messwerte von Person zu Person verschieden.<br />
Die besten Ergebnisse erhält man,<br />
wenn das System auf den jeweiligen Benutzer<br />
trainiert wird. Personal Computerïst<br />
hierbei wörtlich zu nehmen, das System beobachtet<br />
seinen Benutzer genau und kann,<br />
je nach Anwendung entsprechend programmiert,<br />
seine Ausgaben an dessen momentane<br />
Laune anpassen (so ist es zum Beispiel<br />
möglich, Rückmeldungen zu geben, wenn<br />
der Anwender bei einer längeren Aktion des<br />
Rechners anfängt, ungeduldig zu werden.<br />
Oder man kann eine Stereoanlage bauen,<br />
die von sich aus auf ein neues Lied wechselt,<br />
wenn sie feststellt, daß dem Benutzer der gerade<br />
gespielte Song nicht gefällt).<br />
12.5 Was bringt die Zukunft?<br />
Da meine Kristallkugel gerade in der Reinigung<br />
ist und ich mich mit Astrologie nicht so<br />
sonderlich auskenne, ist dieser Abschnitt im<br />
zum vorigen eher vage. Der geneigte Leser<br />
möge verzeihen, wenn hier auch Aussagen<br />
vorkommen, die er als allgemein bekannt ansieht.<br />
12.5.1 Entwicklung der Hardware<br />
In Bezug auf die Verbesserung der Rechenleistung<br />
ist zumindest für die nächsten<br />
zehn Jahre kein Ende abzusehen. Schnellere<br />
Rechner ermöglichen Systeme mit umfangreicherem<br />
Weltmodelle bei gleichblei-<br />
178<br />
benden Reaktionszeiten oder mit schnelleren<br />
Reaktionszeiten bei gleichbleibender<br />
Komplexität des Weltmodells. Zusätzlich erlauben<br />
sie die Verarbeitung umfangreicherer<br />
Eingaben und die Erzeugung ausgefeilterer<br />
Ausgaben (die Grafikbeschleuniger sind<br />
hierfür ein gutes Beispiel; in einigen Jahren<br />
dürften wir auf unseren Bildschirmen Computeranimationen<br />
sehen, die in ihrer Qualität<br />
denen, die wir heute im Kino betrachten,<br />
in nichts nachstehen werden). Contact Water<br />
beispielsweise könnte mit mehr Rechenleistung<br />
die Stellung der Hand ohne Sensor<br />
an der Hand sondern stattdessen über Videobildanalyse<br />
erkennen und grafisch ausgefeilteres<br />
Wasser darstellen.<br />
Abbildung 106: Contact Water deLuxe<br />
[Can01]<br />
Ausgefallenere Sensoren beziehungsweise<br />
Eingabehardware wird ihren Weg in die Praxis<br />
finden, hier ist jedoch mit deutlichen Wartezeiten<br />
zu rechnen, da die momentan in der<br />
Forschung verfügbaren Eingabegeräte nicht<br />
unbedingt robust genug für den Alltagseinsatz<br />
und preiswert genug für die Massenproduktion<br />
sind. Es ist durchaus damit zu<br />
rechnen, daß dabei Jahrzehnte und nicht nur
Jahre vergehen. So schnellebig die Informatik<br />
auch ist, der Wissenstransfer braucht vergleichsweise<br />
lange. Das gilt natürlich auch<br />
für Ausgabehardware, aber was Verbesserungen<br />
bereits eingeführter Ausgabetechniken<br />
anbelangt, ist mit schnelleren Ergebnissen<br />
zu rechnen. So ist davon auszugehen,<br />
daß innerhalb der nächsten Jahre Systeme<br />
zur Einspiegelung von Grafiken in die Brille<br />
oder direkt in die Augen in auch für Privatanwender<br />
bezahlbare Regionen gelangen<br />
werden. Sollte dies auf Basis von Lasertechnologie<br />
geschehen, ist sogar vergleichsweise<br />
gute Qualität, sprich deutlich höhere Auflösung<br />
als VGA, zu erwarten. Ausgabehardware<br />
dürfte auch insofern einfacher zu perfektionieren<br />
sein, als bekannte Daten aus<br />
dem Rechner in die Umwelt überführt werden<br />
müssen, während die Eingabeseite unbekannte<br />
Daten aus der Umwelt erfassen<br />
und dem Rechner verfügbar machen muss.<br />
Neuartige Materialien und Bauweisen werden<br />
sehr dazu beitragen, Computerhardware<br />
allgegenwärtig werden zu lassen. Derzeit<br />
ist die Hardwarevoraussetzung für Ubiquitous<br />
Computing der Einbau von Chips in die<br />
betroffenen Gegenstände. In Zukunft könnte<br />
die Computerhardware über diese Art der<br />
Einbettung hinauswachsen, wenn das Material,<br />
aus dem ein Gegenstand gefertigt wird,<br />
selbst zu Berechnungen in der Lage ist. So<br />
ist es derzeit schon möglich, elektronische<br />
Schaltkreise auf Plastik aufzudrucken und es<br />
gibt auch schon leitfähiges Plastik. In Zukunft<br />
müsste man in einen Gegenstand aus Plastik<br />
keinen Chip mehr einbauen, das Plastik<br />
wird dessen Funktionen übernehmen. Auch<br />
im Bereich Wearable Computing wird intensiv<br />
daran gearbeitet, den Stoff, aus dem Kleidungsstücke<br />
geschneidert werden, zur Computerkomponente<br />
aufzuwerten (so gibt es<br />
bereits leitfähige Textilien [Bli01]).<br />
Darüber hinaus würden andere Bauweisen,<br />
wie z.B. komplett optisch arbeitende Computer<br />
es ermöglichen, auch unter extremen<br />
Bedingungen (wie z.B. großer Hitze) zu arbeiten,<br />
die herkömmliche Halbleiterbausteine<br />
nicht ertragen können.<br />
12.5 Was bringt die Zukunft?<br />
Abbildung 107: Alan MacDiarmid entwickelte<br />
leitende Polymere (die Folien<br />
sind aus Polyanilin, die<br />
rechte ist dotiert und leitfähig)<br />
[Cor91b]<br />
12.5.2 Entwicklung der Software<br />
Eine besondere Art der Physical-Virtual Integration,<br />
an der seit langem heftig geforscht<br />
wird, ist die Künstliche Intelligenz [Kur93].<br />
Ein System, das in der Lage wäre, den<br />
Turing-Test zu bestehen, müsste vermutlich<br />
über ein enormes Weltwissen, sprich ein extrem<br />
ausgefeiltes Weltmodell, verfügen. Allerdings<br />
wäre das nicht nur eine Form von<br />
Physical-Virtual Integration, sondern auch eine<br />
Form von Virtual-Virtual Integration, also<br />
eine Verbindung des Weltmodells im Computer<br />
mit dem Weltmodell im Kopf des Benutzers.<br />
Um im Gespräch mit beliebigen Menschen<br />
wirklich bestehen zu können, muss<br />
das System in der Lage sein, sich zumindest<br />
teilweise in die Gedankenwelt seiner Gesprächspartner<br />
hineinzuversetzen und möglichst<br />
auch deren Gefühle nachvollziehen<br />
können. Nachvollziehen geht jedoch über<br />
das bloße Ermitteln des momentanen Gefühlszustandes<br />
hinaus: Ein langfristiges Ziel<br />
von Affective Computing ist die Entwicklung<br />
von Maschinen beziehungsweise Software<br />
179
Ingo Grüll<br />
mit eigenen Gefühlen, das Gebiet ist also<br />
eng mit der Künstlichen Intelligenz verzahnt.<br />
Doch es ist ungewiss ob es jemals derartige<br />
Computer mit richtigen Gefühlen und menschenähnlicher<br />
Intelligenz geben wird. Zumindest<br />
werden wir noch lange Zeit darauf<br />
warten müssen.<br />
Was uns aber schon in naher Zukunft erwartet,<br />
ist die zunehmende Verwendung von<br />
Methoden aus der Fachrichtung der Künstlichen<br />
Intelligenz im Bereich Physical-Virtual<br />
Integration. Computer, die ihre Umwelt beobachten<br />
und ihren Zustand daran anpassen<br />
sind zwar schön und gut, richtig interessant<br />
wird Ubiquitous Computing aber erst, wenn<br />
die Computer beginnen, zu verstehen, was<br />
sie beobachten. Und gerade die Verbindung<br />
von Wearable und Affective Computing verspricht,<br />
schon bald Früchte zu tragen, da die<br />
für Affective Computing benötigten Sensoren<br />
unauffällig und vor allem für den Träger einigermaßen<br />
unaufdringlich in die Kleidung integriert<br />
werden können.<br />
Abbildung 108: Computer und Sensoren<br />
„verschwinden” in der Jacke<br />
- ideal für Affective Computing<br />
[Bli01]<br />
Vermutlich ist auch mit einer weiteren Verbreitung<br />
von Expertensystemen oder besser<br />
gesagt mit einer weiten Verbreitung der Einbettung<br />
von Expertensysteme im Rahmen<br />
von Physical Virtual Integration zu rechnen.<br />
Denn die Erstellung von expliziten Weltmodellen<br />
ist bei Expertensystemen schon länger<br />
üblich. Die dabei gewonnenen Erkenntnisse<br />
und Erfahrungen dürften auch bei Sy-<br />
180<br />
stemen von Nutzen sein, die sehr viel stärker<br />
in ihre reale Umgebung integriert sind<br />
als dies bei Expertensystemen üblicherweise<br />
der Fall ist.<br />
12.5.3 Entwicklung der Anwendungen<br />
Gerade Ubiquitous Computing wird von immer<br />
ausgefeilteren Weltmodellen profitieren.<br />
Nehmen wir das Beispiel der Location Based<br />
Services. Heute ist es bereits möglich, Informationen<br />
an Koordinaten der realen Welt zu<br />
knüpfen, die sich an den jeweiligen Koordinaten<br />
oder im Umkreis davon mit geeigneten<br />
Endgeräten abrufen lassen. Zum Teil lässt<br />
sich diese Information schon heute an einzelnen<br />
Objekten festmachen. So wäre es möglich,<br />
Leuten, die auf dem Münsterplatz in <strong>Ulm</strong><br />
stehen und in Richtung Münster schauen, Informationen<br />
darüber zu geben. Wenn sich<br />
aber jemand mit einer Person unterhält, die<br />
zufälligerweise vor dem Münster steht, dürfte<br />
er diese Information nicht wünschen. Mit verbesserter<br />
Mustererkennung könnte ein zukünftiges<br />
System erkennen, was sein Benutzer<br />
gerade betrachtet, und nur dazu Informationen<br />
geben. Ein derartiger Location Based<br />
Service könnte innerhalb <strong>Ulm</strong>s sogar zu Souveniren<br />
in Form des Münsters die Informationen<br />
über das Münster geben. Ein flexibles<br />
System dieser Art liegt allerdings angesichts<br />
der derzeitigen Leistungen von Computern<br />
auf dem Gebiet der Bilderkennung noch in<br />
weiter Ferne.<br />
Möglicherweise werden einige Anwendungen<br />
für Wearable Computing schon vorher<br />
durch analoge Anwendungen intelligenter<br />
Zimmer vorweggenommen [Pen96]. Zimmer<br />
und Kleidungsstücke haben nämlich eines<br />
gemeinsam: Menschen halten sich in ihnen<br />
auf. Intelligente Zimmer können zwar mehrere<br />
Benutzer gleichzeitig aufweisen (was bei<br />
intelligenter Kleidung normalerweise nicht<br />
der Fall sein dürfte), aber wenn es sich um<br />
private Räume handelt, werden sie genauso<br />
persönlich werden können wie ein Kleidungsstück.<br />
Und da sich in einem Zimmer<br />
größere und leistungsfähigere Hardware unterbringen<br />
lässt, die dann ausgefeiltere Soft-
ware ausführen kann, lassen sich gleichartige<br />
Anwendungen in dieser Hinsicht einfacher<br />
und früher für intelligente Zimmer realisieren.<br />
Es ist sogar wahrscheinlich, daß die<br />
beiden miteinander verbunden werden, zumindest<br />
für Affective Computing bietet sich<br />
das an. Hierbei könnte die Kleidung die Laune<br />
des Trägers identifizieren und sie an das<br />
Zimmer übermitteln, das entsprechend reagiert.<br />
Mögliche Anwendungen reichen von<br />
sich selbst regelnden Heizungen über die<br />
bereits erwähnte persönliche Stereoanlage<br />
bis hin zum Anrufbeantworter, der nicht nur<br />
weiß, wen er durchstellen darf, sondern auch<br />
nachvollziehen kann, wann er das tun darf,<br />
unter Berücksichtigung des Gemütszustandes<br />
des Angerufenen und des Anrufers.<br />
Voraussagen über sich in Zukunft aus der<br />
Entwicklung von Hard- und Software in Bezug<br />
auf Physical-Virtual Integration ergebende<br />
neuartige Anwendungen sind noch ungewisser<br />
als Voraussagen über die zukünftige<br />
Entwicklung der Hard- und Software für<br />
sich. Denn selbst wenn sich letztere so verändern,<br />
wie vorausgesehen (was wohl auch<br />
nur zum Teil der Fall sein wird), ist noch lange<br />
nicht gesagt, daß absehbare Anwendungsmöglichkeiten<br />
auch wirklich von den Benutzern<br />
akzeptiert werden beziehungsweise<br />
überhaupt den erwarteten Nutzen erbringen.<br />
Und es wird garantiert wichtige und weitverbreitete<br />
Anwendungen geben, die sich jetzt<br />
noch gar nicht absehen lassen - was zumindest<br />
die Voraussage erlaubt, daß das Feld<br />
Physical-Virtual Integration auch und gerade<br />
im Bereich Ubiquitous Computing noch<br />
für lange Zeit interessant bleiben wird. Zum<br />
Abschluß wage ich sogar die Behauptung,<br />
daß man als Entwickler für Ubiquitous Com-<br />
Literatur<br />
puting nicht nur die entsprechende Fachliteratur,<br />
sondern unbedingt auch Science Fiction<br />
lesen sollte. Denn einige der momentan<br />
eher abgefahren erscheinenden Ideen aus<br />
der Science Fiction können als Grundlage<br />
für die Entwicklung zukünftiger Anwendungen<br />
dienen, sobald Hard- und Software einen<br />
Entwicklungsstand erreicht haben, der die<br />
Ideen technisch möglich macht. Und bei guten<br />
Science Fiction Autoren wird man gleich<br />
noch einige der positiven und negativen Auswirkungen<br />
finden, die sich aus der Realisierung<br />
der jeweiligen Idee ergeben könnten.<br />
Abbildung 109: Das System erfasst Benutzer<br />
und ermöglicht, mit virtuellen<br />
Objekten zu interagieren<br />
[Pen96]<br />
[Abo99] Gregory D. Abowd: Mobile and Ubiquitous Computing Reading List. http:<br />
//c2000.cc.gatech.edu/classes/cs8113c_99_spring/readings/<br />
overview% .html, 1999.<br />
[Bli01] Ralf Blittkowsky: Kommunikative Klamotten. c’t, 15/2001, S. 84.<br />
181
Literatur<br />
[BM98] Rob Barrett und Paul P. Maglio: Informative things: How to attach information<br />
to the real world. In UIST’98. UIST Conference Proceedings, San Francisco,<br />
California, USA, 1998.<br />
[Can01] Inc. Canon: Contact Water. http://www.mr-system.co.jp/canon-mr/<br />
contact-water/index.html, 2001.<br />
[Cle91] Alan Clements: The Principles of Computer Hardware (Second Edition). Oxford<br />
University Press, 1991.<br />
[Cor91a] Elizabeth Corcoran: Spektrum der Wissenschaft - Sonderheft 11: Das Billionending,<br />
1991.<br />
[Cor91b] Elizabeth Corcoran: Spektrum der Wissenschaft - Sonderheft 11: Nanotechnik,<br />
1991.<br />
[Foe97] Anne Foerst: Feel the Difference. c’t, 8/1997, S. 116.<br />
[FS99] Paul Freiberger und Michael Swaine: fire in the valley by freiberger and swaine.<br />
http://www.fireinthevalley.com/, 1999.<br />
[Gmb02] Wacom Europe GmbH: WACOM | Home. http://www.wacom-europe.com/<br />
de/index.asp, 2002.<br />
[Gro01] Affective Computing Research Group: Affective Computing Homepage. http:/<br />
/affect.media.mit.edu/AC_affect.html, 2001.<br />
[HTK 97] Shinkuro Honda, Hironari Tomioka, Takaaki Kimura, Takaharu Ohsawa, Kenichi<br />
Okada und Yutaka Matsushita: A virtual office environment based on a shared<br />
room realizing awareness space and transmitting awareness information. In<br />
UIST’97. UIST Conference Proceedings, Banff, Alberta, Canada, 1997.<br />
[Kur93] Raymond Kurzweil: Das Zeitalter der Künstlichen Intelligenz. Carl Hanser Verlag,<br />
1993.<br />
[Lim02] Smart Media Group Limited: robotics-technology.com - Robots. http://www.<br />
robotics-technology.com/robots/reis/index.html, 2002.<br />
[NAS00] Johnson Space Center / NASA: JSC Digital Image Collection - STS61. http://<br />
images.jsc.nasa.gov/iams/html/pao/STS61.htm, 2000.<br />
[Pen96] Alex P. Pentland: Intelligente Zimmer. Spektrum der Wissenschaft, 6/1996, S.<br />
44–51.<br />
[Rhe95] Howard Rheingold: Virtuelle Welten - Reisen im Cyberspace. Rowohlt Taschenbuchverlag,<br />
1995.<br />
[RS99] Community Research und Development Information Service: VIDAS: Video Assisted<br />
Audio Coding and Representation. http://www.cordis.lu/infowin/<br />
acts/analysys/products/thematic/mpeg4/vid% as/vidas.htm,<br />
1999.<br />
[Swa93] Doron D. Swade: Der mechanische Computer des Charles Babbage. Spektrum<br />
der Wissenschaft, 4/1993, S. 78–84.<br />
[TL86] Redaktion Time-Life, Hrsg.: Grundlagen der Computertechnik. Time-Life Bücher,<br />
1986.<br />
[tmg02] tangible media group: tangible media group. http://tangible.media.mit.<br />
edu, 2002.<br />
[UI99] John Underkofler und Hiroshi Ishii: Urp: A luminous-tangible workbench for urban<br />
planning and design. In Human Factors in Computing Systems. CHI Conference<br />
Proceedings, Pittsburgh, PA, USA, 1999.<br />
182