Mobile Lokalisierung mit WLAN-Access-Points

Die Möglichkeit der Positionsbestimmung mit mobilen Geräten bietet Unternehmen einen großen Mehrwert in Hinblick auf positionsgebundene Informationsflusssteuerung und Indoor-Navigation.

Eine große Hürde in der Technologie der Positionsbestimmung ist die nötige Ausmessung des Positionsrasters. Zur Erleichterung dieser Ausmessung stehen unterschiedliche Vorgehensweisen zur Verfügung.

Im Laufe des Kundenprojekts wurden durch die Bestimmung der Vor- und Nachteile dieser Methoden, die in diesem Rahmen vielversprechendste ausgewählt und Software-mäßig umgesetzt. Das Ergebnis des Kundenprojekts soll eine lauffähige mobile Anwendung sein, die in der Lage ist, durch Triangulation von Signalstärken (RSSIs) einzelner WLAN-Access-Points, die Ausmessung von Räumlichkeiten zu gewährleisten. Dies geschieht in Verbindung mit einem Server zur Speicherung und Verarbeitung der Positionsdaten, der ebenfalls im Zuge dieses Projekts im Hause der Organon Informationssysteme GmbH entwickelt wird.

Standortbezogene Dienste

Die Lokalisierung spielt seit je her eine wichtige Rolle in vielen Bereichen von Wirtschaft und Gesellschaft. Galt es früher noch die Position eines fremden Heeres oder den Standort von Handelsschiffen zu bestimmen, hat die Positionsbestimmung heute, mit der Verwendung von Navigationsgeräten in Automobilen, Luft-, Raum- und Seefahrt und sogar durch gezielte, positionsbezogene Werbung auf Smartphones, Einzug in unseren Alltag gehalten. Immer neue Technologien, die auch besonders durch die mobile Internetnutzung vorangetrieben werden, machen es möglich, die Position elektronischer Geräte, wie z.B. Smartphones, mit immer größerer Genauigkeit zu bestimmen. Durch die Entwicklung von Funktechniken wie Bluetooth, Near Field Communication (NFC) und Wireless Local Area Network (WLAN), die in den meisten Smartphones, teilweise sogar in Kombination, verfügbar sind, können Positionsbestimmungssysteme vielfachen Nutzen in den verschiedensten Lebensbereichen erzielen.

Verfahren zur Positionsbestimmung

Es existieren unterschiedliche Verfahren, die zur Positionsbestimmung einzeln oder in Kombination eingesetzt werden können, die Triangulation, die Trilateration und die Szenenanalyse. Diese werden im Folgenden im Detail betrachtet.

Triangulation

Die Triangulation wird schon seit hunderten von Jahren zur Entfernungsmessung verwendet und ist auch heute noch in der Landvermessung Stand der Technik. Die Lage der unbekannten Position kann in der Ebene in Abhängigkeit zu den bekannten Werten über die Winkelbeziehungen ermittelt werden.

Ist die Basislänge c zwischen den gegebenen Punkten A und B bekannt, kann man durch Anpeilen des Punktes C und den daraus resultierenden Winkeln α und β die Längen a und b ermitteln und erhält darüber die Koordinaten von C.

Trilateration

Bei der Trilateration wird die Position eines bestimmten Punktes mittels des Abstands zu bereits bekannten Punkten mathematisch berechnet.

Da einem Client im WLAN die Signalstärken ausgehend von jedem verbundenen Access Point zur Verfügung stehen, können diese als Eingabewerte der Trilateration genutzt werden, indem man sie für die Entfernungen, also die Werte r1, r2 und r3, einsetzt. Um mit den Signalstärken arbeiten zu können, muss man sich zunächst bewusst sein, wie die Werte zu interpretieren sind. Die Werte der Signalstärken finden sich im negativen Zahlenbereich und nehmen mit größerer Entfernung ab. Im WLAN ist ein Wert von -35 dBm z.B. „besser“ als ein Wert von -57 dBm, zwischen -80 dBm und -90 dBm reißt das Signal meist ab. Um die Signalstärken in der Trilateration nutzen zu können, muss man alle Entfernungen mit diesen Signalstärken messen.

Szenenanalyse

Bei der Szenenanalyse wird in der Regel initial ein Raster ausgemessen um die Position des zu bestimmenden Objekts anhand dieses Rasters zu ermitteln. Die in der Vorbereitung ermittelten Daten werden in einer Datenbank abgelegt und die Position des zu bestimmenden Objekts mit diesen Werten verglichen. Es gibt unterschiedliche Möglichkeiten in der die Szenenanalyse Anwendung findet.
So können zum Abgleich beispielsweise Bilddaten genutzt werden, wie teilweise in der Robotik von sich autonom bewegenden Robotern, oder man nutzt z.B. Empfangsstärken. Für andere Lokalisierungsverfahren bedeuten die durch Verzerren verschlechterten Empfangsstärken der Funksignale (aufgrund von Störfaktoren wie Wänden, Gegenständen, anderen Funkzellen etc.) einen großen Genauigkeitsverlust. Bei der Szenenanalyse werden diese Verschlechterungen jedoch kompensiert, da ein durch eine Störquelle beeinflusstes Signal ebenfalls mit dieser Beeinflussung vorher in die Ausmessung eingeflossen ist und somit beim Abgleich trotzdem eine Lokalisierung möglich macht.
Lediglich eine Veränderung der Lokalität, sei es durch Baumaßnahmen, Hinzufügen von störender Funktechnik oder auch das Verstellen, Entfernen oder Hinzufügen von Objekten wie Möbeln, könnte die Werte im Einflussbereich dieser Quelle unbrauchbar und eine erneute Ausmessung der Lokalität nötig machen.

Positionsbestimmung im WLAN

Mit der rasant ansteigenden Anzahl mobiler Geräte und dem Wunsch nach Flexibilität und Kostenreduzierung hat der Einsatz drahtloser Vernetzung (WLAN) als Ergänzung und teilweise als Ersatz der kabelgebundenen Vernetzung in Computernetzwerken stark zugenommen. WLAN ist in Privathaushalten, Unternehmen sowie öffentlichen Einrichtungen mittlerweile zur Selbstverständlichkeit geworden.
Um flächendeckend ein gutes Signal zu gewährleisten wird insbesondere in Unternehmen und öffentlichen Einrichtungen mit mehreren Zugangspunkten, sogenannten WLAN-Access-Points, gearbeitet. Dadurch können die oben genannten Varianten zur Positionsbestimmung mit vergleichsweise geringem Aufwand angewendet werden.
Davon können auch viele Bereiche des Alltags profitieren.

Umsetzung des Softwareprojekts durch Mitarbeiter der Organon Informationssysteme GmbH

Die Umsetzung des Softwareprojekts folgt den Vorgaben des Unternehmens für die Entwicklung von Softwaresystemen im Eigenauftrag. Für jedes Projekt findet ein Planungsprozess statt, der die Entwicklung in einzelne Phasen unterteilt. Zu Beginn dieses Planungsprozesses wurde ein Kick-off-Meeting durchgeführt, mit Vorstellung des Projektziels, Festlegung des Projektstrukturplans, der Verantwortlichkeiten und der Meilensteine, sowie die Entscheidung für ein Vorgehensmodell. Das zu verwendende Vorgehensmodell wird im Einzelfall vor dem Hintergrund der Anforderungen, die die zu lösende Aufgabe stellt, den Kenntnissen der beteiligten Mitarbeiter und den Erfahrungen aus ähnlichen vorangegangenen Projekten entschieden. Für das Praxisprojekt fiel die Entscheidung für das Wasserfallmodell. Im Rahmen des Meetings wurden Arbeitspakete an die Teilnehmer verteilt.

Anforderungsanalyse

Ziel der Anforderungsanalyse, als einem ersten Schritt der Softwareentwicklung, ist die Anforderungen des Auftraggebers an das zu entwickelnde System zu ermitteln.
Die Grundidee des Auftraggebers, eine Basissoftware für die Ortsbestimmung von Objekten zu entwickeln und diese mit einer zentralen Datenbank sowie mit Standardschnittstellen versehen um aufzusetzende Anwendungsmodule zu erweitern, entstand aus einem früheren Vorprojekt heraus und nach Durchführung einer Marktanalyse.
Zunächst ist gewünscht nur eines der Verfahren zur Positionsbestimmung in diesem Praxisprojekt zu nutzen, jedoch die Entwicklung so anzulegen, dass die beiden anderen Verfahren zu einem späteren Zeitpunkt jedes einzeln alternativ, bzw. in Kombination miteinander genutzt werden können.
Nach Erstellung eines Anforderungsprofils mit grundsätzlichen Angaben zur Funktionalität, der einzusetzenden Technik, notwendiger Flexibilität für den Einsatz weiterer Technik, Anforderungen an Transaktionsdurchsatz und Skalierbarkeit, Verfügbarkeit, Softwarequalität,, Sicherheit und Datenschutz wurde ein Lastenheft mit allen Anforderungsspezifikationen erzeugt.

Grobkonzept

Das in der Anforderungsanalyse erstellte Lastenheft diente als Grundlage für ein Grobkonzept des künftigen Systems. Das Grobkonzept umfasst einige Vorfestlegungen bezüglich der zu verwendenden Hard- und Softwarearchitektur. Als Architektur für die Informations- und Diensteverteilung wurde das Client-Server-Modell festgelegt, da dies neben Änderungen und Aktualisierungen der Positionsdaten und zu verteilenden Informationen und Diensten eine Entlastung der Benutzergeräte, eine bessere Lastverteilung im Gesamtsystem, sowie eine einfachere Wartung und Pflege der einzelnen Soft- und Hardwarekomponenten ermöglicht.

Für den Betrieb im Modus der Szenenanalyse ist es erforderlich mittels Positionsmessungen ein Lokalisationsraster zu erstellen. Hierbei müssen der zentrale Server des Systems und eine spezielle Client-Applikation eingesetzt werden, die lediglich der Ausmessung des Lokalistationsrasters dienen. Ein Service-Mitarbeiter geht hierbei ein Raster mit Punkten in einem Abstand von 1 m (4 Punkte pro Quadratmeter) ab und übermittelt die Daten an den Server. Auf dem Server nimmt eine Routine der Software „LocalizationServer“ diese Werte entgegen und speichert sie unter der entsprechenden Positionseinheit (z.B. Raum) in seiner Datenbank ab.
Nachdem die Ausmessung des Standorts und die Unterteilung in logische Einheiten, anhand der tatsächlichen Raumaufteilung, stattgefunden hat, werden den Positionseinheiten Informationen und Dienste zugewiesen, in der Datenbank abgelegt und ggf. nötige Co-Routinen im Server aufgerufen. Nach dieser initialen Erfassung und Zuordnung soll das System den Betrieb aufnehmen können.

Um die Position eines Endgerätes feststellen zu können, muss sich der Nutzer zunächst mit seinem Endgerät in das WLAN einloggen, dessen WLAN-Access-Point-Signalstärken zur Positionsbestimmung herangezogen werden. Zuerst wird beim Starten der Service-App (LocalizationClient) automatisch eine Verbindung zum Server aufgebaut und die Signalstärken, die vom Endgerät empfangen werden, an den Server übermittelt. Darauf folgend sucht der Server in seinen Lokalisationsdaten die nächstliegenden Werte und die zu dieser Einheit zugewiesenen Informationen und Dienste in seiner Datenbank.

Softwareanforderungen

Die zu entwickelnde Software soll es möglich machen, die Position des Benutzer-Gerätes eines Anwenders im Gebäude zu bestimmen. Als Positionseinheiten werden mittels der Serversoftware nach dem Ausmessen des Firmenstandorts die Räume verwendet, in die der Standort bauartbedingt unterteilt ist. Informationen und Dienste, die an bestimmte Räume geknüpft sind, sollen dem Anwender auf dem mobilen Gerät durch den Server zur Verfügung gestellt werden.

Hardwareanforderungen

Um eine möglichst genaue Positionsbestimmung durchführen zu können, ist es nötig mindestens drei Zugangspunkte im lokalen WLAN zur Verfügung zu haben. Da die Anwendung zur Positionsbestimmung mit möglichst niedrigem Aufwand auf mobilen Geräten eingesetzt werden soll und zur Entwicklung bereits Kompetenzen im Hause zur Verfügung stehen, hat das Unternehmen Android-Geräte als Zielplattform festgelegt. Um Investitionen zur Vorhaltung von Hardware zu vermeiden, sowie eine hohe Flexibilität und Skalierbarkeit zu erreichen, wurde der Einsatz virtueller Systeme entschieden.

Softwareentwurf

Der Softwareentwurf ist der Entwurfsprozess zur Planung einer Software-Lösung. Er ist Teil des gesamten Softwareentwicklungsprozesses und setzt auf dem Lastenheft aus der Anforderungsanalyse auf. Die Ergebnisse des Softwareentwurfs werden im sogenannten Pflichtenheft festgehalten.

Softwarearchitektur

Der Entwurf der Softwarearchitektur stellt die Zusammenhänge der zugrunde liegenden Anforderungen des zu entwickelnden Softwaresystems dar. Er zeigt die Komponenten des Systems und die zwischen ihnen bestehenden Verbindungen. Es handelt sich dabei keinesfalls um einen detaillierten Entwurf des Systems, sondern vielmehr um die Darstellung von z.B. Programmmodulen, Softwareschichten, Schnittstellen, Daten- und Funktionsgrafen. Mit dem Architekturentwurf werden grundlegende Entscheidungen getroffen, die einen erheblichen Einfluss auf den weiteren Systementwurf haben, dessen Detaillierung in den weiteren Phasen des Entwurfsprozesses stattfindet.

Objektorientierte Analyse und Design

In der Phase „Objektorientierte Analyse und Design“ werden die in der vorangehenden Anforderungsanalyse gewonnenen Erkenntnisse genutzt, um aus den Anforderungen zunächst Use-Cases und dann detaillierte Klassendiagramme zu erstellen, die als Muster für die nachfolgende Entwicklungsphase genutzt werden. Es existieren einige Softwarelösungen, die die Entwurfsmuster dieser Phase nutzen, um Quellcode zu generieren und so die zuvor in UML erstellten Klassen als Körper für die weitere Programmierung zur Verfügung zu stellen.

Zunächst werden Klassendiagramme für den LocalizationServer, LocalizationClient und ServiceClient erstellt.
Es wird ein Raum neben seinen lokalen Attributen über die Klasse „Position“ definiert. Einem Raum liegt also eine Menge (hier: ArrayList) an Positionen zugrunde, die das Raster mit der eindeutigen Raumnummer bilden, in dem sich der Client bewegt. Eine Position besteht hierbei aus drei Positionswerten, ausgehend von drei WLAN-Access-Points. Eine Erweiterung um beliebig viele Positionswerte, also weitere WLAN-Access-Points zur Verbesserung der Lokalisierung ist in Zukunft vorgesehen, wurde aber in dieser Softwareversion noch nicht umgesetzt. Die Mindestzahl von drei WLAN-Access-Points darf nicht unterschritten werden, da eine zuverlässige Lokalisierung sonst nicht mehr erfolgen kann.
Weiterhin kann man dem Klassendiagramm entnehmen, dass je nach Typ des Clients entweder die Helferklasse ServiceClient oder die Helferklasse LocalizationClient durch die Klasse LocalizationServer generiert werden, sobald eine Verbindung eingeht. Je nach Helferklasse werden dann unterschiedliche Funktionen zur Verwaltung oder zum Abrufen von Informationen und Diensten zur Verfügung gestellt.

Die Klasse „ConnectActivity“ steuert den Aufbau der TCP/IP-Verbindung. Diese Klasse wird von der Hauptklasse erzeugt und beim Verbindungsabbau über das Kontextmenü der Hauptklasse zerstört. Ebenfalls, wie im LocalizationServer, existiert eine Klasse Position, in der die drei Werte für je einen WLAN-Access Point abgelegt werden. In der Hauptklasse sorgt die Methode positionListener() ständig dafür, dass die Variable „position“ mit den Signalstärken der aktuellen Position gefüllt ist. Der aktuelle Raum wird durch einen Befehl vom LocalizationServer überschrieben, sobald die an den Server übermittelte Position eine andere Raumnummer zurückliefert. Die auf dem Server abgelegten Räume werden durch einen Servicemitarbeiter mit der Android-Applikation „ServiceClient“ festgelegt.

Vergleicht man die Klasse „ServiceClient“ mit der Klasse „LocalizationClient“ ist in ersterer die Methode „collectGridPositions()“ enthalten, die einen festgelegten Raum durch eine Menge an Positionswerten definiert. Diese Positionswerte werden manuell (durch Betätigung eines Buttons auf dem Bildschirm des Smartphones) der Liste „posArray“ vom Typ ArrayList hinzugefügt. Nach Abschluss der Definition eines Raumes, werden die gespeicherten Positionswerte zusammen mit der Raumnummer an den Server übermittelt.

Nach Abschluss der Softwareentwurfsphase wurde ein Architecture Review durchgeführt, um das Risiko von Fehlentwicklungen bei der nachfolgenden Implementierung zu vermeiden. Die Ergebnisse des Softwareentwurfs wurden im Review-Meeting freigegeben.

Implementierung

Das Pflichtenheft als Ergebnis der Entwurfsphase ist der Ausgangspunkt für die Programmierung.
Zunächst wurden die Projekte „LocalizationServer“ und LocalizationClient“ angelegt und die Client-Server-Verbindung programmiert. Parallel zu diesen Projekten wurden für einzelne Komponenten eigenständige Test-Projekte angelegt um die Komponenten unabhängig zu entwickeln und später zusammenzuführen.
Der nächste Schritt war die Programmierung einer Android-App, die die Signalstärken der verfügbaren WLAN-Access-Points ausliest und diese Daten in einem eigens festgelegten Protokoll in JSON (JavaScript Object Notation) an den Server überträgt. Diese Android-App wurde als Vorlage für LocalizationClient und ServiceClient verwendet. Für den ServiceClient wurden entsprechende Oberflächen generiert, die zum Ausmessen des initialen Rasters geeignet sind, die Oberflächen des LocalizationClient wurden für die Darstellung von Informationen gestaltet. Die einzelnen Software-Elemente auf den Clients und dem Server wurden entsprechend der Objektorientierten Analyse & Design (OOA und OOD) umgesetzt.
Parallel zur Programmierung, wurde eine Softwaredokumentation erstellt. Es wurden neben dieser Softwaredokumentation detailliertere OOA- und OOD-Diagramme, ein relationales Datenbankmodell und eine Roadmap zur Produkteinführung erstellt. Zur Qualitätssicherung wurden Testfälle spezifiziert, die in jeweiligen Modultests verwendet wurden.

System- und Integrationstest

Zur Validierung des Gesamtsystems war es unsere Aufgabe anhand der Anwendungsfälle und den Anforderungsdefinitionen einen Testplan zu erstellen, sowie zahlreiche Testfälle für funktionale und nicht-funktionale Anforderungen zu beschreiben. Die Testfälle wurden auf Testfallformblättern erstellt, die auch gleichzeitig zur Protokollierung der Testergebnisse verwendet wurden. Jeder Testfall beinhaltet den Testablauf, die Eingaben und das erwartete Ergebnis.

Anhand des Testplans wurden alle Testfälle geprüft, die Testergebnisse dokumentiert und im Fehlerfall, nach dessen Behebung, nochmals geprüft. Zur Validierung der Multiuserfähigkeit des Systems, wurde gemäß Testplan auch eine Reihe von Tests mit mehreren Mitarbeitern in einem bzw. mehreren Räumen durchgeführt. Aufgrund einiger, in den Tests aufgetretener Fehler, mussten zusätzliche Testfälle hinzugefügt werden. Auf alle aufgetretenen Schwierigkeiten und Fehlfunktionen konnte schnell reagiert und die Software angepasst werden.
Die Tests zur Zuverlässigkeit der vom Server aus den übermittelten Signalstärken errechneten und an die Clients zurückgegebenen Positionseinheiten zeigten eine zufriedenstellende Positionsermittlung, solange sich der Client nicht zu nah im Wandbereich aufhielt.
Die abschließenden Tests ergaben eine zufriedenstellende Lokalisierung der Clients und eine reibungslose Informationsübermittlung ergeben. Der Testplan und alle Testfalldokumente werden zu Nachweiszwecken und zur späteren Wiederverwendung archiviert.

Die Software ist bei einem unserer Kunden erfolgreich im produktiven Einsatz. Der Kunde möchte an dieser Stelle nicht namentlich genannt werden.