\input{stylesheets/stylesheet.link.tex}
\theauthor{Nikias Bassen, Dennis Lubert}{nikias@tzi.de, plasmahh@tzi.de}
\theversion{$ $Revision$ $}
\title{ Pflichtenheft für Positionsbestimmungsmodul und Management System
    $ $Revision$ $ }

\begin{document}
\createtitle

\tableofcontents

\section{Architektur}

Das System besteht aus einem Manager, sowie mehreren Modulen. Die
Module sind für den Zugriff auf die Hardware zuständig und liefern auf
Anfrage eine Position zurück. 

Ein direktes User Interface steht nicht zur Verfügung, jedoch eine
Testapplikation namens IWLocator. Diese ist nur zu Testzwecken
gedacht, reell soll später eine Position in beliebige Anwendungen
eingebunden werden, wie z.B. einen Dienst zur Positionsanzeige.

Geplante Module sind WLAN, GPS sowie GSM/UMTS. Andere Systeme sollten
flexibel einfügbar sein.
Weiterhin ist als gesamte Zielanforderung gesetzt, dass die
zurückzuliefernde Position eine minimale Genauigkeit von 5cm hat.

\section{Systemanforderungen}
Das Location System benötigt eine iWear-kompatible Umgebung. Dies setzt
insbesondere einen Computer mit Linux mindestens Version 2.4.x
voraus, jedoch ist Linux 2.6.x aufgrund der besseren Thread- und
Prozessverwaltung dringend empfohlen. Einzelne Module können spezielle
Anforderungen haben, diese sind seperat aufgelistet.

\section{LocationManager}
\subsection{Generell}
Der LocationManager verwaltet eine Anzahl von Referenzen auf Locator-Module.
Das Management der Objekte selbst obliegt der Anwendung bzw.
dem Dienst, welche den LocationManager nutzen wollen. 
Für jedes Modul gibt es eine eigene Funktion um dieses Modul
anzumelden. Da keine Klassenstruktur genutzt werden soll kann auch
kein generelles Modul geschrieben werden, ein neu zu entwickelndes
Modul benötigt dann die entsprechenden Änderungen im Location Manager.
\subsection{Funktionalität}
Der LocationManager ist selbst von der generellen Iwear Manager Klasse
abgeleitet und hat dadurch schon einige Management-Funktionalitäten.
\subsubsection{Management}
Der LocationManager stellt Funktionen bereit, über die einzelne
Locatoren an- und abgemeldet werden können, welche jeweils für
einzelne Module anders ist.
Der Manager soll dazu weiterhin in der Lage sein (teilweise durch die
Manager Basisfunktionalitäten)
\begin{itemize}
\item einzelne Module Anhand ihrer ID zu identifizieren (sofern die
	Module eine ID besitzen)
\item Listen von Modulen Anhand ihrer Funktionalitäts-Subgruppe zu
bestimmen (GPS, GSM, WLAN etc.)
\item aktive Power Management Funktionen der Basis Module (sleep,suspend
etc.) auf allen von ihm verwalteten Submodulen auszuführen, wahlweise
eingegrenzt durch IDs oder Typidentifizierer. Dieses natürlich nur
sofern die Module dazu in der Lage sind.
\end{itemize}
\subsubsection{Positionsbestimmung}
Der LocationManager kann nach einer aktuellen Position gefragt
werden. Um diese zu ermitteln, wird er die einzelnen Module nach ihrer
Position fragen, und zusammen mit deren angegebenen RMS-Werten eine
Annäherung an die reelle Position geben. Der Teil an Daten, welcher
von einem Modul nicht zur Verfügung gestellt wird, soll vom
LocationManager durch einen gecachten Datenbankzugriff rekonstruiert
werden. Das bedeutet auch, falls ein Modul ausfällt, dass versucht
wird aus den restlichen Modulen die Werte zu rekonstruieren.

Eine Anfrage nur an bestimmte Modulgruppen wäre zwar denkbar, ist
jedoch zur Zeit noch nicht vorgesehen. Einzelne Module können jedoch
direkt über die Managementfunktionalitäten angesprochen werden, falls
dieses nötig sein sollte, um z.B. erweiterte Funktionalitäten zu
nutzen.
\subsubsection{Positionslernen}
Einige Module sind so konzipiert, dass sie Positionen lernen und die
später wiedererkennen können. Dem LocationManager kann mitgeteilt
werden, dass die aktuelle Position gelernt wird. Dies kann durchaus
mehrere Sekunden dauern, in denen sich der Benutzer nicht sehr stark
bewegen sollte, um das Ergebnis nicht zu verfälschen. Um dem Benutzer
Feedback über den aktuellen Fortschritt zu geben, wird durch einen
Callback-Mechanismus der aktuelle Fortschritt zurückgegeben. Derselbe
Mechanismus kann auch dazu eingesetzt werden, den aktuellen Scan
abzubrechen.
\subsection{Position}
Die Position wird durch die Parameter Ort (in Menschenlesbarer Form),
Weltkoordinaten, Custom xyz Koordinaten, Heading (in Radians), Höhe
(in Metern) Geschwindigkeit (in Metern pro Sekunde), jeweils für die
beiden Orte einen RMS-Wert, welcher die Güte angibt. Weiterhin wird
eine Zeit der Gültigkeit in Sekunden und Mikrosekunden seit der Epoche
angegeben (was dafür eine maximale Auflösung von einer Mikrosekunde
festlegt).

Dies bezieht sich nur auf die Position, welche vom LocationManager
zurückgegeben wird.
Die Positionen der einzelnen Module wird von diesen bestimmt, und je
nach Modul wird im LocationManager das nötige implementiert um die
Daten in ein für den LocationManager brauchbares Format umzuwandeln.

Anmerkung: Auch wenn dieses zeitlich noch nicht relevant zu sein
scheint, könnte es Probleme geben, sobald das Programm im Jahre 2038
oder danach verwendet wird. Auf dieses Problem sollte, sofern das
Betriebssystem durch die \texttt{struct timeval} dies nicht selbst
tut, spätestens 2030 eingegangen werden.
\subsection{Systemanforderungen}
Der LocationManager benötigt zur Laufzeit eine Verbindung zu einer
SQL Datenbank, welche von den Iwear Datenbankklassen angesprochen
werden kann, und mit einer entsprechenden Datenbasis versehen ist.
Desweiteren können einzelne Module gesonderte Hardwareanforderungen
haben.

\subsection{Locator Module}
Ein Locator Modul gibt irgendeine Art von Information über die
Position zurück. Wie genau das zu tun ist regelt jedes Modul selbst.
\subsubsection{Generelle Anforderungen}
Um ein gewisses Verhalten zu garantieren muss jedes Modul die
folgenden Bedingungen erfüllen :
\begin{itemize}
\item Anforderungen sind innerhalb von maximal 10s abzuarbeiten.
Sollte abzusehen sein, dass Anfragen generell länger dauern, so ist
dafür zu sorgen, dass durch einen geeigneten Mechanismus (z.B. Thread
der regelmässig die Position holt und abspeichert) die Werte
zwischengespeichert werden, damit sie schnell bereitstehen. Dabei ist
es unerheblich ob bei aufeinanderfolgenden Abfragen dieselben Werte
zurückgegeben werden, hauptsache es sind die für das Modul neuesten
erreichbaren Werte.
\item Die Genauigkeit ist als Wert anzugeben, welcher von dem Modul
bestimmt wird. Natürlich kann ein Modul auch mal kein solchen Wert
angeben, wenn es keinen hat.
\end{itemize}
\subsection{WLAN Locator}
Der WLAN Locator soll mit Hilfe der Empfangsgüteinformationen von
Access Points die Aktuelle Position des Benutzers Approximieren.
\subsubsection{Positionsbestimmung}
Durch in der Datenbank gespeicherte Empfangsgüteinformationen ist der
WLAN Locator in der Lage, gewisse zuvor gespeicherte Punkte
wiederzuerkennen. Die Güte der gelieferten Positionen hängt stark von
den räumlichen Gegebenheiten ab. Zur kompensation von Sprüngen
zwischen nicht direkt erreichbaren Orten hat der WLAN Locator eine
interne Verknüpfung von gepeicherten Orten, welche direkt aneinander
liegen. Weiterhin kann ein Differential Service die Güte noch sehr
stark erhöhen, dieser würde jedoch zur Zeit erfordern, dass die Karte
im rfmon-Modus läuft, was ihren normalen Betrieb unmöglich macht.
\subsubsection{Benutzerinterface}
Zur Zeit existiert kein Benutzerinterface direkt für den WLAN Locator.
Er kann jedoch über die Testapplikation IWLocator angesteuert werden.
Hierüber können auch neue Positionen gelernt werden. 
Ein grafisches Interface ist als Standalone Applikation nicht
vorgesehen, sollte jedoch als Dienstanwendung innerhalb des
 iWear-Frameworks realisiert werden.
\subsubsection{Hardware- und sonstige Anforderungen}
Für die Ortsbestimmung über WLAN wird eine 802.11b kompatible Wireless
LAN Karte benötigt.
Weiterhin muss der Linux Treiber für diese Karte das Scannen nach
Access Points im laufenden Betrieb beherrschen (ioctls
\texttt{SIOCSIWSCAN} und \texttt{SIOCGIWSCAN}).
Für WLAN Karten mit Orinoco Chipsatz wird ein spezieller Treiber
bereitgestellt, welcher dazu in der Lage ist. 
Weitere unterstüzte Karten :
\\ \\
(Hier mal ne schicke tabelle bauen)
\\ \\
Zusätzlich muss das Scannen nach Access Points vom aktuellen Benutzer
erlaubt sein. Das bedeutet, dass eine angepasste Version des Treibers
verwendet werden muss, bei dem auch normale Benutzer nach Access Points
scannen dürfen.


\end{document}