DPArchiv.0099

Diplomarbeit
Location Sensing für
ortsabhängige Dienste auf
Basis von Web-Services
Tino Fleuren
Juli 2004
Betreuer: Prof. Dr. Paul Müller
Dipl. Inform. Markus Hillenbrand
Fachbereich Informatik
AG Integrierte Kommunikationssysteme
TU Kaiserslautern - Postfach 3049 - 67653 Kaiserslautern
Kurzfassung
Eine Hauptaufgabe von ortsabhängigen Systemen ist die Erfassung des Aufenthaltsortes
einer Person und die Ermittlung der physikalischen Ressourcen und der Software
Dienste in ihrer Nähe, um maßgeschneiderte und nutzerabhängige Dienste bereitstellen
zu können. Für ortsbewusste Applikationen ist ein Positionsdienst wünschenswert, der
standardisierte
Positionsinformationen
anbieten
kann,
mehrere
Lokalisierungs-
technologien gleichzeitig einsetzt und damit zum Beispiel innerhalb und außerhalb von
Gebäuden operieren kann. Außerdem sollte ein solcher Positionsdienst - transparent für
die Applikation - die Steuerung und den Übergang von einer Technik zur nächsten
übernehmen. Ist dieser Positionsdienst auf Basis von Web-Services realisiert, so
ermöglicht er einen standardisierten Zugriff auf von Diensten bereitgestellten
Operationen mittels einer Kommunikation zwischen heterogenen Plattformen. Ziel
dieser Arbeit ist es einen solchen Positionsdienst zu modellieren und zu entwickeln.
Ich versichere, dass ich die vorliegende Diplomarbeit selbstständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Tino Fleuren
1
2
EINLEITUNG ......................................................................................................... 1
1.1
MOTIVATION ...................................................................................................... 1
1.2
AUFGABENSTELLUNG DER DIPLOMARBEIT ........................................................ 3
1.3
ANFORDERUNGEN AN DEN POSITIONSDIENST ..................................................... 3
1.4
AUFBAU DIESER ARBEIT .................................................................................... 4
GRUNDLAGEN DER LOKALISIERUNG ......................................................... 5
2.1
POSITIONIERUNGSMODELLE ............................................................................... 5
2.1.1
Geometrische Positionierungsmodelle...................................................... 5
2.1.2
Symbolische Positionierungsmodelle ........................................................ 9
2.1.3
Bezeichnungen......................................................................................... 12
2.1.4
Kombinationen von Positionierungsmodellen ........................................ 13
2.2
LOKALISIERUNGSTECHNIKEN ........................................................................... 14
2.2.1
Triangulation .......................................................................................... 14
2.2.2
Analyse des Ortes .................................................................................... 18
2.2.3
Näherungsmessung ................................................................................. 19
2.3
3
SENSOR-FUSION ............................................................................................... 20
LOKALISIERUNGSSYSTEME ......................................................................... 23
3.1
VERGLEICHSKRITERIEN .................................................................................... 23
3.2
SATELLITENGESTÜTZTE LOKALISIERUNGSSYSTEME ........................................ 26
3.2.1
GPS ......................................................................................................... 26
3.2.2
Differential GPS ...................................................................................... 31
3.2.3
GLONASS................................................................................................ 32
3.2.4
3.3
GALILEO ................................................................................................ 32
ZELLFUNKNETZGESTÜTZTE LOKALISIERUNGSSYSTEME ................................... 33
3.3.1
Cell ID ..................................................................................................... 33
3.3.2
Enhanced Observed Time Difference (E-OTD) ...................................... 34
3.3.3
Wireless Assisted GPS (A-GPS) .............................................................. 35
3.4
4
INDOOR LOKALISIERUNGSSYSTEME ................................................................. 36
3.4.1
Active Badge System ............................................................................... 36
3.4.2
Active Bat System .................................................................................... 37
3.4.3
Cricket ..................................................................................................... 39
3.4.4
RADAR .................................................................................................... 40
3.4.5
Smart Floor ............................................................................................. 42
MODELLIERUNG DES POSITIONSDIENSTES............................................ 45
4.1
HAUPTKOMPONENTEN ..................................................................................... 45
4.2
POSITIONIERUNGSMODELL ............................................................................... 49
4.2.1
Geometrisches Modell ............................................................................. 49
4.2.2
Symbolisches Modell ............................................................................... 50
4.2.3
Logisches Gebiet ..................................................................................... 51
4.2.4
Lokalisierbares Objekt ............................................................................ 53
4.2.5
Inklusion eines lokalisierbaren Objektes in einem logischen Gebiet...... 54
4.3
KOMPONENTENBESCHREIBUNG ........................................................................ 56
4.3.1
Location-Sensing-Device ........................................................................ 57
4.3.2
Position-Service-Engine.......................................................................... 60
5
4.3.3
Position-Service-Engine und LSDevice der Infrastruktur ...................... 64
4.3.4
Position-Web-Service .............................................................................. 64
REALISIERUNG .................................................................................................. 69
5.1
VORGABEN....................................................................................................... 69
5.2
TECHNISCHE GRUNDLAGEN ............................................................................. 69
5.2.1
Holux GM-200 Smart GPS-Empfänger .................................................. 69
5.2.2
Serielle Schnittstelle ................................................................................ 70
5.2.3
Java Web-Service Development Pack ..................................................... 70
5.3
PROTOTYPISCHE IMPLEMENTIERUNG ............................................................... 71
5.3.1
Die Hilfsklassen ...................................................................................... 72
5.3.2
Die Position Engine ................................................................................ 74
5.3.3
Der Position-Web-Service....................................................................... 78
5.3.4
Client-Applikation ................................................................................... 82
6
ZUSAMMENFASSUNG UND AUSBLICK ....................................................... 85
7
ANHANG A ........................................................................................................... 87
7.1
DIE SCHNITTSTELLE ZUR HARDWARE .............................................................. 87
7.2
DIE SCHNITTSTELLE DES WEB-SERVICES ......................................................... 88
8
ANHANG B ........................................................................................................... 90
9
LITERATURVERZEICHNIS ............................................................................. 92
1
Einleitung
1.1 Motivation
Die
Hauptaufgaben
von
ortsabhängigen
Systemen
sind
die
Erfassung
des
Aufenthaltsortes einer Person und die Ermittlung der physikalischen Ressourcen und
der Software Dienste in ihrer Nähe, um maßgeschneiderte und nutzerabhängige Dienste
bereitstellen zu können. Ortsbewusste Applikationen sollen zum Beispiel Fragen
beantworten, wie:
Wo befindet sich Peter?
Welcher Drucker ist in seiner Nähe?
Auf welchen Weg erreicht Peter den Drucker?
Hat die ortsbewusste Applikation die Position ermittelt, kann sie zum Beispiel in einem
Verzeichnisdienst nachschauen, wo sich der nächste Drucker befindet und wie Peter
dorthin gelangt.
Navigationssoftware für Autofahrer, (aber auch für Wanderer, Radfahrer oder InlineSkater) ist bereits ziemlich verbreitet, aber viele Anwendungsgebiete, in denen
Positionsinformationen benötigt werden, sind noch unterentwickelt. Zum Beispiel kann
durch zentimetergenaue Bodenbearbeitung mithilfe von Geodaten, Satellitenbildern und
GPS (Global Positioning System) - das so genannte „Precision Farming“- die
landwirtschaftliche Produktivität erhöht werden.
Aber wie erfolgt die Positionsbestimmung?
In den letzten Jahren sind eine Vielzahl von Lokalisierungssystemen (engl. location
sensing systems) entwickelt worden, die in der Lage sind, die Position von mobilen
Objekten zu bestimmen. Sie wurden für die unterschiedlichsten Anwendungen
konzipiert und variieren daher stark in der Art der Positionsbestimmung und der
Darstellung der Positionsdaten. Einige funktionieren nur außerhalb von Gebäuden, wie
GPS, andere nur innerhalb von Gebäuden mithilfe einer Kombination aus einer
Lokalisierungsinfrastruktur
und
tragbaren
Rechengeräten.
Für
ortsbewusste
Applikationen ist nun ein Positionsdienst wünschenswert, der standardisierte
1
Positionsinformationen anbieten kann und mehrere Lokalisierungstechnologien
gleichzeitig einsetzt, um damit innerhalb und außerhalb von Gebäuden operieren zu
können. Außerdem sollte ein solcher Positionsdienst - transparent für die Applikation die Steuerung und den Übergang von einer Technik zur nächsten übernehmen. Dieser
Positionsdienst sollte auf Basis von Web-Services realisiert werden, da diese Zugriff auf
- von Diensten bereitgestellten - Operationen mittels einer Kommunikation zwischen
heterogenen Plattformen ermöglichen. Die ortsbewusste Applikation wird auf einem
tragbaren Rechengerät ausgeführt und kann den Positionsdienst über Internet zum
Beispiel mit Wireless-LAN- oder Handy-Verbindungen ansprechen.
Abbildung 1.1: Positionsdienst
Abbildung 1.1 zeigt ein System, das einen Positionsdienst benutzt. Die ortsbewusste
Applikation erhält von diesem die eigene Position und kann weitere Informationen von
einem Verzeichnisdienst beziehen. Es wäre auch denkbar, dass die mobilen Geräte sich
bei einem Trackingdienst registrieren, diesem ihre Position übermitteln und Positionen
von anderen Teilnehmern abfragen können. Für dieses System bildet der Positionsdienst
die Grundlage.
Ziel dieser Diplomarbeit ist es einen solchen Positionsdienst zu modellieren und zu
entwickeln.
2
1.2 Aufgabenstellung der Diplomarbeit
In dieser Arbeit wird ein Positionsdienst entworfen, der ortsbewussten Applikationen
über eine API (engl. application programming interface) zur Verfügung gestellt wird.
Eine einfache Schnittstelle abstrahiert von den Details der einzelnen benutzten
Lokalisierungssysteme und vereinheitlicht deren Funktionalität. Zu diesem Zweck
werden
zunächst
(in
einem
Vergleich)
anhand
von
geeigneten
Kriterien
Gemeinsamkeiten und Unterschiede von Lokalisierungssystemen aufgezeigt. Die
Kriterien werden so ausgewählt, dass aus ihnen die API des Positionsdienstes abgeleitet
werden kann. Die Realisierung des Positionsdienstes erfolgt auf Basis von WebServices in Java. Dieser Positionsdienst wird mit einer realen Anbindung eines GPSEmpfängers von Holux (GM-200) in einer Testumgebung an der TU Kaiserslautern
ausgeführt.
1.3 Anforderungen an den Positionsdienst
Der zu entwickelnde Positionsdienst soll folgende Anforderungen erfüllen:
Bereitstellen von symbolischen und geometrischen Positionsinformationen
Positionen
können
unterschiedlich
dargestellt
werden.
Die
meisten
Lokalisierungssysteme verwenden geometrische Positionen, d. h. Koordinaten in einem
Koordinatensystem. Für viele Anwendungsfälle sind aber menschenlesbare abstrakte,
sogenannte symbolische, Positionsangaben von Vorteil. Daher müssen Funktionen zur
Verfügung gestellt werden, die für Konvertierungen zwischen geometrischen und
symbolischen Angaben benutzt werden können.
Realisierung des Positionsdienstes auf Basis eines Web-Services, den jede
ortsbewusste Applikation über eine entsprechende API nutzen kann
Der Zugriff auf den Positionsdienst soll standardisiert sein, um eine hohe Flexibilität zu
erreichen.
Um einen standardisierten Zugriff auf den Positionsdienst zu ermöglichen wird dieser
als Web-Service realisiert. Dadurch ist es möglich, die eigene Position über eine API
abzufragen und die gewünschte Darstellungsform der Position auszuwählen.
3
Einbinden von mehreren Lokalisierungssysteme als Module
In der aktuellen Forschung wurden einige interessante Lokalisierungssysteme
entwickelt, die für unterschiedliche Anwendungsgebiete eingesetzt werden. Diese sollen
als Module in den Positionsdienst integriert werden können, sodass ein gleichzeitiges
Benutzen verschiedener Techniken ermöglicht wird. Der Positionsdienst muss dabei
den Übergang von einer Technik zur nächsten koordinieren.
1.4 Aufbau dieser Arbeit
Die vorliegende Arbeit ist in folgende Kapitel gegliedert. In Kapitel 2 wird
Grundlagenwissen zum Thema Lokalisierung vorgestellt. Dazu werden zunächst
Modelle zur Darstellung von Positionen beschrieben und danach grundlegende
Lokalisierungstechniken erklärt. In Kapitel 3 werden Kriterien aufgestellt, die für den
Vergleich der realen Lokalisierungssysteme dienen. Aus diesen Kriterien wird dann in
Kapitel 4 der Positionsdienst entworfen. Hierzu wird ein Positionierungsmodell
entwickelt, das festlegt, wie Positionen dargestellt werden. In Kapitel 5 werden wichtige
Realisierungsaspekte der Umsetzung des Modells in Java beschrieben. Es schließen sich
eine Zusammenfassung und ein Ausblick an.
4
2
Grundlagen der Lokalisierung
Es gibt viele Möglichkeiten für die Darstellung von Positionen. Für ein System, das die
Benutzung von mehreren Lokalisierungstechnologien realisiert, ist es wichtig, die
verschiedenen Formen zu kennen und ein einheitliches Format anzubieten. Daher
werden in diesem Kapitel Modelle für die Positionierung aufgezeigt. Ferner werden
einige Technologien zur Positionsbestimmung beschrieben. Dieses Grundlagenwissen
ist notwendig, um existierende Lokalisierungssysteme zu verstehen.
2.1 Positionierungsmodelle
Modelle für die Positionierung bilden die Grundlage jeder Positionsbestimmung. Sie
legen das Format für die Positionsangabe fest. Ein Lokalisierungssystem kann zwei
Klassen von Informationsdaten bereitstellen: geometrische und symbolische. In
geometrischen
Modellen
werden
Positionen
als
Punkte
in
einem
n-dimensionalen-Koordinatensystem dargestellt. Im Gegensatz dazu werden bei den
symbolischen Modellen die Positionen in von Menschen lesbaren Bezeichnern, wie
beispielsweise Gebäudenummern, angegeben.
2.1.1
Geometrische Positionierungsmodelle
Geometrische
Positionierungsmodelle
verwenden
Koordinatensysteme.
Ein
Koordinatensystem wird durch seine Darstellungsformen (u. a. kartesisch, polar,
Höhe-Breite-Koordinaten) und seinen Ursprung definiert. Innerhalb von Gebäuden wird
zum Beispiel oft der Empfänger als Ursprung angegeben und dann ein kartesisches
Koordinatensystem benutzt.
Außerhalb von Gebäuden basieren die Referenz-Koordinatensysteme auf möglichst
exakten Beschreibungen der Größe und Gestalt der Erde. Die Bestimmung der Figur der
Erde ist eine der Hauptaufgaben der Geodäsie, d. h. der Geowissenschaft, die sich mit
der Vermessung der Erdoberfläche und ihrer Objekte sowie dem Erdschwerefeld
beschäftigt. Da die Oberfläche der Erde von sehr komplexer Form ist, werden zu deren
Abstraktion und Vereinfachung geodätische Bezugssysteme eingeführt. Dazu gehören
die
mathematischen
Lagebeschreibung
Bezugsflächen
sowie
die
Kugel
und
physikalische
Rotationsellipsoid
Bezugsfläche
für
Geoid
die
als
5
Höhenbezugssystem. Das Geoid ist jene Niveaufläche (Äquipotentialfläche) des
Erdschwerefeldes, die in mittlerer Höhe des Meeresspiegels verläuft. Die geodätischen
Bezugsflächen besitzen infolge ihrer gekrümmten Oberfläche für Berechnungen wie
Distanzen und Flächen mathematisch ungünstige Eigenschaften. Aus diesem Grunde
werden Kartenprojektionen eingeführt, die ein ebenes Abbild der Erdoberfläche liefern.
Es sind eine Vielzahl unterschiedlicher Koordinatensysteme in Gebrauch, die auf
verschiedenen geodätischen Daten, Bezugssystemen und Projektionsmethoden basieren.
Einige davon werden im Folgenden kurz vorgestellt.
2.1.1.1
Erdfeste geozentrische Koordinatensysteme
Ein erdfestes geozentrisches Koordinatensystem (engl. earth-centered, earth-fixed) muss
in wohldefinierter Weise fest mit dem Erdkörper verbunden sein. Man nennt ein solches
terrestrisches Bezugssystem „Vereinbartes erdfestes System“ (engl. conventional
terrestrial system, CTS). Der Ursprung des erdfesten Koordinatensystems liegt im
Erdmittelpunkt des jeweiligen Referenzellipsoiden. Die z-Achse steht normal zur
Äquatorebene und zeigt zum Nordpol, die x-Achse liegt in der Äquatorebene und weist
auf den Nullmeridian durch Greenwich und die y-Achse vervollständigt das
rechtshändige, orthogonale Achsenkreuz (s.Abbildung 2.1).
Abbildung 2.1: Erdfestes geozentrisches Koordinatensystem
6
2.1.1.2
Geographische Koordinatensysteme
Das geographische Koordinatensystem aus Längengrad (engl. longitude), Breitengrad
(engl. latitude) und Höhe (engl. height) ist das bekannteste und am häufigsten
verwendete System sowohl zur zweidimensionalen als auch zur dreidimensionalen
Positionsangabe. Bei diesen Koordinatensystemen handelt es sich um ebene
Bezugssysteme, mit dessen Hilfe Bereiche der als Ellipsoid oder Kugel angenommen
Erde in einer Ebene betrachtet werden können. Für die Abbildung der Erdoberfläche auf
eine Ebene gibt es verschiedene Projektionsverfahren aus dem Bereich der
Kartographie. All diese Verfahren nehmen Bezug auf geodätische Referenzsysteme wie
das World Geodetic System 1984 (WGS84), das zum Beispiel beim Global Positioning
System (GPS; vgl. Kapitel 3.2.1) benutzt wird, oder das Europa Datum von 1950
(ED50). Hierbei liegen die Unterschiede zwischen den Bezugssystemen in der
Verwendung verschiedener Referenzkörper und -parameter. Die Referenzkörper
werden, je nachdem ob die ganze Erde (WGS84) oder nur Teilgebiete wie etwa Europa
(ED50) abgebildet werden sollen, entsprechend an den Erdkörper angepasst.
Abbildung 2.2: Geographisches Koordinatensystem [DANA95]
Die Referenzebenen zur Definition von Länge und Breite sind die Äquatorebene und die
Hauptmeridianebene, die senkrecht zur Äquatorebene steht und den Null- bzw.
Hauptmeridian (engl. prime meridian), der durch Greenwich verläuft, enthält. Die
geodätische Breite eines Punktes ist definiert als der Winkel zwischen der Äquatorebene
und dem Lot an dem Referenzellipsoiden in dem betrachteten Punkt. Die geodätische
Länge wird bestimmt durch den Winkel zwischen der Hauptmeridianebene, und der
7
senkrecht zur Äquatorebene stehenden Ebene, die den Punkt enthält (s. Abbildung 2.2).
Die Angabe einer geodätischen Länge oder Breite erfolgt in der Einheit Grad (°),
Minuten (’) und Sekunden ("). Die Distanz in Meter von der Oberfläche des
Referenzellipsoiden zu einem Punkt in orthogonaler Richtung zum Ellipsoiden, gibt die
geodätische Höhe eines Punktes an.
2.1.1.3
Die
Konforme Koordinatensysteme
konformen
Koordinatensysteme
basieren
auf
den
geographischen
Koordinatensystemen. Jedoch wird hier ein anderes Projektionsverfahren verwendet.
Die Oberfläche des
Referenzellipsoiden wird in
Streifen, die sogenannten
Meridianstreifen, eingeteilt. Bei der Universal Transverse Mercator (UTM) Projektion
wird die Erdoberfläche zum Beispiel entlang des Äquators in sechzig 6° breite Streifen,
die etwa von 80° nördlicher bis 80° südlicher Breite reichen, aufgeteilt.
Abbildung 2.3: Konforme Koordinatensysteme
Die konformen Koordinaten eines Punktes werden durch einen Rechts-/Ostwert (E) und
einen Hoch-/Nordwert (N) angegeben (s. Abbildung 2.3) Der Rechtswert ist der
Abstand vom Bezugsmeridian des Abbildungsstreifens bis zur Position des Objektes.
Der Hochwert wird bestimmt durch den Abstand (bzw. die Bogenlänge) des gesuchten
Punktes vom Äquator, gemessen entlang des Bezugsmeridians.
8
Abbildung 2.4: Universal Transverse Mercator Zonen [DANA95]
Bei UTM und anderen konformen Koordinatensystemen werden die Meridianstreifen
mit Bezeichnern versehen und zusätzlich in Zonen unterteilt (s. Abbildung 2.4).
Innerhalb dieser Zonen wird die Position eines Objektes wiederum durch einen vom
linken Zellenrand gemessenen Rechtswert und einen vom unteren Zellenrand
gemessenen Hochwert angegeben. Eine vollständige Positionsangabe besteht demnach
aus der Angabe der entsprechenden Zone, einem Rechts- und einem Hochwert.
2.1.2
Symbolische Positionierungsmodelle
Bei den symbolischen Positionierungsmodellen werden Standorte und Objekte mit
abstrakten Bezeichnern versehen, die der Angabe des Aufenthaltsortes dienen. Es bietet
sich an, Standorte mit Mengen und Objekte mit Elementen dieser Mengen zu
identifizieren. Eine Positionsangabe könnte folgendermaßen aussehen: „Pathfinder“
befindet sich auf dem „Mars“, d. h. Pathfinder  Mars. Es sind mehrere symbolische
Positionierungsmodelle vorstellbar, die nachfolgend erläutert werden.
2.1.2.1
Zellenbasiertes Positionierungsmodell
In diesem Modell wird ein Standort von dem Lokalisierungssystem in einzelne, von
Positionssensoren überwachte, Gebiete aufgeteilt, denen eindeutige symbolische
Bezeichner zugeordnet werden. Diese Gebiete werden Zellen genannt, deren
9
komplizierte reale Gestalt durch möglichst einfache geometrische Figuren modelliert
wird.
Abbildung 2.5: Zellenbasiertes Positionierungsmodell
In Abbildung 2.5 sieht man ein Beispiel von Zellen zweier Lokalisierungssysteme, die
sich überschneiden. Das erste Lokalisierungssystem ist das Global System for Mobile
Communications (GSM) (s. Kapitel 3.3) und das zweite ist das Active Bat System
(s. Kapitel 3.4.2). Sind gleichzeitig mehrere Lokalisierungssysteme vorhanden, die sich
in der Genauigkeit unterscheiden, kann es passieren, dass sich die Zellen überlappen
und Objekte sich gleichzeitig in mehreren Zellen befinden. Es könnte ein Objekt in der
GSM 2- und gleichzeitig in der Active Bat 3-Zelle lokalisiert werden. Die
Überschneidungen von Zellen werden bei diesem Modell nicht berücksichtigt, d. h. sie
können nicht festgestellt werden.
2.1.2.2
Zonenbasiertes Positionierungsmodell
Teilt man den Standort in die nicht–überlappenden Gebiete ein, die bei dem
zellenbasierten Modell entstanden sind, so ergibt sich das zonenbasierte Modell
[Leon98].
10
Abbildung 2.6: Zonenbasiertes Positionierungsmodell
Jedes nicht–überlappende Gebiet, die sogenannte Zone, ist Teil einer oder mehrerer
Zellen. Da sich die Zonen nicht überschneiden können, kann sich ein lokalisiertes
Objekt nur in genau einer Zone befinden, auch wenn es in mehreren Zellen
verschiedener Lokalisierungstechnologien geortet wird. Dadurch erhöht sich die
Genauigkeit der Positionsangabe gegenüber dem zellenbasierten Modell. Ein Objekt,
das sich in Zone E befindet, wird beim zellenbasierten Modell von den
Lokalisierungssystemen in den Zellen GSM 2, Active Bat 1 und Active Bat 2 erfasst,
was ein viel weiteres Lokalisierungsfeld einschließt (s. Abbildung 2.6).
2.1.2.3
Domänenbasiertes Positionierungsmodell
Ein Nachteil des zellen- als auch des zonenbasierten Modells ist, dass keine
Beziehungen zwischen den Zellen bzw. Zonen spezifiziert werden können. Bei dem
domänenbasierten Positionierungsmodell werden die abstrakten Gebiete durch eine
hierarchische Ordnung in eine Relation gesetzt. Eine Domäne entspricht dabei einer
Betrachtungsebene, die Gebiete mit gleichen Eigenschaften zusammenfasst, wie zum
Beispiel alle Gebäude. Die Relation könnte hier entsprechend der geometrischen
Positionen und der Gebietsgrößen definiert werden, wie zum Beispiel Raum 344 „ist
Teil von“ Gebäude 32. Es sind aber auch andere Ordnungen denkbar, wie zum Beispiel
Raum 348 „gehört zum“ Fachbereich Informatik (s. Abbildung 2.7). Ist ein
lokalisierbares Objekt Mitglied einer bestimmten Domäne, so befindet es sich auch in
allen „Vater“-Domänen.
11
Abbildung 2.7: Domänenbasiertes Positionierungsmodell
Domänen können sich, genauso wie Zellen, überschneiden. Allerdings ist es mit dem
domänenbasierten Positionierungsmodell möglich, eine Relation zwischen den
Domänen und den Zonen anzugeben (s. Abbildung 2.7). In diesem Beispiel ist das
abstrakte Gebiet mit dem Namen „Raum 346“ in die Zonen „B“ und „D“ eingeteilt.
Eine
Kombination
aus
einem
zonenbasierten
und
einem
domänenbasierten
Positionierungsmodell ist für symbolische Positionsangaben am besten geeignet.
2.1.3
Bezeichnungen
Um den passenden ortsabhängigen Dienst anbieten zu können, müssen manche
Applikationen fähig sein, lokalisierte Objekte zu identifizieren oder zu klassifizieren.
Insbesondere wenn die Positionsbestimmung Infrastruktur-seitig erfolgt, wird ein
automatischer Identifikationsmechanismus benötigt, da die Infrastruktur alle Objekte
gleichzeitig erfasst und sie daher unterscheiden muss (s. Kapitel 3.1).
Eine allgemeine Technik, die eindeutige Identifizierungen ermöglicht, ist der globale
Namensdienst, der die Vergabe von global eindeutigen Bezeichnern (engl. globally
unique identifiers, GUID) zentral steuert. Das zu lokalisierende Objekt sendet seine
GUID an das Lokalisierungssystem und dieses kann dann positions- und
objektabhängige Dienste bereitstellen. Dem Besucher eines Museums könnte zum
Beispiel das nächstliegende Ausstellungsobjekt in seiner Muttersprache beschrieben
werden.
Bei lokalen Namensdiensten findet die Namensvergabe beim Nutzer statt. Versuche
diese Art von Namensdienst zu realisieren, wurden unter anderem bei der ortsbewussten
Anwendung comMotion, die am MIT Media Laboratory entwickelt wurde, untersucht
12
[NaSc00]. Das Ziel dieser Anwendung ist es bestimmte Orte, die der Nutzer häufig
aufsucht, mit ToDo-Listen zu versehen, so könnte die Einkaufsliste eines Nutzers mit
seinem Lebensmittelgeschäft verbunden werden. Diese Anwendung benutzt für die
Lokalisierung das Global Positioning System (s. Kapitel 3.2.1). Das comMotion-System
ist so konzipiert, dass es das Ortsverhalten des Anwenders erlernt. Sobald der Benutzer
zum dritten Mal am selben Ort vom System registriert wird, erhält er die Aufforderung,
diesen Ort mit einer persönlichen virtuellen Bezeichnung zu versehen. Die
satellitenbasierten
GPS-Koordinaten
werden
somit
in
anwenderverständliche,
symbolische Ortsbezeichnungen wie zum Beispiel „Schule“ oder „Arbeitsplatz“
übersetzt, die jedoch nur für den jeweiligen Benutzer verständlich und unterscheidbar
sind.
Bei den meisten Lokalisierungssystemen müssen symbolische Bezeichnungen von
Objekten in der realen Welt (wie z. B. Raumnummern, Dienstbezeichnungen etc.)
manuell festgelegt und dem System bekannt gemacht werden. Dies bedeutet erstens
einen großen Aufwand, da diese Bezeichnungsdefinitionen gepflegt werden müssen und
zweitens eine Einschränkung der Skalierbarkeit. Daher wird nach Möglichkeiten
geforscht, einen Namensdienst zu realisieren, der selbstständig wichtige Orte erkennt
und diese auch bezeichnen kann [Hito03].
2.1.4
Kombinationen von Positionierungsmodellen
Symbolische Positionierungsmodelle eignen sich hervorragend um Positionsangaben zu
strukturieren, während ihr größter Nachteil die Ungenauigkeit der Positionsangaben ist.
Geometrischen Modellen hingegen mangelt es an Strukturierbarkeit und Abstraktion,
dafür bieten sie jedoch ausreichend genaue Positionsinformationen. So kann zwar
bestimmt werden, ob sich zwei Objekte innerhalb eines Gebäudes ungefähr einen Meter
von einander entfernt aufhalten, aber nicht, ob sich eine Mauer zwischen ihnen befindet.
Geometrische Positionsangaben können meistens sehr einfach durch geeignete
mathematische Berechnungen ineinander umgewandelt werden, aber bei den
symbolischen Positionierungsmodellen ist ein Vergleich zwischen den Daten oft sehr
schwierig.
Werden in einem System mehrere Lokalisierungstechniken gleichzeitig genutzt, kann
im
Allgemeinen
nicht
Positionierungsmodell
davon ausgegangen
verwenden.
Um
die
werden, dass
Vorteile
der
alle
das
gleiche
geometrischen
und
13
symbolischen Modelle vollständig zu nutzen, sollte ein solches System ein kombiniertes
Modell verwenden, bei dem mit einem Bezeichner wie zum Beispiel „Raum11“ auch
eine geographische Position assoziiert werden kann.
Daher ist es nötig, dass man Positionsdaten verschiedener Modelle ineinander
umwandeln kann.
Um dies zu erreichen werden bei der Abbildung von geometrischen in symbolische
Positionen, den geometrischen Positionen Gebiete zugeteilt, die einen symbolischen
Namen besitzen. Dadurch kann einer geometrischen Position ein symbolischer
Positionsbezeichner zugeordnet werden. Wenn sich eine geometrische Position zum
Beispiel innerhalb eines Zimmers befindet, erhält sie als symbolische Position die
Raumnummer.
Um symbolische in geometrische Positionen abzubilden, könnte man zum Beispiel
Raumnummern den Mittelpunkt eines Raumes zuordnen.
2.2 Lokalisierungstechniken
In
dem
folgenden
Abschnitten
werden
verschiedene
Techniken
zur
Positionsbestimmung aufgezeigt. Triangulation, Näherungsmessung und Ortsanalyse
sind drei Basistechniken für die Ortung. Lokalisierungsssysteme können jede dieser
Techniken einzeln oder in Kombination anwenden [HiBo01].
2.2.1
Triangulation
Bei der Triangulation werden die geometrischen Eigenschaften von Dreiecken für die
Ermittlung einer Position ausgenutzt. Es gibt zwei verschiedene Möglichkeiten,
Positionen durch Triangulation zu bestimmen: Lateration berechnet die Position mittels
Abständen und Angulation mithilfe von Winkeln.
2.2.1.1
Lateration
Bei der Lateration wird die zweidimensionale Position eines Objektes durch
Abstandsmessung zu drei Referenzpunkten ermittelt, deren Ortsvektoren linear
unabhängig sind, d. h. von denen keine zwei Punkte auf einer Geraden liegen
(s. Abbildung 2.8). Im dreidimensionalen Raum werden vier Bezugspunkte benötigt.
14
Abbildung 2.8: Distanzbestimmung durch Lateration im zweidimensionalen Raum
[HiBo01]
Die Anzahl der Referenzpunkte kann gegebenenfalls durch zusätzliches Wissen über die
entsprechende Infrastruktur reduziert werden. So kann zum Beispiel beim Active Bat
System (s. Kapitel 3.4.2) die dreidimensionale Position mit drei Referenzpunkten
ermittelt werden, da es Deckensensoren gibt, die sich immer höher befinden als das zu
lokalisierende Objekt und daher eine Position über den Sensoren ausgeschlossen
werden kann.
Es gibt verschiedene Techniken um den Abstand zu messen. Die drei Verbreitesten sind
die direkte Messung, die Laufzeitmessung und die Dämpfung.
Direkte Messung
In der Roboterforschung wird die Position von autonomen mobilen Robotern oft durch
physikalische Aktionen oder Bewegungen ermittelt. So kann der Roboter zum Beispiel
messen, wie weit er fährt oder wie weit sich der Roboterarm bewegt hat.
Laufzeitmessung (engl. time of flight)
Die am häufigsten angewandte Technik für die Abstandsmessung geht folgendermaßen
vor: es wird die Zeit gemessen, die ein Signal braucht, um vom Punkt P zu einem
Objekt X zu gelangen. Dieses Signal kann eine emittierte Licht-, Funk- oder
15
Schallwelle sein, deren spezifische Geschwindigkeit bekannt sein muss. So errechnet
sich die Distanz als Produkt der Laufzeit und der Geschwindigkeit:
Distanz  Signallauf zeit  Signalgesc hwindigkeit
Die Signallaufzeit wird mit der Uhrzeit des Senders im Punkt P und des Empfängers
berechnet, indem die Zeitspanne gemessen wird, die zwischen dem Zeitpunkt des
Erzeugens und des Empfangs des Messsignals liegt. Dabei wird vorausgesetzt, dass die
Uhren des Senders und des Empfängers exakt synchron laufen.
Das Objekt X kann dabei auch selbest in Bewegung sein, wie zum Beispiel ein
Flugzeug, das mit einer bekannten Geschwindigkeit fliegt. Bei dem Einweg-Verfahren
reicht es aus, das Signal nur einmal von P nach X zu senden. Je nach Beschaffenheit der
Objekte und des Senders am Punkt P, kann es allerdings auch notwendig sein, die Zeit
vom Punkt P zum Objekt X und wieder zurück zu messen, die sogenannte
Round-Trip-Time.
Um mit Laufzeitmessung korrekte Ergebnisse zu erhalten, müssen einige Fehlerquellen
ausgeschlossen werden:

Uhrendrift
Da die Zeit mit Uhren gemessen wird, müssen die Uhren synchronisiert sein.
Deshalb ist Uhrendrift eine mögliche Fehlerquelle, die zu falschen
Positionswerten führt. Die Satelliten, die zum Beispiel beim Global Positioning
System (GPS) benutzt werden, haben jeweils eine Atomuhr installiert, die von
Bodenstationen überwacht und im Falle von Uhrendrift korrigiert wird
(s. Kapitel 3.2.1).

Multipath-Fehler
Das größte Problem der Entfernungsberechnung mit Laufzeitmessung ist, dass
das gesendete Signal und reflektierte Signale nicht zu unterscheiden sind. Diese
indirekten Signale haben einen längeren Weg zurückgelegt und der gemessene
Abstand ist daher falsch. Gegenmaßnahmen beinhalten den Vergleich von
Messungen mehrerer Empfänger, um Signalverfälschungen aufzudecken.
16

Atmosphärische Störungen
Bei
der
satellitengestützten
Lokalisierung
verringert
sich
die
Signalgeschwindigkeit während das Signal die Atmosphäre durchdringt und dies
kann zu Ungenauigkeiten bei der Laufzeitmessung führen.
Dämpfung
Die Intensität eines emittierten Signals vermindert sich mit zunehmendem Abstand zu
seiner Quelle. Diese Verminderung der Signalstärke bezeichnet man als Dämpfung
(engl. attenuation). Kennt man die physikalischen Eigenschaften des Trägers und die
anfängliche Signalstärke, kann die Distanz mithilfe der Signalstärke beim Empfang
berechnet werden. Innerhalb von Gebäuden, in Räumen mit vielen Hindernissen, ist
diese Technik aber nicht so genau wie die Entfernungsberechnung durch
Laufzeitmessung [HiBo01].
2.2.1.2
Angulation
Diese Technik funktioniert im Prinzip analog zur Lateration, jedoch werden hier zur
Positionsbestimmung keine Abstände, sondern Winkel benutzt. So errechnet sich die
zweidimensionale Position bei der Angulation aus den Winkeln eines Objektes X zu
zwei festen Referenzpunkten, bezüglich Null Grad nördlich. Dabei muss der Abstand
zwischen den Referenzpunkten bekannt sein (s. Abbildung 2.9). Im dreidimensionalen
Raum wird zusätzlich eine Scheitelkreis–Messung (engl. azimuth) benötigt [HiBo01].
17
00
Winkel 2
Winkel 1
bekannte
Länge
X
Abbildung 2.9: Angulation
2.2.2
Analyse des Ortes
Die Positionierungstechnik „Analyse des Ortes“ (engl. scene analysis) versucht die
Position anhand markanter Merkmale der direkten Umgebung zu ermitteln.
Üblicherweise werden diese Merkmale vereinfacht, damit sie leichter verglichen werden
können. So kann zum Beispiel die Umrisslinie einer Landschaft, die von einer Kamera
eines autonomen mobilen Roboters aufgenommen wird, für die Positionsermittlung
benutzt werden (s. Abbildung 2.10).
Abbildung 2.10: Erkannte Horizontallinie [BeGr95]
Die statische Analyse des Ortes vergleicht aufgenommene Schnappschüsse mit
vorgegebenem Wissen über einen bestimmten Standort.
18
Bei einer differentiellen Analyse des Ortes wird versucht, die Position mittels
erkennbaren
Veränderungen
in
aufeinanderfolgenden
Schnappschüssen
der
Ortsaufnahmen zu bestimmen. Unterschiede in den Ortsaufnahmen bedeuten, dass sich
ein Objekt bewegt hat. Wenn die Positionen bestimmter Elemente der Umgebung
bekannt sind, kann das Objekt berechnen, wo es sich befindet.
Der Vorteil dieser Ortungstechnik liegt darin begründet, dass lediglich passive
Beobachtungen und Messungen nötig sind, um die Position eines Objektes zu ermitteln.
Es ist keine weitere Infrastruktur wie zum Beispiel ein Sensorennetzwerk oder Satelliten
notwendig. Allerdings erhöht der Algorithmus zur Analyse zwangsläufig die
Anforderungen an die Rechenleistung der mobilen Objekte. Ein weiterer Nachteil ist,
dass die Umgebungskarten bei Veränderungen der örtlichen Gegebenheiten aktualisiert
werden müssen, d. h. konkret, dass in einem Zimmer zum Beispiel keine Möbel verstellt
werden dürfen, um bei Verwendung der alten Karten korrekte Positionsangaben zu
erhalten.
2.2.3
Näherungsmessung
Bei der Ortungstechnik Näherungsmessung (engl. proximity measures) wird festgestellt,
ob sich ein Objekt in der „Nähe“ eines bekannten Standortes befindet. Die Anwesenheit
des Objektes wird durch Sensoren mit beschränkter Reichweite erkannt. Es gibt viele
verschiedene derartige Sensoren. Drei allgemeine Typen von Sensoren sind folgende:
2.2.3.1
Physischer Kontakt
Am einfachsten ist es, die Anwesenheit durch Berührungs- oder Drucksensoren
festzustellen, deren Position bekannt ist.
2.2.3.2
Überwachung von Access Points zu drahtlosen zellularen
Netzwerken
Eine weitere Möglichkeit ist, zu überwachen, ob sich ein Objekt in Reichweite eines
Access Points zu einem drahtlosen zellularen Netzwerk (Wireless LAN) befindet,
sodass die Position grob angegeben werden kann.
19
2.2.3.3
Überwachung automatischer ID–Systeme
Automatische
Identifizierungssysteme
sind
zum
Beispiel
Barcode-Scanner,
Geldautomaten, etc. Da der Standort dieser Systeme bekannt ist, kann bei Benutzung
eines dieser Systeme durch ein bestimmtes Objekt festgestellt werden, wo sich dieses
Objekt befindet.
2.3 Sensor-Fusion
Sensor-Fusion bezeichnet die Zusammenführung von Messungen verschiedener
Sensoren. Ziel ist es dabei, durch die Kombination verschiedener Sensoren neue
Informationen und durch die Nutzung mehrerer gleicher Sensoren verbesserte
Sensorinformationen abzuleiten. In vielen Anwendungsgebieten, wie zum Beispiel der
Robotik, wird nach Sensor-Fusion-Algorithmen geforscht.
Jeder Sensor hat spezifische Stärken und Schwächen, die sich aus der gewählten
Technologie und den Design-Parametern ergeben. Dies kann bei Störeinflüssen, wie
Rauschen
in
Bauteilen,
Temperaturschwankungen
etc.,
zu
schlechteren
Messergebnissen oder zum Ausfall des Sensors führen. Zum Beispiel ist eine Kamera
im Dunkeln bei Nacht unbrauchbar. Um die Robustheit des Sensorensystems und die
Qualität der Sensorenmessungen zu verbessern reicht es im Allgemeinen nicht aus, nur
die Anzahl der verwendeten Sensoren zu erhöhen, sondern es kommt auch auf die
verwendeten Verknüpfungsmethoden an.
Durch die Integration mehrerer Sensoren soll erreicht werden, umfangreichere und
genauere Informationen in kürzerer Zeit und mit geringeren Kosten zu erhalten. Dies
hat mehrere Vorteile. Indem man eine Gruppe gleichartiger Sensoren verwendet erreicht
man durch Redundanz eine Reduzierung der Unsicherheit in den Messungen und damit
eine exaktere Erfassung der Umwelt. Fallen einzelne Sensoren aus, können die
gewünschten Informationen von den übrigen Sensoren gemessen werden, was eine
Erhöhung der Zuverlässigkeit des Gesamtsystems zur Folge hat. Bei Anwendung von
Redundanz muss allerdings das Problem von zweideutigen Messungen gelöst werden.
Gehen zwei Uhren zum Beispiel unterschiedlich, muss festgestellt werden, welche Uhr
falsch geht. Einen weiteren Vorteil bietet die Integration von Sensoren, wenn diese
komplementäre Informationen liefern können. In diesem Fall erkennen die Sensoren
unterschiedliche Merkmale und können sich gegenseitig ergänzen. Zusätzlich erhöht
20
sich auch die Arbeitsgeschwindigkeit des Sensorensystems, da gleichartige Sensoren
parallel arbeiten und das Ergebnis des schnellsten Sensors übernommen wird.
Es gibt eine Vielzahl von Algorithmen für die Sensor-Fusion. Verfahren wie
stochastische Approximation, gewichtetes Mittel, Bayes’scher Schätzer oder KalmanFilter werden in der Literatur näher betrachtet [Durr02].
21
3
Lokalisierungssysteme
In diesem Kapitel wird ein Überblick über bestehende Lokalisierungssysteme (engl.
location sensing systems) vermittelt. Diese Systeme verfolgen verschiedene Ansätze
und haben unterschiedliche Eigenschaften. Um die Systeme vergleichen zu können,
werden daher zunächst Kriterien aufgestellt, die im Hinblick auf die Erstellung einer
möglichst allgemeinen Programmierschnittstelle ausgewählt wurden und keine
Bewertung der Lokalisierungssysteme zum Ziel haben.
3.1 Vergleichskriterien
Technologie
Die Vielzahl der Lokalisierungssysteme sind aus den Versuchen entstanden, mit neuen
Technologien und in verschiedenen Anwendungsgebieten, den Aufenthaltsort mobiler
Geräte zu bestimmen. Man kann Lokalisierungssysteme danach unterscheiden, welche
Technologie verwendet wird.
Größenbereich: Indoor / Outdoor
Fast alle Lokalisierungssysteme können entweder innerhalb von Gebäuden (engl.
indoor) oder außerhalb im Freien (engl. outdoor) eingesetzt werden. Dies hat technische
Gründe, zum Beispiel liegt es bei satellitengestützten Lokalisierungssystemen daran,
dass innerhalb von Gebäuden die Signale der Satelliten nicht empfangen werden
können. Die meisten Indoor-Lokalisierungssysteme benötigen eine installierte
Infrastruktur bestehend aus einem Sensorennetzwerk. Außerdem werden ganz andere
Technologien benutzt als außerhalb von Gebäuden. Daher kann die Lage eines Objektes
in Gebäuden ohne diese Infrastruktur häufig gar nicht oder nur sehr ungenau bestimmt
werden. Das Kriterium Größenbereich klassifiziert das System demnach als Indooroder Outdoor-Lokalisierungssystem.
Umfang
Der
Anwendungsumfang
kann
durch
die
räumliche
Ausdehnung,
die
ein
Infrastrukturelement abdecken kann, abgeschätzt werden. So ist der Empfang der
23
GPS-Satelliten weltweit möglich, aber bei anderen System wie zum Beispiel Smart
Floor auf einen Raum begrenzt.
Ferner kann der Umfang auch durch die mögliche Anzahl von Nutzern pro
Infrastrukturelement und Zeitintervall spezifiziert werden. Dabei hat die Betrachtung
der Zeit einen wichtigen Einfluss auf die Bestimmung des Umfangs. Kann ein
Lokalisierungssystem zum Beispiel den Anfragen der Nutzer nicht schnell genug
nachkommen, so hat dies entweder zur Folge, dass sich die Antwortzeiten erhöhen, oder
dass Positionen weniger oft aktualisiert werden und sich damit die Genauigkeit der
Angaben verringert.
Positionierungsmodell: geometrisch / symbolisch
Positionen können auf zwei grundlegende Weisen angegeben werden: bei den
geometrischen Modellen in einem Koordinatensystem und bei dem symbolischen
Modellen mithilfe von abstrakten Bezeichnern (s. Kapitel 2.1).
Position: relative / absolute Abbildung
Eine Position kann entweder absolut oder relativ zu anderen bekannten Positionen
angegeben werden. Lokalisierungssysteme, die absolute Positionen berechnen, benutzen
ein gemeinsames Koordinatensystem für alle lokalisierten Objekte, sodass eine Position
für jeden Empfänger genau die gleiche Stelle beschreibt.
Im Gegensatz dazu sind bei relativen Positionsangaben immer Positionen relativ zu
einem bekannten Bezugspunkt gemeint. Eine relative Angabe ist zum Beispiel die
Aussage „Der Drucker befindet sich im Nebenzimmer“ und die absolute Angabe dazu
„Der Drucker befindet sich im Raum 10“. Ist die absolute Position dieses
Bezugspunktes bekannt, so kann die relative Lage in die absolute Position umgerechnet
werden und umgekehrt.
Orientierung
Manche Lokalisierungssysteme sind in der Lage, neben Positionsangaben auch
Angaben über die Orientierung bzw. Ausrichtung eines Objektes zu machen. Dies kann
nützlich sein um festzustellen, auf welchen Gegenstand der Nutzer gerade zeigt oder
schaut. So wäre es möglich, dass ein Redner bei einem Vortrag nur auf die Wand zu
zeigen braucht, auf die sein Diagramm projiziert werden soll.
24
Lokalisierungstechnik
In Kapitel 2.2 wurden bereits einige Lokalisierungstechniken vorgestellt, anhand deren
eine weitere Unterscheidung der Lokalisierungssysteme möglich ist.
Aktive Komponente einer Positionierung: zu lokalisierendes Objekt / Infrastruktur
Bei einigen Systemen findet die Positionsberechnung bei dem lokalisierten (mobilen)
Objekt selbst statt. Dadurch erfährt nur das Objekt die Position, was eine höhere
Datensicherheit gewährleistet. Beim Global Positioning System (GPS) zum Beispiel
verfügen die Satelliten nicht über Informationen, die die Identität oder den Standort der
Empfänger betreffen (s. Kapitel 3.2.1).
In anderen Lokalisierungssystemen findet die Positionsbestimmung zentral statt. Die
Infrastruktur muss daher kontinuierlich von allen zu lokalisierenden Objekten Signale
empfangen, mit denen die Position ermittelt werden kann. Da die Berechnungen bei der
Infrastruktur liegen, können Technologien der lokalisierten Objekte kleiner und billiger
ausfallen, da sie weniger Rechenleistung und Speicherbedarf benötigen. Allerdings
unterliegen Sicherheits- und Datenschutzfragen ausschließlich dem System.
Genauigkeit und Zuverlässigkeit
Ein Lokalisierungssystem sollte exakte und wiederholbare Messungen durchführen
können. Ein System kann zum Beispiel eine Positionierung mit einer Genauigkeit der
Angaben innerhalb eines Gebietes von zehn Zentimetern und mit einer Zuverlässigkeit
von 99 % aller Messungen durchführen, d. h. Abweichungen von mehr als zehn
Zentimetern finden nur in einem Prozent der Messungen statt.
Erkennung von Objekten
Oft sind Dienste nicht nur orts-, sondern auch nutzerabhängig. Jeder Nutzer ist dann
durch seine Globally Unique Identifier (GUID) (s. auch Kapitel 2.1.3) eindeutig
identifizierbar. Bei manchen Systemen erfolgt die Positionierung Infrastruktur-seitig,
ohne dass der Nutzer ein Gerät bei sich haben muss (zum Beispiel bei Smart Floor,
s. Kapitel 3.4.5). Um dann festzustellen, wo sich eine bestimmte Person befindet, muss
diese eindeutig erkannt werden.
25
3.2 Satellitengestützte Lokalisierungssysteme
Eine
Kategorie
von
Lokalisierungssystemen
benutzt
Satelliten
zur
Positionsbestimmung. Ist die Position mehrerer Satelliten und der Abstand zu ihnen zu
einem bestimmten Zeitpunkt bekannt, lässt sich die Position äußerst präzise bestimmen.
Einer der weiteren Vorteile der satellitengestützten Lokalisierungssysteme ist die breite
Verfügbarkeit. Zum einen ist ein einfaches Empfängergerät heute preiswert zu erwerben
und benötigt nur wenig Platz, daher ist es von jedermann fast überall einsetzbar. Zum
anderen ist die Positionsbestimmung mithilfe von Satelliten nicht von Bedingungen, wie
der Tageszeit oder der eigenen Position, abhängig. In diesem Abschnitt werden die
Systeme GPS und dessen Weiterentwicklungen, GLONASS und das noch in der
Entwicklung befindliche GALILEO, vorgestellt.
3.2.1
GPS
In diesem Kapitel wird das Global Positioning System
(GPS)
beschrieben.
Diese
Technologie
wird
hier
ausführlicher beschrieben, da für diese Diplomarbeit ein
GPS-Empfänger zu Verfügung stand (s. Kapitel 5.2.1).
Technologie
Satelliten
Größenbereich
nur Outdoor
21 weltweite Satelliten und 3 Ersatzsatelliten
Umfang
5 Bodenstationen
Positionierungsmodell
Geometrisch mit WGS84 als Bezugssystem
Position
absolute Abbildung
Orientierung
nein
Lokalisierungstechnik
Lateration mit Distanzberechnung durch Laufzeitmessung von
Radiowellen
aktive Komponente einer
Positionierung
zu lokalisierendes Objekt
26
Genauigkeit und Zuverlässigkeit
1-5 Meter bei 95-99 Prozent
Erkennung von Objekten
nein
Tabelle 1: GPS
Das Global Positioning System ist das am Häufigsten genutzte Positionierungs- und
Navigationssystem der Welt. Es wurde vom US-Verteidigungsministerium für das
Militär in Auftrag gegeben, hat ungefähr zwölf Milliarden US-Dollar gekostet und kann
seit 1988 weltweit genutzt werden. Der offizielle Name ist NAVSTAR (Abkürzung für
Navigation Satellite Timing and Ranging) [Schu96].
Das System besteht aus drei Teilen: dem Weltallsegment (engl. space segment),
bestehend aus den stationären Satelliten, dem Kontrollsegment (engl. control segment),
d. h. den Bodenstationen und dem Nutzersegment (engl. user segment).
Die 24 Satelliten (21 aktive und 3 Ersatzsatelliten) bilden das Weltallsegment. Sie
umkreisen die Erde zweimal am Tag in einer Höhe von ungefähr 20200 Kilometern,
wobei sich jeweils vier Satelliten auf einer Orbitalbahn aufhalten. Durch diese
Satellitenkonstellation wird erreicht, dass jeder GPS-Empfänger auf der Erdoberfläche
die Signale von mindestens vier Satelliten gleichzeitig empfangen kann. Die
Radiosignale können Wolken, Glas und Kunststoff durchdringen, aber keine soliden
Hindernisse wie zum Beispiel Häuser oder Berge.
Das Kontrollsegment setzt sich aus fünf weltweiten Bodenstationen zusammen, die die
Flugbahn und Uhrzeit der Satelliten überwachen und gegebenenfalls Abweichungen
korrigieren.
Das
Nutzersegment
umfasst
alle
Nutzer
mit
ihren
verschiedenen
GPS-Empfängerausführungen. Die GPS-Empfänger benutzen die von den Satelliten
empfangenen Signale zur Berechnung der Position, der Geschwindigkeit und der
exakten Zeit. Die größten Anwendungsbereiche sind die Navigation von Schiffen,
Flugzeugen, Bodenfahrzeugen und Personen mit Handgeräten.
Die Position eines Satelliten setzt sich aus zwei Informationen zusammen: den
Almanach-Daten und den Ephemeriden-Daten. Die ersteren geben die approximierten
Positionen der empfangenen Satelliten an und werden im GPS-Empfänger gespeichert,
sodass dieser nun die Umlaufbahnen und die vermuteten Positionen der Satelliten kennt.
27
Diese Daten werden periodisch aktualisiert, während sich die Satelliten fortbewegen.
Die tatsächliche Flugbahn eines Satelliten kann sich leicht von der vermuteten
unterscheiden.
Daher
überwachen
die
Bodenstationen
Umlaufbahn,
Höhe,
Geschwindigkeit und Position der Satelliten. Dies sind die sogenannten EphemeridenDaten. Bei Abweichungen werden die korrigierten Informationen zu dem Satelliten
geschickt und so auch von den GPS-Empfängern entgegengenommen.
Der Aufenthaltsort eines GPS-Empfängers wird durch Lateration (s. Kapitel 2.2.1) mit
einer Distanzberechnung durch Laufzeitmessung von Radiowellen bestimmt. Da sich
die Satelliten im Weltall befinden, kann die mögliche Position des Empfängers im
Weltall ausgeschlossen werden. Daher kann die Lateration mit drei Satelliten
durchgeführt werden. Hierfür muss der GPS-Empfänger seinen Abstand zu den
Satelliten ermitteln. Die Entfernungsbestimmung erfolgt nach dem Einweg-Verfahren.
Die Geschwindigkeit eines Radiosignals ist gleich der Lichtgeschwindigkeit und beträgt
im luftleeren Raum ungefähr 340.000 km/s. Allerdings muss jegliche Verzögerung
aufgrund der Erdatmosphäre abgezogen werden. Bei der Bestimmung der Signallaufzeit
wird vorausgesetzt, dass die Uhr des Satelliten und die des Empfängers exakt synchron
und mit hoher Geschwindigkeit laufen. So kann zum Beispiel ein Zeitfehler von 0,1 s
schon zu einem Positionsfehler von 300 Metern führen.
gestrichelte Kreise: gemessener Abstand
durchgezogene Kreise: tatsächlicher Abstand
Abbildung 3.1: Zeitfehlerkorrektur:
28
Die Satelliten werden daher mit Atomuhren bestückt, deren Einsatz in den Empfängern
allerdings zu teuer wäre. Der sich ergebende Uhrendrift in den GPS-Empfängern und
die daraus resultierenden Entfernungsfehler werden mithilfe von Zeitkorrekturen
vermieden.
Diese
Distanzmessung
Zeitkorrekturen
zu
einem
werden
vierten
aus
der
Satelliten
Signallaufzeit
bzw.
der
bestimmt.
In
der
Abbildung 3.1 wird diese Korrektur für den zweidimensionalen Fall gezeigt, wo
ebenfalls ein Schnittpunkt ausgeschlossen werden kann.
Jeder Satellit strahlt auf zwei Frequenzen aus. Diese Frequenzen sind für alle Satelliten
des GPS gleich. Zwei Träger werden verwendet, wobei diese jeweils unterschiedliche
Informationen (Codes) beinhalten.
Abbildung 3.2: Verschiebung zur Laufzeitbestimmung [Schu96]
Diese Codes dienen der eindeutigen Identifizierung der Satelliten und der
Laufzeitmessung der Signale. Um die im Empfänger erzeugte Kopie des Codes mit dem
ankommenden Signal zu synchronisieren, ist eine Phasenverschiebung () notwendig,
die gleichzeitig ein Maß für die Signallaufzeit (t) vom entsprechenden Satelliten zum
Empfänger ist (s. Abbildung 3.2). Dazu zählt man im einfachsten Fall die
Verschiebungen, die für eine Korrelation benötigt werden.
Beim Design von GPS wurde versucht die maximale Genauigkeit zu erreichen.
Trotzdem kann es zu Fehlern kommen, die Abweichungen von fünfzig Meter
verursachen
können.
Folgende
Faktoren
können
die
Genauigkeit
der
Positionsbestimmung beeinträchtigen:
29
Abbildung 3.3: Mögliche Fehlerquellen [Gar00]

Atmosphärische Störungen
Die Signalgeschwindigkeit verringert sich während das Signal die Atmosphäre
durchdringt und weicht daher von der Geschwindigkeit im All ab.

Multipath-Fehler
Die Signale können auf Gebäude oder Berge treffen und von deren Oberflächen
reflektiert werden, sodass die Signallaufzeit länger ist und daher die Position falsch
berechnet wird.

Empfang von zu wenigen Satelliten
Je mehr Satelliten ein GPS-Empfänger empfangen kann, desto genauer wird die
Positionsbestimmung. Die Signale können von Häusern, Bergen etc. gedämpft oder
blockiert werden. Daher kann der Aufenthaltsort innerhalb von Gebäuden oder unter
Wasser nicht ermittelt werden.

Ephemeriden-Fehler / Uhrendrift / Messfehler
Ephemeriden-Fehler und Uhrendrift sind mögliche Fehlerquellen (s. weiter oben), die
von den Bodenstationen überwacht werden. Außerdem können Messfehler aufgrund
von Signalstörungen die Genauigkeit der Positionsbestimmung beeinträchtigen.

Beabsichtigte Verringerung der GPS-Genauigkeit
Um potenziellen Gegnern der USA nicht die gleiche Positionsgenauigkeit zu gewähren,
aktivierte das Militär eine künstliche Abschwächung der Signalstärke, die sogenannte
Selective Availability (SA), wodurch sich die Positionsgenauigkeit der zivilen
30
GPS-Geräte auf 50-200 Meter reduzierte. Nach Ende des kalten Krieges wurden solche
Maßnahmen unnötig und daher wurde SA am 2. Mai 2000 deaktiviert.
3.2.2
Differential GPS
Bei der Seefahrt können Kursabweichungen von 50-200 Metern dazu führen, dass ein
Schiff nicht sicher in den Hafen kommt. Die oben angesprochene Selective Availability
führte dazu, dass Differential GPS (DGPS) entwickelt und realisiert wurde.
Bei
dieser
Technik
werden
zusätzliche
Bodenstationen
errichtet,
die
mit
Referenzempfängern ausgestattet sind, deren exakte Position bekannt ist, und die daher
Fehler in den Satellitensignalen bestimmen können. So werden aus der durch den
Satelliten
angegebenen
Korrektureninformationen
Position
und
erstellt.
der
Diese
bekannten
Position
Informationen
differenzielle
werden
an
die
DGPS-Empfänger häufig mittels Funk gesendet und von diesen zur Korrektur der
empfangenen GPS-Satellitensignale verwendet. So kann mithilfe dieses Verfahrens die
Genauigkeit im Idealfall auf unter fünf Meter verbessert werden.
Abbildung 3.4: Differential GPS [Schu96]
In Deutschland wird das „Real Time Differential GPS“ als kommerzieller Dienst von
der
Deutschen
Telekom
AG
betrieben.
Dieser
Dienst
basiert
auf
einem
Gemeinschaftsvorhaben des Instituts für Angewandte Geodäsie, Außenstelle Potsdam,
und der Deutschen Telekom AG [Schu96].
31
3.2.3
GLONASS
GLONASS (Global Navigation Satellite System) ist ein weiteres satellitengestütztes
Navigationssystem, das in der ehemaligen UdSSR während des kalten Krieges für das
Militär entwickelt wurde und von den heutigen GUS-Staaten (Gemeinschaft
Unabhängiger Staaten) weiter betrieben wird. Bisher gibt es keine zivilen
Anwendungen. Das System ist dem GPS sehr ähnlich. Es werden ebenfalls 21 aktive
und drei Ersatzsatelliten verwendet, die in drei Ebenen auf Umlaufbahnen in einer Höhe
von 19100 km die Erde umkreisen. Allerdings gibt es kleine Unterschiede zwischen den
beiden Systemen. Die Systeme benutzen unterschiedliche Referenzellipsoide. GPS
operiert mit dem WGS 84 (World Geodetic System 1984), während GLONASS im
PZ-90 (Parametry Zemli 1990) arbeitet. Bei GPS benutzen alle Satelliten die gleichen
Trägerfrequenzen, wohingegen jeder Satellit bei GLONASS eine spezifische Frequenz
benutzt. Bei den Satelliten-Codes verhält es sich genau umgekehrt, d. h. GPS hat für
jeden Satelliten einen spezifischen Code und bei GLONASS sind die Codes für jeden
Satelliten gleich [Roßb00].
3.2.4
GALILEO
GALILEO ist Europas geplantes satellitengestütztes Navigationssystem für zivile
Zwecke, das Unabhängigkeit vom US-amerikanischen GPS garantieren soll. Der erste
Satellit soll vor Ende des Jahres 2005 in die Umlaufbahn gebracht werden, sodass
GALILEO bis 2008 in Betrieb genommen werden kann. Es bietet eine höhere
Genauigkeit und Zuverlässigkeit und kann mit GPS zusammenarbeiten. Dabei werden
27 aktive und 3 Ersatzsatelliten benutzt werden, die in 24000 km Höhe ihre
Umlaufbahn haben. Zwei Galileo-Kontrollzentren (GCC) werden in Europa die
Flugbahn der Satelliten überwachen. Zusätzlich wird es weltweit zwanzig GalileoSensorstationen (GSS) geben, die ihre Messungen an die GCC weiterleiten. Die GCC
nutzen die Daten der Sensorstationen, um die Integritätsinformationen zu berechnen und
das Zeitsignal aller Satelliten mit dem der Bodenstationsuhren abzugleichen.
GALILEO soll zuverlässiger sein als GPS und verfügt daher über die Fähigkeit, eine
„Integritätsmeldung" versenden zu können, die den Nutzer unmittelbar über auftretende
Fehler informiert. Außerdem wird GALILEO anders als GPS ohne Schwierigkeiten in
Städten und in Gebieten nördlicher geographischer Breite empfangen werden können.
32
Als weitere Funktion wird Galileo einen globalen Such- und Rettungsdienst (SAR)
bereitstellen, der auf dem Cospas-Sarsat-System beruht. Hierfür wird jeder Satellit mit
einem Transponder ausgestattet, der die Notrufsignale der Nutzergeräte an das
Rettungskoordinierungszentrum weiterleitet, welches wiederum die Rettungsaktion
auslöst. Gleichzeitig sendet das System ein Signal an den Nutzer mit der Information,
dass Hilfe unterwegs ist [GALI04].
3.3 Zellfunknetzgestützte Lokalisierungssysteme
Für die Telefongesellschaften ist es möglich, den Aufenthaltsort eines Mobiltelefons
festzustellen, da diese eine Verbindung zu den Sendestationen aufbauen müssen. Es gibt
verschiedene Mobilfunknetze. Die wichtigsten sind das „Global System for Mobile
Communications“ (GSM), das in Europa eingesetzt wird, das auf GSM basierende
System „GSM Packet Radio System“ (GPRS) und das „Universal Mobile
Telecommunications
Systems“
(UMTS),
welches
eine
deutlich
erhöhte
Datenübertragungsrate aufweist. Mit Unterstützung dieser Mobilfunknetze können
verschiedene Lokalisierungstechniken realisiert werden, die im Folgenden beschrieben
werden [Snap03].
3.3.1
Cell ID
Technologie
Mobiltelefon
Größenbereich
Outdoor und Indoor
Umfang
weltweit vernetztes Telefonsystem; mit verschiedenen Systemen
realisierbar wie GSM, GPRS, UMTS
Positionierungsmodell
symbolisch durch die Angabe der Zelle
Position
absolut
Orientierung
nein
Lokalisierungstechnik
Näherungsmessung: das Mobiltelefon sendet einen
Registrierungswunsch an den Service Provider, der daher weiß in
welcher Zelle sich der Benutzer befindet
aktive Komponente einer
Positionierung
Infrastruktur
Genauigkeit
500m-20km GSM, 100m-5km UMTS
33
Erkennung von Objekten
ja, jedes Mobiltelefon besitzt eine eindeutige ID
Tabelle 2: Cell-ID
Die Lokalisierungstechnik Cell-ID funktioniert in GSM-, GPRS- und UMTS-Netzen.
Das Funknetz identifiziert die Basisstation (engl. Base Transceiver Station, BTS), mit
der das Mobiltelefon eine Verbindung aufgebaut hat und die Position des Telefons. Das
Einzugsgebiet dieser Basisstation ist die sogenannte Zelle (s. Kapitel 2.1.2), die eine
eindeutige ID besitzt. Die Position des mobilen Gerätes wird dann durch die ID der
Zelle ausgedrückt. Eine typische GSM-Zelle hat einen Durchmesser zwischen zwei und
zwanzig Kilometern. Die Zellen sind normalerweise grob kreisrund, können aber als
Sechsecke leichter modelliert werden, sodass sich ein Wabennetz von adjazenten Zellen
ergibt. In Städten sind die Zellen sehr klein, was eine Positionsangabe im Umkreis von
ungefähr 300 Metern ermöglicht. In weniger bewohnten Gebieten haben die Zellen
einen Radius bis zu 35 Kilometern. Verlässt ein mobiles Gerät eine Zelle, stellt die
entsprechende Basisstation fest, dass sich das Signal des Gerätes verringert und fordert
alle Basisstationen in der Umgebung auf die Mitteilung zu senden, wie viel Leistung sie
von ihm erhalten. Dann übergibt die erste Basisstation die Inhaberschaft an die Zelle,
die das stärkste Signal empfängt, d. h. diejenige, in deren unmittelbarer Nähe sich das
mobile Gerät jetzt befindet. Anschließend wird das Gerät über seine neue Basisstation
informiert. Dieser Vorgang wird als Übergabe (engl. handoff) bezeichnet. Da die Form
der Zellen bedingt durch Signalstärke-Schwankungen nicht einheitlich ist, ist diese
Technik der Positionsbestimmung oft zu ungenau. Ein Vorteil besteht allerdings darin,
dass keine Modifikation an den Mobiltelefonen oder dem Funknetz benötigt wird.
3.3.2
Enhanced Observed Time Difference (E-OTD)
E-OTD operiert nur auf GSM- und GPRS-Netzen. Diese Technik benutzt Lateration mit
Distanzberechnung
durch
Laufzeitmessung
von
Funkwellen
zu
mehreren
Basisstationen. Da hier die Zeitmessung von entscheidender Bedeutung ist, werden bei
GSM und GPRS zusätzlich Stationen benötigt, deren exakte Position bekannt ist. Diese
sogenannten Location Measurement Units (LMU) müssen so verteilt sein, dass jede
Basisstation in Reichweite mindestens einer LMU liegt. Da die exakte Position der
LMU bekannt ist, können Messfehler festgestellt werden. Die gesuchte Position wird
ermittelt, indem die Messungen der mobilen Geräte mit den Messungen der LMU
34
verglichen werden und die Position entsprechend korrigiert wird. Die Genauigkeit kann
gegenüber dem Cell-ID-Verfahren auf 100 bis 500 Meter Umkreis erhöht werden, wenn
mindestens drei Basisstationen empfangen werden. In Städten erhält man ein genaueres
Ergebnis als in weniger bewohnten Gegenden, da es dort mehr Basisstationen gibt.
E-OTD ist damit genauer als das Cell-ID-Verfahren, allerdings auf Kosten erhöhten
Nachrichtenverkehrs und massiver Erweiterungen der Netzinfrastruktur. Das Observed
Time Difference of Arrival (OTDOA) ist eine Variante der E-OTD Technik für UMTS
[Snap03].
3.3.3
Wireless Assisted GPS (A-GPS)
Wireless Assisted GPS operiert in GSM-, GPRS- und UMTS-Netzen.
Da GPS den Nachteil hat, dass innerhalb von Gebäuden oder in dicht bebauten Gebieten
fast kein Empfang der Satellitensignale möglich ist, kann das Mobilfunknetz hilfreiche
Informationen zur Verbesserung der Qualität der Positionsangaben beisteuern, indem
beispielsweise die Frequenzen und Positionen derzeit sichtbarer Satelliten zur
Verfügung gestellt werden.
Abbildung 3.5: A-GPS
Das System erhöht auch die Reaktionszeit der GPS-Empfänger, die normalerweise bis
zu drei Minuten brauchen, um erste Ergebnisse nach dem Einschalten zu liefern. Die
Suchzeit, die die 24 Satelliten für die Lokalisierung des Nutzers bei der normalen GPSOrtung benötigen, fällt beim A-GPS-Modell weg, da bekannt ist, in welcher Funkzelle
35
sich der Empfänger aufhält. Mit A-GPS ist auch eine Indoor-Positionsbestimmung
möglich [Snap03].
3.4 Indoor Lokalisierungssysteme
Die bisher vorgestellten Lokalisierungssysteme funktionieren innerhalb von Gebäuden
nur
unzureichend
mit
Ausnahme
der
A-GPS-Technik.
Eine
Indoor-
Positionsbestimmung macht in den meisten Fällen eine Hardware-Infrastruktur, wie
zum Beispiel ein Sensorennetzwerk, notwendig, damit mobile Objekte geortet werden
können.
3.4.1
Active Badge System
Technologie
Infrarot
Größenbereich
nur Indoor
Umfang
eine Basis pro Zimmer, alle 10 Sekunden ein Badge pro Basis
Positionierungsmodell
symbolisch
Position
absolut
Orientierung
nein
Lokalisierungstechnik
zellulare Näherungsmessung
aktive Komponente einer
Positionierung
Infrastruktur
Genauigkeit
auf Zimmergröße beschränkt
Erkennung von Objekten
ja, jedes Badge hat eine GUID
Einschränkungen
Sonnenlicht kann den Empfang des Infrarotlichtes stören
Tabelle 3: Active Badge System
Das Active Badge System gilt als das erste archetypische Indoor-Lokalisierungssystem.
Es wurde 1989 vom ehemaligen Olivetti Research Laboratory (ORL), der heutigen
AT&T Cambridge, entwickelt [WaHo92].
Ursprünglich wurde das System als ortsbasierte Anruf-Zustellung eingesetzt. Das
System zeigte eine Liste aller Mitarbeiter des ORLs, deren Aufenthaltsorte innerhalb
des Gebäudes und die Nummer des nächstgelegenen Telefonapparates an. Die
36
Positionsbestimmung erfolgte mittels zellularer Näherungsmessung. Dazu trug jeder
Mitarbeiter Infrarotsender, die sogenannten Badges (deutsch: Abzeichen), die alle zehn
Sekunden ein Infrarotsignal aussendeten, das von einem im Gebäude installierten
Sensorennetzwerk ausgewertet wurden. Die Positionen wurden hier absolut und
symbolisch angegeben, wobei eine Zelle einem Zimmer entsprach.
Die Sensoren des Sensorennetzwerks werden periodisch per Polling abgefragt, von dem
sogenannten Network-Controller mit einem Zeitstempel versehen und dann von
Lokalisierungsservern ausgewertet. Die empfangenen Daten enthalten nur die
Information, welche ID von welchem Sensor in welchem Subnetz empfangen wird,
woraufhin
der
Lokalisierungsserver
dann
die
Abbildung
der
ID
auf
den
Mitarbeiternamen und die des Sensors auf die Raumnummer übernimmt.
Die Infrarottechnik hat den Nachteil, dass Umgebungslicht oder direktes Sonnenlicht
den Empfang stören können, und dass nur eine geringe Reichweite und damit eine
eingeschränkte Zellengröße ermöglicht werden kann, sodass große Räume in mehrere
Zellen aufgeteilt werden müssen.
3.4.2
Active Bat System
Technologie
Ultraschall
Größenbereich
nur Indoor
Umfang
eine Basis für 10 Quadratmeter, 25 Berechnungen pro Zimmer pro
Sekunde
Positionierungsmodell
geometrisch
Position
absolut
Orientierung
ja
Lokalisierungstechnik
Lateration mit Distanzberechnung durch Laufzeitmessung von
Ultraschallwellen
aktive Komponente einer
Positionierung
Infrastruktur
Genauigkeit und Zuverlässigkeit 9 cm bei 95 Prozent
ja, jeder Bat hat eine GUID
Erkennung von Objekten
37
verhältnismäßig große Infrastruktur mit dem exakt zu
positionierenden Sensornetz an der Decke
Einschränkungen
Tabelle 4: Active Bat System
Im
Rahmen
eines
neueren
Projektes
entwickelte
AT&T
das
Active
Bat
Lokalisierungssystem, das Positionen durch Lateration mit Distanzberechnung mittels
Laufzeitmessung von Ultraschallwellen berechnet. Dieses System arbeitet wesentlich
präziser als das ältere Active Badge System und erreicht eine Genauigkeit von 9 cm bei
einer Zuverlässigkeit von 95 Prozent.
Abbildung 3.6: Vorgehensweise bei Active Bats: ein Bat wird über eine kabellose
Verbindung vom Controller getriggert (1) und sendet daraufhin einen
Ultraschall-Impuls (2) an die in der Decke platzierten Receiver. Diese errechnen die
Distanz durch Laufzeitmessung zum Bat und schicken das Ergebnis an den Controller
(3) [AdCu01].
Benutzer und Objekte werden mit Active Bats versehen, die eine GUID zur
Identifizierung erhalten. Auf eine Controller-Anfrage, die über eine Funkverbindung an
einen Bat geschickt wird, reagiert dieses, indem es ein Ultraschallsignal an das an der
Zimmerdecke angebrachte Sensorennetzwerk aussendet. Nach dem Senden der
Controller-Anfrage an das Bat, wird auch ein Resetsignal an die Deckensensoren
geschickt. Die Sensoren messen die Zeitdifferenz zwischen dem Empfang des
Resetsignals und dem Eintreffen des Ultraschallsignals. Anhand dieser Zeitdifferenz
kann dann der jeweilige Abstand der Sensoren zum Bat berechnet und die Lateration
durchgeführt werden. Möglicherweise auftretende Multipath-Fehler werden durch
sogenanntes „statistisches Entfernen“ [HiBO] herausgefiltert.
38
Die Positionen werden absolut und geometrisch angegeben. Es ist möglich die
Orientierung eines Objektes anzugeben, wenn es mit mehreren Bats an bekannten
Stellen versehen wird. An einem Tisch könnte an zwei Seiten jeweils ein Bat angebracht
werden, sodass man die Ausrichtung erkennt.
Diese Technik benötigt eine verhältnismäßig umfangreiche Infrastruktur mit dem exakt
zu positionierenden Sensorennetzwerk an der Decke. Geringe Erweiterbarkeit, schlechte
Handhabung und hohe Kosten sind wesentliche Nachteile des Active Bat
Lokalisierungssystems [ADCU01].
3.4.3
Cricket
Technologie
Infrastruktur sendet Funksignale zur Synchronisation und
Ultraschall-Signale mit Rauminformationen über sog. „beacons“
Größenbereich
nur Indoor
Umfang
ein „beacon“ pro 1,7 Quadratmeter
Positionierungsmodell
symbolisch und geometrisch
Position
relativ, für jede Gebäudeetage ein lokales
Referenz-Koordinatensystem
Orientierung
ja, mit dem Cricket-Kompass
Lokalisierungstechnik
1. Lateration mit Distanzberechnung durch Laufzeitmessung von
Ultraschallwellen
2. Näherungsmessung
aktive Komponente einer
Positionierung
zu lokalisierendes Objekt
Genauigkeit und Zuverlässigkeit 120x120 cm Gebiete bei ca. 100 Prozent
Erkennung von Objekten
ja
Einschränkungen
keine zentrale Verwaltung
Tabelle 5: Cricket
Das Cricket Indoor-Lokalisierungssystem wurde am Massachusetts Institute of
Technology (MIT) als Teil des 1999 gestarteten „Oxygen“-Projektes entwickelt. Das
System wurde in der Version Cricket v1 lange Zeit am MIT und in anderen
Forschungsgruppen getestet [NiPr00]. Die Verbesserungen wurden in die neue Version
Cricket v2 eingearbeitet, die 2004 auf den Markt kommt [BaRo03].
39
Bei Cricket wird, wie beim Active Bat System (s. Kapitel 3.4.2), eine Kombination aus
Radio- und Ultraschalltechnologie verwendet und die Position durch Lateration mit
Laufzeitmessung ermittelt. Allerdings realisieren beide Systeme unterschiedliche
Architekturen. Beim Active Bat System befinden sich die passiven Empfänger in der
Zimmerdecke und die mobilen Objekte sind mit aktiven Sendern ausgestattet. Cricket
verwirklicht ein gegenteiliges Konzept. Dies hat mehrere Vorteile: da die Berechnung
beim Objekt stattfindet, weiß nur dieses Objekt seine Position und kann schlecht von
anderen abgehört oder verfolgt werden. Das System kann leicht auf neue Benutzer
skaliert werden, da keine zusätzlichen Signale geschickt werden müssen und keine
Signalkollisionen auftreten können.
Die Deckensender (sogenannte Beacons) schicken in regelmäßigen Abständen ein
Funksignal und ein Ultraschallsignal. Die mobilen Geräte empfangen beide Signale und
können so anhand der Zeitdifferenz ihren Abstand zum Beacon errechnen. Das Cricket
System benutzt ein Positionierungsmodell, das geometrische und symbolische
Informationen gleichzeitig angeben kann. Jeder Beacon kennt seine symbolische
Position (z.B. die Zimmernummer) und es wird keine Abbildung von Koordinaten in
symbolische Bezeichner benötigt. Gleichzeitig kennt jeder Beacon seine Koordinaten
bezüglich eines lokalen Referenz-Koordinatensystem, zum Beispiel für eine Etage eines
Gebäudes.
Die Empfänger (sogenannte listeners) können mit einem Cricket-Kompass ausgerüstet
werden, der die Möglichkeit bietet, die Orientierung festzustellen. Dazu wird der
Kompass mit mehreren Ultraschalldetektoren ausgerüstet, sodass eine Orientierung des
mobilen Gerätes bezüglich eines Beacons errechnet werden kann, da dasselbe
Ultraschallsignal des Beacons zu verschiedenen Zeitpunkten empfangen wird.
Die verschiedenen Beacons werden nicht zentral gesteuert, was das Cricket-System
auch im Fall eines Defekts in einem Beacon robust macht. Dies hat allerdings den
Nachteil, dass keine zentrale Administration möglich ist und der symbolische
Bezeichner bei jedem Beacon einzeln eingestellt werden muss.
3.4.4
RADAR
Technologie
IEEE 802.11 Wireless-LAN-Netzwerktechnologie
Größenbereich
nur Indoor
40
Umfang
3 Basisstationen pro Etage
Positionierungsmodell
geometrisch
Position
absolut
Orientierung
nein
Lokalisierungstechnik
1. Implementierung: Analyse-des-Ortes
2. Implementierung: Triangulation
aktive Komponente einer
Positionierung
Infrastruktur
Genauigkeit und
Zuverlässigkeit
3 bis 4.3 Meter bei 50 Prozent
Erkennung von Objekten
ja
Einschränkungen
Lokalisierung nur auf einer Gebäudeetage möglich; Umsetzung auf
mehrere Etagen ist ein nicht-triviales Problem
Tabelle 6: RADAR
Das von Microsoft Reasearch entwickelte RADAR ist ein Indoor-Lokalisierungssystem,
das die IEEE 802.11 Wireless-LAN Netzwerktechnologie zur Positionsbestimmung
verwendet [BaPa00]. RADAR ist vollständig als Software-Erweiterung realisiert und
benötigt keine weitere Hardware-Infrastruktur. Die Basisstationen (auch Access Points
genannt) müssen so im Gebäude angebracht werden, dass sich ihre Empfangsbereiche
überlappen. Dies erhöht auch die Wireless-LAN-Performanz und daher wird diese
Konfiguration in der Regel schon gegeben sein. Die mobilen Objekte benutzen einen
Laptop mit Wireless-LAN-Zugang. RADAR misst an den Basisstationen die
Signalstärke, um daraus die 2-D-Position zu schließen. Zu diesem Zweck muss das
Gebäude vorher vermessen werden und die gewonnenen Daten in einer sogenannten
Radio-Map-Datenbank gesammelt werden. Dies ist eine Datenbank, die geometrische
Positionen und zugehörige Signalstärken der verschiedenen Basisstationen enthält. Die
Genauigkeit der Positionsdaten hängt sehr von den Angaben in der Radio-MapDatenbank ab. Für die Erstellung der Radio-Map wurden zwei Implementierungen
getestet. Eine verwirklicht die Analyse-des-Ortes-Technik und die andere einen
mathematischen Algorithmus, der Triangulation verwendet. Um den Aufenthaltsort
eines mobilen Objektes zu bestimmen, misst dieses die Signalstärke zu den
Basisstationen in seiner Nähe und dann sucht das System in der Datenbank nach der
wahrscheinlichsten Position des Objektes.
41
Die RADAR-Version, die die Analyse des Ortes benutzt, ist genauer als die zweite
Version, beide arbeiten mit einer Zuverlässigkeit von 50 Prozent. Ein Nachteil dieses
Systems besteht darin, dass es bisher nicht in Gebäuden mit mehreren Etagen
funktioniert.
3.4.5
Smart Floor
Technologie
Näherungsmessung durch physischen Kontakt durch Drucksensoren
in Bodenplatten
Größenbereich
nur Indoor
Umfang
ein vollständiges Sensornetzwerk pro Zimmer
Positionierungsmodell
geometrisch
Position
absolut
Orientierung
nein
Lokalisierungstechnik
Näherungsmessung durch physischen Kontakt
aktive Komponente einer
Positionierung
Infrastruktur
Genauigkeit und Zuverlässigkeit auf Größe der Bodenplatten (50 cm x 50 cm) bei 100 Prozent
Erkennung von Objekten
ja
Einschränkungen
bisher nur auf kleine Anzahl Personen beschränkt
Tabelle 7: Smart Floor
Das Projekt Smart Floor vom Georgia Institute of Technology verwendet
Drucksensoren in Bodenplatten, um Personen anhand ihrer Schrittmuster zu
identifizieren und zu verfolgen. An jeder Ecke einer Bodenplatte wird ein Drucksensor
installiert, sodass jeweils vier Bodenplatten auf einem Drucksensor liegen. Die
Sensoren messen nun die Kraft mit der ein Benutzer auftritt, wenn er über den mit den
Bodenplatten bestückten Gang geht. Ein Algorithmus versucht mithilfe eines
Hidden-Markov-Modells [RoGr00] eine Geh-Signatur anzulegen und mit bekannten
Signaturen aus einer Datenbank zu vergleichen, um eine Identifizierung möglich zu
machen. Bei einer Testgruppe von ca. zwanzig Personen konnte bei einer
Testkonfiguration eine Erkennungsrate von 90 % erreicht werden.
42
Der Vorteil dieser Technik ist, dass Personen erkannt werden können, ohne dass sie
irgendwelche technischen Vorrichtungen bei sich tragen müssen. Allerdings müssen
alle Räume mit den Bodenplatten bestückt werden, was hohe Kosten und schlechte
Skalierbarkeit zur Folge hat.
43
4
Modellierung des Positionsdienstes
In diesem Kapitel wird der Entwurf des Positionsdienstes beschrieben, der von
ortbewussten Applikationen über eine API (engl. application programming interface)
benutzt werden kann, die die Details der Positionsbestimmung für die Applikation
transparent macht und nützliche „Middleware“-Funktionalität bereitstellt. Die
Architektur dieses Positionsdienstes wird dabei aus Überlegungen heraus entwickelt,
die sich aus dem Vergleich der zu benutzenden Lokalisierungstechniken ergeben.
4.1 Hauptkomponenten
Im Folgenden werden die beim Vergleich festgestellten Unterschiede zwischen den
oben
beschriebenen
Lokalisierungssystemen
daraufhin
untersucht,
welche
Auswirkungen sie auf eine mögliche Realisierung eines Positionsdienstes haben.
Wie in Kapitel 1 deutlich wurde, verwenden die Lokalisierungssysteme unterschiedliche
Darstellungen von Positionen. Positionen können geometrisch oder symbolisch
angegeben werden und beide können absolut oder relativ sein. Der zu entwickelnde
Positionsdienst muss daher Positionen in einem für die ortsbewusste Applikation
verständlichem
Standardformat
anbieten
können.
Dazu
muss
zunächst
ein
Positionierungsmodell entwickelt werden. Zusätzlich muss der Positionsdienst
Konvertierungsfunktionen zwischen den verschiedenen Arten von Positionsangaben
anbieten.
Neben
den
verschiedenen
Positionsinformationen
Zuverlässigkeit
der
(s. Kapitel 1).
Darstellungsformen
Lokalisierungssysteme
Diese
Tatsache
unterscheiden
in
muss
der
sich
die
Genauigkeit
und
beim
Erstellen
des
Positionierungsmodell berücksichtigt werden, indem Positionen nicht durch Punkte,
sondern durch Aufenthaltsbereiche bezüglich einer bestimmten Genauigkeit bestimmt
werden. Aus den unterschiedlich genauen Positionsangaben, kann eine Position
berechnet werden, deren Genauigkeit größer oder gleich der Genauigkeit der anderen
Angaben ist. Dies nennt man Sensor-Fusion (s. Kapitel 2.3). Liefert zum Beispiel ein
System genaue x- und y-Koordinaten und ein weiteres System genaue Höhenangaben,
so kann die Gesamtmessung der verschiedenen Sensoren verbessert werden. Der
45
Positionsdienst sollte diesen Vorteil nutzen und verbesserte Positionsangaben berechnen
können.
Durch gleichzeitiges Benutzen verschiedener Lokalisierungssysteme können noch
weitere Einschränkungen einzelner Systeme verringert oder aufgelöst werden. Werden
zum Beispiel ein Indoor- und ein Outdoor-System gleichzeitig benutzt, so kann der
Positionsdienst Positionsangaben außerhalb und innerhalb von Gebäuden, in denen die
Indoor-Technik installiert ist, liefern. Auch der Anwendungsumfang kann erhöht
werden: so ist zum Beispiel die SmartFloor-Technik auf einen Raum beschränkt, aber in
der Kombination mit GPS ist theoretisch eine weltweite Positionsermittlung möglich.
Die Berechnung der Position kann entweder im mobilen Endgerät oder in der durch die
Lokalisierungssysteme
bereitgestellten
Infrastruktur
stattfinden.
Dies
ist
ein
Hauptunterschied zwischen den vorgestellten Systemen, der dazu führt, dass der
Positionsdienst durch eine Client-Server-Architektur realisiert wird. Die ClientKomponente „Position-Service-Engine“ wird auf dem Endgerät installiert und enthält
die Schnittstelle zu den ortsbewussten Applikationen, die den Positionsdienst nutzen
sollen.
Sie
kommuniziert
über
Netzwerk
mit
der
Serverkomponente,
dem
„Position-Web-Service“ (PWS).
Für Lokalisierungssysteme, die eine Positionsberechnung auf Seite des Objektes
realisieren, wird auf dem mobilen Endgerät eine Hardware installiert, die über
Hardwaretreiber angesprochen werden kann. Bei anderen Lokalisierungssystemen
findet die Berechnung bei einem Server der Infrastruktur statt, der auch die Steuerung
der Hardware übernimmt. Da es möglich sein soll, verschiedene Lokalisierungssysteme
als Module im Positionsdienst einzubinden und diese gleichzeitig benutzen zu können,
muss es eine Komponente beim Positionsdienst geben, die eine Schnittstelle besitzt, die
den Zugriff auf diese Hardwaretreiber gestattet. Diese Komponente wird mit
„Location-Sensing-Device“ (LSDevice) bezeichnet. Für jedes Lokalisierungssystem
wird dem Positionsdienst eine Instanz dieser Komponente, entweder auf der Clientoder auf der Serverseite, hinzugefügt. Über diese Komponente wird der Zugriff des
Positionsdienstes auf die Hardware entkoppelt, was eine Erweiterbarkeit durch
zukünftige neue Technologien ermöglicht.
Ferner muss es den Applikationen ermöglicht werden, die Infrastruktur-Server durch
eine Netzwerkkommunikation anzusprechen und Positionen bei der Infrastruktur
46
abzufragen. Dabei gibt es eine Vielzahl von verschiedenen Servern. Es ist vorstellbar,
dass in einer Etage eines Gebäudes ein Server zuständig ist und in einer anderen Etage
ein anderer Server, obwohl beide die gleiche Lokalisierungstechnik verwenden. Die
Infrastruktur-Server können sich auch dadurch unterscheiden, dass sie eigene ReferenzKoordinatensysteme
oder
verschiedene
Positionsmodelle
verwenden.
Die
Serverkomponente „Position-Web-Service“ hat infolgedessen die Aufgabe, die
entsprechenden zuständigen Server zu ermitteln und auch Konvertierungen zwischen
verschiedenen Darstellungsformen von Positionen durchzuführen.
Die Lokalisierungssysteme, bei denen die Infrastruktur die aktive Komponente der
Positionierung ist, erfordern eine Identifizierung von mobilen Objekten. Daher muss
jedem mobilen Objekt eine GUID (s. auch Kapitel 2.1.3) zugewiesen werden, damit die
eindeutige Erkennung möglich ist. Diese GUID muss dann bei Anfragen an die
Infrastruktur übergeben werden.
Abbildung 4.1: Architektur des Positionsdienstes
47
Beim Vergleich der Systeme wurde festgestellt, dass einige von ihnen auch Aussagen
über die Orientierung des mobilen Gerätes treffen können, was eine interessante und
nützliche Information ist. Daher wird die Orientierung bei der Konzeption des
Positionsdienstes ebenfalls berücksichtigt.
Durch den Vergleich der unterschiedlichen Lokalisierungssysteme, die von dem
Positionsdienst gleichzeitig zur Positionierung benutzt werden sollen, konnten folgende
Komponenten identifiziert werden, aus denen der Positionsdienst bestehen muss
(s. Abbildung 4.1):
Location-Sensing-Device:
Diese Komponente beinhaltet die Schnittstelle zu den Hardwaretreibern der
verschiedenen Lokalisierungstechniken.
Position-Service-Engine:
Diese Komponente verwirklicht die Schnittstelle, die ortsbewussten Applikationen den
Zugriff auf den Positionsdienst ermöglicht. Sie steuert die Positionsberechnung und die
Kommunikation mit dem Position- Web-Service oder den Infrastrukturkomponenten
und macht diese Vorgänge für die Applikation transparent.
Position-Web-Service:
Diese Komponente nimmt Anfragen zur Konvertierung von geometrischen und
symbolischen Positionen entgegen. Dazu werden hier die Konfigurationsdaten der
geographischen Gebiete verwaltet, in denen auch die zuständigen Infrastruktur-Server
eingetragen sind. Wird eine Positionierung durch die Infrastruktur nötig, so löst der
Position-Web-Service
die
Berechnung
der
Position
bei
der
Komponente
Infrastruktur-Position-Service-Engine aus und stellt die Ergebnisse bereit.
Infrastructure-Position-Service-Engine:
Diese
Komponente
entspricht
Positionsberechnungen
der
Position-Service-Engine
ist,
der
Position-Service-Engine
Infrastruktur
dass
keine
durch.
Der
und
führt
Unterschied
Netzwerkkommunikation
mit
die
zur
dem
Position-Web-Service stattfindet.
48
4.2 Positionierungsmodell
Im letzten Abschnitt wurde dargelegt, dass zunächst ein Positionierungsmodell
entwickelt werden muss, bevor es möglich ist, einen leistungsfähigen Positionsdienst zu
entwerfen. Dieses Positionierungsmodell definiert das Format der Positionen, die vom
Positionsdienst verwendet und der ortsbewussten Applikation zugänglich gemacht
werden. In diesem Abschnitt wird nun ein kombiniertes Modell vorgestellt, das
symbolische und geometrische Positionen verarbeiten kann. Dabei muss in einem ersten
Schritt
die
Genauigkeit
und
die
Zuverlässigkeit
von
geometrischen
Positionsinformationen berücksichtigt werden. Für die symbolischen Angaben wird in
einem
zweiten
Schritt
ein
domänen-
und
zonenbasiertes
Modell
definiert
(s. Kapitel 2.1.2).
Positionen können entweder „lokalisierbaren Objekten“ oder „logischen Gebieten“
zugewiesen werden. Daher werden diese in dem Positionierungsmodell definiert und
Bedingungen für die Inklusion eines Objektes in einem Gebiet angegeben.
4.2.1
Geometrisches Modell
Eine absolute geometrische Position besteht aus der Angabe der Koordinaten in einem
globalen geographischen Koordinatensystem. In diesem Modell wird das bei GPS
eingesetzte, weit verbreitete „World Geodetic System 1984“ (WGS84) für die Angabe
von Koordinaten verwendet (s. Kapitel 2.1.1). Die Koordinaten nach dem WGS84Format können leicht in andere Koordinatensysteme konvertiert werden.
Die vom Positionsdienst benutzten Koordinaten sind dreidimensional, d. h. sie
beinhalten zusätzlich zur Breiten- und Längenangabe eine Höheninformation. Die
Höheninformation wird allerdings in diesem Modell nur dafür benutzt, festzustellen, ob
sich eine Koordinatenangabe auf das richtige Stockwerk bezieht. Dies dient einerseits
einer einfacheren Darstellung und ist andererseits für die meisten Fälle bereits
ausreichend. Bei den bisherigen Einsatzszenarien für ortsbezogene Anwendungen, wie
einem Stadtführer, müssen selten übereinander liegende mobile Objekte, sehr wohl aber
Gebäude mit mehreren Etagen berücksichtigt werden. Eine Erweiterung auf den
dreidimensionalen Fall ist ohne große Änderungen der im Weiteren beschriebenen
Mechanismen möglich.
49
Manche Lokalisierungstechniken können nur relative geometrische Positionen angeben,
d. h. sie benutzen ein lokales Koordinatensystem, das zum Beispiel auf einen
Bezugspunkt in einem Gebäude ausgerichtet ist. Ein lokales Koordinatensystem kann
sogar notwendig werden, wenn das Gebiet mobil ist (z. B. ein Koordinatensystem, das
Positionen auf einem Schiff angibt).
Diese Koordinaten könnten auch in Breite, Länge und Höhe angegeben werden,
genauso wie die absoluten Positionen. Allerdings sind Angaben in einem kartesischen
Koordinatensystem innerhalb von Gebäuden bedeutungsvoller, da es zum Beispiel
leicht ist, festzustellen, dass sich zwei Objekte mit den Koordinaten (1m, 1m) und (1m,
2m) einen Meter auseinander befinden, aber die Angaben in Breite und Länge wären für
die wenigsten Nutzer zu verstehen.
4.2.2
Symbolisches Modell
Für symbolische Positionsangaben wird ein kombiniertes domänen- und zonenbasiertes
Modell benutzt (s. Kapitel 2.1.2). Die Standorte werden in sich nicht überschneidende
Zonen eingeteilt, die sogenannten logischen Gebiete, die jeweils einen eindeutigen
Bezeichner, den sogenannten Gebietsnamen, erhalten. Eine Domäne entspricht dabei
einer Betrachtungsebene, die Gebiete mit gleichen Eigenschaften zusammenfasst. Zum
Beispiel gehören alle Gebäude eines Geländes zur Domäne „DOMAIN_BUILDING“.
Dabei werden auch die geographischen Gegebenheiten berücksichtigt, zum Beispiel
besteht ein Gebäude aus mehreren Etagen etc., sodass die nächst größere Domäne die
Gebiete der kleineren Domäne enthält. Eine Menge von Domänen wird durch diese
„enthält“-Beziehung sortiert. Es wird dadurch eine hierarchische Ordnung entsprechend
der geographischen Gegebenheiten erreicht. Befindet sich zum Beispiel ein Raum R in
einem bestimmten Gebäude G, so gilt: G „enthält“ R oder RG. Es wird folgende
Hierarchie von Domänen vorgeschlagen:

DOMAIN_CONTINENT

DOMAIN_STATE

DOMAIN_TERRITORY

DOMAIN_BUILDING

DOMAIN_FLOOR

DOMAIN_ROOM
50
Es
wären
aber
noch
weitere
Domänen
denkbar,
wie
zum
Beispiel
DOMAIN_COMPANY etc..
Ein Gebietsname wird durch eine Zeichenkette dargestellt, die keine Leerzeichen
enthält, wie zum Beispiel „Building32“ oder „Room344“. Ein symbolischer
Positionsbezeichner ist durch eine Menge von Gebietsnamen definiert, die entsprechend
ihrer
Domänenzugehörigkeit
absteigend
sortiert
sind.
Dabei
wird
der
Positionsbezeichner als Zeichenkette dargestellt, bei der die Gebietsnamen durch einen
Punkt getrennt angegeben werden. Eine absolute symbolische Positionsinformation
besteht dann aus dieser Zeichenkette und der Angabe der Domäne, wie das folgende
Beispiel veranschaulicht:
absolut:
TU_Kaiserslautern.Building32.Room344, DOMAIN_ROOM
Eine relative Positionsinformation aus dem Gebietsnamen wird wie folgt dargestellt:
relativ:
4.2.3
Room344
Logisches Gebiet
Mit logischen Gebieten (engl. logical area, kurz LA) werden geographische Regionen
bezeichnet, wie zum Beispiel Gebäude, Etagen und Räume. Logische Gebiete können
mit Mengen identifiziert werden, da sie untereinander eine Teilmengenbeziehung haben
und da sie Objekte enthalten können. Ist zum Beispiel R ein Zimmer und G ein
Gebäude, dann gilt: RG. Ein logisches Gebiet kann aus mehreren Zonen bestehen, die
durch die Angabe von konvexen Polygonen definiert werden (s. Abbildung 4.2). Die
Konvexität der Polygone schafft günstige mathematische Eigenschaften, die zum
Beispiel die Berechnung vereinfachen, ob sich ein Punkt innerhalb oder außerhalb des
Polygons befindet. Um die Ausmaße der logischen Gebiete nicht auf konvexe Formen
einzuschränken, können sie aus mehreren Polygonen bestehen, sodass konkave Gebiete
aus kleineren konvexen Polygonen zusammengesetzt werden können. Ein Polygon P
wird durch seine Eckpunkte definiert: P=A0,...,An, wobei die Eckpunkte Ai entgegen
dem Uhrzeigersinn angegeben werden.
Zusätzlich wird das logische Gebiet von einem Rechteck (s. blauen Rand in der
Abbildung 4.2) eingerahmt. Dieses kann genutzt werden, um schnell auszuschließen,
51
dass sich ein Objekt innerhalb des logischen Gebietes befindet, indem nicht dessen
genaue Form betrachtet wird, sondern nur das Rechteck.
Abbildung 4.2: Logisches Gebiet
Mit diesem Modell ist es auch möglich, mobile Gebiete in Betracht zu ziehen. Ein
Beispiel für ein mobiles Gebiet könnte ein Schiff sein, das in Bewegung ist.
Die Eigenschaften eines logischen Gebietes werden durch seinen Deskriptor
beschrieben, der wie folgt aufgebaut ist:
Logical Area Descriptor:

GUID: jedem Gebiet wird eine GUID zugeteilt, anhand derer eine eindeutige
Identifizierung möglich ist

Name: dies ist der Gebietsname (s. Kapitel 4.2.2)

Description: eine nähere Beschreibung

Mobility: STATIC oder MOBILE: Die meisten logischen Gebiete werden
statisch sein, wie zum Beispiel Gebäude. Es ist aber auch möglich, ein Schiff
oder ein Flugzeug als mobiles logisches Gebiet zu betrachten.

Scale: INDOOR oder OUTDOOR: dieser Wert gibt an, ob sich das Gebiet
innerhalb oder außerhalb von Gebäuden befindet.
52

Domain: hier wird angegeben zu welcher Domäne das logische Gebiet gehört;
wird
zum
Beispiel
ein
Zimmer
beschrieben,
wäre
die
Domäne:
DOMAIN_ROOM (s. Kapitel 4.2.2)
Die symbolische Position eines logischen Gebietes wird durch den symbolischen
Bezeichner ausgedrückt, zum Beispiel: „TU_Kaiserslautern.Building32.Room11“, die
geometrische Position durch einen geographischen Punkt, der sicher innerhalb des
Gebietes liegt, zum Beispiel der Mittelpunkt des Gebietes.
4.2.4
Lokalisierbares Objekt
Lokalisierbare Objekte (engl. locatable object, kurz LO) können Endgeräte, wie zum
Beispiel Laptops, Handys oder Drucker sein. Sie befinden sich innerhalb von logischen
Gebieten und werden daher mit Elementen von Mengen identifiziert. So sind Angaben
über den Aufenthalt eines lokalisierbaren Objektes innerhalb eines logischen Gebietes
durch folgende Aussage möglich: Sei o ein lokalisierbares Objekt. Das Objekt o
befindet sich im logischen Gebiet G, d. h. oG.
Abbildung 4.3: Aufenthaltskreis eines lokalisierbaren Objektes
Die geometrische Position eines lokalisierbaren Objektes setzt sich zusammen aus der,
von der Lokalisierungstechnik ermittelten, geographischen Position sowie einer Angabe
über die Genauigkeit dieser Information. Daraus ergibt sich als Aufenthaltsbereich des
lokalisierbaren Objektes ein Kreis, der sogenannte Aufenthaltskreis (s. Abbildung 4.3).
Die reale Position des lokalisierbaren Objektes liegt somit irgendwo innerhalb des
Kreises. Die symbolische Position eines lokalisierbaren Objektes entspricht dem
symbolischen Bezeichner des logischen Gebietes, der dieses Objekt enthält. Zur
Verdeutlichung: befindet sich ein lokalisierbares Objekt o in einem Gebiet G, ist die
symbolische
Position
von
o
der
Bezeichner
von
G:
„TU_Kaiserslautern.Building32.Room344“.
53
Zusätzlich kann die Orientierung des lokalisierbaren Objektes angegeben werden. Es
kann dabei zwischen der geometrischen und der symbolischen Orientierung
unterschieden werden. Die geometrische Orientierung wird durch einen Winkel in Grad
ausgedrückt. Dabei entspricht der magnetische Norden Null Grad, der Osten 90 Grad
etc.. Aus der geometrischen Position und der geometrischen Orientierung kann ermittelt
werden, in Richtung welches logischen Gebietes das Objekt zeigt. Der symbolische
Bezeichner dieses Gebietes ist die symbolische Orientierung.
Lokalisierbare Objekte können mobil sein wie zum Beispiel Laptops, Handys, etc. Es
gibt jedoch auch statische Objekte, deren Position von Interesse ist, wie zum Beispiel
Drucker oder Scanner. Die Objekte können danach kategorisiert werden, ob sie
Dienstnutzer (Kategorie USER) oder Dienstanbieter (Kategorie RESSOURCE) sind.
Folgende Eigenschaften beschreiben ein lokalisierbares Objekt:
Locatable Object Descriptor:

GUID: jedes Objekt benötigt eine GUID, um Lokalisierungssysteme mit
Erkennung benutzen zu können

Name: ein menschen-lesbarer Name

Description: eine nähere Beschreibung

Mobility: STATIC oder MOBILE: lokalisierbar sind mobile Endgeräte, wie
Laptops aber auch fix installierte Geräte wie Drucker etc.

Category: USER oder RESSOURCE: diese Eigenschaft drückt aus, ob es sich
bei diesem LO um einen Nutzer oder einen Dienstanbieter handelt.
4.2.5
Inklusion eines lokalisierbaren Objektes in einem
logischen Gebiet
Die Position eines lokalisierbaren Objektes kann aufgrund von Ungenauigkeiten in den
Sensormessungen der verschiedenen Lokalisierungstechniken nicht als ein Punkt in
einem Koordinatensystem spezifiziert werden, sondern wird als Aufenthaltsbereich in
Form eines Kreises angegeben (s. Abbildung 4.3). Daher müssen Bedingungen
festgelegt werden, die bestimmen, wann sich ein Objekt innerhalb eines logischen
54
Gebietes befindet. Zu diesem Zweck wird die sogenannte Überlappung eingeführt.
Schneidet sich der Aufenthaltskreis mit dem Polygon des logischen Gebietes, wird
ermittelt,
wie
viel
Prozent
die
Schnittfläche
von
der
Gesamtfläche
des
Aufenthaltskreises ausmacht. Diese Prozentzahl ist die Überlappung und für jedes
logische Gebiet wird festgelegt, wie groß diese Überlappung mindestens sein muss,
damit angenommen werden kann, dass sich ein lokalisierbares Objekt innerhalb des
logischen Gebietes befindet.
Zusätzlich zur Überlappung wird verlangt, dass eine für jedes logische Gebiet
festgelegte Mindestgenauigkeit erreicht wird, weil sonst keine Aussagen über die
Inklusion möglich sind. Daher sehen die Bedingungen für den Aufenthalt eines
lokalisierbaren Objektes o in einem logischen Gebiet G folgendermaßen aus:
1. Genauigkeit von o  von G verlangte Genauigkeit
2. Überlappung von o  von G verlangte Überlappung
Sind diese Bedingungen erfüllt, gilt oG.
Abbildung 4.4: Inklusion eines Objektes in einem logischen Gebiet
In der Abbildung 4.4 gilt für das eingezeichnete Gebiet die Forderung einer MindestÜberlappung von 40%. Objekt 1 hat eine Überlappung von 41% und liegt damit
genauso wie Objekt 4 innerhalb des Gebietes. Allerdings erreicht Objekt 2 diese
Mindest-Überlappung nicht und liegt deshalb außerhalb. Die Positionsbestimmung von
Objekt 3 ist zu ungenau und wird daher nicht in Betracht gezogen.
Der kürzeste Weg zwischen zwei Punkten entlang der idealisierten Erdoberfläche ist bei
weiteren Entfernungen, d. h. mehr als einem Kilometer, (wie zum Beispiel zwischen
zwei Städten,) keine Gerade, sondern ein Bogen. Der Abstand ist daher die Länge des
Bogens auf dem Referenzkörper, der als Modell der Erde gewählt wurde. Die
55
Referenzkörper können Kugeln, Ellipsoide oder Geoide sein (s. Kapitel 2.1.1). Die
Verwendung
von
Geoiden
als
Referenzkörpern
führt
zu
sehr
komplexen
mathematischen Modellen, weshalb in den meisten Fällen Kugeln oder Ellipsoide für
Kurs- oder Abstandsberechnungen bevorzugt werden.
Bei den Berechnungen zur Inklusion eines lokalisierbaren Objektes in einem logischen
Gebiet befinden sich zwei Punkte im Vergleich zum Erdumfang sehr nah beieinander,
und aus diesem Grund reicht es für die Abstandsberechnungen in der Nähe eines fixen
Punktes aus, die Erde als „flach“ zu betrachten [EdWi03]. So werden weitere Punkte in
einem kartesischen Koordinatensystem mit dem fixen Punkt als Ursprung, der y-Achse
in Richtung Norden und der x-Achse in Richtung Osten betrachtet. Ist der Ursprung als
geographischer Punkt (lat0, lon0) gegeben, und ein weiterer Punkt als (lat, lon), so kann
der letztere als Punkt in dem Koordinatensystem, das die Erde als flach modelliert,
angegeben werden:
x  polare _ Erdkrümmung  cos(lat 0)  (lon  lon 0)
y  äquatoriale _ Erdkrümmung  (lat  lat 0)
In dem Koordinatensystem können Abstandsberechnungen mit der euklidischen Norm
durchgeführt werden.
Diese Approximationen versagen allerdings in der Nähe der Pole und bei großen
Abständen. Dann liegt der Fehler bei: (
Abstand
)2
Erdkrümmung
Um zu berechnen, ob sich ein Objekt in einem logischen Gebiet befindet, wird der
Mittelpunkt des Aufenthaltskreises des Objektes als Ursprung genommen und die zu
überprüfenden Eckpunkte des Polygons in das lokale Koordinatensystem, dass die Erde
als flach modelliert, umgerechnet. Dann ist es möglich eine Schnittfläche zu bestimmen
und die Überlappung zu berechnen.
4.3 Komponentenbeschreibung
In diesem Abschnitt werden nun die Komponenten des Positionsdienstes und deren
Interaktion miteinander beschrieben. Dabei werden zwei Schnittstellen vorgestellt,
deren Entwicklung zum Ziel dieser Arbeit gehört. Die erste Schnittstelle ermöglicht den
standardisierten Zugriff auf die Hardware. Die zweite Schnittstelle ist jene, über die der
56
Positionsdienst genutzt werden kann. Ihre wichtigsten Funktionen und deren
Funktionsweisen werden erklärt.
4.3.1
Location-Sensing-Device
Die Location-Sensing-Devices
(kurz LSDevice) realisieren den Zugriff auf die
installierten Lokalisierungssysteme und bieten dazu eine standardisierte Schnittstelle an,
die auf die vom Hersteller mitgelieferten Hardware-Treiber der jeweiligen Technik
zugreift. Die von der Hardware bereitgestellten Positionsdaten werden dabei in das vom
Positionierungsmodell festgelegte Format konvertiert. Soll zum Beispiel ein GPSReceiver benutzt werden, muss es ein Location-Sensing-Device geben, das den Zugriff
auf die GPS-Technik ermöglicht. Jede dieser Komponenten kann ganz unterschiedlich
realisiert sein. Wie die Komponenten operieren und gestaltet sind, hängt von der
benutzten Hardware ab. Alle Location-Sensing-Devices müssen aber die gleiche
Schnittstelle realisieren und können dann zur Position-Service-Engine hinzugefügt
werden.
Die
Position-Service-Engine
bezieht
alle
installierten
Location-Sensing-Devices in die Positionsbestimmung mit ein und greift über die
Schnittstelle auf sie zu. Dazu muss sie abfragen können, welche Art von Informationen
das Location-Sensing-Device bereitstellen kann.
Die Art der Informationen werden in dem sogenannte LSDevice Descriptor gespeichert.
Dieser kann alle möglichen Eigenschaften beschreiben, die ein Lokalisierungssystem
besitzen kann (s. Tabelle 8). Hierzu zählen die verschiedenen möglichen Positions- und
Orientierungsangaben, die ein LSDevice berechnen kann. Ob das LSDevice in der
Infrastruktur oder bei der PSEngine installiert wurde, kann über die Eigenschaft „aktive
Komponente der Berechnung“ in Erfahrung gebracht werden. Wichtig ist auch, ob es
sich um eine Indoor- oder eine Outdoor-Technik handelt und in welcher Domäne das
System operieren kann.
Positionsangaben
absolute geometrische
relative geometrische
absolute symbolische
relative symbolische
Orientierung
geometrisch
symbolisch
57
Aktive Komponente bei der Berechnung
Infrastruktur
Objekt
Domäne
(s. Kapitel 4.2.2)
Größenbereich
Indoor
Outdoor
Tabelle 8: Art der Informationen, die ein Location Sensing Device bereitstellen kann
Die Komponente LSDevice arbeitet nach dem „Pull-Prinzip“, d. h. die Informationen
sollen auf Anfrage berechnet werden. Manche Hardwaretreiber fragen die Hardware in
einem Prozess (bzw. einem Thread) periodisch ab. Andere sind Ereignis-gesteuert, d. h.
sie erhalten immer dann ein Signal, wenn wieder Informationen zur Verfügung stehen.
Die Realisierung der einzelnen LSDevices kann daher intern sehr unterschiedlich
ausfallen. Um das „Pull-Prinzip“ zu erreichen, wird bei Ereignis-gesteuerten
Lokalisierungstechniken der letzte von der Hardware berechnete Wert zurückgegeben.
Abbildung 4.5: Architektur der Komponente Location-Sensing-Device
Es besteht für die ortsbewusste Applikation die Möglichkeit, über einen Direktzugang
bzw. einen Tunnel Zugriff auf spezielle Funktionalität der Hardware zu erhalten
(s. Abbildung 4.5). Da es sein könnte, dass eine Lokalisierungstechnologie neue
58
Funktionalität zu der vom Positionsdienst benutzten bereitstellen kann, wäre die
Applikation in der Lage, die Funktionen des Positionsdienstes und die zusätzlichen zu
benutzen. Auf diese Weise wird verhindert, dass der Positionsdienst die Funktionalität
einschränkt.
Ein
Beispiel
von
denkbaren
Zusatzinformationen
wäre
die
Geschwindigkeit des mobilen Objektes, die beim Positionsdienst nicht relevant ist, aber
vielleicht der Applikation nützt.
4.3.1.1
Schnittstellenbeschreibung
In Kapitel 1 wurde gezeigt, dass jedes Lokalisierungssystem unter Umständen völlig
verschiedene Hardware nutzt. Daher muss jede Hardware vor der Benutzung
konfiguriert werden. Über die Funktion configure() werden die notwendigen Parameter
übergeben und die Konfiguration durchgeführt. Ein GPS-Receiver wird zum Beispiel
über eine serielle Schnittstelle angesprochen, deren Port und Baudrate bekannt sein
müssen. Arbeitet eine Lokalisierungstechnik mit Erkennung, benötigt diese eine
Beschreibung des lokalisierbaren Objektes, die zum Beispiel auch die GUID enthält
(s. Kapitel 4.2.4). Diese Beschreibung wird ebenfalls über die Funktion configure()
übergeben. Nach der Konfiguration muss die Hardware mithilfe der Funktion initialize()
in den Betriebszustand versetzt werden.
configure
ermöglicht die Konfiguration des LSDevices
initialize
initialisiert das Gerät
activate
deactivate
aktiviert oder deaktiviert ein Gerät um
Ressourcen zu sparen
isActive
gibt an, ob ein Gerät aktiviert ist
getDescriptor
gibt den LSDevice Descriptor zurück
isLocationSensingAvailable
stellt fest, ob die Hardware eine Positionierung
durchführen kann
getGeometricPosition
ermittelt die geometrische Position
getSymbolicPosition
ermittelt die symbolische Position
getGeometricOrientation
ermittelt die geometrische Orientierung
getSymbolicOrientation
ermittelt die geometrische Orientierung
Tabelle 9: Schnittstelle zur Hardware
59
Folgendes Szenario ist vorstellbar: Auf einem Laptop sind verschieden Indoor- oder
Outdoor-LSDevices installiert und dieser befindet sich innerhalb eines Gebäudes. Um
festzustellen,
wo
sich
der
Laptop
befindet,
initiiert
die
PSEngine
eine
Positionberechnung aller installierter LSDevices. Obwohl Outdoor-Systeme nicht
innerhalb von Gebäuden operieren können, werden diese dennoch benutzt. Dies belastet
die Energie- und Rechnerressourcen. Um die Ressourcen zu schonen, gibt es daher die
Möglichkeit, die Lokalisierungshardware über die Funktionen activate() / deactivate()
aus- bzw. einzuschalten. Über die Funktion getDescriptor kann der LSDevice
Descriptor abgefragt werden (s. Kapitel 4.3.1). Dieser beschreibt das LSDevice und
kann genutzt werden um festzustellen, dass es nicht innerhalb von Gebäuden
funktioniert und daher deaktiviert werden sollte. Die PSEngine fragt über die Funktion
isActive() den Zustand eines LSDevices ab und kann so entscheiden, ob es in die
Berechnung mit einbezogen werden soll. Es wäre aber auch möglich, dass eine IndoorTechnik im Moment der Abfrage keine Positionierung durchführen kann, da die
Sensoren das Objekt nicht erfassen können (z. B. können Systeme, die Infrarotwellen
zur Ortung benutzen durch starke Sonnenstrahlung gestört werden). Dies kann über die
Funktion isLocationSensingAvailable() herausgefunden werden. Sie liefert ein positives
Ergebnis, wenn die Hardware in der Lage ist, die Position zu berechnen. Bei GPS würde
zum Beispiel innerhalb von Gebäuden eine negative Rückmeldung kommen.
Nachdem ermittelt wurde, dass ein LSDevice zur Positionsbestimmung benutzt werden
kann, können die gewünschten Positions- oder Orientierungsinformationen über
mehrere Funktionen abgerufen werden (s. Tabelle 9). Zum Beispiel gibt die Funktion
getGeometricPosition() die geometrische Position zurück.
4.3.2
Position-Service-Engine
Die Komponente Position-Service-Engine (kurz PSEngine) stellt für die ortsbewussten
Applikationen die Schnittstelle zum Positionsdienst bereit und ist der Teil der Software,
der auf dem mobilen Gerät ausgeführt wird. Sie steuert die Positionsberechnungen und
bietet den ortbewussten Applikationen standardisierte, symbolische und geometrische
Positionsinformationen, sowie Angaben über die Orientierung an.
60
4.3.2.1
Schnittstellenbeschreibung
Wenn die Position-Service-Engine gestartet wird, benötigt sie mehrere Informationen.
Eine ist die Beschreibung des lokalisierbaren Objektes, d. h. der Locatable Object
Descriptor,
der
der
Position-Service-Engine
über
die
Funktion
setLocatableObjectDescriptor() zur Verfügung gestellt wird (s. Tabelle 10). Wird dieses
Objekt zum Beispiel von dem Sensorennetzwerk einer Indoor-Lokalisierungstechnik
erfasst, so wird dieses anhand der GUID erkannt und so eine Positionierung ermöglicht.
Um die gewünschte Information bei der Infrastruktur abzufragen, muss die
Position-Service-Engine den zuständigen Position-Web-Service ermitteln. Zu diesem
Zweck muss zunächst der oberste PWS in der Hierarchie bekannt sein. Dieser wird über
die Funktion setGlobalPositionWebService() gesetzt. Ausgehend von dem globalen
PWS kann die Position-Service-Engine nun den zuständigen PWS ermitteln (wie dies
geschieht, ist in Kapitel 4.3.4 beschrieben).
installDevice
uninstallDevice
installiert bzw. deinstalliert ein LSDevice
setLocatableObjectDescriptor
übergibt der Position-Service-Engine eine
Beschreibung des Endgerätes auf dem sie
ausgeführt wird. Diese Informationen werden
unter anderem von den LSDevices benötigt, die
eine Positionierung mit Erkennung durchführen
setGlobalPositionWebService
da der Position-Web-Service hierarchisch
aufgebaut ist, braucht die
Position-Service-Engine Informationen über den
obersten PWS
getSymbolicPosition
ermittelt die symbolische Position. Es werden
alle installierten LSDevices mit einbezogen
getGeometricPosition
ermittelt die geometrische Position. Es werden
alle installierten LSDevices mit einbezogen
getGeometricOrientation
ermittelt die geometrische Orientierung. Es
werden alle installierten LSDevices mit
einbezogen
getSymbolicOrientation
ermittelt die symbolische Orientierung. Es
werden alle installierten LSDevices mit
einbezogen
Tabelle 10: Die API vom Positionsdienst
Nachdem die Position-Service-Engine diese Informationen besitzt, können ihr die
LSDevices, die vorher konfiguriert und initialisiert wurden, über die Funktion
61
installDevice() hinzugefügt werden. Diese Funktion erlaubt zusammen mit der Funktion
uninstallDevice() ein dynamisches Einbinden verschiedener Lokalisierungssysteme
während der Laufzeit.
Nun ist eine Positionsbestimmung möglich und kann über zwei Funktionen abgerufen
werden. Die Funktion getSymbolicPosition() berechnet die symbolische Position. Dabei
kann die gesuchte Domäne angegeben werden. Wenn zum Beispiel nur nach dem
Gebäude gesucht wird und nicht versucht wird das Zimmer zu ermitteln, kann die Suche
vorher abgebrochen werden.
Die Funktion getGeometricPosition() liefert die geometrische Position in WGS84.
Dabei kann eine gewünschte Genauigkeit angegeben werden, sodass versucht wird
diese zu erreichen. Hat zum Beispiel eine Lokalisierungstechnik die geometrische
Position mit einer ausreichenden Genauigkeit berechnet, wird nicht mehr versucht die
Genauigkeit mithilfe anderer installierter Techniken zu erhöhen.
Bei beiden Funktionen ist es möglich, Benutzereingaben oder -vorwissen mit in die
Positionierung einzubeziehen, wodurch sich die Berechnung steuern und vereinfachen
lässt. Zu diesem Wissen zählt zum Beispiel der Größenbereich (s. Kapitel 3.1). Ist
bekannt, dass sich das Objekt in einem Gebäude befindet, müssen keine OutdoorTechnologien in die Berechnung mit einbezogen werden. Aber auch Wissen über die
aktive Komponente der Berechnung oder die Domäne kann nützlich sein. Ist die
geometrische Position bekannt, muss diese nur in die symbolische umgerechnet werden.
Außerdem kann der zuständige Position-Web-Service angegeben werden, sodass dieser
nicht mehr gesucht werden muss.
4.3.2.2
Komponentenbeschreibung
Die Position-Service-Engine kann ihrerseits in verschiedene Komponenten aufgeteilt
werden. Die Struktur der Position-Service-Engine ist in Abbildung 4.6 dargestellt. Dabei
ist sowohl der Datenfluss (grüne Pfeile) als auch der Kontrollfluss (blaue Pfeile)
eingezeichnet. Bei den einzelnen Komponenten wird zwischen „Data Repositories“ (eckige
Kästen) und „Computational Units“ (abgerundete Kästen) unterschieden. „Data
Repositories“ (deutsch „Datenbehälter“) sind passive
abstrakte
Datentypen und
„Computational Units“ (deutsch „rechnende Einheiten“) sind Komponenten, die aktiv
Berechnungen durchführen. Diese Informationen machen die Interaktion der Komponenten
deutlich.
62
Der Ablauf einer Anfrage zur Positionsbestimmung durch die ortsbewusste Applikation
wird im Folgenden am Beispiel der geometrischen Positionen erklärt.
Abbildung 4.6: Architektur der Komponente: Position-Service-Engine
Die Komponente Control steuert den Kontrollfluss der Position-Service-Engine. Sie
bietet dem ortsbewussten Programm die Funktionen der oben beschriebenen
Schnittstelle an. Angenommen, die ortsbewusste Applikation möchte die geometrische
Position des Laptops bestimmen, auf dem sie installiert ist. Dann wird bei einer
Positionsbestimmung zuerst versucht die Position von den lokal installierten
Lokalisierungssysteme berechnen zu lassen. Dies ist die Aufgabe der Komponente
LSDevice
Coordinator.
Sie
verwaltet
dazu
eine
Liste
der
installierten
Lokalisierungssysteme und versucht festzustellen, welches dieser Systeme die gesuchte
Information liefern kann, in diesem Beispiel die geometrische Position mit einer
gewünschten Genauigkeit. Dazu werden alle aktiven und benutzbaren LSDevices
abgefragt. Konnte die Information mit den gewünschten Parametern, d. h. in diesem
Beispiel mit der ausreichenden Genauigkeit ermittelt werden, so kann die Komponente
Control das Ergebnis schon jetzt zurückgeben. Wurde die gewünschte Genauigkeit von
keiner Lokalisierungstechnik erreicht, versucht die Komponente Sensorfusion aus allen
ermittelten Positionen, die zwischenzeitlich in einer Liste gespeichert werden, eine
Positionsangabe zu berechnen, die mindestens die gewünschte Genauigkeit erreicht.
Dabei werden auch Zweideutigkeiten in den Positionsinformationen mithilfe der
63
Zuverlässigkeit
der
LSDevices
aufgelöst.
In
dem
Fall,
dass
zwei
Lokalisierungstechniken Positionen angeben, die weit auseinander liegen, hat die
Aussage der Technik mehr Gewicht, die eine höhere Zuverlässigkeit bietet. Sind keine
der LSDevices in der Lage, die gewünschte Position zu berechnen, wenn zum Beispiel
ein GPS-Empfänger keinen Satelliten empfängt, und die anderen Geräte nur
symbolische Informationen liefern, werden die Lokalisierungssysteme befragt, die auf
den Servern der Infrastruktur installiert sind. Dazu muss eine Netzwerkverbindung zu
dem Position-Web-Service hergestellt werden. Für die Netzwerkkommunikation ist die
Komponente PWS Communicator verantwortlich. Sie ermittelt den zuständigen
Position-Web-Service und fragt nach der gewünschten Information. Es ist aber möglich,
dass dieser das Objekt auch nicht lokalisieren kann. Als letzte Möglichkeit bleibt in
diesem Fall nur, die von den lokalen LSDevices oder durch den Position-Web-Service
ermittelte symbolische Position in eine geometrische Position umzurechnen. Diese
Konvertierungsfunktionen bietet auch der Position-Web-Service an, der dazu wieder
vom PWS Communicator aufgerufen wird. Die zurückgegebene geometrische Position
wird dann an die Applikation weitergeleitet.
4.3.3
Position-Service-Engine und LSDevice der
Infrastruktur
Die beiden Komponenten Position-Service-Engine und LSDevice werden bei den
Infrastruktur-seitigen Lokalisierungssystemen ebenfalls benötigt. In der Infrastruktur
entfällt allerdings bei der Position-Service-Engine der PWS Communicator, der im Fall
der
Objekt-seitigen
Berechnung
für
die
Netzwerkkommunikation
mit
dem
Position-Web-Service zuständig ist. Wird der Position-Web-Service zum Beispiel
aufgefordert, die Infrastruktur nach einer Position zu befragen, ruft dieser die
entsprechenden Funktionen der Infrastructure-Position-Service-Engine auf und schickt
die Ergebnisse als Antwort zurück. Die Infrastructure-Position-Service-Engine
verwendet dabei die gleiche Sensorfusion-Einheit wie die Position-Service-Engine.
4.3.4
Die
Position-Web-Service
Komponente
Position-Web-Service
(PWS)
ist
dafür
zuständig,
Positionsinformationen innerhalb eines bestimmten geographischen Gebietes, seines
Zuständigkeitsgebietes (engl. service area), zu verwalten. Außerdem ermöglicht sie den
64
Zugriff auf die Positionsinformationen der mobilen Objekte, die durch externe
Positionierungssensoren
in
der
Infrastruktur
bestimmt
werden
und
bietet
Konvertierungsfunktionen zwischen symbolischen und geometrischen Positionsdaten
an.
Abbildung 4.7: Zuständigkeitsgebiete der PWS nach Domänen
Durch die große Datenmenge und die Vielzahl der Zugriffe von Seiten der
Clientkomponenten bietet sich eine Realisierung mithilfe einer verteilten Architektur an,
die eine größere Skalierbarkeit und Performanz erreichen kann. Ein mobiles Objekt
kommuniziert dabei mit dem PWS über eine drahtloses Kommunikationsmedium, wie
zum Beispiel GSM oder GPRS (s. Kapitel 3.3) oder ein Wireless-LAN.
Eine hierarchische Anordnung der PWS erlaubt eine hohe Skalierbarkeit. Der
Positionsdienst ist damit nicht nur auf einzelne Gebäude beschränkt, sondern es ist eine
Anwendbarkeit „im Großen“ möglich, denkbar wäre sogar ein weltweiter Einsatz.
Dabei ergibt sich die hierarchische Anordnung aus dem Entwurf des symbolischen
Positionierungsmodell und der hierarchisch definierten Domänenstruktur. Ein PWS
kann in seinem Zuständigkeitsgebiet eine Domäne verwalten, wie zum Beispiel die
Domäne „Gebäude32“. Er teilt dieses logische Gebiet in kleinere, sich nicht
überlappende Untergebiete ein, die einer anderen Domäne entsprechen und von
weiteren PWS verwaltet werden (s. Abbildung 4.7).
65
Ein PWS hat die Aufgabe festzustellen, ob sich ein lokalisierbares Objekt in seinem
Zuständigkeitsgebiet aufhält. Diese Information kann in Form einer geometrischen oder
einer symbolischen Positionsangabe erfolgen, wobei die betrachtete Domäne die des
Zuständigkeitsgebiet ist. Folgendes Beispiel zeigt, wie der zuständige PWS gefunden
wird: der für die „Etage3“ von „Gebäude32“ zuständige PWS, verwaltet die Zimmer
dieser Etage (s. Abbildung 4.8). Die symbolische Position dieser Etage sieht wie folgt
aus:
„TU_Kaiserslautern.Building32.Floor3“, DOMAIN_FLOOR
Abbildung 4.8: Beispiel eines Zuständigkeitsgebietes
Die einzelnen Teilgebiete dieses Zuständigkeitsgebietes, wie zum Beispiel „Raum344“
gehören zur Domäne DOMAIN_ROOM.
Der Position-Web-Service bietet die Funktion getSymbolicOrientation() zur Berechnung
der symbolischen Orientierung eines anfragenden lokalisierbaren Objektes an. Diese
Funktion erwartet als Eingabe die geometrische Position und Orientierung, die durch
eine Lokalisierungstechnik festgestellt wird. Da die geometrische Orientierung ein
Winkel ist (s. Kapitel 4.2.4), kann so mithilfe der geometrischen Position ein
Richtungsvektor berechnet werden. Schneidet man die Halbgerade durch diesen
66
Richtungsvektor mit den Polygonen der logischen Gebiete, kann man bestimmen,
welches logische Gebiet in der gedachten Verlängerung des Richtungsvektors das
nächste ist. Die symbolische Position dieses Gebietes ist die symbolische Orientierung
des anfragenden lokalisierbaren Objektes. In der Abbildung 4.8 ist ein lokalisierbares
Objekt eingezeichnet, das sich im Flur eines Gebäudes befindet und in die Richtung des
Raumes 348 zeigt.
Um den PWS zu finden, der für dieses Zuständigkeitsgebiet verantwortlich ist, fragt ein
Client zunächst den in der Hierarchie obersten PWS. Dieser gibt Auskunft darüber,
welcher PWS für das gesuchte Teilgebiet zuständig ist, in dem sich das Objekt befindet.
Als nächstes fragt der Client diesen PWS nach der symbolischen Position. So werden
nach und nach die jeweiligen PWS ermittelt, bis derjenige gefunden ist, der das
Zuständigkeitsgebiet mit der gesuchten Domäne verwaltet. Ist der gesuchte PWS
gefunden, kann beispielsweise eine Konvertierung einer geometrischen in eine
symbolische Position erfolgen. Soll nun das Zimmer ermittelt werden, muss derjenige
PWS befragt werden, der für „Floor3” zuständig ist.
Um auch logische Gebiete unterstützen zu können, die mobil sind, muss weitere
Funktionalität bereitgestellt werden, damit ein Zuständigkeitsgebiet dynamisch
angepasst werden kann. Ist zum Beispiel ein PWS für das logische Gebiet zuständig, das
einem Meer entspricht, so verwaltet der PWS alle Schiffe als Untergebiete. Verlässt ein
Schiff dieses Meer, muss es bei diesem PWS abgemeldet und bei dem PWS, der für das
nächste logische Gebiet zuständig ist, angemeldet werden.
Da die einzelnen PWS über eine Netzwerkkommunikation erreichbar sein sollen,
werden sie als Web-Services realisiert. Andere Techniken wie DCOM, CORBA oder
RMI setzen meist aufwändigere Protokolle zur Rechnerkommunikation ein. WebServices nutzen weitgehend bestehende Infrastruktur und eingeführte Protokolle: sie
können auf Webservern ausgeführt werden und kommunizieren unbehindert von
Firewalls
über
HTTP;
bei
Bedarf
lassen
sich
gebräuchliche
Verschlüsselungsmechanismen wie SSL anwenden. Ähnlich wie Webseiten arbeiten
diese Mechanismen prinzipiell plattformübergreifend. Das bedeutet, dass ein auf einem
Linux-Rechner unter Apache laufender Web-Service auch von Clients auf einem
Windows-Rechner, einem Macintosh oder einem entsprechend ausgestatteten JavaHandy benutzt werden kann und die Client-Software keine Kenntnisse über die
Serverplattform oder die verwendete Programmiersprache benötigt. Neben “Remote
67
Procedure Calls“, also Aufrufen entfernter Methoden und Funktionen, verarbeiten WebServices Dokumenten-basierte Nachrichten. Zusätzlich haben Web-Services die
Vorteile, dass ein Anbieter sie in einem verteilten, globalen Verzeichnis gemäß einer
Spezifikation namens UDDI (Universal Description, Discovery and Integration) von
dem anbietenden Web-Service-Provider registrieren lassen kann, und dass Clients diese
Dienste dort finden können [Bell02].
An dieser Stelle wird nicht detaillierter auf Web-Services eingegangen, in der Literatur
finden sich detailliertere Beschreibungen [ChJe02].
68
5
Realisierung
Im Folgenden wird die Realisierung des im vorherigen Kapitel beschriebenen
Positionsdienstes betrachtet. Begonnen wird mit den Vorgaben dieser Arbeit für die
Realisierung des Systems. Dafür müssen einige weitere, auf technischen Grundlagen
basierende Entwurfsentscheidungen getroffen werden, die zunächst beschrieben
werden. Anschließend wird auf die eigentliche Implementierung des Prototypen
eingegangen.
5.1 Vorgaben
Der Positionsdienst wird in Java realisiert. Eine Beispiel-Applikation demonstriert, wie
der Positionsdienst benutzt werden kann. Dazu wird der Client des Positionsdienstes auf
einem
Laptop
installiert
und
ein
GPS-Empfänger
eingebunden,
der
zur
Positionsbestimmung benutzt wird. Der Laptop ist in der Lage, über eine
Wireless-LAN-Verbindung
mit
dem
Web-Service
zu
kommunizieren.
Der
Position-Web-Service soll auf einem Server bereitgestellt und mit Daten über einen
Bereich der Technischen Universität Kaiserslautern konfiguriert werden. Mit diesen
Daten kann gezeigt werden, wie eine Umrechnung von geometrischen in symbolische
Positionsangaben erfolgt.
5.2 Technische Grundlagen
In diesem Abschnitt werden technische Gesichtspunkte vorgestellt, die wesentlich für
die Realisierung des Positionsdienstes und die Beispiel-Anwendung sind. Diese
umfassen die Beschreibung der verwendeten Entwicklungspakete für die Realisierung
von Web-Services in Java und die Anbindung eines GPS-Empfängers über eine serielle
Schnittstelle zur Demonstration des Positionsdienstes.
5.2.1
Holux GM-200 Smart GPS-Empfänger
Der differentielle GPS-Empfänger Holux GM-200 des Unternehmens Holux
Technology Inc. kann bis zu zwölf Satelliten gleichzeitig empfangen und erreicht
mithilfe von in Echtzeit erhaltenen Korrekturdaten, d. h. mit Differential-GPS, eine
Positionsgenauigkeit von unter fünf Metern.
69
Für die Positionsbestimmung können verschiedene geographische Koordinatensysteme
verwendet werden. Ein Koordinatensystem kann dabei aus einer vordefinierten Liste
oder durch die Angabe der entsprechenden geodätischen Daten durch den Benutzer
festgelegt werden. Zusätzlich zur Positionsbestimmung ist die Messung der eigenen
Geschwindigkeit und der Empfang genauer Zeitsignale möglich. Die Version GM-200
besitzt einen USB-Anschluss, aber die Kommunikation mit dem Empfänger erfolgt
über eine simulierte serielle Schnittstelle gemäß dem Standart RS-232, wobei eine
Reihe von unterschiedlichen Übertragungsraten unterstützt wird.
Das unterstützte Schnittstellenprotokoll basiert auf der, vom National Marine
Electronics Association definierten, NMEA 0183 ASCII Schnittstellenspezifikation
[SiRF02].
5.2.2
Serielle Schnittstelle
Die Kommunikation mit dem Holux GM-200 Smart GPS-Empfänger erfolgt über eine
simulierte serielle Schnittstelle. Dies erfordert also eine Zugriffsmöglichkeit auf die
serielle Schnittstelle zur Realisierung der Anbindung des GPS-Empfängers in Java. Ein
direkter
Zugriff
auf
die
Gerätetreiber
hätte
den
Nachteil,
dass
die
Plattformunabhängigkeit verloren ginge. Eine bessere Lösung besteht deshalb in der
Verwendung der „Java Communication API“ von Sun Microsystems Inc..
Die Programmierschnittstelle „Java Communication API“ (auch unter dem Namen
javax.comm
bekannt)
erlaubt
die
Entwicklung
plattformunabhängiger
Kommunikationsanwendungen und bietet den Zugriff auf serielle (RS 232) und auf
parallele (IEEE 1284) Schnittstellen. Sie steht in zwei Implementierungen zur
Verfügung, eine für die Plattform Solaris und eine für Win32.
Um den Vorteil der Plattformunabhängigkeit nicht einzubüßen, wird der für die
Anbindung des Holux GM-200 Smart GPS-Empfängers erforderliche Zugriff auf die
serielle Schnittstelle über die Programmierschnittstelle des „Java Communication APIs“
realisiert.
5.2.3
Java Web-Service Development Pack
Das Java Web-Service Development Pack (JWSDP) von Sun Microsystems Inc. bietet
die Möglichkeit für Java-basierte Entwicklung und den Einsatz von Web-Services und
70
XML-Anwendungen. Das JWSDP stellt eine Sammlung von APIs und Tools bereit, die
für die Entwicklung von Web-Services benötigt werden.
In einem typischen Web-Service-Szenario schickt eine Applikation eine Anfrage an
einen Web-Service, der über eine bestimmte URL zu erreichen ist, und benutzt dafür
das SOAP-Protokoll (Simple Object Access Protocol). Die SOAP-Spezifikation
definiert ein Framework für den Austausch von XML-Dokumenten. Der Web-Service
empfängt die Anfrage, führt die Berechnung aus und schickt die Ergebnisse zurück.
Die Java API für XML-basiertes RPC (engl. remote procedure call), das sogenannte
JAX-RPC, ist die Programmierschnittstelle für die Entwicklung und Benutzung von
Web-Services. Ein auf RPC basierender Web-Service ist eine Sammlung von
Funktionen, die ein Remote-Client über Rechnernetzwerke aufrufen kann. Ein typisches
Beispiel hierfür ist ein Lagerbestandsdienst, der eine SOAP-Anfrage nach einem Preis
eines Produktes, das sich im Lager befindet, beantworten kann. Die Schnittstelle des
Web-Services, die Ein- und Ausgabeparameter und die zu verwendenden Protokolle
werden in der „Web-Services Description Language“ (WSDL) beschrieben. Der
WSDL-Standard definiert eine einheitliche Sprache zur Beschreibung von WebServices und basiert auf auf XML, sodass die Notation des WSDL-Standards in XML
ist [ChJe02].
Für die Realisierung des PWS wurde das Java Web-Service Development Pack in der
Version 1.3 verwendet.
5.3 Prototypische Implementierung
In diesem Abschnitt soll gezeigt werden, wie die im Entwurf beschriebenen
Komponenten
in
Java
realisiert
werden.
Die
Client-Komponente
Position-Service-Engine findet sich dabei in dem Java-Package de.icsy.da.fleuren.ps
wieder. Dieses enthält die Klassen, die zur Realisierung des Clients benötigt werden
und die autonom erzeugten Client-Stubs, die der Kommunikation mit einem WebService dienen. Das Package de.icsy.da.fleuren.pws beinhaltet die Server-Komponente
Position-Web-Service. Hier befinden sich die Klassen, die die Verwaltung der
Server-Daten übernehmen und die Funktionalität des Zuständigkeitsgebietes realisieren.
Zusätzlich enthält das Package de.icsy.da.fleuren.shared Klassen, die an verschiedenen
Stellen von der Client- und der Server-Komponente benutzt werden. Dazu zählen
71
Klassen, die die verschiedenen Darstellungen von Positionsangaben kapseln und eine
Bibliothek, die nützliche mathematische Funktionen zur Verfügung stellt.
5.3.1
Die Hilfsklassen
In dem Java-Package shared befinden sich die Hilfsklassen. Die Klasse GeoMath ist
eine Mathematik-Bibliothek, deren Funktionsumfang alle Methoden beinhaltet, die die
im Positionsdienst benötigten Berechnungen durchführen können. Dazu zählen
Abstands- und Flächenberechnungen, um die Überlappung ausrechnen zu können und
Funktionen, die die Projektion der Koordinaten nach WGS84 auf die als flach
modellierte Erde durchführen.
Ferner wird in diesem Package die Klasse Sensorfusion definiert, die benutzt wird, um
die Messungen verschiedener Sensoren für die Berechnung einer genaueren
Positionsangabe zu verwenden. In der derzeitigen Implementierung ist eine einfache
Methode vorhanden, um Messungen verschiedener Sensoren zu verbessern. Die
Komponente Sensorfusion wird sowohl in der Position-Service-Engine als auch in dem
Position-Web-Service verwendet und kann leicht durch andere Versionen ersetzt
werden, die neue Sensor-Fusion-Algorithmen einsetzen.
Abbildung 5.1: Sensorfusion
72
In der derzeitigen Implementierung wird bei zwei unterschiedlichen geometrischen
Positionsangaben die Lage der beiden Aufenthaltskreise zueinander festgestellt.
Schneiden sich die beiden Kreise, so befindet sich die tatsächliche Position innerhalb
der Schnittmenge, daher wird als genauere Position ein Kreis um diese Schnittfläche
berechnet (s. Abbildung 5.1 a)). Schneiden sich die Kreise nicht, so wird anhand der
Zuverlässigkeit der Lokalisierungssysteme entschieden, welche Positionsangabe korrekt
ist. In der Abbildung 5.1 b) ist die Angabe der zweiten Lokalisierungstechnik zum
Beispiel zuverlässiger, da eine Angabe zu 99 % korrekt ist.
UNKNOWN
nicht unterstützte Eigenschaften erhalten diese
Konstante
CATEGORY_USER
CATEGORY_RESSOURCE
legt die Kategorie eines lokalisierbaren Objektes
fest
MOBILITY_MOBILE
MOBILITY_STATIC
beschreibt die Mobilität
SCALE_INDOOR
SCALE_OUTDOOR
charakterisiert die Lokalisierungssysteme nach
dem Größenbereich
DOMAIN_CONTINENT
DOMAIN_COUNTRY
DOMAIN_STATE
DOMAIN_TERRITORY
DOMAIN_BUILDING
DOMAIN_FLOOR
DOMAIN_ROOM
legt eine Hierarchie der Domänen fest
POSITIONTYPE_GEOMETRIC_ABSOLUTE
POSITIONTYPE_GEOMETRIC_RELATIVE
POSITIONTYPE_SYMBOLIC_ABSOLUTE
POSITIONTYPE_SYMBOLIC_RELATIVE
beschreibt die Art der Positionsinformationen
ORIENTATIONTYPE_GEOMETRIC
ORIENTATIONTYPE_SYMBOLIC
beschreibt die Art der
Orientierungsinformationen
COMPUTATION_OBJECT
COMPUTATION_INFRASTRUCTURE
beschreibt, ob die Berechnung bei der
Infrastruktur oder beim lokalisierbaren Objekt
liegt
Tabelle 11: Konstanten des Positionsdienstes
Zu weiteren Hilfsklassen gehören die im Subpackage descriptor befindlichen
Deskriptoren. Diese beschreiben, wie im Entwurf definiert, die logischen Gebiete
(LogicalAreaDescriptor), die lokalisierbaren Objekte (LocatableObjectDescriptor), alle
Daten über einen Position-Web-Service (PWSDescriptor) und die Fähigkeiten einer
Lokalisierungstechnik
(LSDeviceDescriptor),
d. h.
eines
LSDevices.
Die
Beschreibungen erfolgen über Konstanten, die in der Klasse Constants definiert werden
73
(s. Tabelle 11). Zum Beispiel kann in einem LSDeviceDescriptor über die Konstante
SCALE_OUTDOOR
beschrieben
werden,
dass
es
sich
um
ein
Outdoor-
Lokalisierungssystem handelt.
In dem Subpackage position werden Klassen definiert, die Positions- oder
Orientierungsinformationen
speichern
können.
Dazu
zählen
die
Klassen
SymbolicPosition und GeometricPosition, die an vielen Stellen im Positionsdienst
benutzt werden. Eine symbolische Position besteht, wie im Entwurf angegeben, aus
einer Zeichenkette und einer Konstanten, die die Domäne festlegt. Die geometrische
Position besteht aus einer geographischen Positionsangabe durch ein GeographicPointObjekt und der Genauigkeitsangabe in Metern. Bei den beiden Positionsklassen
SymbolicPosition und GeometricPosition besteht die Möglichkeit, über die Methode
isValid() festzustellen, ob die Positionsangabe gültig ist. Diese Angabe wird dazu
genutzt, in einer Funktion eine ungültige Positionsangabe zurückzugeben, wenn zum
Beispiel keine Position ausgerechnet werden kann. Eine andere Möglichkeit wäre die
Rückgabe von NULL-Referenzen, was aber leicht zu NULL-Pointer-Exceptions führen
kann, die die Robustheit der Software verringern.
5.3.2
Die
Die Position Engine
Klasse
PSEngine
im
Package
de.icsy.da.fleuren.ps
enthält
die
Programmierschnittstelle der Position-Service-Engine.
engine= new PSEngine( locatableObjectDescriptor,
pwsDescriptor );
gps = new GPSDevice ( gpsDescriptor );
gps.configure( gpsProperties );
gps.initialize();
gps.activate();
engine.installDevice( gps );
Abbildung 5.2: Konfiguration der PSEngine
Um eine ortbewusste Applikation zu entwickeln, muss diese ein Objekt der Klasse
PSEngine instanziieren und benötigt dafür eine Beschreibung des lokalisierbaren
Objektes durch einen LocatableObjectDescriptor, der bei Infrastruktur-seitiger
Berechnung zur Identifikation gebraucht wird. Außerdem ist für den Zugriff auf den
Position-Web-Service
eine
Beschreibung
des
globalen
PWS
durch
einen
PWSDescriptor, erforderlich. Diese Deskriptoren werden beim Aufruf des Konstruktors
übergeben.
74
Danach muss die ortsbewusste Applikation für alle installierten Lokalisierungssysteme
ein Objekt generieren, das die Schnittstelle LSDevice implementiert. Über dieses kann
die Lokalisierungstechnik benutzt werden. Dazu muss sie konfiguriert, initialisiert und
im Anschluss der PSEngine hinzugefügt werden (s. Abbildung 5.2).
Nun können die Funktionen zur Positions- und Orientierungsermittlung, die im Entwurf
spezifiziert wurden, genutzt werden.
5.3.2.1
Die Schnittstelle LSDevice
Die Schnittstelle LSDevice definiert alle Funktionen, die im Modell spezifiziert wurden
(s. Kapitel 4.3.1.1) und die die Klasse PSEngine benutzen, um auf die Hardware einer
Lokalisierungstechnik zugreifen zu können. Für jede Lokalisierungstechnologie, die
vom Positionsdienst verwendet werden soll, muss eine Klasse geschrieben werden, die
diese Schnittstelle implementiert. Die Funktionsweisen der Klassen können dabei intern
völlig unterschiedlich konzipiert sein, und sie müssen einen Zugriff auf die
Hardware-Treiber über eine Hardware-Abstraction-Layer realisieren.
Auch die Parameter mit denen dieses Lokalisierungssystem konfiguriert wird, können
verschieden sein. Daher erwartet die Methode configure() als Eingabeparameter ein
Objekt
der
Klasse
java.util.Properties,
mit
dem
eine
von
der
jeweiligen
Implementierung der LSDevice-Schnittstelle abhängige Parameterübergabe möglich ist,
da spezifiziert werden kann, welche Parameter ein Properity-Objekt enthält. Kann ein
Lokalisierungssystem eine der möglichen Positionsinformationen nicht liefern, zum
Beispiel wenn keine Angaben der symbolischen Position möglich sind, so muss die
Funktion getSymbolicPosition() derart implementiert sein, dass sie eine symbolische
Position zurückliefert, die ungültig (engl. invalid) ist. Die Funktion getDescriptor()
muss einen LSDeviceDescriptor zurückgeben, der vollständige Informationen enthält.
Unvollständige Deskriptoren können zu Fehlern führen. Sind zum Beispiel die GUIDs
in den Diskriptoren nicht ihrer Definition folgend alle eindeutig unterscheidbar, können
auch die Lokalisierungssysteme nicht unterschieden werden.
Die Klassen GPSSimulator und GPS implementieren die Schnittstelle LSDevice. Die
erste bietet die Möglichkeit ein Lokalisierungssystem zu simulieren. Dazu können der
Start- und der Endpunkt eines Weges und eine Schrittweite angegeben werden, sodass
der GPSSimulator gibt bei Aufruf der Methode getGeometricPosition() Punkte auf
75
diesem Weg angibt. Die zweite realisiert den Zugriff auf den Holux GPS-Empfänger
GM-200. Dazu wird über die serielle Schnittstelle mithilfe des NMEA-Protokoll der
Empfänger nach der aktuellen Position abgefragt.
5.3.2.2
Die Klasse PSEngine
Die
PSEngine
Klasse
realisiert
die
Komponente
Control
im
Modell
der
Position-Service-Engine (s. Kapitel 4.3.2) und stellt die Schnittstelle zur ortsbewussten
Applikation bereit. Sie enthält eine Liste der installierten Lokalisierungssysteme, d. h.
der Klassen, die die Schnittstelle LSDevice implementieren.
Auf diese Liste greift ein LSDeviceCoordinator-Objekt zu, das die im Modell gleich
benannte Komponente realisiert, die die lokal installierten Lokalisierungssysteme zur
Positionsbestimmung verwaltet. Ein weiteres Attribut der Klasse PSEngine ist der
PWSCommunicator, der die Kommunikation mit dem Position-Web-Service übernimmt.
Wird die Funktion getGeometricPosition() der PSEngine aufgerufen (s. Abbildung 5.3),
wird zunächst durch den LSDeviceCoordinator eine von verschiedenen lokalen Geräten
berechnete Liste mit Positionsangaben erstellt. Diese Funktion erwartet als Parameter
ein Objekt der Klasse UserKnowledge. Dieses Objekt kann Wissen speichern, welches
die Berechnungen vereinfachen kann. Dazu zählen sowohl die Domäne und der
Größenbereich als auch eine symbolische oder geometrische Position. Hierzu kann der
Benutzer auch angeben, welcher PWS angesprochen werden soll, sodass eine Suche
nach dem zuständigen PWS nicht bei dem globalen PWS starten muss, sondern tiefer in
der Hierarchie beginnen kann. Dies spart einerseits Zeit und verringert andererseits den
Netzwerkverkehr.
76
Abbildung 5.3: Ablauf einer Abfrage nach der geometrischen Position
Falls eine Positionsangabe nur relativ berechnet werden konnte, kann der
Referenzpunkt, auf den sich die Angabe bezieht, durch die Klasse UserKnowledge
übergeben werden, und so eine Umrechnung in absolute Positionen ermöglichen. Die
Methode
isDeviceUsable()
der
Klasse
LSCoordinator
überprüft,
welche
Lokalisierungssysteme zur Positionsbestimmung nutzbar sind. Dazu wird bei jedem
LSDevice überprüft, ob das Gerät aktiviert ist, ob es die Art der gesuchten Information
berechnen kann und ob eine Positionsbestimmung in dem Moment technisch möglich
ist. Jede berechnete Position wird in einer Liste gespeichert. Die Liste der
77
Positionsangaben wird der Sensorfusion-Funktion getGeometricPosition() übergeben,
die aus diesen Positionen eine möglichst genaue Positionsangabe errechnet. Ist diese
Liste leer, d. h. es ist keine lokale Positionsbestimmung möglich, wird versucht, eine
symbolische Position zu ermitteln und diese dann durch den Position-Web-Service
konvertieren zu lassen. Die Aufgabe, den zuständigen PWS zu ermitteln und dessen
Remote-Procedures aufzurufen, hat die Klasse PWSCommunicator.
Wird hier eine symbolische Position ermittelt, die vom Position-Web-Service in eine
geometrische Position umgerechnet werden soll, so wird dafür die Methode
getGeometricPosition() des PWSCommunicator aufgerufen. Diese Methode erhält als
Parameter die symbolische Position und das Objekt der Klasse UserKnowledge. Als
erstes muss die Methode herausfinden, welcher PWS für diese symbolische Position
zuständig ist. Dabei kann die Suche bei dem vom Benutzer beschriebenen, dem
globalen oder dem zuletzt benutzten PWS beginnen. Mit diesem wird dann eine
Netzwerkverbindung aufgebaut und mit der Remote-Procedure getPWS() abgefragt, ob
der PWS für diese Position zuständig ist. Gibt der Position-Web-Service sich selbst als
Referenz zurück, so ist er der gesuchte PWS. Ansonsten wird eine Verbindung zu dem
PWS aufgebaut, dessen Beschreibung übergeben wurde. Ist der zuständige PWS
gefunden
kann
die
symbolische
getGeometricPosition()
konvertiert
Position
werden.
mit
Der
der
Remote-Procedure
Ablauf
der
anderen
Konvertierungsfunktionen und der Orientierungsabfragen erfolgt analog.
5.3.3
Der Position-Web-Service
Um einen Web-Service mit JAX-RPC zu implementieren, müssen zwei Dateien erstellt
werden. Die erste enthält eine Definition der Web-Service-Schnittstelle, die die
Remote-Procedures beschreibt, und die zweite Datei enthält die Implementierung dieser
Prozeduren.
Diese
beiden
Dateien
befinden
sich
in
dem
Package
de.icsy.da.fleuren.pws.server; die Schnittstelle heißt PositionWebServiceIF und die
Implementierung PositionWebServiceImpl. Die Schnittstelle muss von java.rmi.Remote
abgeleitet
werden
und
die
Web-Service-Funktionen
müssen
die
Exception
RemoteException werfen können.
Die Schnittstelle definiert die Funktion getPWS(), die als Eingabe einen symbolischen
Bezeichner eines der Untergebiete des Zuständigkeitsgebietes erhält und dann den
PWSDescriptor desjenigen PWS zurückgibt, der für dieses Untergebiet zuständig ist.
78
Dazu muss die symbolische Position bekannt sein. Ist dies nicht der Fall, und ein Client
kennt nur die geometrische Position, muss diese vorher in die symbolische Position
umgerechnet werden. Dazu werden beim Web-Service Konvertierungsfunktionen
angeboten, die Umrechnungen von geometrischen in symbolische Positionsangaben und
umgekehrt durchführen. Die Implementierungen dieser Funktionen sind alle nach dem
gleichen Funktionsprinzip aufgebaut.
Zunächst muss der Zustand des Web-Services geladen werden. Dazu wird das
Zuständigkeitsgebiet geladen, welches durch die Klasse ServiceArea realisiert wird und
die eigentliche Funktionalität des PWS enthält. Das Laden des Zuständigkeitsgebietes
geschieht dabei mithilfe der Klasse ServiceAreaLoader, die eine Klassenmethode
namens loadServiceArea() besitzt. Bei der derzeitigen Implementierung lädt diese
Methode die Konfiguration aus einer manuell zu erstellenden Textdatei; der Aufbau
dieser Datei kann in Anhang B eingesehen werden. Die Klasse ServiceAreaLoader
könnte aber bei Bedarf auch durch eine Version ersetzt werden, die ihre Daten zum
Beispiel aus einer Datenbank oder einem Verzeichnisdienst bezieht. Nach dem Laden
der Instanz der ServiceArea-Klasse kann die entsprechende Konvertierungsfunktion
oder die Funktion getPWS() aufgerufen werden. Im Anschluss daran kann der Zustand
des Web-Service mit der Funktion saveServiceArea() der Klasse ServiceAreaLoader
abgespeichert werden. In der derzeitigen Implementierung bleibt der Zustand des
Zuständigkeitsgebiet immer gleich und es erfolgt keine Speicherung. Das liegt daran,
dass bei der Implementierung keine mobilen logischen Gebiete in Betracht gezogen
werden. In dem Fall, dass mobile logische Gebiete unterstützt werden sollen, würde es
aber notwendig werden, die Konfiguration der mobilen Gebiete speichern zu können.
Weitere Funktionen, die in PositionWebServiceIF definiert werden, dienen der Abfrage
der Infrastruktur nach Positions- oder Orientierungsangaben. Auch hier muss bei der
Implementierung zunächst der Zustand des Position-Web-Service wiederhergestellt
werden.
Daher wird eine Instanz der Klasse LSDeviceCoordinator mithilfe der LSDeviceLoaderKlasse geladen. Diese hat wie bei der Client-Version die Aufgabe, die Abfrage der
installierten Lokalisierungssysteme zu koordinieren und verwaltet dazu eine Liste der
Objekte, die die Schnittstelle LSDevice implementieren (s. Kapitel 5.3.2.1). Diese
Objekte ermöglichen den Zugriff auf die Hardware-Treiber, der in der Infrastruktur
79
installierten Lokalisierungssysteme. Diese Objekte können in einem eigenen Prozess
weiterlaufen, wenn sie z. B. Ereignis-gesteuerte Positionsberechnungen durchführen.
5.3.3.1
Die Klasse ServiceArea
Die Komponente PWS verwaltet ein Zuständigkeitsgebiet. Dieses wird durch die Klasse
ServiceArea realisiert. Ein Zuständigkeitsgebiet besteht aus einem logischen Gebiet, das
in mehrere Untergebiete aufgeteilt ist. Ein logisches Gebiet wird durch ein Objekt der
Klasse LogicalArea repräsentiert. Daher enthält die Klasse ServiceArea sowohl eine
Liste von LogicalArea-Objekten, die den Untergebieten entsprechen als auch ein
LogicalArea-Objekt, das eine Beschreibung des gesamten Zuständigkeitsgebietes
beinhaltet. Zum Beispiel könnte das Zuständigkeitsgebiet eine Etage eines Gebäude
sein. Dann ist ein logisches Gebiet die gesamte Etage mit der Domäne
DOMAIN_FLOOR. Die einzelnen Zimmer auf der Etage (einschließlich des Flures)
sind die anderen logischen Gebiete, und diese gehören zur Domäne DOMAIN_ROOM
(s. Abbildung 4.8). Zusätzlich verwaltet die Klasse die PWSDescriptoren der PWS, die
für die jeweiligen Untergebiete zuständig sind.
Die Hauptfunktionen der Klasse ServiceArea sind die Konvertierungen zwischen
geometrischen und symbolischen Positionsinformationen.
Die Funktion getGeometricPosition() erwartet als Eingabe eine symbolische Position
und überprüft dann alle Untergebiete daraufhin, ob sie diese Position verwalten.
Verwaltet ein PWS zum Beispiel eine Gebäudeetage, dann würde nach einem
bestimmten Zimmer gesucht. Dazu müssen alle LogicalArea-Objekte nach ihrer
symbolischen Position befragt werden. Nach dem Auffinden dieses Zimmers wird die
geometrische Position des Zimmers zurückgegeben. Die geometrische Position wird
beim Instanziieren der ServiceArea-Klasse spezifiziert. Analog dazu kann die Funktion
getSymbolicPosition() die Umrechnung von geometrischen Angaben in symbolische
vornehmen. Zu diesem Zweck wird zuerst mittels der Funktion rightFloor() überprüft,
ob sich das Objekt in der richtigen Etage befindet. Ist dies der Fall, wird von jedem
LogicalArea-Objekt die Überlappung der angegebenen geometrischen Position mit dem
Untergebiet berechnet. Da die Berechnung der Überlappung rechenintensiv ist, wird
zunächst in einem schnellen Pre-Test mithilfe der Funktion mightContain() der Klasse
LogicalArea überprüft, ob eine Überlappung möglich ist, sodass im positiven Fall die
Überlappung schließlich ausgerechnet wird. Das ServiceArea überprüft dann, ob die für
80
das Zuständigkeitsgebiet verlangte Überlappung erreicht wird, d. h. ob die angegebene
geometrische Position innerhalb dieses logischen Gebietes liegt. Die symbolische
Position des so identifizierten logischen Gebietes ist die gesuchte. Die verlangte
Überlappung sollte möglichst mehr als fünfzig Prozent betragen, sodass nur genau ein
Untergebiet in Frage kommen kann. Andernfalls wäre es zum Beispiel möglich, dass
sich ein Objekt genau zwischen zwei Zimmern befindet und bei beiden eine
Überlappung von 50% ausgerechnet wird. In diesem Fall würde der Positionsdienst nur
die symbolische Position der nächsthöheren Domäne, d. h. hier der Etage, zurückgeben.
Eine weitere Funktion der Klasse ServiceArea namens getPWS() ermittelt den für eine
bestimmte symbolische Position zuständigen PWS. Dazu muss nur das entsprechende
logische Gebiet gesucht und der zuständige PWS zurückgegeben werden.
5.3.3.2
Die Klasse LogicalArea
Die Klasse LogicalArea verwaltet alle Daten eines logischen Gebietes. Da ein logisches
Gebiet aus mehreren konvexen Polygonen bestehen kann, enthält diese Klasse eine
Liste der Polygone, dessen Punkte gegen den Uhrzeigersinn angegeben werden müssen.
Die Punkte eines Polygons werden dabei in absoluten Koordinaten, d. h. nach dem
WGS84 (s. Kapitel 2.1.1.2), angegeben.
Die Hauptaufgabe dieser Klasse ist, die Überlappung eines mobilen Objektes mit dem
verwalteten logischen Gebiet festzustellen. Dazu wird zunächst mit der Funktion
rightFloor() überprüft, ob die Höhenangabe zwischen der Boden- und der Deckenhöhe
des logischen Gebietes liegt. Dann kann durch den Aufruf der Funktion mightContain()
überprüft werden, ob eine Überlappung ausgeschlossen werden kann. Dazu wird in
dieser Funktion mithilfe des Rechtecks, das das logische Gebiet umgibt, und einem
Rechteck, das den Aufenthaltskreis umgibt, festgestellt, welche Lage die beiden
Rechtecke zueinander haben. Wenn die beiden Rechtecke keine Schnittfläche besitzen,
kann auch keine Überlappung zwischen dem Polygon und dem Aufenthaltskreis
vorliegen. Schneiden sich die beiden Rechtecke, so ist diese Tatsache nur ein Hinweis
auf eine mögliche Überlappung, da es zum Beispiel auch sein kann, dass sich nur das
Rechteck, das den Kreis umschließt, nicht aber der Kreis selbst, mit dem Polygon
schneidet.
81
Daher muss nun mit der Funktion getOverlap() die tatsächliche Überlappung
ausgerechnet werden. Dazu werden Überlappungen des Aufenthaltskreises mit allen
Polygonen überprüft, die das logische Gebiet definieren, und diese werden zur
Gesamtüberlappung addiert. Da die Punkte des Polygons in Koordinaten nach WGS84
vorliegen, werden diese als erstes auf die flache Erde projiziert, wobei der Mittelpunkt
des Aufenthaltskreises, d. h. die Position des Objektes, der Ursprung des approximierten
Koordinatensystems ist. Mit den so berechneten Punkten wird ein Objekt der Klasse
Polygon instanziiert, das die Überlappungsberechnung durchführt. Dazu wird jede
Kante des Polygons nacheinander mit dem Kreis geschnitten (s. Abbildung 5.4).
Abbildung 5.4: Berechnung der Überlappung
Haben Kreis und Kante einen Schnittpunkt oder liegt einer der Eckpunkte der Kante
innerhalb des Kreises, so werden diese in eine Liste aufgenommen. Nachdem alle
Kanten überprüft wurden, enthält diese Liste einerseits alle Schnittpunkte von Kreis und
Polygon und andererseits die Eckpunkte, die innerhalb des Kreises liegen. Die Punkte
aus dieser Liste bilden auch ein Polygon, dessen Fläche berechnet wird. Zu dieser
Fläche müssen noch die Kreissegmente hinzuaddiert werden, die auch zur Schnittfläche
gehören. Danach kann ausgerechnet werden wie viel Prozent die Schnittfläche vom
gesamten Kreis ausmacht.
5.3.4
Client-Applikation
In dieser Arbeit wird eine ortsbewusste Applikation implementiert, die den
Positionsdienst
mithilfe
der
Position-Service-Engine
benutzt.
Diese
einfache
Applikation dient der Demonstration der möglichen Funktionalität und deren Einsatz.
Dabei wird auf einem Server-Computer der Position-Web-Service bereitgestellt, der mit
Daten über eine Etage eines Gebäudes der Technischen Universität Kaiserslautern
82
konfiguriert ist. Die Applikation zeigt, wie geometrische Positionsangaben des realen
oder simulierten GPS-Empfängers in symbolische umgerechnet werden können. Dabei
wird der GPS-Empfänger so benutzt, dass mindestens angezeigt werden kann, in
welchem Zimmer sich der Empfänger befindet.
83
6
Zusammenfassung und Ausblick
Ein Positionsdienst bildet die Grundlage für die Nutzung ortsabhängiger Dienste. Dieser
Positionsdienst sollte möglichst innerhalb und außerhalb von Gebäuden funktionieren
und
daher
ein
dynamisches
Einbinden
verschiedener
Lokalisierungssysteme
unterstützen. In der aktuellen Forschung werden viele Ansätze verfolgt und
Technologien verwendet, um Positionen von Objekten zu ermitteln. Um mehrere
Lokalisierungssysteme vergleichen zu können, wurde daher am Anfang dieser Arbeit
ein Überblick über verschiedene Verfahrensweisen zur Positionsbestimmung gegeben.
Dabei wurden die Lokalisierungstechniken Triangulation, Analyse des Ortes und
Näherungsmessung beschrieben.
Die
heutigen
Lokalisierungssysteme
liefern
verschiedene
Formen
von
Positionsangaben. Um die Verwendung beliebiger Lokalisierungssysteme sicher zu
stellen,
wurden
verschiedene
Positionierungsmodelle
betrachtet.
Fazit
dieser
Betrachtung ist, dass ein Positionsdienst sowohl geometrische (z. B. geographische
Koordinaten), als auch symbolische, d. h. auf von Personen lesbaren abstrakten
Bezeichnern basierte, Positionsangaben unterstützen sollte.
Um ein neues Modell für einen Positionsdienst zu entwerfen, wurde zunächst ein
Vergleich von unterschiedlichen realen Lokalisierungssystemen durchgeführt, die
repräsentativ für eine benutzte Technologie sind. Die Lokalisierungssysteme wurden in
drei Hauptkategorien eingeteilt, die satellitengestützten, die zellfunkgestützten und die
Indoor-Lokalisierungssysteme. Für den Vergleich wurden Kriterien aufgestellt, aus
denen das Modell des Positionsdienstes entwickelt werden konnte.
Durch den Vergleich konnten die Hauptkomponenten identifiziert werden, aus denen
ein Positionsdienst bestehen muss, um alle Lokalisierungssysteme zu unterstützen.
Manche Lokalisierungssysteme benutzen ein Empfangsgerät, das auf dem mobilen
Objekt zur Positionsbestimmung verwendet wird, d. h. die Berechnung findet auf dem
mobilen Rechengerät selbst statt. Andere Lokalisierungssysteme brauchen eine
Infrastruktur, zum Beispiel in Form eines Sensorennetzwerkes, die Signale von den
mobilen Objekten empfängt und so die Position berechnet. Diese Position kann dann
über eine Netzwerkkomponente abgefragt werden. Aus diesem Grund wurde der
Positionsdienst
mithilfe
einer
Client-Server-Architektur
konzipiert.
Die
85
Server-Komponente wurde auf Basis von Web-Services entwickelt, da so ein
standardisierter Zugriff auf die Funktionen der Server-Komponente ermöglicht wird.
Im Anschluss an die Modellierung wurde der Positionsdienst in Java realisiert. Eine
Beispiel-Anwendung demonstriert mit einem realen GPS-Empfänger, wie der
Positionsdienst arbeitet.
Die derzeitige Realisierung hat nur einen prototypische Charakter. Die Konfiguration
der Zuständigkeitsgebiete der einzelnen Position-Web-Services erfolgt im Moment
statisch, d. h. durch Einlesen einer manuell erstellten Textdatei. Hier wäre es
wünschenswert, eine Möglichkeit zu entwickeln, diese Daten komfortabeler
einzustellen. Es wäre auch eine Anbindung des Systems an ein sogenanntes
Geographisches Informationssystem (GIS) denkbar. Diese Informationssysteme
verwalten Daten über Orte der Erde und sind die elektronische Form von Landkarten.
Eine zusätzliche Verbesserung wäre die Erweiterung der ortsbewussten BeispielAnwendung, sodass genaue Karten dargestellt werden können. Außerdem sollte neben
dem benutzen GPS-Empfänger eine Indoor-Technologie installiert werden. Hier wären
zum Beispiel Techniken interessant, die Wireless-LAN zur Positionsermittlung
benutzten, wie RADAR (s. Kapitel 3.4.4), weil in den meisten Fällen die Access Points
schon vorliegen und keine weitere Infrastruktur benötigt wird.
86
7
Anhang A
Zwei Schnittstellen sollen hier näher betrachtet werden. Die erste ist die Schnittstelle,
über die ein Zugriff auf die Hardware ermöglicht wird und die zweite ist die
Schnittstelle zum Web-Service.
7.1 Die Schnittstelle zur Hardware
Die Schnittstelle LSDevice:
//-------------------------------------------------------------/**
* Sets the device specific properties. <BR>
* This could include setting the LocatableObjectDescriptor if
* recognition is necessary or the reference position that is
* needed for a convertion of relative to absolute positions.
*
* @param properties
*/
public void configure( Properties properties );
//-------------------------------------------------------------------/**
* Initialize the hardware.
*/
public void initialize();
//-------------------------------------------------------------------/**
* The descriptor defines which kind of position information the device
* can deliver.
* @see positionService.descriptor.LSDeviceDescriptor
*
* @return the descriptor
*/
public LSDeviceDescriptor getDescriptor();
//-------------------------------------------------------------------/**
* If the Device can deliver it return geometric positions. Return invalid
* geometric position if it cannot.
*
* @return a geometric position
*/
public GeometricPosition getGeometricPosition();
//-------------------------------------------------------------------/**
* If the Device can deliver it return symbolic positions. Return invalid
* symbolic position if it cannot.
*
* @return a symbolic position
*/
public SymbolicPosition getSymbolicPosition();
//------------------------------------------------------------------/**
* If the Device can deliver it return the geometric orientation.
* Return Constants.UNKNOWN if it cannot.
*
* @return orientation angle in degree
87
*/
public double getGeometricOrientation();
//-------------------------------------------------------------------/**
* If the Device can deliver it return symbolic orientation. Return
* invalid symbolic position if it cannot.
*
* @return symbolic orientation
*/
public SymbolicPosition getSymbolicOrientation();
//-------------------------------------------------------------------/**
* Test if the hardware can deliver positions.
*
* @return true if location sensing is available
*/
public boolean isLocationSensingAvailable();
//-------------------------------------------------------------------/**
* Activate this device.
*/
public void activate();
//-------------------------------------------------------------------------/**
* Return if the device is active.
*
* @return true if the device is active
*/
public boolean isActive();
7.2 Die Schnittstelle des Web-Services
Die Schnittstelle PositionWebServiceIF:
//-------------------------------------------------------------------------/**
* Asks the PWS which PWS is responsible for the symbolic position sp.
* Returns this PWS if no other PWS is responsible.
*
* @param ws_sp
* @return the PWS descriptor
* @throws RemoteException
*/
public WS_PWSDescriptor getPWS( WS_SymbolicPosition ws_sp )
throws RemoteException;
//-------------------------------------------------------------------------/**
* Asks the infrastructure to determine the geometric position.
* The infrastructure will need to identify the locatable object.
*
* @param lo
* @return the geometric position
* @throws RemoteException
*/
public WS_GeometricPosition getGeometricPosition(WS_LocatableObjectDescriptor
lo ) throws RemoteException;
//-------------------------------------------------------------------------/**
* Asks the infrastructure to determine the symbolic position.
* The infrastructure will need to identify the locatable object.
88
*
* @param lo
* @return the symbolic position
* @throws RemoteException
*/
public WS_SymbolicPosition getSymbolicPosition(WS_LocatableObjectDescriptor lo
) throws RemoteException;
//-------------------------------------------------------------------------/**
* Convert the symbolic position to the geometric position.
*
* @param sp
* @return the geometric position
* @throws RemoteException
*/
public WS_GeometricPosition getGeometricPosition( WS_SymbolicPosition sp )
throws RemoteException;
//-------------------------------------------------------------------------/**
* Convert the geometric position to the symbolic position.
*
* @param gp
* @return the symbolic position
* @throws RemoteException
*/
public WS_SymbolicPosition getSymbolicPosition( WS_GeometricPosition gp
)throws RemoteException;
//-------------------------------------------------------------------------/**
* Convert the orientation to symbolic orientation.
*
* @param gp the geographic position
* @param orientation angle in degree
* @return the symbolic orientation
* @throws RemoteException
public WS_SymbolicPosition getSymbolicOrientation( WS_GeometricPosition gp,
double orientation )throws RemoteException;
89
8
Anhang B
Hier wird das Beispiel einer Konfigurationsdatei gezeigt, die von der Klasse
ServiceAreaLoader geladen wird und dazu dient, ein ServiceArea-Objekt zu
konfigurieren. Die Daten dieser Datei definieren ein Zuständigkeitsgebiet, das aus
einem logischen Untergebiet besteht.
// A SERVICE AREA- File
// This is an example for an service area file.
//-------- number of logical areas (service area included)
2
//======== first logical area
=================================================
//======== la descriptor ========
// guid
3203
// name
Building 32
// description
Building of the computer science department.
// mobility (mobile=2, static=4)
4
// scale (indoor=2, outdoor=4)
2
// domain(see descriptor.Constants)
64
//======== end la descriptor ========
// symbolic position
TU_KL.Building_32.floor_3
// the geographic position
53.89212; 8.68694; 12
// the demanded accuracy (in meter)
0.09
// the demanded overlap (in %)
55
// the demanded height accuracy
0.1
// the minimum floor (in meter/ -1 if not relevant)
-1
// the maximum floor (in meter/ -1 if not relevant)
-1
//======== the boundary ========
// number of polygons
2
// number of points in polygon0
4
49.4465282719616; 7.763050000000001; 0.0
49.4465282719616; 7.763239291114333; 0.0
49.44657678098693; 7.763239291114333; 0.0
49.44657678098693; 7.763050000000001; 0.0
// number of points in polygon1 (example: 54.89212; 7.68694; 12)
4
49.446508509025335; 7.763050000000001; 0.0
49.446508509025335; 7.763239291114333; 0.0
49.4465282719616; 7.763239291114333; 0.0
49.4465282719616; 7.763050000000001; 0.0
//======== PWS Descriptor ========
// GUID
1
// name
Building 32, floor 3 PWS
90
// description
Building 32, floor 3 PWS. Installed LSS: none;
// URLString
http://localhost:8080/PositionWebService-jaxrpc/PositionWebService?WSDL
// NameSpace URI
PositionWebService/PositionWebService
// ServiceName
PositionWebService
// PortName
PositionWebServiceIFPort
//======== next logical area
==================================================
//======== la descriptor ========
// guid
3203349
// name
conference room
// description
conference room of the AG ICSY.
// mobility (mobile=2, static=4)
4
// scale (indoor=2, outdoor=4)
2
// domain(see descriptor.Constants)
256
//======== end la descriptor ========
// symbolic position
TU_KL.Building_32.floor_3.Room349
// the geographic position
53.89212; 8.68694; 12;
// the demanded accuracy (in meter)
0.09
// the demanded overlap (in %)
55
// the demanded height accuracy
0.1
// the minimum floor (in meter/ -1 if not relevant)
-1
// the maximum floor (in meter/ -1 if not relevant)
-1
//======== the boundary ========
// number of polygons
1
// number of points in polygon
4
49.4465282719616; 7.763050000000001; 0.0
49.4465282719616; 7.763239291114333; 0.0
49.44657678098693; 7.763239291114333; 0.0
49.44657678098693; 7.763050000000001; 0.0
//======== PWS Descriptor ========
// GUID
1
// name
Building 32, floor 3 PWS
// description
Building 32, floor 3 PWS. Installed LSS: none;
// URLString
http://localhost:8080/PositionWebService-jaxrpc/PositionWebService?WSDL
// NameSpace URI
PositionWebService/PositionWebService
// ServiceName
PositionWebService
// PortName
PositionWebServiceIFPort
//======== next logical area
==================================================
//======== end ========= ==================================================
91
9
Literaturverzeichnis
[AdCu01] Addlesee, M.; Curwen, R.; Hodges, S.; Newman, J.; Steggles, P.; Ward, A.
and Hopper, A.: Implementing a Sentinent Computing System
IEEE Computer Magazine, pp. 50 - 56. August 2001.
[BaPa00] P. Bahl and V. Padmanabhan:
RADAR: An In-Building RF-Based User Location and Tracking System
Proc. IEEE Infocom 2000, IEEE CS Press, Los Alamitos, Calif., 2000, pp.
775-784
[BaRo03] Hari Balakrishnan, Roshan Baliga, Dorothy Curtis, Michel Goraczko, Allen
Miu, Nissanka B. Priyantha, Adam Smith, Ken Steele, Seth Teller, Kevin
Wang:
Lessons from Developing and Deploying the Cricket Indoor Location
System
MIT Computer Science and Artificial Intelligence
Laboratory,(CSAIL)November 2003
[BeGr95] J. Ross Beveridge, Christopher Graves and Christopher E. Lesher:
Local Search as a Tool for Horizon Line Matching
Technical Report CS-96-109 des Computer Science Department der
Colorado State University, December 16, 1995
[Bell02]
Tom Bellwood, Senior Technical Staff Member:
Understanding UDDI
IBM , July 2002
http://www-106.ibm.com/developerworks/library/ws-featuddi/
[ChJe02]
David Chappell, Tyler Jewell:
Java Web-Services
O'Reilly, March 2002
[DANA95] Peter H. Dana:
Coordinate Systems Overview
Department of Geography, University of Texas at Austin, 1995
http://www.colorado.edu/geography/gcraft/notes/coordsys/coordsys_f.html
[Durr02]
Hugh Durrant-Whyte:
Introduction to Sensor Data Fusion,
http://www.acfr.usyd.edu.au/teaching/graduate/Fusion/index.html, 2002
[EdWi03] Ed Williams:
Aviation Formulary V1.41
http://williams.best.vwh.net/index.html, 2003
[GALI04] Mitteilung der Kommission der europäischen Gemeinschaften an das
Europäische Parlament und den Rat:
Stand der Durchführung des Forschungsprogramms GALILEO zu Beginn
des Jahres 2004
92
http://europa.eu.int/comm/dgs/energy_transport/galileo/documents/doc/com
_2004_0112_de.pdf
[Garm00] Garmin Corporation:
Beginner’s Guide to GPS ,
http://www.garmin.com/aboutGPS/manual.html
2000
[HiBo01] J. Hightower, G. Borriello:
A Survey and Taxonomy of Location Systems for Ubiquitous Computing
University of Washington, Technical Report UW-CSE 01-08-03, August 24,
2001
[Hito03]
Jeffrey Hightower:
From Position to Place
In “Proceedings of The 2003 Workshop on Location-AwareComputing”,
pages 10–12, October 2003. part of the 2003 Ubiquitous Computing
Conference.
[Leon98]
Leonhardt, U.:
Supporting Location Awareness in Open Distributed Systems
PhD thesis, Department of Computing, Imperial College of Science,
Technology and Medicine,University of London, 1998
[NaSc00] Natalia Marmasse, Chris Schmandt:
Location-aware information delivery with comMotion
HUC 2000 Proceedings, pp.157-171, Springer-Verlag
[NiPr00]
Nissanka B. Priyantha, Anit Chakraborty, Hari Balakrishnan:
The Cricket Location-Support system
Proc. 6th ACM MOBICOM, Boston, MA, August 2000.
[RoGr00] Robert J. Orr and Gregory D.:
The Smart Floor: A Mechanism for Natural User
GVU Technical Report GIT-GVU-00-02 (full paper), January 2000
[Roßb00] Udo Roßbach:
Positioning and Navigation Using the Russian Satellite System GLONASS,
Universität der Bundeswehr München, 2000
[Schu96]
Schumann, T. Dipl. Ing.:
Global Positioning System - GPS
Fachgebiet Elektronische Messtechnik des Instituts für Kommunikationsund Messtechnik, Technische Universität Ilmenau 1996
http://ikmcip1.e-technik.tu-ilmenau.de/~traut/gps_www/gps_main.htm
[Schu03]
Schuman, Toralf Dipl.Ing.:
Global Positioning System – GPS
http://www.toralf-schumann.de/html/gps_prz.html
[SiRF02]
SiRF Technology, Inc.
NMEA Reference Manual
93
http://www.sirf.com
2002
[Snap03]
Snaptrack Incorporated:
Location Technologies for GSM, GPRS and UMTS Networks
2003
[WaHo92] Roy Want, Andy Hopper, Veronica Falcão and Jonathan Gibbons:
The Active Badge Location System
ACM Transactions on Information Systems, January 1992
94