Inhaltsverzeichnis
Werbung
Inhaltsverzeichnis 1 Einleitung 1 2 Anforderungen an das Präsentationssystem 2 2.1 Lokationssysteme im Überblick ........................................................2 2.1.1 Active Badge System ..................................................................2 2.1.2 Cricket System ............................................................................4 2.2 Analyse ..............................................................................................6 2.3 Anforderungsermittlung ....................................................................7 3 Designmodell 9 3.1 Drei-Schicht Modell ..........................................................................9 3.2 Interaktion zwischen den Modulen .................................................10 4 Implementierung 12 4.1 Cell-of-Origin Lokationssystem mit Smart-Its Particles.................12 4.2 Software Umgebung ........................................................................13 4.3 Implementierung der Präsentationsschicht......................................14 4.3.1 Benutzeroberfläche für Lokationsdatenmodell .........................14 4.3.2 Benutzeroberfläche für Lokationsbeschreibung und Lokationsbindungsdienst ..........................................................19 4.3.3 Benutzeroberfläche für die Präsentation der Lokationsinformation ................................................................21 4.4 Implementierung der Informationsbasis und der Schicht für Verarbeitung und Filtrierung ...........................................................24 5 Zusammenfassung 29 Literaturverzeichnis 30 1 Einleitung Eine Reihe von Lokationssystemen sind entwickelt wurden, um Anwendungen von Ubicomp zu unterstützen, wobei diese Anwendungen von der Lokationsinformation abhängig sind [1]. Bisherige verwendete Lokationssysteme in Ubicomp besitzen die folgenden Eigenschaften: 1. Jedes Lokationssystem hat seine eigene Benutzeroberfläche. 2. Die Benutzeroberfläche ist stets in das gesamte System integriert. Daher unterstützt die Benutzeroberfläche eines Lokationssystems die Präsentation der Lokationsinformation anderer Lokationssysteme nicht. In diesem Fall ist es schwierig, die Lokationsinformationen der verschiedenen Lokationssysteme auf eine ähnliche Weise darzustellen. Dies motiviert die Trennung von der Präsentation des Lokationsinformation vom Lokationssystem. Das Lokationssystem liefert nur noch Positionsdaten von Objekten in dem Lokationssystem eigenen Format. Die Präsentation geschieht unabhängig vom verwendeten Datenlieferanten und Format und erfolgt in einer für den Benutzer übersichtlichen Weise. Ziel dieser Studienarbeit ist es daher, ein Präsentationssystem zu entwerfen, das die Präsentation von Lokationsinformation verschiedener Lokationssysteme erlaubt. Das Präsentationssystem wird nicht für ein spezifisches Lokationssystem entwickelt, sondern soll sich an verschiedene Lokationssysteme anpassen können. Im Kapitel 2 werden zwei Lokationssysteme, nämlich das Active Badge Location System und das Cricket Location-Support System, vorgestellt und miteinander verglichen. Mit Hilfe von Vergleichen und Analysen werden die Anforderungen an das Präsentationssystem formuliert. Das Kapitel 3 beschreibt ein für das Präsentationssystem entworfene 3-Schicht Model. Im Kapitel 4 wird die konkrete Implementierung des Präsentationssystems betrachtet. Das Kapitel 5 fasst diese Arbeit zusammen. 1 2 Anforderungen an das Präsentationssystem In diesem Kapitel werden die Anforderungen an ein einheitliches Präsentationssystem formuliert. Dazu werden zwei typische Vertreter im folgenden detailliert vorgestellt. Anhand der Analyse der zwei Systeme werden die Anforderungen ermittelt. 2.1 Lokationssysteme im Überblick 2.1.1 Active Badge System Das von Olivetti Research Ltd. (ORL) entwickelte Active Badge System [2] ist in der Lage, durch die Ermittelung des Standorts von Badges seinen Träger in eine Umgebung zu verfolgen. Das Badge ist ein kleines elektronisches Gerät, welches eine eindeutige ID seines Besitzers per Infrarot periodisch sendet. Ortsfeste Sensorstationen empfangen die Information und geben sie an einen Server über das drahtgebundene Netzwerk weiter. Der Server bearbeitet die Daten und stellt diese dann einem Client zur Verfügung, der die Information auf eine anschauliche Weise darstellen kann. Das gesamte System wurde als 4-Schichten-Architektur implementiert. Abb. 2.1. veranschaulicht den Aufbau. Abbildung 2. 1:Vier-Schichten-Architektur des Active Badge Systems Netzwerk-Controller Der Netzwerkcontroller ist verantwortlich für die Abfrage der ortsfesten Sensorstation, von der als nächstes Sensordaten abgeholt werden sollen. 2 Repräsentation Dieses Schicht erzeugt ein geeignetes Format für die Repräsentation der aufgezeichneten Sensordaten. Diese werden in Tripel gepackt, die den Zeitstempel, die Lokation und die ID des Badges enthalten. Datenverarbeitung Da zahlreiche Daten in kurzer Zeit gesammelt werden, müssen diese Daten gefiltert und komprimiert werden. Beispielsweise ist es nicht notwendig, Positionsdaten eines Badges weiterzugeben, das seinen Aufenthaltsort nicht geändert hat. Es muss lediglich der Zeitpunkt der letzten Sichtung an dem Ort aktualisiert werden. Darstellungsschnittstelle Diese Schicht ist zuständig für die Darstellung der Lokationsinformationen, die die ersten drei Schichten liefern. Dies kann beispielsweise durch textliche Darstellungen geschehen, oder auch durch graphische Visualisierungen von Räumen und Menschen. Abb. 2.2 veranschaulicht die textliche Darstellung. Abbildung 2. 2:Textliche Darstellung der Lokationsinformation Ergänzend zur textlichen Darstellung wird noch ein Command Interpreter im System eingesetzt. Die in dem Command Interpreter ausführbare Befehle unterstützen den Benutzer bei Abfragen. Die benutzten Befehle sind, FIND (name) Gibt die aktuelle Lokation des bezeichneten Badges zurück. Falls der Standort des Badges vor kurzer Zeit geändert wurde, werden alle in den letzten fünf Minuten ermittelte Standorte zurückgegeben. WITH (name) Lokalisiert das bezeichnete Badge und stellt die Information anderer Badges, die in der selben Lokation liegen, zur Verfügung. 3 LOOK (location) Ermittelt welches Badge in der vorgegebenen Lage vorliegt. HISTORY (name) Erstellt einen Bericht über die Historie des Standorts des bezeichneten Badges während einen Stunden. 2.1.2 Cricket System Das Cricket System [3] ist ein Location-support System für innere, mobile und lokationsabhängige Anwendungen. In diesem System spielen zwei kleine verschiedenartige Gräte, nämlich „Beacon“ und „Listener“, wichtige Rollen. Durch die Zusammenarbeit der beiden stellen die Anwendungen ihren physikalischen Orte fest. Das Beacon ist ein kleines ortsfestes Gerät und liegt in einem geographischen Raum. Es ist zuständig für die Verbreitung der geographischen Information innerhalb des geographischen Raums. Hingegen hören die Listeners den Nachrichten des Beacons zu und leiten daraus ihre eigenen Standorte ab. Der Listener wird an Dienstesknoten (Drucker, TV usw.) und mobile Geräte angeschlossen. Sobald der Listener die Lokationsinformation bekommt, leitet er die Information an die Dienstesknoten oder die mobilen Geräte weiter. Nachdem die Dienstesknoten diese Information erhalten haben, melden sie sich bei einem Resource Discovery Dienst an. Die Applikationen von Benutzern melden sich nicht an, sofern sie nicht von anderen entdeckt werden wollen. Im von MIT Laboratory entwickelte Cricket System wurden noch das INS (Intentional Naming System ) [4] und ein Map Server eingesetzt. Das INS ist hier als ein Resource Discovery Dienst verwendet. Ein wesentlicher Begriff im INS ist der des virtuellen Raum. Der virtuelle Raum ist eine Ansammlung von Anwendungen oder Diensten. Jeder virtuelle Raum besitzt eine Reihe von Name Resolvers, die Anfragen von Namen der in dem virtuellen Raum exsistierten Einheiten beantworten. Jede Einheit ist durch einen Intentional Name, der eine hierarchische Ansammlung von Werten und Attributen der Einheit ist, beschrieben. Wir werden durch eine konkrete Anwendung des Cricket Systems, nämlich Floorplan, erklären, wie die Lokationsinformation verarbeitet und danach dem Benutzer präsentiert wird. Das Floorplan ist eine Navigationsanwendung, die einen Benutzer bei der Ermittlung seines Standorts in einem Gebäude helfen kann. Darüber hinaus werden die in der 4 Nähe des Benutzers vorhandene Dienste angezeigt. Diese werden bei der Bewegung des Benutzers immer dynamisch aktualisiert. Als Erstes werden Zimmer und Etage durch virtuelle Räume dargestellt. Jeder virtuelle Raum wird durch ein Zeichenkette identifiziert. Der Map Server enthält den Lageplan der Gebäude und die Abbildung zwischen den virtuellen Räumen und die dazugehörigen Koordinaten auf dem Lageplan. Jedes Beacon verbreitet den Namen des virtuellen Raums, in dem es sich befindet. Während ein Benutzer sich in dem Gebäude bewegt, kann der Listener die aktuelle Lokationsinformation, nämlich den Namen des virtuellen Raums, ausrechnen und holt dann die Koordinaten des virtuellen Raums von dem Map Server ab. Danach markiert der Floorplan diese Koordinaten auf dem vorher von dem Map Server heruntergeladenen Lageplan. Da die in einem virtuellen Raum vorhandenen Dienste sich bei dem INS angemeldet haben, kann der Listener durch das Abfragen des INS solche Dienste entdecken und auf dem Lageplan anzeigen. Abb.2.3 veranschaulicht das von dem Floorplan angezeigte aktuelle Bild. Abbildung 2. 3: Navigationsanwendung: Floorplan Aus diesem Bild ist zu erkennen, dass der Benutzer (dargestellt durch einen Punkt) sich jetzt im Zimmer 504 befindet. Einige Dienste (dargestellt durch die entsprechenden Symbole) sind ihn zur Verfügung gestellt, wie z.B. TV Dienst und MP3 Dienst. 5 2.2 Analyse Im letzten Abschnitt wurden zwei Lokationssysteme detailliert vorgestellt. Bei näherer Betrachtung der Systeme kann man dabei Unterschiede und Gemeinsamkeiten feststellen, wie die Lokationsinformation dargestellt und interpretiert wird. Die in dem Active Badge System definierte Lokationsinformation ist eine 3-Tupel mit (BadgeID, Lokation, Zeitstempel). Die gepackten Informationen werden zuerst verarbeitet und anschließend als Eingabe an die Darstellungsschnittstelle weitergegeben. Die Darstellungsschnittstelle des Active Badge Systems interpretiert die Informationen und präsentiert dem Benutzer dieses Ergebnis auf eine textliche Weise. Bei der Vorstellung des Active Badge System wurde auch ein Command Interpreter erwähnt. Dieser Command Interpreter soll als eine Benutzeroberfläche zur Präsentation der Lokationsinformationen betracht werden. Benutzer geben die Befehle in dem Command Interpreter ein, und dieser Command Interpreter zeigt verschiedene Information an, z.B. die aktuelle Lokation einer Badge oder alle Badges in einer Lokation. In dem Cricket System wird die geographische Lokation als ein virtueller Raum bezeichnet. Jeder virtuelle Raum wird durch eine Zeichenkette identifiziert. Der Listener hört die von Beacon verbreitete Information ab und rechnet die Lokationsinformation aus. Jedoch kann diese Lokationsinformation nicht ummittelbar an den Benutzer weitergegeben werden. Sie muss durch den Map Server interpretiert werden. Danach kann das Ergebnis dem Benutzer präsentiert werden. Beide erwähnten Lokationssysteme definieren eigene Formate der Lokationsinformation, wie z.B. die 3-Tupel im Active Badge System und der virtuelle Raum im Cricket System. Die Interpretation der Lokationsinformation ist unterschiedlich und wird durch verschiedene Module erledigt. Im Active Badge System ist eine Darstellungsschnittstelle zu diesem Zweck verwendet. Dagegen ist im Cricket Sytem ein Map Server verantwortlich für die Interpretation der Lokationsinformation. Die Präsentation der Lokationsinformation ist je nach Lokationssystem auf verschiedene Weise implementiert. Die Lokationsinformation im Active Badge System wird textlich präsentiert, und das Cricket System stellt die Lokationsinformation auf graphische Weise dar. Die beiden Systeme besitzen eigene Module, die das unterstützen. Im Active Badge System wird das Modul „Darstellungsschnittstelle“ genannt. Im Cricket System ist das Modul in der Anwendung „Floorplan“ eingebaut. Sowohl die Darstellungsschnittstelle des Active Badge System als auch das in dem „Floorplan“ eingebaute Modul müssen 6 von dem jeweiligen System direkt unterstützt werden. Im Cricket System wird es von dem Map Server unterstützt. Im Active Badge System übernehmen die darunter liegenden Schichten die Verantwortung dafür. Bei einer näheren Betrachtung der beide Systeme wird festgestellt, dass die Faktoren, die die Präsentation der Lokationsinformation eines Lokationssystems beeinflussen, im Wesentlichen folgenden drei Kategorien angehören: Das Format der Lokationsinformation: Es definiert die Syntax der Lokationsinformation. Die Interpretation der Lokationsinformation Der Entwurf des für die Präsentation der Lokationsinformation verantwortlichen Moduls: Je nach dem Entwurf des Moduls kann die Lokationsinformation auf graphische oder textliche Weise den Benutzern präsentiert werden. 2.3 Anforderungsermittlung In diesem Abschnitt wird nun analysiert, welche Anforderungen ein einheitliches Präsentationssystem erfüllen soll. Ziel des Entwurfs des Präsentationssystems ist die kohärente Darstellung verschiedener Lokationsinformation. Ein wichtiger Schritt davon ist die Separation des Präsentationsmoduls von dem übrigen Lokationssystem. Nur wenn das Präsentationsmodul nicht abhängig von einem spezifischen Lokationssystem ist, kann es als eine gemeinsame Benutzeroberfläche für die Präsentation der verschiedenen Lokationsinformation aus unterschiedlichen Lokationssystemen angewendet werden. Aufgrund der im Abschnitt 2.2 beschriebenen drei Faktoren ist die Trennung des Präsentationsmoduls von dem ganzen Lokationssystem nicht unkompliziert. Das vom Lokationssystem definierte Format der Lokationsinformation muss im Präsentationssystem sichtbar sein. Damit kann das Präsentationssystem die verschiedenen Formate der Lokationsinformation erkennen. Das Präsentationssystem muss in der Lage sein, die Lokationsinformation auf eigene Weise zu interpretieren. Die einheitliche Darstellung der Lokationsinformation ist sonst durch das Präsentationssystem unmöglich. Das Präsentationssystem soll zudem zusätzliche Funktionalitäten erlauben, die nicht unbedingt vom verwendeten Lokationssystem unterstützt werden. Dazu gehört das Verfolgen von mobilen Geräte. 7 Zusammenfassend ergeben sich die folgenden Anforderungen an das Präsentationssystem, Es kann verschiedene Lokationssystem unterstützen. Die Bedingung dafür lauten, Kompatibilität der verschiedenen Lokationsinformation. Fähigkeit zur Interpretation der Lokationsinformation Präsentation der aktuellen Lokationsinformation. Präsentation der historischen Lokationsinformation. 8 3 Designmodell 3.1 Drei-Schicht Modell Nachdem die Anforderungen an das Präsentationssystem festgelegt wurden, wird im folgenden ein 3-Schichten Modell vorgestellt. Abb. 3.1. verdeutlicht die Architektur des Modells. Abbildung 3. 1: Drei-Schicht Modell Informationsbasis: Diese Schicht ist zuständig für die Ansammlung der Information und das Ablegen der Daten. Sie beinhaltet folgende Module, Lokationsdatenmodell: Es definiert die Syntax der Lokationsinformation. Dieses Modell dient der Anpassung des Präsentationssystems an die verschiedenen Formate der Lokationsinformation. Lokationsbeschreibung: Sie beschreibt den von dem Lokationssystem abgedeckten Raum auf eine graphische Weise, z.B. ein Stadtplan oder ein Lageplan. Lokationsbindungsdienst: Der Lokationsbindungsdienst steht für die Interpretation der nach dem Lokationsdatenmodell gelieferte Daten zur Verfügung, wobei die Interpretation beschreibt, wie die Daten auf die Lokationsbeschreibung abgebildet werden sollen. LokationsDB: Die Lokationsinformation wird in einer Datenbank abgelegt, damit die Historie der Information abgefragt werden kann. Lokationssystem: Es ist ein beim Präsentationssystem angewendetes System, das die mobilen Geräte lokalisieren kann. 9 Verarbeitung und Filtrierung: Die von der Informationsbasis erhaltene Lokationsinformation wird in dieser Schicht verarbeitet. Bei Anforderung der Präsentationsschicht werden die Daten zweckmäßig filtriert. Präsentation: Die Benutzeroberflächen werden in dieser Schicht implementiert. Die Benutzeroberflächen sind zuständig für die Präsentation der Lokationsinformation und die Konfiguration der Module der Informationsbasis. 3.2 Interaktion zwischen den Modulen Die wichtigen Funktionalitäten der Module wurden im Abschnitt 3.1 vorgestellt. Hier werden die Zusammenarbeit der Module und der Zusammenhang zwischen den Module betrachtet. Dabei werden zwei Sichten auf das Präsentationssystem unterschieden. Sicht von der Verwaltung Abbildung 3. 2: Sicht von der Verwaltung Da das Präsentationssystem verschiedene Lokationssysteme unterstützen soll, muss das Modell die Möglichkeit bieten, das Präsentationssystem dem Lokationssystem entsprechend einzustellen. Das Lokationsdatenmodell ist abhängig von dem verwendeten Lokationssystem. Die Konfiguration des Lokationsdatenmodells muss auf dem entsprechenden Lokationssystem beruhen. Der Inhalt der Lokationsbeschreibung soll ausschließlich vom Präsentationssystem entschieden werden. Ein Beispiel dafür: die Lokationsbeschreibung kann ein Lageplan eines Gebäudes sein, falls das Präsentationssystem die Lokationsinformation innerhalb dieses Gebäudes anzeigen soll. Der Lokationsbindungsdienst hat die Aufgabe, eine Abbildung zwischen der Lokationsbe- 10 schreibung und das Lokationsdatenmodell herzustellen. Die Verwaltung dieser drei Module wird direkt durch die Benutzeroberflächen der Präsentationsschicht unterstützt. Sicht von der Anwendung Abbildung 3. 3: Sicht von der Anwendung Die von dem Lokationssystem erhaltene ursprüngliche Lokationsinformation wird in der Mittelschicht mit Hilfe des Lokationsdatenmodells und des Lokationsbindungsdienstes bearbeitet und gefiltriert. Die verarbeiteten Daten werden sowohl in der LokationsDB gespeichert als auch von der Präsentationsschicht aufgenommen. Die abgelegten Daten stehen der Präsentationsschicht für die Ermittelung der Historie der Lokationsinformation zur Verfügung. Die Lokationsbeschreibung wird vorher in die Präsentationsschicht geladen. Danach kann die Lokationsinformation auf der Lokationsbeschreibung markiert werden. 11 4 Implementierung In diesem Kapitel wird die Implementierung des Präsentationssystems aufgrund dem in Kapitel 3 beschriebenen Designmodell vorgestellt. Das hier implementierte Präsentationssystem wird zuerst für das von Smart-Its Particles[5] gestützte Cell-of-Origin Lokationssystem angewendet. Es ist allerdings aufgrund seines Designs auch für andere Lokationssysteme einsetzbar. 4.1 Cell-of-Origin Lokationssystem mit Smart-Its Particles Das Cell-of-Origin (CoO) ist eine Lokalisierungstechnik, die für die Ermittlung der Lokation eines mobilen Gerätes zuständig ist. Wenn ein mobiles Gerät mit einer Basisstation kommuniziert, wird die Lokation des mobilen Gerätes durch die Position dieser Basisstation festgelegt. Dieses Prinzip findet in modernen drahtlosen Kommunikationsnetzwerken, zum Beispiel im GSM Netz[6]. Wichtige Hardware Particle: Ein kleines mobiles Gerät, das Daten und die eigene ID senden kann. XBridge: Ein ortsfestes Gerät mit eigenen Lokationsinformationen, das Daten der Particle erweitert um diese Lokationsinformationen ins UDP Netzwerk schicken kann. 12 Topologie Abbildung 4.1: Topologie des Lokationssystem Das System lokalisiert die mobilen Geräte auf einen Raum. In jeden Raum wird eine XBridge gestellt. Alle XBridges werden an das Netzwerk angeschlossen. Die Particles kommunizieren mit einer XBridge. Die Lokationsinformation und die Daten der Particles werden in das UDP Paket gepackt und durch die XBridge ins Netzwerk gesendet. Lokationsdatenmodell Dieses Lokationssystem verwendet das RAUM[7] Modell zur Beschreibung der inneren Umgebung, z.B. die Büros eines Instituts. Das RAUM Modell stellt die Lokationen semantisch und geometrisch durch ein Benennungsschema dar, wobei das Benennungsschema eine hierarchische Struktur hat und in einem Baumdiagramm dargestellt werden kann. Jeder Knotenpunkt des Baumdiagramms repräsentiert eine Lokation. Der von der Wurzel bis zu dem Zielknoten entstandene Pfad beschreibt eine vollständige Lokation. 4.2 Software Umgebung Wir verwenden die Client/Server-Architektur als die Plattform, auf der das Präsentationssystem laufen kann. Daher ist die Implementierung des Präsentationssystem in zwei Teile aufgeteilt. Abb.4.2 verdeutlicht diese Aufteilung. 13 Abbildung 4.2: Client/Server-Architektur Das Präsentationssystem umfasst drei Java-Applets, die in jedem Browser mit Java Unterstützung laufen können. Außerdem verwenden wir Foxserv[8], eine Apache/mySql/PHP Installation für Windows Betriebssystem, um die ServerPlattform zu unterstützen. 4.3 Implementierung der Präsentationsschicht Die Implementierung der Präsentationsschicht besteht aus drei Benutzeroberflächen, die im Folgenden beschrieben werden. 4.3.1 Benutzeroberfläche für Lokationsdatenmodell Entsprechend dem von diesem Präsentationssystem unterstützten Lokationssystem ist hier das Lokationsdatenmodell auf das RAUM Modell geprägt. Das RAUM Modell in der Benutzeroberfläche wurde durch eine Baumstruktur repräsentiert. Durch die Benutzeroberfläche darf ein Administrator den Baum manipulieren. Die erlaubten Operationen sind, einen Baum erzeugen und löschen, einen Unterbaum oder ein Blatt löschen, Einen Knoten hinzuzufügen den Namen eines Knoten modifizieren. Die maximale Tiefe des Baums einstellen. 14 Zusätzlich können auch die Konfiguration von XBridges mit Lokationsinformation im RAUM-Format und das Suchen von aktuellen XBridges in dieser Benutzeroberfläche durchgeführt werden. Programmbeschreibung Diese Benutzeroberfläche ist durch Java Applet implementiert. Abb.4.3 verdeutlicht die unterschiedlichen Klassen des Programms und den Zusammenhang der Klassen. Abbildung 4. 3: Klassendiagramm Die Klasse „LocationTreeAdmin“ definiert das Aussehen der Benutzeroberfläche für die Manipulation des Lokationsdatenmodells und ist zuständig für die Behandlung der Ereignisse durch den Benutzer. Abb.4.4 verdeutlicht diese Benutzeroberfläche. 15 Abbildung 4. 4: Benutzeroberfläche des Lokationsbaums Die folgenden Abbildungen verdeutlichen die Manipulationen des Baums. Einen Knoten hinzufügen Abbildung 4. 5: Hinzufügen eines Knotens 16 Den Namen eines Knotens modifizieren Abbildung 4. 6: Verändern eines Knotens Knoten oder den Baum löschen Abbildung 4. 7: Löschen Die Tiefe beschränken Abbildung 4. 8: Beschränkung der Tiefe 17 Der Baum wird dauerhaft in der Datenbank gespeichert. Die Klasse „LocationTableDBHandler“ definiert die entsprechenden Methoden, mit denen die Klasse „LocationTree“ auf der Datenbank zugreifen kann. Die Klasse „LocationTree“ ist zuständig für die Veränderung des Aussehens des Baums auf der Benutzeroberfläche. Jede Veränderung des Baums wird durch die beiden Klassen ebenso in die Datenbank gespiegelt. Die Interaktion zwischen der Benutzeroberfläche und der Datenbank ist in Abb.4.9 angegeben. Abbildung 4. 9: Datenfluss bei Veränderung Die Konfiguration einer XBridge ist in Abb.4.10 veranschaulicht. Die vollständige Lokationsinformation eines Knotens ist der von der Wurzel bis zu diesem Knoten entstandene Pfad. Die XBridge ist durch die IP Adresse identifiziert. Abbildung 4. 10: Konfiguration einer XBridge 18 Durch die Kommunikation mit der XBridge wird die Lokationsinformation in der XBridge eingetragen. Wegen der Beschränkung der Sicherheit darf ein Applet ausschließlich mit dem Server, von dem dieses Applet kommt, kommunizieren. Daher wird die eigentliche Konfiguration nicht durch das Applet sondern durch den Server geschaffen. Die Klasse „PreconfigureXPort“ ist nur für folgende Operationen zuständig die Gültigkeit der IP Adresse zu prüfen die Lokationsinformation und die IP Adresse an den Server weiterzugeben. Wir werden die Implementierung des Servers im Abschnitt 4.4 vorstellen. 4.3.2 Benutzeroberfläche für Lokationsbeschreibung und Lokationsbindungsdienst Da das Von Smart-Its Particles gestützte Cell-of-Origin Lokationssystem derzeit nur im Rahmen von einer Etage verwendet wird, stellt diese Benutzeroberfläche die Lokationsbeschreibung als einen Lageplan der Etage dar. Die Benutzeroberfläche integriert einen Editor, mit dem der Lageplan bearbeitet werden kann. Um den Lokationsbindungsdienst zu erstellen, wird eine Tabelle in die Benutzeroberfläche eingebaut. Programmbeschreibung Diese Benutzeroberfläche ist durch Java Applet implementiert. Abb.4.11 verdeutlicht die Klassen des Programms und den Zusammenhang der Klassen. Abbildung 4. 11: Klassendiagramm Die Klasse „FloorplanAdmin“ definiert das Aussehen der Benutzeroberfläche. Abb.4.12 verdeutlicht die Benutzeroberfläche. 19 Abbildung 4. 12: Editor und Mapping Der Editor ist in der Klasse „DrawingManagement“ auf Basis von DnD (Drag and Drop) implementiert. Mit dem Editor kann ein einfacher Lageplan einer Etage erzeugt werden, wobei die Zimmer der Etage durch die Rechtecke in dem Lageplan repräsentiert werden. Wenn ein Benutzer das Bürosymbol mit der Maus zur Malerleinwand zieht und darauf positioniert, wird ein Rechteck auf der Malerleinwand erstellt. Die Größe und die Position des Rechtecks sind veränderbar. Mit der rechten Taste der Maus kann ein Rechteck radiert werden. Jedes Rechteck repräsentiert ein Zimmer auf der Etage. Die Klassen „MappingTable“ und „MappingTableModel“ sind zuständig für die Erstellung und die Verwaltung der Abbildungstabelle. Sobald ein Rechteck auf der Malereinwand erzeugt wird, wird eine neue Zeile in die Abbildungstabelle gleichzeitig hinzufügt. Das heißt, jede Zeile identifiziert genau ein Rechteck. Abb.4.13 verdeutlicht die Abbildungstabelle. 20 Abbildung 4. 13: Mapping Der Namen des Rechtecks kann in der ersten Spalte der Zeile eingegeben werden. Dementsprechend wird der in dem gemalten Rechteck angezeigte Name automatisch korrigiert. Das Element der zweiten Spalte einer Zeile ist als eine Liste gerendert, in dem die Blätter des im Abschnitt 4.3.1 erzeugten Baums aufgezählt werden. Wenn ein Benutzer ein Blatt von der Liste auswählt, entsteht in der Zeile eine Bindung zwischen dem Rechteck und einer Lokationsinformation. Die zwei Buttons, nämlich „Save“ und „Open“, stehen für die folgenden Funktionalitäten zur Verfügung, Der gemalte Lageplan und der definierte Lokationsbindungsdienst können in der Datenbank gespeichert werden. Die gespeicherten Daten können sich in dieser Benutzeroberfläche wieder aufladen, damit der Lageplan und der Lokationsbindungsdienst weiter editiert werden können. Diese zwei Funktionalitäten sind in der Klasse „FloorplanContentHandler“ implementiert. Mit der in dieser Klasse definierten Methode kann die Klasse „FloorplanAdmin“ auf die Datenbank zugreifen. 4.3.3 Benutzeroberfläche für die Präsentation der Lokationsinformation Die Hauptaufgabe der Benutzeroberfläche ist es, die Positionen der mobilen Geräte graphisch auf dem Lageplan anzuzeigen. Dabei können drei Merkmale der Präsentation zugeordnet werden, Präsentation der Lokationsinformation der letzten 60 Minuten. Aktuelle Positionen der mobilen Geräte. Die Historie der Lokationsinformation aller bekannten Geräte an einem Tag. 21 Programmbeschreibung Diese Benutzeroberfläche ist durch Java Applet implementiert. Abb.4.14 verdeutlicht die Klassen des Programms und den Zusammenhang der Klassen. Abbildung 4. 14: Klassendiagramm Die Klasse „Representation“ definiert das Aussehen der Benutzeroberfläche. Abb.4.15 verdeutlicht die Benutzeroberfläche. Diese Benutzeroberfläche besteht aus vier Teilen, nämlich dem „Active Scan“, dem „Review last hour“, dem „Legend“, dem Fenster des Displays und der „History“. Abbildung 4. 15: Repräsentation 22 Das „Active Scan“ ist zuständig für die Ermittlung der Lokationsinformation eines mobilen Gerätes oder aller Geräte. Ob die Ermittlung für ein Gerät oder alle Geräte durchgeführt wird, ist abhängig von dem eingegebenen ID. Wenn das ID "255.255 .255.255.255.255.255.255" lautet, werden alle Geräte ermittelt. Sonst wird nur das mit dem vorgegebenen ID identifizierte Gerät ermittelt. Abb.4.16 verdeutlicht das „Active Scan“. Abbildung 4. 16: Scan Wieder wegen der Beschränkung der Sicherheit kann das Applet die Ermittelung nicht allein erledigen. Die Klasse „PreScan“ ist dafür zuständig, Die eingegebene ID an den Server weiterzugeben. Die Ergebnisse von dem Server abzuholen. Der Server führt die Ermittlung durch und speichert die Ergebnisse in der Datenbank. Die ausführliche Implementierung dieses Vorgang wird im Abschnitt 4.4 beschrieben. Das „Review last hour“ ist zuständig für die Ermittlung der Lokationsinformation für alle Geräte innerhalb der letzten 60 Minuten. Jeder aufgezählte Zeitpunkt identifiziert einen Schnappschuss der Lokationsinformation in dem Moment. Wenn ein Zeitpunk ausgewählt ist, wird die entsprechende Lokationsinformation in dem Fenster des Displays angezeigt. Abb.4.17 verdeutlicht diesen Teil. Abbildung 4. 17: Benutzeroberfläche für den Rückblick Das Abholen der ersten sechzig nach den Zeitpunkten geordneten Lokationsinformationen wird durch die Klasse „SnapshotDBHandler“ durchgeführt. 23 Die „History“ steht der Abfrage der Lokationsinformation zur Verfügung. Abb.4.18 verdeutlicht diesen Teil. Abbildung 4. 18: Benutzeroberfläche für die Historie Ein Benutzer kann durch den Kalender ein Datum festlegen. Danach können alle Lokationsinformationen des Datums durch den Slider durchgeblättert werden. Der Slider wird durch drei Buttons gesteuert, und die Geschwindigkeit der automatischen SliderBewegung ist auf drei Stufen aufgeteilt. Sobald das Datum festgelegt wird, müssen die Lokationsinformationen von der Datenbank abgeholt werden. Diese Aufgabe ist durch die Klasse „SnapshotDBHandler“ erfüllt. Die Legende, in der Oberfläche als „Legend“ bezeichnet, und das Fenster des Displays sind zuständig für das Anzeigen der Lokationsinformation. Der Lageplan wird zuerst ins Fenster geladen. Die Position eines mobilen Geräts ist durch ein Farbkennzeichen auf dem Lageplan markiert. Die Legende interpretiert die Farbkennzeichen, d.h. welches mobile Gerät durch welches Farbkennzeichen repräsentiert wird (siehe Abb.4.13). 4.4 Implementierung der Informationsbasis und der Schicht für Verarbeitung und Filtrierung Die Informationsbasis wird unmittelbar durch die auf dem Server installierte Datenbank unterstützt. Das Lokationsdatenmodell, die Lokationsbeschreibung und der Lokationsbindungsdienst sind in der Datenbank gespeichert und können durch die im Abschnitt 4.3.1 und 4.3.2 beschriebenen Benutzeroberflächen manipuliert werden. Die in der LokationsDB gespeicherten Daten sind abhängig von der mittleren Schicht. 24 Daher bezieht sich die komplette Implementierung nur auf die mittlere Schicht und die Speicherung der verarbeiteten Daten. Zusätzlich wird die Kommunikation mit dem Client unterstützt, damit der Client Aufgaben, wie z.B. Konfiguration der XBridge und Anfrage der mobilen Geräte erledigen kann. Programmbeschreibung Zuerst erklären wir die Implementierung der mittleren Schicht und die Speicherung der Daten. Abb.4.19 verdeutlicht die Klasse des Programms. Abbildung 4. 19: Klassendiagramm Wenn ein mobiles Gerät mit der in der Nähe aufgestellte XBridge kommuniziert, werden die Lokationsinformation der XBridge und die ID des mobilen Geräts in das UDP Paket gepackt und durch die XBridge ins Netzwerk geschickt. Um die UDP Pakete einzufangen und zu bearbeiten, definieren wir zwei Klassen, nämlich „PacketOverhear“ und „LocationAnalyser“. Die Klasse „PacketOverhear“ ist eine Thread Klasse. Die Aufgabe dieses Thread ist das Netzwerk abzuhören. Sobald ein UDP Paket abgefangen wird, extrahiert das Thread die ID und die Lokationsinformation des mobilen Geräts. Die extrahierten Daten werden zusammen mit einem Zeitstempel in Form einer Datenstruktur, die durch die Klasse „PacketInfo“ definiert ist, gepackt. Danach wird das entsprechende „PacketInfo“ Objekt in den Puffer geschrieben. Der Vorgang der Kommunikation zwischen der XBridge und einem mobile Gerät ist nicht ausschließlich auf eine XBridge beschränkt. D.h. obwohl die Lokation eines 25 mobilen Geräts nicht geändert wird, kommuniziert das Gerät mal mit dieser XBridge mal mit einer anderen XBridge. Daher muss eine Entscheidung getroffen werden, welche Lokation richtig ist. Wir lösen dieses Problem mit Hilfe der Häufigkeit. D.h. in einem festgelegten Zeitraum wird diejenige Lokation akzeptiert, von der die meisten Pakete geschickt werden. Der durch die Klasse „PacketPool“ erstellte und verwaltete Puffer unterstützt die Ermittlung der Häufigkeit. Abb.4.20 verdeutlicht die Struktur. Abbildung 4. 20: Struktur des „Packet Pool“ Das angekommende „PacketInfo“ Objekt wird nach der ID des mobilen Geräts organisiert. Alle Pakete des selben Geräts sind weiter nach der Lokationsinformation organisiert. Falls jetzt ein „PacketInfo“ Objekt ankommt, wird zuerst die mit der ID identifizierte Tabelle durchsucht, ob die in dem „PacketInfo“ Objekt bezeichnete Lokation bereits in der Tabelle existiert. Wenn ja, wird der Zähler des „PacketInfo“ Objekts, das von dem Element „Location“ verwiesen ist, um eins hochgesetzt. Wenn nein, wird ein neues Element für die Lokation hinzufügt und verweist an das „PacketInfo“ Objekt. Der Zähler wird ebenso um eins hochgesetzt. Jede Minute werden die Daten des Puffers bearbeitet. Bei allen gespeicherten „PacketInfo“ Objekten vom der selben ID werden die Zähler miteinander verglichen. Jenes Objekt, das den maximalen Zähler enthält, wird als das gültige Ergebnis geliefert. Die Klasse „LocationAnalyser“ implemtiert ein Timer-task, das jede Minute einmal durchgeführt wird. Die Aufgabe des Timer-tasks besteht darin, die Daten vom Puffer abzuholen und den Puffer zu benachrichtigen, dass alle Daten des Puffers jetzt gelöscht werden können. Dann steht der Puffer wieder für die Ansammlung von Daten zur Verfügung. Die abgeholten Daten werden in Form eines Parameter an die Methode der Klasse „LocationSnapshot“ weitergeben, wobei diese Daten eine Reihe von 26 „PacketInfo“ Objekte sind. Jedes „PacketInfo“ Objekt repräsentiert nun ein mobiles Gerät und enthält seine Lokationsinformation und den Zeitstempel. Mit Hilfe der Klassen „OfficeDataDBHandler“ und „MappingDBhandler“ kann die durch den Lokationsbindungsdienst definierte Abbildung („office name“, „location“) in der Datenbank abgefragt werden. So wird für jedes mobile Gerät ein Schnappschuss erstellt. Der Schnappschuss enthält die folgenden Informationen, die ID des mobilen Geräts, die aktuelle Position( „office name“) des mobilen Geräts, den Zeitstempel. Die Schnappschüsse werden dann durch die Klasse „SnapshotDBHandler“ in der LokationsDB gespeichert. Nun erklären wir wie der Server dem Client dabei hilft, die XBridge zu konfigurieren und die mobilen Geräte abzufragen. Abb.4.21 verdeutlicht die Klassen des Programms. Abbildung 4. 21: Klassendiagramm Beim Server wird ein Port eröffnet. Das von der Klasse „ClientActionAgent“ implementierte Thread hört dem Port zu. Der Client erstellt eine Verbindung mit dem Port und sendet dem Server die Information. Die Information besteht aus zwei Teilen. Ein Teil ist der Name des Dienstes. Der andere ist der Parameter, den der Dienst braucht. Abb.4.22 verdeutlicht das Format der Information. 27 Abbildung 4. 22: Format der Information Das Thread empfängt die Information und analysiert sie. Falls sie „scan“ lautet, führt das Thread die Abfrage der mobilen Geräte durch, wobei die Abfrage durch das Helo/Oleh Scan implementiert ist. Die ID des abgefragten mobilen Geräts wird von dem Thread in ein UDP Paket gepackt und ins Netzwerk geschickt. Über das Netzwerk von XBridges erreicht dieses Paket die mobilen Geräte. Das befragte mobile Gerät beantwortet die Anfrage mit seiner ID und die XBridge leitet diese weiter in das UDP Netzwerk, wo sie vom Server wieder vom Netz genommen werden. Das Thread wartet 2 Sekunden, um die zurückgeschickten UDP Pakete anzusammeln. Durch die Analyse der in den UDP Pakete enthaltenen Lokationsinformationen der XBridge wird die Lokation des mobilen Gerät ermittelt. Das Thread sendet dann dem Client das Ergebnis vom „scan“ zurück. Falls die Bezeichnung des Dienstes „config“ lautet, kommuniziert das Thread mit der XBridge und konfiguriert die XBridge mit der Lokation, die aus einem 16 Byte Identifikator des Lokationsbaums und einer Beschreibung des Pfades im Lokationsbaums für die Position besteht. Ziel der Konfiguration ist es, die Lokationsinformation in die XBridge zu schreiben. Die XBridge bietet 44 Bytes zur Speicherung der semantischen und geometrischen Lokationsinformation an. Der Identifikator wird in den ersten 16 Bytes gespeichert. Die anschließenden 24 Bytes sind zuständig für die Speicherung der Beschreibung der Position. Die letzten 4 Bytes, die im RAUM Format die geometrische Lokation beschreiben, sind mit „0“ initialisiert. Das Cell-of-Origin System basierend auf den verwendeten XBridges kann die Lokation eines mobilen Gerätes nicht besser als die semantische Beschreibung der Lokation ermitteln. 28 5 Zusammenfassung Diese Arbeit hat eine generische Architektur für die Trennung der Darstellung der Lokationsinformation vom verwendeten Lokationssystem. vorgestellt. Auf der Architektur basierend wurde ein Präsentationssystem für das von Smart-Its Particles[5] gestützte Cell-of-Origin Lokationssystem entwickelt. Das entwickelte Präsentationssystem ist hilfreich für die Analyse der Lokationsdaten eines Lokationssystem. Die auf dem Server laufenden Programme sind Java Applikationen. Die Benutzeroberflächen des Präsentationssystems sind mit Java Applets implementiert. Daher lässt sich das Präsentationssystem in verteilten Umgebungen von mehreren Benutzern flexibel einsetzen. Bei dem Präsentationssystem gibt es noch einige Stellen, die in der Zukunft verbessert werden können, z.B. die Verwaltung der eingesetzten zentralen Datenbank, die für die Speicherung der Lokationsdaten zuständig ist. Die sollte die Last des Servers überwachen und die entsprechende Statistik erstellen können. Zusätzlich können neue Funktionalitäten in den graphischen Editor hinzufügt werden, damit der Benutzer bessere Lokationsbeschreibung erstellen kann. 29 Literaturverzeichnis [1] M. Addlesee, R. Curwen, S. Hodges, J. Newman, P. Steggles, A. Ward, and A. Hopper. Implementing a sentient computing system. IEEE Computer, 34(8):50.56, Aug. 2001. [2] WANT, R., HOPPER, A., FALCAO, V., AND GIBBONS, J. The Active Badge Location System. ACM Transactions on Information Systems 10, 1 (January 1992), 91–102. [3] Nissanka B. Priyantha, Anit Chakraborty, and Hari Balakrishnan The Cricket Location-Support System, Abstract, 2-6. MIT Laboratory for Computer Science Cambridge, MA 02139 [4] LILLEY, J. Scalability in an Intentional Naming System. Master’s thesis, Massachusetts Institute of Technology, May 2000. [5] TecO Smart-Its Particles. Available online: http://particles.teco.edu [Accessed: May 2004]. [6] GSM Association Permanent Reference Document SE.23. Location Based Services. Version 3.1.0, January 2003, Available online: http://www.gsmworld.com/documents/lbs/se23310.pdf [Accessed: 9/2004] [7]. Beigl, M. Zimmer, T. Decker, C.: A Location Model for Communicating and Processing of Context. Personal and Ubiquitous Computing Vol. 6 (5-6), 2002, 341357. [8] http://www.foxserv.net 30
