Diplomarbeit

Hochschule Karlsruhe – Technik und Wirtschaft
University of Applied Sciences
Diplomarbeit
Interdisziplinäre Referenzimplementierung eines drahtlosen
Sensornetzwerkes zur Erfassung von Messdaten und deren simultanen
Speicherung, Auswertung und Visualisierung in einem WebGIS
Prof. Dr. rer. nat. Detlef Günther-Diringer
vorgelegt von
Uwe Riegger
Matrikelnummer 014890
Studiengang Kartographie und Geomatik
Bonn, im Juni 2006
Diplomarbeit
für Herrn Uwe Riegger
Thema: Interdisziplinäre Referenzimplementierung eines drahtlosen Sensornetzwerkes zur
Erfassung von Messdaten und deren simultanen Speicherung, Auswertung und
Visualisierung in einem WebGIS
Bisher werden große Investitionen an Arbeitskraft und Finanzmitteln für die Datenerfassung bzw.
-beschaffung verwendet und nicht an vorhandene Informationssysteme gekoppelt. Die zuständigen Personen
müssen meistens in ihr Untersuchungsgebiet reisen, um die dort erfassten Daten auf einen externen Speicher
zu sichern und anschließend in ein Informationssystem integrieren. Dabei kann es vorkommen, dass
Sensoren oder Datenlogger ausfallen und die Anreise und der Zeitraum der Erfassung nutzlos waren.
Eine Möglichkeit, den Kostenfaktor „Daten“ zu reduzieren und den gestiegenen Anforderungen an ein
leistungsstarkes
und
modernes
Informationsmanagement
gerecht
zu
werden,
bieten
drahtlose
Sensornetzwerke in Verbindung mit einem WebGIS.
Die schnelle Entwicklung im Bereich der Halbleitertechnik und der Sensorik hat in den letzten Jahren zu
einer zunehmenden Miniaturisierung geführt. Diese Technik wird in Form von drahtlosen Sensornetzwerken
zusammengeschaltet, bei der sich hunderte bis tausende Sensoren spontan und autark miteinander vernetzen,
Daten erfassen und diese Informationen zu einem zentralen Knoten transportieren. Von dort kann ein Uplink
ins Internet erfolgen.
Diese Möglichkeit, Datenpakete in einem Multihop genannten Verfahren energieeffizient an eine Datenbank
zu übertragen, eröffnet der Datenakquisition für geographische Informationssysteme ungeahnte
Möglichkeiten. Besonders internetgestützte, WebGIS genannte geographische Informationssysteme
ermöglichen eine simultane Aufbereitung und Visualisierung der Daten, für einen weltweiten
Informationsaustausch.
Die Firma terrestris in Bonn beschäftigt sich mit WebGIS-Applikationen und Informationssystemen auf
Basis von freier Software. Im Rahmen dieser Diplomarbeit soll nun ein Portal entwickelt werden, welches
die Ankopplung eines drahtlosen Sensornetzwerkes an ein webbasiertes, geographisches Informationssystem
ermöglicht. Der ganze Prozess der Erfassung, Speicherung, Aufbereitung und Visualisierung wird mit der
Software C, PHP, HTML, CSS, UMN Mapserver, Mapbender, PostgreSQL/PostGIS, Scatterviewer, Ubuntu,
Apache HTTP Server und GRASS realisiert.
Bearbeitungszeit:
4 Monate
Ausgabedatum:
15.02.06
Abgabetermin:
15.06.06
Prof. Dr. D. Günther-Diringer
Erklärung
II
Erklärung
Hiermit erkläre ich, die vorliegende Diplomarbeit selbstständig verfasst und
nur die angegebenen Quellen und Hilfsmittel verwendet zu haben.
Karlsruhe, den 06.06.2006
_________________________
(Uwe Riegger)
Danksagung
III
Danksagung
An dieser Stelle möchte ich all jenen danken, die durch ihre fachliche und persönliche
Unterstützung zum Gelingen dieser Diplomarbeit beigetragen haben.
Besonderer Dank gebührt meinen Eltern, die mir dieses Studium durch ihre Unterstützung
ermöglicht haben.
Bedanken möchte ich mich auch bei Herrn Prof. Dr. rer. nat. Detlef Günther-Diringer, für die
Betreuung und Korrektur dieser Diplomarbeit. Trotz der Entfernung zwischen Karlsruhe und
Bonn, wurde ich immer durch seine freundliche Hilfsbereitschaft unterstützt.
Ebenso gilt mein Dank den Mitarbeitern der Firma terrestris, vor allem Hinrich Paulsen, Till
Adams, Lars-Hendrick Schneider, Dennis Hellmich, Marc Jansen und Martin Geilhausen.
Inhaltsverzeichnis
IV
Inhaltsverzeichnis
Erklärung........................................................................................................................ II
Danksagung................................................................................................................... III
Inhaltsverzeichnis ........................................................................................................ IV
Abkürzungsverzeichnis.................................................................................................VI
Abbildungsverzeichnis..................................................................................................IX
1 Einleitung....................................................................................................................1
1.1 Zielsetzung............................................................................................................ 3
1.2 Struktur der Arbeit................................................................................................ 4
Teil I:
Drahtlose Sensornetzwerke................................................................................... 5
2 Theoretische Grundlagen .......................................................................................10
2.1 Hardwarekomponenten ...................................................................................... 10
2.2 Netzwerktopologie.............................................................................................. 13
2.2.1 Multihop.......................................................................................................14
2.2.2 Gateways – Schnittstellen zu anderen Netzen ............................................ 15
2.3 Kommunikation und Protokolle..........................................................................16
2.3.1 Physikalische Schicht.................................................................................. 18
2.3.2 MAC Protokoll.............................................................................................18
2.3.2.1 Energieeffiziente und zuverlässige Steuerung der MAC Schicht........ 19
2.3.2.1.1 S-MAC .......................................................................................... 21
2.3.2.1.2 T-MAC ..........................................................................................24
2.3.3 Zeitsynchronisation......................................................................................27
3 ScatterWeb Plattform............................................................................................. 30
3.1 ScatterWeb Hardware......................................................................................... 31
3.1.1 MSP 430.......................................................................................................31
3.1.2 ESB ............................................................................................................. 32
3.1.3 eGate/WEB.................................................................................................. 33
3.2 Inbetriebnahme des ESB und eGate/WEB......................................................... 34
3.3 Software Architektur und Programmierung....................................................... 35
3.3.1 Firmware...................................................................................................... 36
3.3.1.1 ScatterWeb.Data................................................................................... 38
3.3.1.2 ScatterWeb.Message.............................................................................39
Inhaltsverzeichnis
V
3.3.2 Anwendungssoftware...................................................................................40
3.3.2.1 ScatterWeb.Event................................................................................. 42
3.4 Die ScatterWeb Plattform im praktischen Einsatz............................................. 43
Teil II:
Verarbeitung und Visualisierung von Messdaten aus einem drahtlosen
Sensornetzwerk.......................................................................................................... 46
4 Bisherige Lösungsansätze........................................................................................47
4.1 COMMON-Sense Net.........................................................................................47
4.2 MoteLab.............................................................................................................. 48
5 SensorGIS................................................................................................................. 51
5.1 Systementwurf und Implementierung.................................................................51
5.1.1 Übersicht des Gesamtsystems......................................................................52
5.1.2 Originäre Datenerfassung............................................................................ 55
5.1.2.1 Aggregation .........................................................................................58
5.1.3 WebGIS........................................................................................................60
5.1.3.1 UMN Mapserver und Apache Webserver............................................ 60
5.1.3.1.1 Die MAP-Datei.............................................................................. 61
5.1.3.1.2 WMS.............................................................................................. 64
5.1.3.2 PostgreSQL mit PostGIS: Geographische Datenbank..........................66
5.1.3.2.1 Geodatenmodell in PostGIS...........................................................67
5.1.3.2.2 Sensordatenmodellierung...............................................................68
5.1.3.3 Client - Schnittstelle zum Benutzer...................................................... 70
5.1.3.3.1 Mapbender..................................................................................... 75
5.1.4 Kopplung von GRASS GIS und WebGIS .................................................. 77
6 Ausblick.................................................................................................................... 80
7 Fazit........................................................................................................................... 82
Literaturverzeichnis...................................................................................................... 83
Abkürzungsverzeichnis
Abkürzungsverzeichnis
ACK
ACKnowledgement
ASCII
American Standard Code for Information Interchange
CAP
Contention Access Period
CGI
Common Gateway Interface
CPU
Central Processor Unit
CSS
Cascading Style Sheets
CTS
Clear To Send
DBMS
Datenbankmanagementsystem
DS
Data Send
ECR
Embedded Chip Radio
ESB
Embedded Sensor Board
EPSG
European Petroluem Survey Group
FRTS
Future-Ready-To-Send
GIS
Geographisches Informationssystem
GIF
Graphics Interchange Format
GPRS
General Paket Radio Service
GRASS
Geographic Resources Analysis Support System
GSM
Global System for Mobile Communications
GUI
Graphic User Interface
HTML
Hypertext Markup Language
HTTP
HyperText Transfer Protocol
IDSW
Inverse distance weighted average
IP
Internet Protocol
VI
Abkürzungsverzeichnis
ISM
Industrial, Scientific and Medical
ISO
International Organization for Standardization
JPG
Joint Photographic Group
JTAG
Joint Test Action Group
MAC
Medium Access Control
MD5
Message Digest Algorithm 5
MMS
Multimedia Messaging Service
MSP
Mixed Signal Processor
NAC
Network Allocation Vector
OGC
Open Geospatial Consortium
ORDBMS
Objektrelationales Datenbankmanagementsystem
OSI
Open Systems Interconnection
PDA
Personal Digital Assistant
PHP
rekursives Akronym für PHP: Hypertext Preprocessor
PNG
Portable Network Graphics
RAM
Random Access Memory
RF
Radio-Frequenz
ROM
Read-Only Memory
RSM
Read Sensor Mask
RTS
Request To Send
RTT
Round Trip Time
S-MAC
Sensor Medium Access Control
SSM
Set Sensor Mask
SQL
Structured Query Language
SVG
Scalable Vector Graphics
VII
Abkürzungsverzeichnis
TDMA
Time Division Multiple Access
T-MAC
Timeout Medium Access Control
TCP
Transmission Control Protocol
TDMA
Time Division Multiple Access
UMN
University of Minnesota
URL
Uniform Resource Locator
WebGIS
Webbasiertes, geographisches Informationssystem
WKB
Well-Known-Binary
WKT
Well-Kown Text
WLAN
Wireless Local Area Network
WMS
Web Map Service
WPAN
Wireless Personal Area Networks
XML
Extensible Markup Language
VIII
Abbildungsverzeichnis
IX
Abbildungsverzeichnis
Abb. 1: Die Grafik zeigt beispielhaft ein drahtloses Sensornetzwerk welches mit
unterschiedlichen Sensoren ausgestattet ist und durch Kommunikation im Netzwerk
Datenpakete an eine Basisstation mit Anschluss an das Internet sendet........................3
Abb. 2: Diverse Sensorknoten .......................................................................................5
Links: Smart Dust von der Universität Berkeley, USA. Quelle: [23].
Mitte: BTnode von der Universität Zürich. Quelle: [24].
Rechts: ESB (Embedded Sensor Board) der Firma ScatterWeb, Berlin. Quelle: [25].
Abb. 3: Drahtloses Sensornetzwerk zur Überwachung des marinen Ökosystems der
Ostsee (basierend auf [5])............................................................................................... 8
Abb. 4: Überblick über die fünf Hauptkomponenten eines Sensorknoten. .................. 9
Abb. 5: Schematische Darstellung einer Baum- und Sterntopologie...........................12
Abb. 6: Weg eines Datenpaket in einem Multihop Netzwerk.................................... 13
Abb. 7: Multihop.......................................................................................................... 14
Links: Die grüne Linie ist der neuer Weg eines Datenpakets, nachdem ein
Sensorknoten ausgefallen ist und somit der alte Weg (blaue Linie) hinfällig ist.
Rechts: Umgehung eines Hindernisses mit Multihop.
Abb. 8: Ein drahtloses Sensornetzwerk mit einem Gateway, welcher den Austausch
mit externen Systemen erlaubt......................................................................................14
Abb. 9: OSI-Modell (basierend auf [50])....................................................................15
Abb. 10: Grundprinzip des S-MAC............................................................................. 19
Abb. 11: Synchronisierte Schlaf- und Wachphasen von drei Sensorknoten............... 20
Abb. 12: Zwei virtuelle Cluster mit jeweils einem Synchronizer und einem
Randknoten................................................................................................................... 20
Abb. 13: RTS/CTS-Schema und NAV........................................................................ 21
Abb. 14: Unterschiedliche Wachmodi bei T-MAC und S-MAC, wenn ..................... 22
keine RTS/CTS Nachricht empfangen oder gesendet wird. ........................................22
Abb. 15: Knoten C kann Knoten D nicht in derselben Wachperiode erreichen..........23
Abb. 16: Knoten C sendet ein FRTS zu Knoten D und speichert wann er wieder
aufwachen muss. Hierbei kollidiert die FRTS mit der DS-Nachricht, welche nur ein
Dummy ist..................................................................................................................... 24
Abbildungsverzeichnis
X
Abb. 17: Ermittlung der Himmelrichtung eines akustischen Signals anhand der
Ankunftszeiten des Signals und der geographischen Position der Sensorknoten
(basierend auf [50]).......................................................................................................28
Abb. 18: Berechnung der Phasenverschiebung (basierend auf [52])..........................28
Abb. 19: Verarbeitungsablauf des MSP 430 (basierend auf [28])...............................32
Abb. 20: ESB (Embedded Sensor Board) der Firma ScatterWeb. Quelle: [25].......... 33
Abb. 21: Datenstrom zwischen einem drahtlosen Sensornetzwerk und dem Internet.....
34
Abb. 22: Trennung des Programmcode in die Bereiche Anwendung und Firmware
(System). Als Schnittstelle fungieren Callback-Funktionen........................................ 35
Abb. 23: Eingabe-Konsole von ScatterViewer............................................................ 38
Abb. 24: Schematischer Aufbau der ScatterWeb Software v2.3................................. 40
Abb. 25: Schematischer Aufbau eines drahtlosen Sensornetzwerkes mit Verbindung
zu einem PC über das Internet und Detektierung einer Bewegung mit anschließendem
Versand via Multihop zum Basisknoten (eGate/WEB)................................................43
Abb. 26: Verarbeitung und Visualisierung von Messdaten aus einem drahtlosen
Sensornetzwerk............................................................................................................. 43
Abb. 27: Verbindungsgraph der Sensorknoten. Quelle: [10]...................................... 45
Abb. 28: In diesem Ausschnitt ist die Einstellung der Sendeleistung der Sensorknoten
möglich [10]. ................................................................................................................46
Abb. 29: Grundriss des EECS und Darstellung der installierten Sensorknoten und
ihrer Verbindungsqualität zu anderen Sensorknoten. Quelle: [36]. ............................ 47
Abb. 30: Belegungsplan des MoteLab. Quelle: [47]................................................... 48
Abb. 31: Schematische Darstellung des Gesamtsystem.............................................. 50
Abb. 32: Verwendete Software zur Umsetzung des Gesamtsystem. .......................... 52
Abb. 33: Zustände von drei Nachrichten aus einem drahtlosen Sensornetzwerk zum
PHP-Programm. ........................................................................................................... 54
Abb. 34: Algorithmus zur Erfassung von Temperaturdaten in kontinuierlichen
Zeitabständen, wobei Temperaturmessung in unkontinuierlichen Zeitabständen aus
dem drahtlosen Sensornetzwerk gesendet werden können...........................................56
Abb. 35: einfache WebGIS Client Server Architektur..............................................57
Abb. 36: Ebenenhierarchie der MAP-Datei................................................................. 58
Abb. 37: Rasterbild mit Grundriss und Sensorknoten nach einem getMap-Aufruf.... 62
Abb. 38: Sensordatenmodell. ...................................................................................... 64
Abbildungsverzeichnis
XI
Abb. 39: ER-Modell von SensorGIS............................................................................65
Abb. 40 a/b/c/d/e: Arbeitswerkzeuge zur Exploration des Informationsraumes........ 66
Abb. 41: Übersichtskarte mit roten Rechteck, dass den Darstellungsbereich in der
Hauptkarte markiert...................................................................................................... 66
Abb. 42a: Button für die Funktionalität Details-on-Demand...................................... 67
Abb. 42b: Popup-Fenster mit Metadaten zum Sensorknoten mit der ID 1..................67
Abb. 43: Filterfunktion der Ebenen............................................................................. 68
Abb. 44: Rasterbild der Temperaturverteilung in einem Raum durch Interpolation aus
vier Messungen. .......................................................................................................... 69
Abb. 45: Thematische Karte der Temperaturverteilung in einem Raum mit Angabe
der minimalen und maximalen Temperatur durch eine Legende................................. 69
Abb. 46: Temperaturdiagramm eines Sensorknotens.................................................. 70
Abb. 47: Darstellung der aktuellen Temperaturmessungen.........................................70
Abb. 48: Graphische Oberfläche des Mapbenders zur Verwaltung der einzusetzenden
Werkzeuge in SensorGIS. .......................................................................................... 71
Abb. 49: Frontend von SensorGIS. Erstellt mit Mapbender........................................70
Abb. 50: Schematische Darstellung des internen Ablauf zur Erstellung einer
thematischen Karte....................................................................................................... 73
Abb. 51: Durch eine Verschneidung der Temperaturkarte mit dem Grundriss würde
der schwarz gekennzeichnete Bereich entfallen. Der schwarze Pfeil stellt einen
Gradienten von kalt nach warm dar.............................................................................. 75
Einleitung
1
1 Einleitung
Einleitung
Bei dem Aufbau eines Geographischen Informationssystems (GIS) werden die größten
Ressourcen an Arbeitskraft und Finanzmitteln in die Datenerfassung bzw. -beschaffung
investiert und lassen die Daten zum teuersten Gut eines Informationssystems werden [1,2,3].
Bisher sind die meisten Datenerfassungsverfahren nicht an vorhandene Informationssysteme
gekoppelt. Die zuständigen Personen müssen oftmals in ihr Untersuchungsgebiet reisen, um die
dort erfassten Daten auf einen externen Speicher zu sichern. Es kann dabei vorkommen, dass
Sensoren oder Datenlogger ausfallen und somit die Anreise und der Zeitraum der Erfassung
nutzlos waren. Dabei sind herkömmliche Datenerfassungsnetzwerke, die im Gelände installiert
und vor Ort gewartet werden müssen, aufgrund mangelnder Flexibilität und hoher Kosten
insgesamt recht schwerfällig. Des Weiteren handelt es sich hierbei oft um Expertensysteme, die
nur von Spezialisten installiert und in Betrieb genommen werden können. Aufgrund der oben
geschilderten Unflexibilität ist es auch schwer, spontane Messungen vorzunehmen, wie dies
z.B. für eine Temperaturmessung bei einem Waldbrand oder der Vibrationsermittlung bei
einem Bauvorhaben erforderlich wäre. [5]
Die Datengrundlage von geographischen Informationssystemen ist in den meisten Fällen relativ
statisch. D.h., die Datengrundlagen sind isoliert und werden durch manuelle Eingaben
erweitert. Für geographische Phänomene wie z.B. administrative Grenzen, die sich nicht häufig
ändern, ist diese Herangehensweise vollkommen ausreichend. Jedoch für Geodaten, die einer
stärkeren Dynamik unterliegen, wie z.B. Temperatur, Wasserstände, Erschütterungen und
Sonneneinstrahlung ist eine andere Herangehensweise sinnvoller. [4]
Eine Möglichkeit, den Kostenfaktor „Daten“ zu reduzieren und den gestiegenen Anforderungen
an ein leistungsstarkes, dynamisches und modernes Informationsmanagement gerecht zu
werden, bieten drahtlose Sensornetzwerke. Drahtlose Sensornetzwerke sind ein neuer Typus
von geographischen Informationssystemen zur tiefgreifenden, kontinuierlichen Erfassung und
Überwachung der Umwelt.
Die unterschiedlich erfassten Informationen eines drahtlosen Sensornetzwerkes können,
nachdem sie zu einem Endknoten geleitet wurden, mittels passenden Schnittstellen in ein
Einleitung
2
Datenbankmanagementsystem
(DBMS)
via
Internet,
Global
System
for
Mobile
Communications (GSM), General Paket Radio Service (GPRS), Funk oder einem anderen
Kommunikationsträger
überführt
werden.
Da
ein
drahtloses
Sensornetzwerk
aus
miniaturisierten Computern besteht, lassen Sie alle Möglichkeiten der Kommunikation zu und
bieten somit dem Anwender die Möglichkeit, interaktiv den Prozess des „Data-Workflows“ zu
beeinflussen. Es können Ergebnisse der Datenexploration wieder direkt in das System in Form
einer Justierung des Grenzwertes eines Sensors, der z.B. zur Erfassung der Feuchtigkeit in
einem Untersuchungsgebiet dient, zurückgeführt werden.
Momentan sind drahtlose Sensornetzwerke noch theoretisches Forschungsgebiet an vielen
Universitäten weltweit. Es gibt zwar einige kommerzielle Produkte, jedoch werden sie meist
nur zu Demonstrations- und Forschungszwecken eingesetzt. Bis zum Zeitpunkt der Erstellung
dieser Diplomarbeit im Juni 2006 gibt es kein kommerzielles Sensornetz welches großflächig
installiert wurde und praktisch eingesetzt werden kann. Des Weiteren sind kaum Applikationen
vorhanden, welche die erfassten Daten aus drahtlosen Sensornetzwerken effektiv verarbeiten
und visualisieren können. Da die Forschungsarbeiten primär an Fakultäten der Informatik
getätigt werden und Applikationen zur Visualisierung der erfassten Daten nicht im
Vordergrund stehen, soll im Rahmen dieser Diplomarbeit ein interdisziplinärer Ansatz aus der
Informatik und den Geowissenschaften aufgezeigt werden. Dabei werden die theoretischen
Grundlagen von drahtlosen Sensornetzwerken beschrieben und in direkten Zusammenhang mit
webbasierten, geographischen Informationssystemen gebracht.
Einleitung
3
Abb. 1: Die Grafik zeigt beispielhaft ein drahtloses Sensornetzwerk, welches mit unterschiedlichen
Sensoren ausgestattet ist und durch Kommunikation im Netzwerk Datenpakete an eine Basisstation mit
Anschluss an das Internet sendet.
1.1 Zielsetzung
Zielsetzung
Die vorliegende Arbeit soll die theoretischen Grundlagen von drahtlosen Sensornetzwerken
erläutern. Dazu gehören die Aspekte der zugrundeliegenden Hardwarekomponenten, sowie die
softwaretechnischen Implementierungen, die für einen funktionalen Betrieb nötig sind. Dabei
soll anhand von Kommunikationsprotokollen eine gewisse Art an künstlicher Intelligenz von
drahtlosen Sensornetzwerken dargestellt werden.
Des Weiteren wurde ein drahtloses Sensornetzwerk als sogenanntes Starter-Kit der Firma
ScatterWeb aus Berlin erworben, um auf den theoretischen Grundlagen praktische Erfahrungen
im Umgang mit der Installation und der Funktionsweise sammeln zu können.
Zielsetzung
4
Darüber hinaus soll eine Plattform entwickelt werden, die es ermöglicht, simultan Daten aus
einem drahtlosen Sensornetzwerk zu erfassen und diese über das Internet visualisieren zu
können. Die Serverkomponenten des Systems sollen nur mit Hilfe von Open-Source Produkten
entwickelt werden und die Datenspeicherung, der Datenaustausch und die visuelle
Repräsentation soll den Spezifikationen des OGC (Open Geospatial Consortium) entsprechen.
Dazu soll ein Client konzipiert und implementiert werden, der alle Möglichkeiten der visuellen
Datenexploration zur Verfügung stellt, um aus den Daten des drahtlosen Sensornetzwerkes
Informationen ableiten zu können.
1.2 Struktur der Arbeit
Die Arbeit ist in zwei Teile gegliedert :
Erster Teil
Im zweiten Kapitel werden zunächst die Grundlagen von drahtlosen Sensornetzwerken
dargestellt.
Dazu
gehört
die
Beschreibung
der
zugrundeliegenden
Hardware,
der
Netzwerkarchitektur und die interne Kommunikation im Netzwerk. Kapitel 3 widmet sich der
funktionalen Erläuterung eines drahtlosen Sensornetzwerkes der Firma ScatterWeb. Neben
einer Beschreibung des Aufbaus der Hardware und der ScatterWeb Systemsoftware werden
praktische Erfahrungen mit dem Umgang der Hard- und Software aufgezeigt.
Zweiter Teil
Kapitel 4 zeigt bisher entwickelte webbasierte Applikationen, die zur Visualisierung von
Messdaten aus drahtlosen Sensornetzwerken verwendet werden. Das Kapitel SensorGIS
konzentriert sich auf
die praktische Umsetzung eines webbasierten, geographischen
Informationssystems und deren Anbindung an das drahtlose Sensornetzwerk der Firma
ScatterWeb. Zum Abschluss beschreibt Kapitel 6 einen Ausblick und Kapitel 7 ein Fazit des
Erreichten.
Drahtlose Sensornetzwerke
Drahtlose Sensornetzwerke
5
Teil I:
Drahtlose Sensornetzwerke
„Drahtlose Sensornetzwerke werden Anwendungen zur Umweltüberwachung, Haustechnik und
Logistik revolutionieren“ [29].
Die Entwicklung im Bereich der Halbleitertechnik und der Sensorik hat in den letzten Jahren zu
einer
zunehmenden
Miniaturisierung
der
notwendigen
Hardware
von
drahtlosen
Sensornetzwerken geführt. Kleinstcomputer, sogenannte Embedded Systems, sind ausgestattet
mit einem Controller, einem Speicher und einer Sende- und Empfangseinheit. Als
Energieversorgung kommen Batterien oder andere Quellen in Frage, die Energie aus der
Umwelt des Sensors gewinnen können (Solarzellen, Thermoelemente, Piezokristalle,
Dynamos). [5]
Die Basishardware kann mit unterschiedlichsten Sensoren ausgestattet werden, z.B. Sensoren
zur Messung von Temperatur, Vibration, Bewegung, Infrarot, Feuchtigkeit, u.s.w..
Grundsätzlich lassen sich mit der Basishardware alle Sensoren koppeln, die über ein
elektronisches Ausgangssignal verfügen. Durch die Kopplung der Basishardware und der
Sensorik enstehen Sensorknoten. Die heutige Generation drahtloser Sensorknoten gibt es von
der Größe eines Schuhkartons bis hin zu kleinsten Sensorknoten, sogenannten Smart Dust
Sensoren, mit Abmessungen im Millimeterbereich. Die Zahl der Sensorknoten kann in
drahtlosen Sensornetzwerken zwischen einem halben Dutzend und mehreren tausend Knoten
variieren. Vor diesem Hintergrund mehrerer tausend Sensorknoten in einem Netzwerk besteht
die Forderung nach kleinen und billigen Sensorknoten. In Abbildung 2 sind einige
Sensorknoten abgebildet.
Drahtlose Sensornetzwerke
6
Drahtlose Sensornetzwerke
Abb. 2:
Links: Smart Dust von der Universität Berkeley, USA [23].
Mitte: BTnode von der ETH Zürich [24].
Rechts: ESB (Embedded Sensor Board) von der Firma Scatterweb, Berlin [25].
Vorteile von drahtlosen Sensornetzwerken
Mit Hilfe von Routing- und Aggregationsalgorithmen gestattet das Sensornetz eine
automatische, dynamische, dezentrale und flächendeckende Beobachtung von verteilten,
schwer zugänglichen oder bewegten Phänomenen. Drahtlose Netzwerke bieten eine Vielzahl an
Vorteilen gegenüber traditionellen, zentralisierten Vernetzungsansätzen. Eine verbesserte
Energieeffizienz bei der Kommunikation mit anderen Sensorknoten ist durch den Einsatz der
Multihop-Topologie möglich. Im Gegensatz zu Point-to-Point- Netzwerken, in welchen jeder
Knoten direkten Kontakt zum Host benötigt und die Sendeleistung sehr hoch ist, können in
Multihop-Netzwerken die Daten über andere Knoten zum Host geleitet werden. Sie kommen
somit mit einer wesentlich geringeren Energiezufuhr aus. Ferner können während der MultihopÜbertragung zusätzliche Informationen von anderen Knoten verarbeitet und mit in die
Übertragungen integriert werden.„Dabei wird aus einer relativ großen Menge von Rohdaten
auf niedrigem Informationsniveau (beispielsweise eine Menge von Sichtungen eines Objektes
durch verschiedene Sensorknoten) eine eher kleine Datenmenge auf relativ hohem
Informationsniveau (beispielsweise die Durchschnittsgeschwindigkeit und Bewegungsrichtung
des beobachteten Objektes) generiert“ [30].
Über die Tatsache hinaus, dass Daten simultan erfasst, gespeichert und ausgegeben werden,
Drahtlose Sensornetzwerke
7
sind nach Bollmann & Koch [54] die unterschiedlichen Kriterien einer hohen Datenqualität
erfüllt: Die Daten liegen immer aktuell vor und können somit in Echtzeit über das Internet
präsentiert werden. Durch die Topologie und Algorithmen des Netzwerkes wird eine hohe
Fehlerfreiheit des Netzwerkes und die Vollständigkeit der Daten gewährleistet. Aufgrund der
Möglichkeit, in Interaktion mit den Sensoren zu treten, kann der Benutzer die räumliche und
zeitliche Auflösung der Datenerfassung editieren und somit Einfluss auf das Datenmodell
nehmen.
Zudem gewährleisten drahtlose Sensornetzwerke eine Verbesserung der Skalierbarkeit, sowie
der Ausfallsicherheit. Ein dezentrales System ist aufgrund der Redundanz des Netzwerkes
weniger anfällig für den Ausfall von Sensorknoten. Dezentrale Algorithmen sind im
praktischen Einsatz leicht zu skalieren und wahrscheinlich der einzige Weg, um in großen
Arealen flächendeckend messen zu können. [52]
Drahtlose Sensornetzwerke im praktischen Einsatz
Aktuell vollzieht sich ein Paradigmenwechsel in der Art der Datenerfassung von physischen
Parametern. Erfolgte früher noch die originäre Datenerfassung durch schätzen, zählen oder
messen direkt in der Realität, so wird dies heutzutage in vielen Bereichen des alltäglichen
Lebens durch den Einsatz entsprechender Sensoren automatisch durchgeführt. Hierzu zählen
Sensoren an Autobahnen, die die Verkehrsdichte oder die Sichtweite messen und diese Werte
an eine Zentrale weitergeben. Auch Straßenlaternen werden, in Abhängigkeit vom Tageslicht,
automatisiert an- und ausgeschaltet. Diese Liste ließe sich beliebig fortsetzen. Drahtlose
Sensornetzwerke sind ebenfalls darauf ausgelegt, die oben beschriebenen Messungen
durchzuführen, gehen aber in ihren Anwendungsfeldern noch weit darüber hinaus. Die folgende
Aufzählung stellt einen Ausschnitt der denkbaren Einsatzfelder für drahtlose Sensornetzwerke
dar:
Drahtlose Sensornetzwerke
- Umweltmonitoring (z.B. Verkehr, Klimatologie, Geomorphologie, etc.)
- Katastrophenschutz (z.B. Feuer, Hochwasser, Vulkanismus, etc.)
Drahtlose Sensornetzwerke
8
- Umweltmonitoring (z.B. Verkehr, Klimatologie, Geomorphologie, etc.)
- Gebäudeüberwachung (z.B. Sicherheitssysteme, Gebäudeklima, etc.)
- Landwirtschaft (z.B. Bodenfeuchtigkeit, Frostgefahr, etc.)
- Militär (z.B. Objektüberwachung, Gefechtsfelderkundung, etc.)
- Trackingsysteme (z.B. Tiere, Container, Fahrzeuge, Personen, etc.)
Speziell in den USA wird seit einigen Jahren mit drahtlosen Sensornetzwerken experimentiert.
Die Anwendungen reichen von einer klimatologischen Überwachung und Steuerung von
Beleuchtungs- und Bewässerungssystemen eines botanischen Gartens [26] bis hin zur
Beobachtung von Vögeln und deren Verhalten auf einer Insel [27].
Aber auch in Europa wird seit einigen Jahren intensiv mit drahtlosen Sensornetzwerken
experimentiert. Beispielgebend ist ein drahtloses Sensornetzwerk zur Überwachung der Ostsee.
An einer Flussmündung zur Ostsee wurde im Frühjahr 2005 ein drahtloses Sensornetzwerk zur
Messung der Temperatur installiert. Für Meeresforscher sind das wichtige Informationen, um
das marine Ökosystem besser zu verstehen und mögliche Aussagen über zukünftige
Veränderungen treffen zu können. Traditionelle Messungen, entweder direkt aus dem Boot
oder mittels Datenlogger, sollten nicht angewandt werden, da die Daten direkt nach der
Messung zur Verfügung stehen sollten und eine Möglichkeit für eine dauerhafte Installation
gefunden werden sollte. Die Lösung war die Konzeption eines drahtlosen Sensornetzwerkes,
welches aus einer Zahl an Sensorknoten besteht, die in konstanten Abständen an einem Kabel
befestigt sind. Durch eine Boje an der Wasseroberfläche und einem Endgewicht werden die
Sensorknoten senkrecht in der Schwebe gehalten. Mit mehreren solcher Sensorketten ist es nun
möglich ein dreidimensionales Bild der Temperaturverteilung der See zu interpolieren. Die
Sensorknoten senden ihre erfassten Temperaturmessungen zur Boje, welche per Multihop
Verbindung zu anderen Bojen hat. Hierbei ist eine Boje mit einem GPRS-Modul ausgestattet
um die erfassen Daten des gesamten Netztes zum Festland zu übertragen. [5]
Drahtlose Sensornetzwerke
9
Abb. 3: Drahtloses Sensornetzwerk zur Überwachung des marinen Ökosystems der Ostsee (basierend auf
[5]).
Theoretische Grundlagen
Theoretische Grundlagen
10
Theoretische Grundlagen
2 Theoretische Grundlagen
Dieses Kapitel beschäftigt sich mit den theoretischen Grundlagen von drahtlosen
Sensornetzwerken. Dabei werden die primären Elemente der Hard- und Software erläutert, die
zu einem funktionalen Betrieb eines drahtlosen Sensornetzwerkes benötigt werden.
2.1 Hardwarekomponenten
(Das folgende Kapitel 2.1 und die darin enthaltene Grafik basieren auf [29])
Hardwarekomponenten
Die Auswahl passender Hardwarekomponenten für drahtlose Sensornetzwerke ist abhängig von
den Anforderungen und Bedingungen des gewählten Einsatzgebietes. Dabei muss ein
Kompromiss aus den Faktoren Größe, Kosten und Energieverbrauch gefunden werden. Bei
einem Einsatz in einem schwer zugänglichen Gebiet ist die Größe meist nur sekundär, jedoch
sollte der Energieverbrauch gering sein oder wenn möglich, sollten die Sensorknoten mit
erneuerbaren Energieträgern (Solarzellen) ausgestattet werden, damit eine Wartung der
Batterien nicht mehr nötig ist.
Die Grundelemente eines Sensorknoten umfassen fünf Komponenten (Abb. 4):
Controller
Der Controller ist der Kern eines drahtlosen Sensornetzwerkes. Er erfasst die Daten der
Sensoren oder anderer Sensorknoten, verarbeitet diese und entscheidet ob und wann diese
gesendet werden sollen. Dabei werden unterschiedliche Prozesse gestartet, welche z.B.
Kommunikationsprotokolle verarbeiten oder erfasste Daten zum Datenspeicher oder zur
Sendeeinheit transferieren. Solch unterschiedliche Datenverarbeitungsprozessen können von
einer Vielzahl an Controllern durchgeführt werden, die sich in der Systemarchitektur, der
Flexibilität, der Energieeffizienz und den Kosten unterscheiden. Eine Möglichkeit wäre, einen
allgemein verwendbaren Prozessor, wie er in den meisten Desktop Computern vorhanden ist, zu
nutzen. Diese Prozessoren haben jedoch einen exzessiven Energieverbrauch. Eine bessere
Möglichkeit bieten embedded systems. Wie der Name bereits andeutet, haben embedded
systems die Eigenschaften mehrere Komponenten auf einem einzigen Chip zu vereinigen. Diese
Hardwarekomponenten
11
integrierten Schaltkreise setzen sich dann aus einer CPU (Central Processor Unit), einem
Programmspeicher (auf ROM- oder Flash-Basis) und dem Arbeitsspeicher zusammen. Sie
werden herkömmlich als Mikrocontroller bezeichnet [49]. Weitere Merkmale, weshalb
Mikrocontroller bei drahtlosen Sensornetzwerken eingesetzt werden, sind ihre hohe Flexibilität
zur Anbindung an andere Bauteile (Sensoren) und ihre Programmierbarkeit bis auf die
niedrigsten Schichten des OSI-Modell (Open Systems Interconnection Reference Model). Zur
Reduzierung des Energieverbrauchs haben sie die Möglichkeit sich in einen Energiesparmodus
zu versetzen und benötigen in diesem Zustand nur einen Bruchteil ihres normalen
Energiebedarfs.
Speicher
Der Speicher setzt sich aus zwei Bereichen zusammen. Der Random Access Memory (RAM)
dient zur Speicherung von temporären Messdaten der Sensoren und fungiert als
Zwischenspeicher von Datenpaketen anderer Sensorknoten. Der RAM ist ein sehr schneller
Speicher mit kurzen Zugriffszeiten, jedoch verliert er seine Daten wenn die Stromversorgung
ausfällt.
Zur Speicherung von Applikationen wird deshalb der Read-Only Memory (ROM) oder ein
Flash Speicher verwendet. Selbst bei Stromverlust bleiben die Daten, wie bei einer Festplatte,
erhalten.
Transceiver
Der Transceiver dient zum Datenaustausch zwischen den Sensorknoten und ist eine
Kombination aus einem transmitter (Sender) und einem receiver (Empfänger). Einer seiner
primären Aufgaben besteht darin, die Daten des Mikrocontroller in Radiowellen zu
konvertieren und zu versenden. Im Empfangsmodus wiederum werden die erhaltenen
Informationen demoduliert und zum Mikrocontroller geleitet.
Sensor
Durch den Anschluss eines Sensors oder mehrerer Sensoren wird dem Sensorknoten seine
eigentliche Aufgabe zugewiesen. Denn die Intention eines drahtlosen Sensornetzwerk ist nicht
Berechnungen anzustellen oder zu kommunizieren, sondern vielmehr die Umgebung
wahrzunehmen.
Sensoren können dabei in drei Gruppen kategorisiert werden:
Hardwarekomponenten
12
Passive, ungerichtete Sensoren Diese Sensoren messen eine physikalische Größe in der
unmittelbaren Umgebung des Sensorknotens ohne aktiv die
Umwelt zu beeinflussen. Beispiele solcher Sensoren messen
Temperatur, Vibration, Bewegung, Geräusche, Feuchtigkeit
und Luftdruck.
Passive, gerichtete Sensoren
Diese Sensoren sind ebenfalls passiv. Sie haben jedoch
während der Messung eine definierte Richtung. Ein typisches
Beispiel hierfür ist eine Kamera.
Aktive Sensoren
Diese letzte Gruppe von Sensoren untersuchen ihre
Umgebung durch aktiven Einsatz von Radiowellen, Radar,
seismischen Stößen, etc..
Energieversorgung
Netzwerk Topologie
Die Energieversorgung ist bei den meisten drahtlosen Sensornetzwerken eine kritische
Systemkomponente. Denn die Energie wird üblicherweise durch Batterien bereitgestellt, und ist
somit einer mittelbaren Lebensdauer unterworfen, sofern die Batterien nicht extern aufgeladen
werden. Für eine grobe Orientierung, eine normale AA Batterie speichert zwischen 2,2 – 2,5
Ah bei 1,5 V. Die daraus sich ergebende Lebensdauer eines Sensorknotens kann hier nicht
angeführt werden, da die Sensorknoten einer fast nicht zu berechnenden Dynamik der Umwelt
unterworfen sind und eine Abhängigkeit vom verwendeten Kommunikationsprotokolls
vorhanden ist.
Abb. 4: Überblick über die fünf Hauptkomponenten eines Sensorknoten (basierend auf [29]).
Netzwerk Topologie
13
2.2 Netzwerktopologie
Netzwerk Topologie
Die Netzwerktopologie gibt die Struktur der Verbindungen zwischen den einzelnen
Sensorknoten wieder und bildet damit ein Netzwerk.
Der Fortschritt von Netzwerktopologien in drahtgebundenen Netzwerken diente auch der
Entwicklung passender Topologien für drahtlose Sensornetzwerke. Hierbei stellt sich jedoch
die Frage, inwieweit traditionelle Topologien für dieses neue Kommunikationsmedium
geeignet sind. Denn zusätzliche Anforderungen wie hohe Interoperabilität, niedriger
Energiebedarf, hohe Flexibilität und einfache Skalierbarkeit, erhöhen die Komplexität der
nötigen Topologie massiv.
Am Anfang der Entwicklung nutzte man einfache Topologien wie Stern- oder Baumtopologien
[31]. Der Vorteil hierbei ist die zentrale Netzwerkadministration und eine zentrale Vergabe von
Adressen [48]. Der Nachteil besteht darin, dass die Sensorknoten immer direkten Kontakt zur
einer Basisstation haben müssen, was einen hohen Energieverbrauch zur Folge hat. Auch eine
Skalierung des Netzes setzt immer eine Verbindung des Sensorknoten zur Basisstation voraus.
Durch den Ausfall der Basisstation erliegt der Netzverkehr eines Clusters oder der des
gesamten Netzes, wenn die Basisstation mit Verbindung an das äußere Netz betroffen ist. Die
Lösung hierfür wäre eine Architektur, die sich die Fähigkeiten der bidirektionalen
Kommunikation von Sensorknoten zu Nutze macht, und diese bei der Datenübertagung
eingesetzt werden kann.
Abb. 5: Schematische Darstellung einer Baum- und Sterntopologie.
Netzwerk Topologie
14
2.2.1 Multihop
Netzwerk Topologie
Eine Architektur bei der jeder Sensorknoten als
Router eingesetzt werden kann gleicht einem
vermaschten Netz und basiert somit auf der WebTopologie.
Jeder Sensorknoten kann mit anderen Sensorknoten
verbunden sein und der Ausfall eines einzelnen
Knotens hat eine geringe Konsequenz für den
Datenverkehr im Netzwerk. Das Sprichwort „viele
Wege führen nach Rom“ ist hierfür sehr passend.
Bei einem Ausfall eines Sensorknotens, welcher
Datenpakete
anderer
Sensorknoten
übermittelt,
werden daraufhin die Datenpakete über andere
Sensorknoten zum Host geleitet. Diese Technologie,
Abb. 6: Weg eines Datenpaket in
einem Multihop Netzwerk.
Datenpakete über mehrere Sensorknoten senden zu
können, wird als Multihop bezeichnet (Abb. 6). Durch Anwendung dieser Technologie ergibt
sich nicht nur der Vorteil einer hohen Ausfallsicherheit (Abb. 7), vielmehr kommen die
Sensorknoten, in einem eng vermaschten Netz, mit einer weitaus geringeren Sendeleistung aus,
da sie keine direkte Verbindung zur Basisstation haben müssen. Auch etwaige Hindernisse
können durch Multihop umgangen werden, wie Abbildung 7 zeigt. Somit ist auch eine einfache
Skalierbarkeit des Netzes gewährleistet. Neue Sensorknoten müssen nur eine Verbindung zu
einem weiteren Sensorknoten aufweisen. Daher ist das Netzwerk theoretisch beliebig
erweiterbar, ohne zusätzlich weitere Basisstationen installieren zu müssen, da im Grunde jeder
Sensorknoten schon eine Basisstation darstellt, welche Datenpakte entgegennehmen und
weiterleiten kann.
Netzwerk Topologie
15
Abb. 7: Links: Die grüne Linie ist der neue Weg eines Datenpakets, nachdem ein Sensorknoten
ausgefallen ist und somit der alte Weg (blaue Linie) hinfällig ist. Rechts: Umgehung eines Hindernisses
mit Multihop.
2.2.2 Gateways – Schnittstellen zu anderen Netzen
Drahtlose Sensornetzwerke sollten in der Lage sein, Informationen mit anderen Systemen
auszutauschen. Beispielsweise konfiguriert ein Nutzer mit einem PDA ein drahtloses Netzwerk
vor Ort oder ein entfernter Nutzer mit Zugang zum Internet informiert sich über die aktuellsten
Temperaturwerte der Sensorknoten [29]. Zur Transformation der Daten zwischen diesen
Netzwerken müssen Protokollumsetzer, sogenannte Gateways verwendet werden [20]. Sie sind
zur Kopplung von Sensornetzwerken mit anderen Kommunikationsnetzen (Internet, Intranet,
GSM, GPRS) einsetzbar und fungieren als letztes Glied in einem drahtlosen Sensornetzwerk.
Ihre Aufgabe ist es, bidirektional Daten des äußeren Netzes in äquivalente Daten des
Sensornetzwerkes umzuwandeln. Eine Möglichkeit wäre, einen Router zwischen dem äußeren
Netz und dem Sensornetzwerk zu integrieren. Dies würde jedoch bedingen, dass das
Sensornetzwerk das gleiche Protokoll wie das äußere Netz benutzen müsste. Wie zum Beispiel
bei einem Anschluss an das Internet. Dazu müsste das drahtlose Sensornetzwerk auch mit dem
TCP/IP Protokoll kommunizieren. Während diese Option auf jeden Fall nicht außer Acht
gelassen werden sollte [11,13,17,45], hat man sich dafür entschieden, dass drahtlose
Netzwerk Topologie
16
Sensornetzwerke optimierte Protokolle benötigen, welche den speziellen Anforderungen an
Flexibilität und Energieeffizienz gerecht werden [29]. Dementsprechend ist der Einsatz von
Routern unzulänglich. Es werden speziell programmierte Gateways benötigt, die eine
Umwandlung der verschiedenen Protokolle bewerkstelligen können.
Abb. 8: Ein drahtloses Sensornetzwerk mit einem Gateway, welcher den Austausch mit externen
Systemen erlaubt.
2.3 Kommunikation und Protokolle
Kommunikationsprotokolle
In einem drahtlosen Sensornetzwerk müssen die erfassten Messdaten eines Sensors erst eine
Vielzahl an Protokollen und Schichten durchlaufen, bevor die Daten dem Anwender zugänglich
sind. Die dazu erforderliche Kommunikation ist nicht trivial, denn es müssen Anforderungen
bezüglich Zuverlässigkeit, Sicherheit, Effizienz, etc. erfüllt werden. Außerdem müssen
Probleme wie die Übertragung der elektronischen Signale oder der geregelten Reihenfolge der
Kommunikation gelöst werden. Aufgrund dieser Aufgaben und Probleme wurde von der ISO
(International Organization for Standardization) ein sogenanntes OSI Modell (OSI: Open
Systems Interconnection) entwickelt (Abb. 9), welches sich in sieben Schichten aufteilt und
vereinheitlichte Verfahren und Regeln für den Austausch von Daten vorschreibt. Dieses
Schichtenmodell ist keine spezielle Entwicklung von drahtlosen Sensornetzwerken, sondern ein
allgemeingültiges Modell für die Kommunikation informationsverarbeitender Systeme [51].
Kommunikationsprotokolle
17
OSI-Schicht
Einordnung Einheiten
1 Anwendung
2 Darstellung
Anwendung Daten
3 Sitzung
4 Transport
Segment
5 Vermittlung
Transport
Pakete
6 Sicherung
Frames
7 Bitübertragung
Bits
Abb. 9: OSI-Modell (basierend auf [50]).
Kommunikationsprotokolle in Sensorknoten sind die fundamentalen Eckpfeiler eines drahtlosen
Sensornetzwerkes [6]. Die Möglichkeit hardwarenah Einfluss auf die Sensorknoten ausüben zu
können, bietet einige der interessantesten Möglichkeiten in der Programmierung von drahtlosen
Kommunikationsprotokollen [43]. Für die praktische Evaluation neuer Protokolle eignen sich
gängige Netzwerkgeräte wie PCs, Laptops oder PDAs größtenteils nicht, da sie nur
Kommunikationsprotokolle wie das IEEE 802.11 (WLAN) unterstützen und sich unterhalb der
Vermittlungsschicht nicht programmieren lassen [28]. Nach Weilian Su et al. vom Georgia
Institute of Technology in Atlanta, USA [43] fordern Kommunikationsprotokolle von
drahtlosen Sensornetzen gegenüber traditionellen Protokollen in Ad-hoc-Netzwerken (WLAN,
Bluetooth) einen höheren Anspruch an die Programmierung :
- Die Topologie verändert sich häufig.
- Sensorknoten nutzen hauptsächlich das Broadcast Paradigma, um sich im Netz zu
integrieren, während in den meisten Ad-hoc-Netzwerken eine Punkt zu Punkt
Kommunikation stattfindet.
- Sensorknoten haben nur limitierte Ressourcen bezüglich Energie, Rechenleistung und
Speicher.
- Drahtlose Sensornetzwerke werden meist mit speziellen Applikationen ausgestattet; Adhoc-Netzwerke werden häufig für allgemeine Kommunikationszwecke konstruiert.
In den folgenden Abschnitten werden nun die wichtigsten Schichten und die dazugehörenden
Protokolle beschrieben, die sich hauptsächlich mit der Kommunikation in einem drahtlosen
Sensornetzwerk befassen.
Kommunikationsprotokolle
18
2.3.1 Physikalische Schicht
Die physikalische Schicht oder Bitübertragungsschicht ist die unterste Schicht des OSI-Modells
und primär mit der Übertragung (Modulation) und dem Empfang (Demodulation) von
drahtlosen Wellenformen und deren Verarbeitung zu digitalen Daten beschäftigt. Diese
Aufgabe wird durch den Transceiver ausgeführt. Die Herausforderung in drahtlosen
Sensornetzen besteht darin, passende Modulationsschemata und Transceiver zu finden, welche
einfach, preiswert, jedoch robust genug sind, um die geforderten Aufgaben zu erfüllen [29].
Beim Einsatz drahtloser Übertragungstechniken muss die Trägerfrequenz sorgfältig ausgewählt
werden. In der Radio-Frequenz (RF) Kommunikation ist die Bandbreite zwischen 3 kHz und
300 Ghz angesiedelt [7]. Dabei haben manche Länder spezielle Lizenzen für reservierte
Frequenzbänder. In Europa kann das GSM 900 exklusiv den Frequenzbereich von 880-915 Mhz
für sich beanspruchen. Es gibt jedoch auch lizenzfreie Bänder, wie das ISM (Industrial,
Scientific and Medical), das jedoch nur bis zu einer bestimmten Sendeleistung lizenzfrei
verwendet werden darf. Es gibt außerdem die Möglichkeit einer optischen oder infraroten
Übertragung. Zum Beispiel nutzen die von der Universität Berkeley entwickelten Smart Dust
Sensorknoten zur Kommunikation künstliche Lichtquellen [33].
2.3.2 MAC Protokoll
MAC Protokoll
Das Medium Access Controll (MAC) Protokoll ist das erste Protokoll über der
Bitübertragungsschicht und ist Teil der Sicherungsschicht, die sich noch aus den Bereichen des
error control und flow control zusammensetzt. Da das MAC Protokoll das größte
Forschungsgebiet von Kommunikationsprotokollen darstellt [29], bezieht sich dieses Kapitel
ausschließlich auf MAC Protokolle.
MAC Protokolle lösen scheinbar einfache Aufgaben: Sie koordinieren den Zugriff auf ein
gemeinsam genutztes Medium, die Frequenz. Aber warum sind dann in den letzten 30 Jahren
eine unüberschaubare Anzahl an Protokollen erforscht, entwickelt und getestet worden?
Die Schwierigkeit liegt gerade in der Koordination des gemeinsam genutzten Mediums. Daher
muss darauf geachtet werden, dass alle Signale verschiedenster Sender ankommen und es dabei
MAC Protokoll
19
nicht zu Kollisionen kommt. Wenn Beispielsweise ein Empfänger zwei Signale gleichzeitig
erhält, spricht man von einer Kollision, wobei alle Informationen zerstört werden. Die meisten
MAC Protokolle versuchen dieses Problem zu minimieren, indem sie die benötigte
Kanalkapazität reduzieren, Kontrollmechanismen integrieren oder versuchen, Kollisionen
vollständig zu verhindern. Es gibt bisher keine Lösung, welche Strategie die bessere ist, denn
jeder Versuch Kollisionen zu verhindern, benötigt auch Kapazitäten und/oder neue Kanäle zur
Übertragung.
MAC Protokolle für drahtlose Sensornetzwerke fordern gegenüber „traditionellen“
MAC
Protokollen mehr Bedingungen, die erfüllt werden sollten oder sogar müssen. Vorerst ist die
Anforderung an energieschonende Protokolle gerichtet. Die ungemeine Wichtigkeit von
energieeffizienten MAC Protokollen ist relativ neu, denn viele der traditionellen Protokolle
beinhalten keine solche Maßnahmen, da sie für Systeme mit genügend Energie programmiert
wurden. Andere Anforderungen wie Fairness, Datendurchsatz oder Latenzzeiten spielen nur
eine untergeordnete Rolle in drahtlosen Sensornetzen. Fairness ist nicht wichtig, da die
Sensorknoten keine individuellen Komponenten darstellen und somit nicht um Bandbreite
konkurrieren, vielmehr müssen sie zusammenarbeiten, um ein gemeinsames Ziel zu erreichen.
Latenzzeiten stehen im Gegensatz zu Energiekonservierung und der Datendurchsatz stellt kein
größeres Problem dar, da die Datenmengen meist nur gering sind. Weitere wichtige
Anforderungen an MAC Protokolle sind die Skalierbarkeit und Robustheit gegenüber einer
häufig sich verändernden Topologie des Netzes, zum Beispiel verursacht durch einen
Batteriewechsel, der Beweglichkeit der Sensorknoten, die Installation neuer Knoten oder der
Exitus vorhandener Knoten. Der Bedarf einer hohen Skalierbarkeit ist naheliegend, wenn man
bedenkt, dass ein Sensornetz aus Dutzenden oder Hunderten von Knoten bestehen kann.
[8,18,29]
2.3.2.1 Energieeffiziente und zuverlässige Steuerung der MAC Schicht
Der Transceiver eines Sensorknotens verbraucht einen erheblichen Anteil der vorhandenen
Energie. Der Verbrauch hängt davon ab, in welcher Phase der Transceiver sich gerade befindet:
Im Sende-, Empfangs-, Leerlauf- oder Schlafmodus. Das Senden und Empfangen verbraucht die
höchsten Energiemengen. Im Leerlauf wird zwar weniger benötigt, da aber die Knoten die
meiste Zeit im Leerlauf sind, ist der Verbrauch über einen längeren Zeitraum zu hoch. Im
MAC Protokoll
20
Schlafmodus hingegen benötigt der Transceiver fast keine Energie, allerdings ist der Knoten in
diesem Zustand fast „taub“. Diese vier Zustände, die der Transceiver einnehmen kann, werden
durch das MAC Protokoll gesteuert.
Folgend werden nun Probleme bei der Steuerung dieser vier Zustände genannt und ansatzweise
passende Lösungen aufgezeigt [29]:
- Leerlauf: Ein Sensorknoten ist bereit Signale zu empfangen, jedoch im Moment
kommen
keine
Signale
am
Empfänger
an.
Diese
ständige
Bereitschaft
ist
energieaufwendig und im Fall einer niedrigen Netzlast unnötig. Den Transceiver
auszuschalten wäre eine Möglichkeit, jedoch können in diesem Zustand keine Signale
empfangen oder gesendet werden. Eine Lösung wäre TDMA (Time Division Multiple
Access) basierte Protokolle bei denen der Transceiver phasenweise in den Schlafmodus
versetzt wird. Dabei wird das Medium (Frequenz) in sogenannte Zeitfenster unterteilt und
ein Datenaustausch ist nur während dieser Zeit möglich.
- Overhearing: Unicast Nachrichten haben eine Quelle und eine Zieladresse. In vielen
drahtlosen Medien, wie ein Radio oder Fernsehen, kann die Information jedoch nur als
Broadcast gesendet werden und erreicht dabei alle Empfänger, welche in Sendereichweite
liegen. Damit nun nicht jeder unbestimmte Sensorknoten in Sendereichweite Daten im
energieintensiveren Empfangsmodus empfängt, um anschließend doch wieder zu
verwerfen, kann Overhearing implementiert werden. Dabei können die Knoten anhand
einer ID erkennen, ob das Datenpaket für sie bestimmt ist oder nicht. Falls Nein,
überhören (overhear) die Knoten die Nachricht. Heidemann, J., et al. [19] zeigt, dass sich
in dichten Sensornetzen durchaus signifikante Energiemengen einsparen lassen.
- Kollision: Kollisionen entstehen, wenn an einem Empfänger zum gleichen Zeitpunkt
mehrere Signale ankommen. Dies zerstört nicht nur alle Informationen, sondern
verschwendet auch Energie. Die Lösung hierfür wären wieder TDMA basierte
Protokolle, bei denen jedem Sensorknoten ein bestimmtes Zeitfenster reserviert wird. In
Netzwerken mit einer niedrigen Netzlast sind Kollisionen meistens kein Problem.
Die häufigsten MAC Protokolle für drahtlose Sensornetzwerke haben Lösungen für solche
Probleme und sind dabei energieschonend. Die Konstruktion solcher Protokolle darf eine
MAC Protokoll
21
gewisse Komplexität nicht überschreiten. Sensorknoten sind von Ihrer Bauweise einfach und
billig und können somit nicht massenhaft Ressourcen zur Verarbeitung und Speicherung von
komplizierten Algorithmen verschwenden. In den folgenden Abschnitten werden nun MAC
Protokolle aufgezeigt, die auf unterschiedliche Weise versuchen, die Probleme der
Energieeffizenz und der Zuverlässigkeit der Datenübertragung zu lösen und dabei nicht zu
komplex sein dürfen.
2.3.2.1.1 S-MAC
Das Sensor Medium Access Control (S-MAC) Protokoll wurde von Wei Ye und John
Heidemann, beide vom Information Science Institute der Universität von South Carolina, sowie
Deborah Estrin vom Computer Science Department der Universität von Kalifornien, Los
Angeles entwickelt [19]. S-MAC regelt die Initialisierung, sowie den Ablaufplan und stellt ein
Kommunikationsschema zur Verfügung. Das primäre Ziel des S-MAC Protokolls ist die
Reduzierung der energieraubenden Probleme von Kollisionen zwischen Datenpaketen und des
permanenten Leerlaufs der Sensorknoten. Die Anforderung des Overhearing wurde ebenfalls
implementiert.
Um das Problem des Leerlaufs zu umgehen werden die Sensorknoten in periodische Schlafund Wachzustände versetzt. S-MAC versucht alle Sensorknoten zu synchronisieren, damit sich
alle Knoten zur gleichen Zeit im richtigen Zustand befinden. D.h. es wäre sinnlos, wenn jeder
Knoten nach seinem eigenen Zeitplan die Zustände wechseln würde, da in Schlafphasen keine
Nachrichten empfangen werden können. Der Wachzustand (Leerlauf) sollte so kurz wie
möglich sein, um Energie zu sparen, jedoch lange genug, um die maximal anfallenden
Datenpakete zu empfangen, da sonst alle Daten verworfen werden müssten. Die Schlafperiode
sollte so lange wie möglich sein. Die Wach- und Schlafperiode ergeben zusammen die
Rahmenzeit und spiegeln die maximale Latenzzeit wieder. Bei einer Schlafphase (Ausschalten
des Transceiver) von einer halben Sekunde und einer Wachphase von einer halben Sekunde,
spart man theoretisch schon 50% an Energie, wenn die Energiekosten zur Initialisierung des
Transceiver nicht berücksichtigt werden.
MAC Protokoll
22
Abb. 10: Grundprinzip des S-MAC.
Zur Initialisierung des Netzes dient ein Synchronisationsimpuls, der das Netz in virtuelle
Cluster teilt und den Zeitplan der Sensorknoten festlegt. Zu Beginn warten alle Sensorknoten
eine zufällige Zeit ab, bis eine SYNC-Nachricht ankommt. Die SYNC-Nachricht enthält die
Information, in welchen periodischen Abständen die Knoten schlafen und wachen sollen. Ist bei
einem Sensorknoten die zufällige Zeitspanne abgelaufen und er hat noch keine SYNCNachricht bekommen, ernennt er sich zu einem Synchronizer und sendet als Broadcast eine
SYNC-Nachricht. Warum die zufällige Wartezeit? Es würde sonst zu Kollisionen kommen, da
alle Knoten zur selben Zeit senden würden. Der Synchronizer hat diese Aufgabe nicht nur zu
Beginn, sondern sendet diese Nachricht in kontinuierlichen Zeitabständen wieder, um einem
time-drift (Zeitverzug) der Knoten entgegenzuwirken und neu hinzukommenden Knoten die
Möglichkeit zu geben, sich einem Cluster zuzuordnen. Wenn nun ein Sensorknoten im
Senderadius zweier Synchronizer liegt, gibt es erstens die Möglichkeit, dass der Knoten bei
beiden Zeitplänen teilnimmt und somit als Gateway zwischen den Clustern fungieren kann,
insbesondere um Broadcast Nachrichten weiterleiten zu können. Der Nachteil ist, dass diese
Randknoten, im Vergleich zu gewöhnlichen Knoten, doppelte Wachzeiten haben. Die zweite
Möglichkeit ist, dass der Sensorknoten sich an die Wach- und Schlafphasen des ersten
Synchronizer hält, den zweiten Zeitplan speichert und im Bedarfsfall „früh aufstehen“ kann, um
eine Nachricht in das sekundäre Cluster senden zu können. Der Nachteil: Broadcast
Nachrichten und Anfragen des sekundären Clusters können so nicht sicher empfangen werden.
MAC Protokoll
23
Abb. 11: Synchronisierte Schlaf- und Wachphasen von drei Sensorknoten.
Abb. 12: Zwei virtuelle Cluster mit jeweils einem Synchronizer und einem Randknoten.
Damit
es
während
Kommunikationsschema
der
die
Übertragung
nicht
zu
Rendezvous-Technik,
Kollisionen
in
Form
kommt,
eines
wurde
als
RTS/CTS-Schema,
implementiert (Abb. 13):
- Knoten A möchte seine Daten an Knoten B senden und sendet eine RTS-Nachricht
(RTS: request to send), welche Informationen über die Datengröße beinhaltet.
MAC Protokoll
24
- Wenn Knoten B die Nachricht erhalten hat, antwortet er mit einer CTS-Nachricht
(CTS: clear to send).
- Knoten A kann mit der Datenübertragung beginnen.
- Knoten B hat alle Daten korrekt erhalten und sendet ein ACK-Nachricht (ACK:
acknowledgement) zurück.
Die Anforderung des overhearing wird auch durch die Verwendung des RTS/CTS-Schema
gelöst. Wenn Knoten A seine Nachricht an Knoten B sendet und Knoten C bekommt diese
Nachricht ebenfalls, dann speichert Knoten C die Länge des Datenpaketes. Anhand dieser
Nachricht kann Knoten C einen sogenannten NAC (Network Allocation Vector) Zähler festlegen
und mit Hilfe dieser Information kann der Knoten für die Dauer der Übertragung in den
Schlafmodus wechseln.
Abb. 13: RTS/CTS-Schema und NAV.
2.3.2.1.2 T-MAC
Das Timeout MAC Protokoll baut auf dem Prinzip des S-MAC Protokoll auf und gilt allgemein
als Verbesserung [18,29,51]. Das grundsätzliche Problem des S-MAC Protokolls sind die
relativ langen Wachphasen. Das Protokoll ist jedoch so implementiert, dass die Länge eine
festgesetzte Größe ist. Somit könnte bei einem großen Datenaufkommen eine vollständige
Übertragung gewährleistet werden. Die Lösung wäre einen Timeout zu definieren, welches eine
MAC Protokoll
25
maximale Wartezeit zum Empfangen einer RTS/CTS- Nachricht gewährt. Ist diese Zeitspanne
überschritten, so kann sich der Knoten vorab in den Schlafmodus versetzen.
Abb. 14: Unterschiedliche Wachmodi bei T-MAC und S-MAC, wenn
keine RTS/CTS Nachricht empfangen oder gesendet wird.
Dieser vorgeschlagene Ansatz von T. van Dam und K. Langendeon von der Universität in Delft,
Niederlande, funktioniert sehr gut bei 1-Hop-Nachbarschaften [44]. Jeder Knoten hört für eine
gewisse Zeit den Kommunikationskanal ab und stellt fest, dass keine Nachricht vorhanden ist
und schaltet sich bis zur nächsten Periode ab. Jedoch entstehen mit dieser Lösung eines
intelligenten Protokolls neue Probleme bezüglich des RTS/CTS-Schemas. Abb. 15 zeigt ein
mögliches Problem auf: Knoten A möchte Daten zu Knoten B senden und verschickt ein RTS.
Knoten B antwortet mit einem CTS, welches auch Knoten C mitbekommt. Knoten C weiß, dass
gleich eine Kommunikation zwischen Knoten A und B starten wird, auch wenn er selbst keine
Verbindung zu Knoten A hat. Anhand der CTS-Nachricht weiß Knoten C wie lange die
Übertragung dauern wird, und kann sich für diese Zeitspanne schlafen legen. Knoten D
bekommt währenddessen nichts von der Kommunikation zwischen den anderen Knoten mit. C
wäre der einzige Knoten in Reichweite zu D, jedoch hat aufgrund der Kanalbelegung durch
Knoten B C nicht die Möglichkeit D darüber zu informieren. Somit geht Knoten D davon aus,
dass keine Kommunikation mehr stattfinden wird und kann sich bis zur nächsten Periode
ausschalten. Wenn Knoten C Daten an Knoten D senden möchte, müsste er bis zur nächsten
Wachperiode warten.
MAC Protokoll
26
Abb. 15: Knoten C kann Knoten D nicht in derselben Wachperiode erreichen.
Diese
Ausgangssituation
wäre,
wie
angesprochen,
kein
Problem
in
1-Hop-
Nachbarschaftsbeziehungen, jedoch würden sich in einem größeren Netzwerk mit vielen
virtuellen Clustern diese Verspätungen beträchtlich akkumulieren und wenn die maximale
Puffergrenze der einzelnen Knoten erreicht ist, sogar das ganze Netz zum Erliegen bringen.
Deswegen haben T. Van Dam und K. Langendeon weitere Kontrollmechanismen
implementiert, die Knoten C ermöglichen, seine Daten während derselben Wachperiode zu
Knoten D zu senden. Hinzu kommen eine FRTS-Nachricht (FRTS: Future-Ready-To-Send) und
eine DS-Nachricht (DS: Data Send). Beide Nachrichten befinden sich in der Reihenfolge hinter
der CTS-Nachricht, bzw. vor den Daten. Bei jeder Nachricht, die verschickt wird, kommt
standardmäßig immer eine DS-Nachricht hinzu, welche keine wichtigen Daten enthält und als
Dummy fungiert. Somit weiß Knoten C, dass nach der CTS-Nachricht Knoten A ein Dummy
verschickt, und er damit die Möglichkeit hat, eine FRTS-Nachricht an D zu senden ohne dabei
die Kommunikation zwischen Knoten A und B zu stören. Die FRTS-Nachricht teilt Knoten D
mit, dass eine andere Kommunikation stattfindet und er jetzt in in den Schlafzustand wechseln
kann, jedoch in x Zeiteinheiten wieder aufwachen muss. Die Länge dieser Schlafphase ergibt
sich aus der CTS-Nachricht von Knoten B. Nachdem Knoten A und B den Datenaustausch
vollzogen haben und Knoten D wieder aktiv ist, hat Knoten C die Möglichkeit eine RTS-
MAC Protokoll
27
Nachricht an Knoten D zu senden. Dennoch gibt es keine Garantie, dass Knoten C diesmal
senden kann. Es besteht lediglich die Option Knoten D zu erreichen. Dieser Ansatz hat
natürlich den Nachteil, dass zusätzliche Kommunikation stattfinden muss und das Protokoll
durch FRTS/DS erweitert werden muss.
Abb. 16: Knoten C sendet ein FRTS zu Knoten D und speichert, wann er wieder aufwachen muss.
Hierbei kollidiert die FRTS mit der DS-Nachricht, welche nur ein Dummy ist.
2.3.3 Zeitsynchronisation
Zeitsynchronisation
Zeit ist ein wichtiger Aspekt für viele Applikationen und Protokolle in drahtlosen
Sensornetzwerken. Isolierte Messwerte sind meistens unbrauchbar, da sich keine Korrelationen
mit anderen Parametern ergeben und wenig Spielraum für notwendige Interpretationen
zulassen. Wann ist ein Ereignis gemessen worden, wie lange dauerte es, oder wie schnell war
das Objekt? Deswegen sollten Messdaten außer den physikalischen Parametern auch Angaben
über die absolute Uhrzeit machen können. Der Bedarf an synchronisierten Netzen wird dadurch
noch erhöht, da Sensorknoten oft auf Kommunikationsprotokollen aufbauen, bei denen die
Knoten simultan zwischen Schlaf- und Wachphasen wechseln müssen, wie das S-MAC oder TMAC aus den vorigen Abschnitten.
Zeitsynchronisation
28
In diesem Abschnitt wird erklärt, weshalb Zeitsynchronisation wichtig ist, wie sie funktioniert
und
welche
Probleme
dabei
aufkommen.
Während
in
der
verkabelten
Welt
Zeitsynchronisationsprotokolle erfolgreich eingesetzt werden, lassen sich diese Lösungen nicht
einfach in drahtlose Sensornetzwerke überführen. Es müssen zusätzliche Lösungen gefunden
werden, die auch eine genaue Zeitsynchronisation in groß angelegten Multihop Netzwerken
zulassen und dabei energieschonende Algorithmen verwenden. Ein einfaches Beispiel (Abb.
17) soll den Bedarf an einer genauen Zeitsteuerung demonstrieren (basierend auf [29]).
Die Wellenfront eines akustischen Signals trifft auf in Reihe installierte Sensorknoten. Jeder
Knoten kennt genau seine geographische Position und speichert die Zeit, wann das Signal
erfasst wurde. Anhand dieser Informationen ist es nun möglich, die Richtung bzw. den Winkel
des Signals zu bestimmen. In Abbildung 17 kann der Winkel α nun aus den Längen d und r mit
Hilfe der trigonomischen Funktionen r=d*sin(α), bzw. α= arcsin(r/d), ermittelt werden. Die
Entfernung d kann anhand der Positionen der Knoten errechnet werden und die Strecke r aus
den gemessenen Zeiten der Sensoren und dem Wissen, dass der Schall c~333m/s zurücklegt.
Angenommen die Strecke d wäre 10 Meter und die Zeitdifferenz (Δt) bei der Erfassung beträgt
0,02 s. Dann ergibt sich r=3,33m aus r=c*Δt und ein Winkel von ~42 Grad, was ungefähr der
Himmelsrichtung NO entspricht.
Abb. 17: Ermittlung der Himmelsrichtung eines akustischen Signals anhand der Ankunftszeiten des
Signals und der geographischen Position der Sensorknoten (basierend auf [29]).
Wenn bei der Messung der einzelnen Zeiten eine Abweichung von 0,004 s vorhanden ist,
verändert sich der Winkel um über 25%. Damit kann ein scheinbar kleiner Fehler in der
Zeitsynchronisation zu einem verzerrten Bild des Ergebnisses führen. Dieses Beispiel
verdeutlicht die Anforderung nach Zeitsynchronisationsverfahren mit einem hohen Maß an
Genauigkeit. Ein Problem dabei ist, dass das Senden und Empfangen nie gleichzeitig
Zeitsynchronisation
29
stattfinden kann, da Faktoren wie die Aufbereitung der Nachricht beim Sender, die Zugriffszeit
auf das Kommunikationsmedium, die Signallaufzeit und die Empfangszeit berücksichtigt
werden müssen. Eine Möglichkeit ist die Berechnung der Round Trip Time (RTT). Sie gibt an,
wie lange ein Signal vom Sender bis zum Empfänger und wieder zurück benötigt. Anhand
dieser Information weiß der Knoten nun, wieviel Zeit er dazu addieren muss, wenn er ein
Synchronisationspaket erhält.
Die Uhren der Knoten basieren, wie Computeruhren, auf Oszillatoren, welche eine konstante
Schwingung in einem bestimmten Frequenzbereich erzeugen. Es kann zu Problemen führen,
wenn die Oszillatoren nicht in konstanten Frequenzen schwingen und so auf Dauer
auseinanderdriften, auch skew genannt [52]. Möglich ist auch, dass die Oszillatoren in der
gleichen Frequenz schwingen, jedoch die Kurven sich nicht synchron überschneiden (Abb. 18).
Es ensteht eine Phasenverschiebung. Abbildung 18 stellt einen Kommunikationsablauf dar,
welcher anhand von drei Nachrichten die Phasenverschiebung zweier Knoten ermittelt, aber nur
unter der Voraussetzung, dass es kein skew und eine konstante Verzögerung D während der
Übertragung gibt. Knoten A liest seine lokale Zeit t1 und sendet dieses Paket zu Knoten B. Als
lokale Zeit t2 speichert Knoten B die Ankunftszeit der Nachricht von Knoten A. Knoten B, zum
Zeitpunkt t3, sendet eine Nachricht zurück zu Knoten A, mit den Angaben t1, t2 und t3. Knoten
A empfängt die Nachricht zum Zeitpunkt t4 und hat nun genug Informationen um die
Phasenverschiebung d zu berechnen: d= (t2-t1-t4+t3)/2. Zum Abschluss sendet Knoten A die
berechnete Phasenverschiebung zu Knoten B.
Abb. 18: Berechnung der Phasenverschiebung (basierend auf [52]).
Die
Herausforderung
besteht
nun
darin,
die
unterschiedlichen
Probleme
des
Auseinanderdriftens, der Phasenverschiebung und der Variabilität von Verspätungen während
der Übertragung mit vorhandenen Lösungsansätzen effektiv in Protokolle zu implementieren.
Da eine ausführliche Beschreibung solcher Implementierungen den Rahmen dieser Arbeit
sprengen würde, ist bei Interesse weiterführende Literatur zu empfehlen [30, 40].
ScatterWeb Plattform
30
ScatterWeb Plattform
3 ScatterWeb Plattform
Die ScatterWeb Plattform beinhaltet alle nötigen Hardwaremodule, wie auch die passende
Software, die zum Aufbau eines drahtlosen Sensornetzwerkes benötigt werden. Die bisherige
und weitere Entwicklung findet an der Freien Universität Berlin im Fachbereich Computer
Systeme und Telematik statt [41]. Da die ScatterWeb Plattform eine Komplettlösung zur
Installation eines drahtlosen Sensornetzwerkes bereitstellt, wurde ein Spin-Off Unternehmen
Anfang 2005 zum kommerziellen Vertrieb gegründet.
Zahlreiche Aspekte der theoretischen Möglichkeiten von drahtlosen Sensornetzwerken wurden
bereits unter Verwendung der ScatterWeb Plattform implementiert und erfolgreich getestet:
- Vergleich von zeitgesteuerten (TDMA) und inhaltbasierten Protokollen [9].
- statisches Routing für eine Multihop-Kommunikation [28].
- eine energieeffiziente MAC-Schicht auf Basis eines TCP/IP Stack [11,12].
- energieeffizientes Routing [39].
- T-MAC und S-MAC in ScatterWeb 3.0 [41].
- Einsatz eines Routingprotokolls, das den Datenverkehr möglichst nur über
Sensorknoten mit Solarzellen routet [46].
- experimentelle Untersuchung der Lebensdauer von drahtlosen Sensornetzwerken
unter Einsatz von Solarzellen und eines GoldCap Kondensators [45].
Die folgenden Abschnitte vertiefen die theoretischen Grundlagen des vorigen Kapitels und
werden mit Hilfe von spezifischen Komponenten der ScatterWeb Hardware und Fragmenten
des Softwarecodes dargestellt. Abschnitt 3.4 spiegelt persönliche Erfahrungen im praktischen
Umgang mit einem drahtlosen Sensornetzwerk auf Basis der ScatterWeb Plattform wieder.
ScatterWeb Hardware
31
ScatterWeb Hardware
3.1 ScatterWeb Hardware
ScatterWeb Hardware
Die ScatterWeb Hardware beinhaltet ein Embedded Sensor Board (ESB), das als Sensorknoten
fungiert, und ein Gateway (eGate/WEB), der den Zugang in das Internet ermöglicht. Zusätzlich
gibt es noch die Module ECR (kleiner Sensorknoten), EYE (Kamera) und EWS (Gateway mit
vielen Schnittstellen), welche Ergänzungen bereitstellen, jedoch nicht essentiell beim Aufbau
eines drahtlosen Sensornetzwerkes sind.
3.1.1 MSP 430
Der MSP 430 (MSP: Mixed Signal Processor) von Texas Instruments ist der Mikrocontroller
und das Herzstück des ESB und des eGate/WEB. Dieser Chip wurde primär unter
Berücksichtigung einer hohen Energieeffizienz konstruiert. Der durchschnittliche Verbrauch
liegt bei 1mA, bei einer Spannung von 3V ([18]. Zum Vergleich: Ein Athlon 1400 MHz
benötigt bei gleicher Spannung etwa 42A, das ist 42000 mal soviel wie der MSP 430. Im
Schlafmodus, welcher durch ein externes Ereignis unterbrochen werden kann, ist der
Energieverbrauch des MSP 430 nochmals 1000 mal geringer. Der Speicher von 64kB setzt sich
aus dem Flash-Speicher, dem RAM, dem Bootloader und dem Speicher für die Peripherie
zusammen. Auf den gesamten Speicher kann mit einem sogenannten Pointer ein direkter
Zugriff erfolgen. 60 der 64kB an Speicher sind für den Flash-Speicher reserviert, um die
Applikationen und permanenten Daten zu speichern.
Ein besonderes Merkmal des MSP 430 ist die Implementierung eines Watch Dog in der
Hardware. Der Watch Dog ist ein Zähler der nach Erreichen eines bestimmten Wertes einen
Reset der Systemsoftware durchführt und somit einen Schutzmechanismus gegenüber
Endlosschleifen und fehlerhaften Codes bildet. Im funktionierenden Betrieb wird der Zähler des
Watch Dog immer wieder reinitialisiert, so dass es nie zu einem Reset im laufenden Betrieb
kommen kann (Abb. 19).
ScatterWeb Hardware
32
Abb. 19: Verarbeitungsablauf des MSP 430 (basierend auf [28]).
3.1.2 ESB
Das Embedded Sensor Board (ESB) vereinigt die notwendigen Komponenten eines
Sensorknotens auf einer Platine mit einer Batteriehalterung der Größe 5x6x2 cm (B/H/T).
Darauf sind unterschiedliche Sensoren angeschlossen: Licht-, Temperatur- und ein
Bewegungssensor sind unter einer weißen Halbkugel versteckt. Der Bewegungssensor kann
Objekte bis auf eine Entfernung von 8 Meter detektieren und zum Beispiel in Verbindung mit
dem Mikrofon, das auch auf dem ESB zu finden ist, als Alarmsystem eingesetzt werden. Ein
weiterer Sensor dient der Registrierung von Vibrationen und basiert auf einem 2-achsigen
Beschleunigungsmesser. Zu einer informativen Weiterverarbeitung der Messdaten ist der
Temperatursensor am besten geeignet, da er der einzige Sensor ist, der einen numerischen Wert
seiner Messung angibt. Die anderen Sensoren senden Impulse nach einer Detektion und geben
somit nur zwei Zustände zur Verarbeitung weiter – aktiv oder inaktiv.
An drahtlosen Kommunikationsschnittstellen stellt das ESB eine Infrarot- und eine
Funkschnittstelle (Transceiver) bereit. Der Transceiver sendet und empfängt im lizenzfreien
Frequenzbereich von 868 MHz und ist für den Datenaustausch zwischen den Sensorknoten und
dem eGate/WEB zuständig. Die serielle Schnittstelle ist zum Anschluss von externen Sensoren
vorgesehen, wie auch zur Datenübertragung an einen PC. Das JTAG-Interface dient zum
Hochladen der Applikationen, die auf dem Sensorknoten betrieben werden sollen.
ScatterWeb Hardware
33
Abb. 20: ESB (Embedded Sensor Board) der Firma ScatterWeb. Quelle: [41].
3.1.3 eGate/WEB
Der eGate/WEB ist der Gateway und verbindet das Sensornetz mit einem anderen Netzwerk,
das den 10/100 BASE-T Ethernet Standard unterstützt. Zu nennen ist hier die Anbindung an das
Internet, oder das lokale Intranet durch Verwendung von einem Router oder einem Switch.
Der eGate/WEB setzt sich aus zwei Bereichen zusammen: Den ersten Bereich bildet ein
Sensorknoten, mit einem Mikrocontroller und einem Transceiver wie der ESB, jedoch ohne
Sensoren. Die eingehenden Daten werden nicht über den Transceiver weitergesendet, sondern
kommen über die serielle Schnittstelle in den zweiten Bereich zum Digi Connect ME Modul.
Dort erfolgt die Transformation der Daten aus dem Sensornetz, dass die eingehenden Daten so
aufbereitet, das sie über das TCP/IP Protokoll in das Internet oder Intranet eingespeist werden
können (Abb. 21).
ScatterWeb Hardware
34
Abb. 21: Datenstrom zwischen dem drahtlosen Sensornetzwerk und dem Internet.
3.2 Inbetriebnahme des ESB und eGate/WEB
Inbetriebnahme des ESB und eGate/WEB
Um das ESB und den eGate/WEB betreiben zu können, müssen die Mikrocontroller mit einer
passenden Applikation ausgestattet werden.
Zur Programmierung des MSP 430 Mikrocontroller wird die Programmiersprache C benutzt.
Sie ist prädestiniert für Mikrocontroller, da sie hochperformant ist und eine hardwarenahe
Programmierung zulässt und damit einen direkten Speicherzugriff ermöglicht. Um den
geschriebenen Quellcode in eine äquivalente, verständliche Maschinensprache umzuwandeln,
wird ein Compiler benötigt. Hierbei wurde der kostenlose C-Compiler mspgcc [38] für die
MSP 430 Mikrocontroller von Texas Instruments benutzt. Damit ein automatisiertes
Kompilieren und Zusammenfügen der Dateien (linken) möglich ist, muss der Compiler wissen,
welche Objektdateien benötigt werden. Diese Information ist in der Makefile enthalten. Nach
der Kompilierung entsteht eine Binärdatei, die auf den Sensorknoten übertragen werden muss.
Dieser Vorgang heißt flashen und wird mit Hilfe des Programms Embedded Workbench
Kickstart [16] von IAR vollzogen. Dabei muss ein Kabel vom Parallellport des PC's an das
JTAG-Interface des Sensorknoten angeschlossen werden. Für die Fehlersuche eignen sich der
im mspgcc enthaltene Kommandozeilendebugger msp430-gdb. Ein Debuggen mit graphischer
Oberfläche ist mit dem Programm Insight möglich, dass auch im Embedded Workbench
Kickstart enthalten ist. Bei beiden Debug-Programmen ist es notwendig, dass vorher ein JTAGProxy als Hintergrundprozess gestartet werden muss.
Software Architektur und Programmierung
35
Software Architektur und Programmierung
3.3 Software Architektur und Programmierung
Software Architektur und Programmierung
Die Software oder das „Mini-Betriebssystem“ für die ScatterWeb Plattform ist modular in zwei
Bereiche aufgeteilt. Die Firmware oder Systemsoftware und die Anwendungssoftware. Dies hat
den
Vorteil,
dass
insbesondere
der
Programmcode
aus
der
Sicherungs-
und
Bitübertragungsschicht vom Code der darauf aufbauenden Anwendung separiert ist, und damit
eine bessere Abstraktion der einzelnen Schichten vorhanden ist. Das Konzept beruht im Ansatz
auf der Architektur der gängigsten Betriebssysteme für PC's. Windows oder Linux bilden den
Grundstock für die darauf aufbauenden Applikationen. Nach der Kompilierung der ScatterWeb
Software wird der gesamte Code jedoch auf einer einzigen Ebene ausgeführt, da keine
Virtualisierungs- oder Zugriffsschutzkonzepte vorhanden sind. Die Firmware initialisiert zu
Beginn sämtliche Hardwaremodule. Dazu gehört der Transceiver und dessen Konfigurationen,
wie die Baudrate und Porteinstellungen. Die Anwendungssoftware nutzt dann die von der
Firmware bereitgestellten Parameter mit Hilfe von Callback Funktionen, die als Schnittstellen
zwischen der Anwendungssoftware und der Firmware agieren (Abb. 22).
Abb. 22: Trennung des Programmcode in die Bereiche Anwendung und Firmware (System). Als
Schnittstelle fungieren Callback-Funktionen.
Die aktuelle Software ScatterWeb v3.0 ist am 12. April 2006 erschienen und beinhaltet eine
Software Architektur und Programmierung
36
Vielzahl an Applikationen (ScatterWeb 2006). MD5, S-MAC und T-MAC sollen als Beispiel
genannt werden. Da die erworbenen Kenntnisse vor dieser Version angeeignet worden sind,
basiert die nähere Erklärung auf den Versionen 2.2. und 2.3 [41].
In den folgenden Abschnitten werden die einzelnen Aufgaben der Objektdateien, der Firmware
und der Anwendungssoftware mit Hilfe von exemplarischen Codefragmenten erläutert.
3.3.1 Firmware
Firmware
Die Firmware regelt zur Beginn u.a. das Starten der Hauptschleife, das Verhalten auf
Interruptereignisse und Routinen für den Zugriff auf die Hardware (Sensoren, Speicher,
Schnittstellen). Die Hauptschleife ist in der Objektdatei ScatterWeb.System programmiert und
ist wie folgt aufgebaut:
Firmware
37
//ScatterWeb.System.c
//Hauptschleife
for(;;) {
//Startet den Watch Dog. Führt bei Bedarf einen Reset des
MSP 430 durch.
System_startWatchdog();
if(runModule & MF_SCOS) Threading_eventHandler();
//Die Funktionen Senden und Empfangen des
Funkmoduls.
if(runModule & MF_RADIO_RX) Net_rxHandler();
if(runModule & MF_RADIO_TX) Net_txHandler();
//Überprüfe abgelaufene Timer.
if(runModule & MF_TIMER) Timers_eventHandler();
//Callback-Funktionen für die serielle Schnittstelle.
if(runModule & MF_SERIAL_RX) {
extern volatile UINT8* serial_line;
if(serial_line != 0) {
if(callbacks[C_SERIAL]) callbacks[C_SERIAL]((void*)
serial_line);
}
}
//Die Funktion für Sensorereignisse. Abhängig von
der Plattform (ESB oder ECR).
#if defined(ESB) || defined(ECR)
if(runModule & MF_SENSORS) if(sensorFlags != 0x00)
Data_sensorHandler();
#endif
...
}
Wie diesem Codefragment zu entnehmen ist, überprüft die Hauptschleife fortlaufend, ob
Sensorereignisse bemerkt wurden, ob Datenpakete am seriellen Port angekommen sind und ob
ausgehende Daten im Buffer gehandhabt werden müssen. Die folgenden Abschnitte beinhalten
Erläuterungen zu relevanten Objektdateien der Firmware.
Firmware
38
3.3.1.1 ScatterWeb.Data
Die Objektdatei ScatterWeb.Data beinhaltet primär Funktionen zur Bearbeitung von
Sensorereignissen. Um Sensorereignisse registrieren zu können, muss eine Callback Funktion
gesetzt werden. Durch System_callbacks[C_SENSOR] wird der Sensor aktiviert und mit
System_callbacks[C_SENSOR]
=
NULL
deaktiviert.
Aktivierte
Sensoren
benötigen
Argumente, die für jeden Sensor spezifisch übergeben werden müssen. Zur Verarbeitung einer
Messung des Temperatursensores werden vier Argumente benötigt:
interval
Wie oft soll eine Temperaturmessung erfolgen.
Data_temperatureON(x,0,0,0) – Alle x ms eine Messung und Signalübergabe.
range
Wieviel muss der Temperaturunterschied betragen, damit die Messung
weitergegeben wird.
Data_temperatureON(x,y,0,0) – Eine Messung alle x ms und eine Weitergabe
der Messung bei einer Differenz von y °C zur vorigen Messung.
diff
In Kombination mit dem zweiten Argument (range), kann ein min./max Bereich
festgelegt werden, wann ein Signal ausgegeben werden soll.
Data_temperatureON(x,y,z,0) – Eine Messung alle x ms und eine Weitergabe
des Signals, wenn die Differenz der Messung im Bereich von y bis z °C liegt.
stepsperdiff
Wenn ein zweites oder drittes Argument übergeben wird, gibt das erste
Argument das Intervall einer Messung an, jedoch nicht die Weitergabe. Eine
kontinuierliche Ausgabe des Signals kann dann über Interval_Dif erfolgen.
Data_temperatureON(x,y,y,z) – Eine Messung alle x ms und eine Weitergabe
der Messung bei einer Differenz von y °C zur vorigen Messung oder alle x*z
(6s*10) Zeiteinheiten.
Dieser Ansatz, die Temperaturmessung anhand von vier Parametern zu beeinflussen, erlaubt
einfache Evaluierungsmethoden, um vorab schon Maßnahmen ergreifen zu können, welche
Ausprägung ein Messwert haben muss. Dies spart Bandbreite und Energie, da viele Messwerte
nicht übertragen werden müssen.
Firmware
39
3.3.1.2 ScatterWeb.Messaging
Die Objektdatei ScatterWeb.Messaging stellt Funktionen zur Verfügung, die eine Interaktion
mit den Sensorknoten möglich macht. Eine Interaktion mit den Sensorknoten kann in Form
einer Konfiguration, wie das Abfragen oder das Setzen der Sendeleistung, stattfinden.
Dreistellige ASCII Kommandos müssen via Funk oder serieller Schnittstelle an den jeweiligen
Sensorknoten gesendet werden. Dazu muss zuerst eine Verbindung mit dem eGate/WEB
(Basisknoten) hergestellt werden. Dafür kann der HyperTerminal von Windows oder das
Programm ScatterViewer von ScatterWeb eingesetzt werden. Diese Programme bieten eine
kommadozeilenbasierte Oberfläche, welche als Kommunikationsschnittstelle zwischen dem
User und dem eGate/WEB arbeitet. Der syntaktische Aufbau eines Befehls ist: @(id) (xxx) [xx]
– Im Feld id wird der Empfänger der Nachricht adressiert, gefolgt von einem Leerzeichen und
dem anschließenden dreistelligen ASCII Kommando. Zum Beispiel der Befehl @4 rsm (read
sensor mask) listet alle aktivierten Sensoren des Knoten mit der ID vier auf. Möchte der User
eine Konfiguration an den Sensoren vornehmen, kann er mit @4 ssm 03 (ssm: set sensor mask)
explizit eine Anweisung geben, welche Sensoren aktiv und welche inaktiv geschaltet werden
sollen. Der letzte Parameter wird als Hexadezimalwert übergeben und gibt an, welche Sensoren
aktiv erfassen sollen. Im genannten Beispiel setzt sich der Wert 03 aus dem Mikrofon 01 und
dem Temperatursensor 02 zusammen.
Firmware
40
Abb. 23: Eingabe-Konsole von ScatterViewer.
3.3.2 Anwendungssoftware
Anwendungssoftware
Die Anwendungssoftware setzt auf die Firmware auf und interagiert, wie in Abschnitt 3.3
schon beschrieben, mit den Callback-Funktionen. Es gibt vier verschiedene CallbackFunktionen:
Periodischer Callback
Diese Callback-Funktion wird in jeder Iteration in der Schleife der
Objektdatei ScatterWeb.Event aufgerufen. ScatterWeb.Event ist Teil
der Anwendungssoftware.
Serieller Callback
Wenn ein kompletter Satz an Daten an der seriellen Schnittstelle
angekommen ist wird der serielle Callback angesteuert.
Funk Callback
Wenn ein Datenpaket über Funk empfangen wird, wird der Funk
Callback aufgerufen und übergibt der Anwendungssoftware einen
Pointer, der den Adressbereich des Datenpaketes referenziert.
Anwendungssoftware
Sensor Callback
41
In periodischen Abständen werden die Messdaten der Sensoren
gelesen. Falls die Sensoren Daten erfassen, wird der Sensor Callback
aufgerufen.
Die Objektdateien der Anwendungssoftware sind speziell für eine Plattform (ESB, ECR oder
Gate/WEB) programmiert worden. D.h., für jede Plattform ist eine modifizierte Objektdatei der
Anwendungssoftware nötig. Hingegen ist die Firmware interoperabel mit allen Plattformen. Um
eine funktionierende Applikation für den Sensorknoten kompilieren zu können, wird die
komplette Firmware benötigt und die passenden Objektdateien Event und Process der
Anwendungssoftware. Diese Zusammensetzung bildet ein funktionierendes Skelett. Den
einzelnen Sensorknoten können nun bestimmte Aufgaben wie Multihop (ScatterRouting),
Verschlüsselung der Datenübertragung (RSA) und energieeffiziente Protokolle (SMAC, TMAC
ab Version 3.0) implementiert werden. Abbildung 24 gibt einen Überblick über die nötigen
Dateien der Firmware und die nötigen und möglichen Dateien der Anwendungssoftware.
Abb. 24: Schematischer Aufbau der ScatterWeb Software v2.3.
Anwendungssoftware
42
3.3.2.1 ScatterWeb.Event
Die Objektdatei ScatterWeb.Event ist Teil der Anwendungssoftware und stellt Methoden zur
Bearbeitung und Weiterleitung von Sensordaten bereit. Sie bietet auch die Möglichkeit einer
simplen Implementierung einer Anwendung. Zum Beispiel, in periodischen Abständen die
LED's der Sensorknoten an- und auszuschalten. Eine Implementierung könnte wie folgt
aussehen:
//ScatterWeb.Event.c
void periodic_function(){
//Der Zähler wird über den seriellen Ausgang ausgegeben.
Comm_print(„%i“, zaehler);
//Wenn der Zähler bis 250 hochgezählt hat, soll er das
grüne Licht anschalten und den Zähler wieder auf null
setzen.
if (zaehler>250){
Data_greenToggle(); //Funktion aus der Firmware
zaehler=0;
}
else {
zaehler++
}
Zugegeben, ein sehr einfaches Beispiel. Dieser Ansatz soll jedoch das Zusammenspiel
zwischen Firmware und Anwendungssoftware praktisch erläutern. Dieser Programmcode kann
als eigenständiges Programm auf die Firmware aufgesetzt werden und sich dabei die
Funktionen der Firmware zu Nutze machen, um indirekt auf die Hardware zugreifen zu können.
Im Beispiel schaltet die Funktion Data_greenToggle(), welche in der Firmware implementiert
ist, eine grüne LED auf der Platine des ESB an und aus.
Die ScatterWeb Plattform im praktischen Einsatz
Die ScatterWeb Plattform im praktischen Einsatz
43
3.4 Die ScatterWeb Plattform im praktischen Einsatz
Die ScatterWeb Plattform im praktischen Einsatz
In diesem Abschnitt wird ein praktischer Versuchsaufbau erläutert, mit dem getestet wurde, ob
die Applikation ScatterRouting die Daten der Sensorknoten via Multihop zum Basisknoten
sendet.
Zu Beginn wurde auf jedem Sensorknoten (ESB) und dem Basisknoten (eGate/WEB) die
Applikation ScatterRouting gespeichert, die die Daten über mehrere Sensorknoten zum
Basisknoten transportiert
(Multihop). Zur Validierung, welcher Sensorknoten Multihop
betreibt oder ob es generell umgesetzt wird, wurden den Sensorknoten zusätzliche
Programmfragmente implementiert. Dabei sollen die LED's der Sensorknoten angesteuert
werden, wenn Multihop umgesetzt wird, oder ein Sensorereignis eintritt. Die rote LED soll
nach der Messung eines Sensorereignisses, hier eine Bewegung, getriggert werden. Die grüne
LED soll angesteuert werden, wenn eine Datenpaket von einem anderen Knoten empfangen
wurde und zur Weiterleitung zum Basisknoten vorgesehen ist.
Nachdem jeder Sensorknoten eine modifizierte ScatterRouting Applikation im Flash-Speicher
des Mikrocontroller gespeichert hat, wurden vier Sensorknoten in einem Gebäude an
unterschiedlichen Plätzen aufgestellt. Die Entfernung von einem Sensorknoten zu einem
Anderen beträgt dabei nie mehr als 20m. Laut Herstellerangaben beträgt die maximale
Reichweite in Gebäuden 100m. Der Basisknoten enthält ebenfalls eine ScatterRouting
Applikation, mit dem Unterschied, dass die Dateien process und event den Belangen eines
Basisknoten angepasst sind und die Programmfragemente zur Steuerung der LED's nicht
enthalten sind. Der Basisknoten wird mit einem Ethernet-Kabel an eine externe
Stromversorgung angeschlossen. Mit einem weiteren Ethernet-Kabel wird das Netzteil mit
einem Router verbunden, der über einen Anschluss an das Internet verfügt.
Nach
dieser
Installation
ist
es
möglich
mit
einem
handelsüblichen
PC
eine
verbindungsorientierte Kommunikation mit dem Basisknoten aufzubauen. Dazu wird das
Programm ScatterViewer benutzt, das anhand der IP des Basisknoten eine Verbindung zum
Basisknoten aufbaut und den Datenaustausch mit dem TCP/IP Protokoll vollzieht. Von diesem
javabasierten Programm kann nun die Konfiguration des Sensornetzes, mittels dreistelligen
ASCII Kommandos, übernommen werden. Dazu gehört zum Beispiel die Aktivierung des
Die ScatterWeb Plattform im praktischen Einsatz
44
benötigten Bewegungssensors. Erfasste Sensorereignisse, werden mit Angabe des Zeitpunktes
der Erfassung zeilenbasiert im ScatterViewer dargestellt.
Nachdem sich die Knoten initialisiert haben und eine Verbindung mit dem Basisknoten oder
anderen Knoten hergestellt wurde, werden die Kommunikationspfade des Netzwerkes
festgelegt, über welche Knoten die Datenpakete weitergeleitet werden. Beim Versuchsaufbau
wurden die Sensorknoten räumlich so platziert, dass sie eine Linie bilden und sich
der
Basisknoten an einem Ende befindet.
Zur Durchführung des Versuches wird eine Bewegung am äußersten Sensorknoten verursacht,
welche durch aufleuchten der roten LED am Sensorknoten bestätigt wird. Wie erwartet, setzt
sich nun eine Kettenreaktion in Gang, bei der die grünen LED's nacheinander getriggert
werden. (Abb. 25). Dies bestätigt, dass die Daten nicht direkt zum Basisknoten gesendet
wurden, sondern mittels Multihop zum Basisknoten geleitet wurden.
Die ScatterWeb Plattform im praktischen Einsatz
45
Abb. 25: Schematischer Aufbau eines drahtlosen Sensornetzwerkes mit Verbindung zu einem PC und
Detektierung einer Bewegung mit anschließendem Versand via Multihop zum Basisknoten (eGate/WEB).
Verarbeitung und Visualisierung von Messdaten aus einem drahtlosen Sensornetzwerk
46
Verarbeitung und Visualisierung von Messdaten aus einem drahtlosen Sensornetzwerk
Teil II:
Verarbeitung und Visualisierung von Messdaten aus einem drahtlosen
Sensornetzwerk
Teil II baut auf den Grundlagen und dem praktischen Verständnis von Teil I auf, und zeigt eine
Möglichkeit zur Verarbeitung und Visualisierung von Daten aus einem drahtlosen
Sensornetzwerk der Firma ScatterWeb. Der Ansatz besteht aus einer Kombination aus
Datenbankmanagementsystem, geographischem Informationssystem (GIS) und dynamischen
Web Technologien (Abb. 26).
Diese Methode, drahtlose Sensornetzwerke an webbasierte, geographische Informationssysteme
(WebGIS) zu koppeln, ist nach eigenen Recherchen, bisher nicht umgesetzt worden oder
zumindest ist keine Internetpräsenz im deutsch- und englischsprachigen Raum verfügbar (Stand
Juni: 2006). Es gibt Projekte, die eine Online-Plattform zur Visualisierung von Messdaten aus
drahtlosen Sensornetzwerken bereitstellen, zum Beispiel in Form einer Tabellenausgabe mit
Angabe der Nummer des Sensorknoten und dessen erfasster Wert [10,37]. Jedoch ist die
Verknüpfung von webbasierten, geographischen Informationssystem und Daten aus drahtlosen
Sensornetzwerken bei keiner dieser Plattformen vorhanden.
Bisherige Lösungsansätze
Auf vorangegangene Arbeiten zur Umsetzung einer solchen Aufgabenstellung konnte somit
nicht zurückgegriffen werden. Was jedoch nicht negativ betrachtet werden sollte, da die
Themen drahtlose Sensornetzwerke und WebGIS als eigenständige Themen behandelt werden
können und nur die Schnittmenge eine neues Gebiet darstellt.
Abb. 26: Verarbeitung und Visualisierung von Messdaten aus einem drahtlosen Sensornetzwerk.
Bisherige Lösungsansätze
47
4 Bisherige Lösungsansätze
Bisherige Lösungsansätze
In diesem Kapitel werden zwei Lösungsansätze zur Visualisierung von drahtlosen
Sensornetzwerken und ihren erfassten Daten aufgezeigt. Beide Ansätze nutzen das Internet als
Visualisierungs- und Kommunikationsplattform.
4.1 COMMON-Sense Net
Das COMMON-Sense Net ist im Centre for Electronics Design and Technology in Bangalore
(CEDT), Indien, installiert [10]. Das Sensornetz besteht aus 10 Sensorknoten (Mica2 motes)
und erfasst vier messbare Werte im Garten des CEDT. Dazu gehören die Temperatur, Bodenund Luftfeuchtigkeit, sowie der Luftdruck. Die gespeicherten Daten werden separat in
Diagrammen dargestellt. Auch eine Ausgabe individueller Diagramme, mit spezifischer
Zeitangabe und Auswahl mehrerer Sensoren, soll in den kommenden Monaten möglich sein.
Des Weiteren werden über eine Schemazeichnung, dynamisch, im Abstand von fünf Minuten,
Vektoren dargestellt, die die aktuellen Übertragungsrouten der erfassten Daten der
Sensorknoten zum Basisknoten repräsentieren (Abb. 27). Dies ist zwar keine hilfreiche
Visualisierungsmethode für naturwissenschaftliche Nutzer die nur an den erfassten Daten
interessiert sind, jedoch bekommt der Informatiker Aufschluss, wie die Datenpakete im Netz
geroutet werden und kann somit auf einen Blick erkennen, ob jeder Knoten eine Verbindung zu
einem Anderen aufweist, oder ob zu viel Datenverkehr über einen Knoten transportiert wird.
Das interessanteste Feature ist jedoch, dass ein autorisierter Nutzer die Möglichkeit hat, eine
Konfiguration des Netzes über einen Internet-Browser vorzunehmen (Abb. 28). Somit kann
diese Person, ohne Installation einer Software, von jedem System mit Zugang zum Internet, auf
das Sensornetz Einfluss nehmen.
Bisherige Lösungsansätze
48
Abb. 27: Verbindungsgraph der Sensorknoten. Quelle: [10].
Abb. 28: In diesem Ausschnitt ist die Einstellung der Sendeleistung der Sensorknoten möglich. Quelle:
[10].
4.2 MoteLab
MoteLab ist an der Harvard Universität, in Cambridge, USA, installiert [37]. Es wurde primär
als Testumgebung für Forscher und Studenten entwickelt, die sich mit drahtlosen
Sensornetzwerken beschäftigen. Dazu wurden 190 Sensorknoten (Mica2 motes) über drei
Etagen in den Räumen des Electrical Engineering and Computer Science (EECS) Gebäude
verteilt. Zur Visualisierung des Sensornetzes wurde der Gebäudeplan genutzt und die Position
der Sensorknoten gekennzeichnet. Vektoren werden hier ebenfalls zur Darstellung von
Verbindungen zwischen Sensorknoten genutzt. Zusätzlich wird die Verbindungsqualität durch
eine Farbcodierung der Vektoren von grün für sehr gut, bis rot für sehr schwach, dargestellt
Bisherige Lösungsansätze
49
(Abb. 29).
Der eigentliche Kern dieser Testumgebung ist die Möglichkeit, selbst programmierte oder
modifizierte Applikationen auf die Sensorknoten über ein Web-Interface hochzuladen, um
verifizieren zu können, dass die Applikation auch in großangelegten Sensornetzwerken so
operiert, wie man es zuvor, lokal mit dem eigenen Sensornetz, mit wenigen Sensorknoten,
getestet hat. Ein großer Vorteil ist, dass der Nutzer nicht direkten Zugang zu den Sensorknoten
haben muss, sondern an einem entfernten Ort seine Applikation programmiert und trotzdem in
dieser großen Umgebung testen kann.
Dies ist möglich, sobald ein Nutzer eine entsprechende Berechtigung hat. Dazu bekommt er
Zugang zu einer separierten Datenbank und kann dort auf seine erfassten Daten direkt
zugreifen. Damit nicht mehrere Nutzer gleichzeitig ihrer Applikationen hochladen können, oder
Nutzer Zugriff auf die Applikationen anderer Nutzer haben, wurde eine Online System
implementiert, dass wie ein Belegungsplan aufgebaut ist. Jeder Nutzer kann sich zu freien
Zeiten, bestimmte Zeitfenster zur Nutzung der Testumgebung reservieren (Abb. 30). Aus der
Perspektive eines Entwicklers ist dies momentan wohl die innovativste Idee, ein drahtloses
Sensornetzwerk, mit anderen Nutzern weltweit, zu teilen [47].
Abb. 29: Grundriss des EECS und Darstellung der installierten Sensorknoten und ihrer
Verbindungsqualität zu anderen Sensorknoten. Quelle: [36].
Bisherige Lösungsansätze
50
Abb. 30: Belegungsplan des MoteLab. Quelle: [47].
SensorGIS
SensorGIS
51
5 SensorGIS
Der Begriff SensorGIS ist im Rahmen dieser Arbeit entstanden. SensorGIS ist die Integration
von drahtlosen Sensornetzwerken in ein webbasiertes, geographisches Informationssystem
(WebGIS). Der Schwerpunkt liegt bei einer adäquaten Aufbereitung und dynamischen
Visualisierung der erfassten Daten und den geographischen Positionen der Sensorknoten. Im
Gegensatz zu den webbasierten Plattformen aus dem vorigen Kapitel, in welchem die
Sensorknoten statisch eingezeichnet sind, bietet SensorGIS einen maximalen Grad an
Individualisierung und Dynamik zur Darstellung der Inhalte, sowie eine echte, automatische
Georeferenzierung.
5.1 Systementwurf und Implementierung
Systementwurf und Implementierung
Über die inhaltlichen Anforderungen hinaus soll das System bestimmte Kriterien erfüllen. Der
Zugriff soll dabei über das Internet erfolgen, wobei Webtechnologien zu einer dynamischen
Darstellung der Inhalte genutzt werden. Die Aufbereitung der erfassten Rohdaten soll in
visuellen Formaten wiedergegeben werden, die von jedem Nutzer einfach verstanden werden
können. Für Sachdaten (Messdaten der Sensorknoten) mit einer geographischen Position
(Sensorknoten) sind Karten prädestiniert. Sie geben dem Nutzer einen schnellen Überblick über
die Situation und detaillierte Informationen können, durch Exploration der Karte, erkannt
werden. Zur Umsetzung der Informationen in eine Karte wurde ein sogenannter Mapserver
verwendet. Der Mapserver bedient sich aus einem Satz an Raster- oder Vektordaten, in diesem
Fall den geographischen Positionen der Sensorknoten und generiert daraus eine Karte, welche
in gängigen Grafikformaten, wie JPG, GIF oder PNG, im Browser ausgegeben wird.
Die erfassten Daten des drahtlosen Sensornetzwerkes werden in einer Datenbank gespeichert,
da sie ein Management von vielen Daten erlaubt und hinsichtlich der Speicherung und Ausgabe
performanter als ein Dateisystem ist [62,67]. Die Positionen der Sensorknoten und die
topographische Basiskarte, die den Bezug zum Georaum herstellt, werden ebenfalls in der
Datenbank gespeichert. Da die im Rahmen dieser Diplomarbeit genutzten Sensorknoten nur in
geschlossenen Räumen eingesetzt werden können, besteht die Basiskarte aus dem Grundriss der
Räume, in denen das Sensornetz installiert ist.
Systementwurf und Implementierung
52
Um dem Anspruch gerecht zu werden, dass SensorGIS ein dynamisches Informationssystem
bereit stellt, soll es möglich sein, dass der Nutzer die Sensorknoten, anhand der geographischen
Orientierung durch die Basiskarte, direkt in das System eintragen und nach Bedarf auch wieder
löschen kann.
Die Implementierung zur Erstellung von thematischen Karten wurde ebenfalls in SensorGIS
realisiert. Der Nutzer hat dabei die Möglichkeit, anhand der gemessenen Temperaturwerte eine
Karte zu generieren, die die Temperaturverteilung in der Umgebung des drahtlosen
Sensornetzwerkes visualisiert.
5.1.1 Übersicht des Gesamtsystems
Übersicht des Gesamtsystems
Die SensorGIS Plattform besteht aus drei Komponenten (Abb. 31). Jede Komponente setzt sich
aus einer Reihe an Applikationen und Prozessen zusammen. Die erste Komponente steuert und
erfasst den eingehenden Datenstrom des drahtlosen Sensornetzwerkes, verarbeitet diesen in ein
standardisiertes Format und trägt die Daten in der zweiten Komponente in eine Datenbank ein.
Die dritte Komponente ist die Anwendung, die die Aufbereitung und Visualisierung der
Geodaten übernimmt.
Übersicht des Gesamtsystems
53
Abb. 31: Schematische Darstellung des Gesamtsystem.
Zur Umsetzung des Entwurfs und der zu erfüllenden Kriterien, ist eine Vielzahl an Programmen
und Bibliotheken notwendig. SensorGIS wurde ausschließlich mit Open Source Produkten
umgesetzt. Als Open Source Software wird solche bezeichnet, die ohne Einschränkungen
genutzt, verändert und kopiert werden darf und der Quellcode dabei frei verfügbar ist [57].
Abbildung 32 basiert auf Abbildung 31 und zeigt, welche Software zur Umsetzung eingesetzt
wurde und veranschaulicht zugleich den Zusammenhang mit dem Gesamtsystem.
Übersicht des Gesamtsystems
Abb. 32: Verwendete Software zur Umsetzung des Gesamtsystem.
Originäre Datenerfassung
54
Originäre Datenerfassung
55
5.1.2 Originäre Datenerfassung
Originäre Datenerfassung
Die Datenerfassung mit der von ScatterWeb entwickelten Plattform Scatterviewer wurde im
Kapitel 3.4 beschrieben. Scatterviewer wurde mit Java programmiert und kann nur lokal auf
einem Rechner ausgeführt werden. Daten, welche Scatterviewer erfasst, werden nicht in einer
Datenbank gespeichert, sondern sind nur in der Konsole verfügbar, solange Scatterviewer als
Applikation gestartet ist. Ferner können die Rohdaten nur mittels Diagrammen graphisch
aufbereitet werden und und es besteht außerdem keine Möglichkeit die erfassten Daten über das
Internet zu publizieren.
Um diese Nachteile zu umgehen wurde ein PHP Programm geschrieben, das serverseitig von
einem Webserver interpretiert und ausgeführt wird. PHP (rekursives Akronym für PHP:
Hypertext Preprocessor) ist eine Skriptsprache und wurde vornehmlich benutzt, da PHP im
weiteren Verlauf auch zur Erstellung der dynamischen Webinhalte und Programmierung
diverser Applikationen verwendet wurde. Außerdem zeichnet sich PHP durch eine breite
Datenbankunterstützung und zahlreich verfügbaren Funktionsbibliotheken aus. Mit PHP ist es
möglich, die erfassten Daten direkt in eine Datenbank zu speichern.
Technische Umsetzung
Zur Erfassung der Daten aus dem drahtlosen Sensornetzwerk muss in PHP ein sogenannter
Socket programmiert werden. Dieser Socket besteht aus einer IP-Adresse zu einer eindeutigen
Lokalisierung des Rechners und einer Port-Nummer zur Adressierung der Schnittstelle. Die
wichtigsten Codefragmente zur Programmierung eines Sockets werden im Folgenden
beschrieben:
Originäre Datenerfassung
56
$address = '212.79.172.183'; //IP-Adresse
$port = 7890; //Port-Nummer
//Nun müssen Funktionen verwendet werden, die anhand dieser Angaben einen
Socket zur Verfügung stellen.
//Ein Socket wird erstellt.
$sock = socket_create (AF_INET, SOCK_STREAM, 0);
//Der Socket wird an die IP-Adresse und den Port gebunden.
$ret = socket_bind ($sock, $address, $port);
//Der Socket wartet auf hereinkommende Verbindungen.
$ret = socket_listen ($sock, 5);
//Der Socket akzeptiert einen Verbindungswunsch.
do {
$msgsock = socket_accept($sock)
//Der Socket liest den hereinkommenden Datenstrom und gibt ihn aus. Eine
Endlosschleife wartet permament auf hereinkommende Daten.
do {
$buf = socket_read ($msgsock, 2048);
echo "$buf\n";
} while (true);
socket_close ($msgsock);
} while (true);
socket_close ($sock);
Damit Daten aus dem drahtlosen Sensornetzwerk gesendet werden können, muss der Gateway
(eGate/WEB) konfiguriert werden. Unter anderem muss eingestellt werden, an welche IPAdresse und Port-Nummer gesendet werden soll. Die Angabe, dass das TCP/IP-Protokoll zur
Übertragung eingesetzt werden soll, ist auch eine wichtige Voraussetzung, damit die
Kommunikation über ein einheitliches Protokoll abläuft. Zusätzliche Einstellungen wie
Übertragungsrate, Parität, Anzahl der Datenbits etc. sind eventuell auch vorzunehmen.
Wenn eine Übertragung möglich ist und die Daten permanent in einer Schleife serverseitig
empfangen werden, sind die meisten Datenpakete in fragmentierter Form vorhanden und
müssen zu einem Datensatz neu zusammengesetzt werden. Eine korrekte Nachricht würde aus
Originäre Datenerfassung
57
der ID, dem Zeitstempel und dessen Wert bestehen. Jedoch müssen zur Datenübertragung die
Nachrichten in kleinere Datenpakete aufgeteilt werden.
In einem Datenpaket ist zum Beispiel der Wert der vorherigen Messung und die ID der
aktuellen Messung vorhanden. Im nächsten Datenpaket folgt die Hälfte des Zeitstempels und im
dritten Paket der Rest mit vielleicht neuen Informationen einer Messung. Damit diese zerlegten
Datenpakete zusammengesetzt werden können, musste ein Algorithmus implementiert werden,
der durch logische Operationen den ursprünglichen Zustand der Nachricht wiederherstellen
kann. Für diesen Zweck muss eine Modifikation der Applikation auf Seiten des Gateways
vorgenommen werden. Wenn ein Sensorereignis versendet werden soll, wird am Anfang und
am Ende jeder Nachricht eine eindeutige Kennzeichnung angefügt. Nachdem die Nachricht
wieder in ihren ursprünglichen Zustand zusammengesetzt wurde, sind die Anfangs- und
Endkennzeichnungen nicht mehr notwendig und können entfernt werden (Abb. 33).
Abb. 33: Zustände von drei Nachrichten die vom Gateway bis zum Server transferiert werden.
Originäre Datenerfassung
58
Der Algorithmus ist so implementiert, dass er zu Beginn alle möglichen Daten des drahtlosen
Sensornetzwerkes ignoriert und darauf wartet, bis ein Anfangskennzeichen empfangen wird.
Wird ein Anfangskennzeichen erfasst, empfängt eine Schleife alle hereinkommenden
Datenpakete und speichert sie temporär ab. Nachdem das Endkennzeichen empfangen wurde,
werden alle Datenpakete vom Anfangs- bis zum Endkennzeichen zusammengesetzt und beide
Kennzeichen entfernt. Anschließend wird die Nachricht durch reguläre Ausdrücke in ihre
Einzelbestandteile ID, Zeitstempel (Datum, Uhrzeit) und Sensorereignis zerlegt und in einer
Datenbank gespeichert. Wie das Datenbankmodell aufgebaut ist, wird in Kapitel 5.1.3.2.2
detailliert erläutert.
5.1.2.1 Aggregation
Aggregation
In diesem Abschnitt soll anhand einer PHP-Implementierung aufgezeigt werden, dass eine
direkte Verbindung zu den theoretischen Grundlagen aus dem ersten Teil hergestellt werden
kann. Im ersten Teil wurde immer auf die Notwendigkeit von energieeffizienten
Implementierungen hingewiesen und Kapitel 3.3.1.1 erklärte mit Hilfe der Objektdatei
ScatterWeb.Data mit der Funktion Data_temperatureON() eine praktische Umsetzung.
Mit dieser Funktion war es möglich, die Temperatur im Abstand von x Zeiteinheiten zu messen,
wobei die Werte nur gesendet werden, wenn die Temperaturdifferenz mehr als y °C beträgt.
Dadurch kann es vorkommen, dass ein Sensorknoten einen Temperaturwert über einen längeren
Zeitraum nicht sendet. Wenn aber eine höhere zeitliche Auflösung und eine Konsistenz in der
Datenbank notwendig ist, um z. B. Werte für genauere Analysen verwenden zu können, ist
diese
Möglichkeit
der
Aggregation
im
Sensornetz
unzulänglich.
Die
Funktion
Data_temperatureON() müsste so konfiguriert werden, dass sie alle x Zeiteinheiten eine
Messung vornimmt und diesen Wert, auch wenn er nicht vom vorigen abweicht, sendet. Dies
wirkt sich nachteilig auf die Energiereserven und die Bandbreite aus.
Durch die Verwendung von PHP kann ein Algorithmus implementiert werden, der es erlaubt,
die Aggregation im drahtlosen Sensornetzwerk beizubehalten und trotzdem die geforderte
zeitliche Auflösung in der Datenbank verfügbar zu machen. Die Temperaturdifferenz in der
Aggregation
59
Funktion Data_temperatureON() wird dabei auf die max. Auflösung des Temperatursensors
eingestellt. Die ESB-Sensorknoten haben eine Auflösung von 0,5°C. In Abständen des
Intervalls ti zur Messung des Temperaturwertes seitens des Sensorknotens wird nun in der
Datenbank geprüft, ob Temperaturmessungen, im Zeitraum des Intervalls ti, von Sensorknoten
empfangen worden sind. Falls dem nicht so ist, kann davon ausgegangen werden, dass keine
Temperaturdifferenz zur vorigen Messung vorhanden ist. Somit wird der letzte Wert der
Messung aus der Datenbank kopiert und in eine neue Zeile mit dem alten Zeitstempel, plus die
Zeit des Intervalls ti, gespeichert (Abb. 34). WebGIS
Abb. 34: Algorithmus zur Erfassung von Temperaturdaten in kontinuierlichen Zeitabständen, wobei
Temperaturmessungen in unkontinuierlichen Zeitabständen aus dem drahtlosen Sensornetzwerk gesendet
werden können.
WebGIS
Dieses Programm wurde als eigenständige Applikation entwickelt, kann jedoch auch in das
PHP-Programm zur Erfassung von Sensorereignissen implementiert werden.
WebGIS
60
5.1.3 WebGIS
WebGIS
Unter einem webbasiertem, geographischen Informationssystem (WebGIS) versteht man die
dynamische und interaktive Visualisierung von geographischen Informationen über das Interoder Intranet, bei der einfache GIS-Funktionalitäten, wie (Zoom, Pan etc.) verfügbar sind [61].
Zur Umsetzung eines WebGIS bedarf es im einfachsten Fall einer Client Server-Architektur, die
eine Anfrage eines Nutzers an einen Webserver sendet und dieser
die Anfrage zum Mapserver weiterleitet. Der Mapserver hat
Zugriff auf einen Satz an Geodaten und generiert ein Rasterbild,
die dann über den Webserver zum Client gesendet wird
(Abb.35). Diese Architektur hat die Bezeichnung eines thin
Clients,
da
jegliche
Interaktion
zu
einer
serverseitigen
Neuberechnung der Karte führt und einen wiederholten
Transport durch das Netz fordert. Thin Clients haben die
geringsten Anforderungen an die Hardware und der Nutzer
benötigt lediglich einen Internet-Browser und kann somit
plattformunabhängig agieren. Im Rahmen der Diplomarbeit
wurde die thin Client Architektur verwendet.
Das Gegenteil zum thin Client ist der thick Client, der direkten
Zugriff auf die Datenbasis hat und die damit zum Teil
Abb. 35: einfache
WebGIS Client Server
Architektur.
rechenaufwändigen Prozesse durch eigenständige Applikationen,
oder in den Browser eingebettete Applets oder Plugins, verarbeiten muss. Ein medium Client
stellt eine Lösung aus der thin- und thick Architektur dar, und wird zum Beispiel beim Einsatz
eines WebGIS in Verbindung mit SVG (Scalable Vector Graphics) eingesetzt [71].
5.1.3.1 UMN Mapserver und Apache Webserver
UMN Mapserver und Apache Webserver
Als Webserver wurde der Apache HTTP Server der Apache Software Foundation genutzt. Er ist
der meistverwendete Webserver im Internet und überzeugt durch eine hohe Geschwindigkeit
und Stabilität, sowie einer breiten Interoperabilität mit anderen Betriebssystemen [70].
UMN Mapserver und Apache Webserver
61
Bei der Wahl des Mapserver fiel die Entscheidung für den UMN (University of Minnesota)
Mapserver. Der UMN Mapserver kann nur in Verbindung mit einem WebServer installiert
werden, da er als CGI-Applikation (CGI: Common Gateway Interface) in der ScriptSchnittstelle des Webservers betrieben wird. In diesem Verzeichnis hat der Mapserver die
Berechtigung vom Nutzer ausgeführt zu werden und hat Zugriff auf die Geodaten.
Der UMN Mapserver ist als eigenständiges Modul in die Umgebung des Apache Webserver
eingekapselt. Startet der Nutzer eine Anfrage an den Webserver findet die Kommunikation über
das HTTP-Protokoll statt und die Generierung von Inhalten, ohne Kartenanfragen, wird nur
über den Webserver geregelt. Besteht eine Kartenanfrage, wird dies über die CGI-Schnittstelle
an den UMN Mapserver weitergeleitet, der daraufhin mit einer Reihe von zusätzlichen
Parametern eine Karte in From eines Rasterbildes generiert. Mit dem HTTP-Protokoll wird
diese Karte via dem Webserver zum Nutzer an seinen Internet-Browser zurückgesendet. [53]
Wie eine solche Kartenfrage aufgebaut ist und mit welchen Angaben der UMN Mapserver eine
Karte generiert, wird in den folgenden Abschnitten erläutert.
5.1.3.1.1 Die MAP-Datei
Die Map-Datei ist eine zu programmierende Datei auf die der UMN Mapserver zurückgreift
und anhand dieser Informationen das Erscheinungsbild der Karte steuert.
Basierend auf den gleichen Geodaten, ist das Design der Karte, hinsichtlich der Darstellung von
Farben und Größen, abhängig von der MAP-Datei. Die MAP-Datei ist hierarchisch aufgebaut.
Jede MAP-Datei definiert eine endliche Zahl an bestimmten Objekten. Diese Objekte
definieren u.a. die Legende, die Maßstabsleiste, die Farben der Kartenelemente, die
hierarchische Struktur der Kartenebenen, die Größe der Karte etc.. Jedes Objekt besteht aus
Schlüsselwörtern, deren Ausprägungen in Form von alphanumerischen Zeichen definiert
werden.
Die zugrundeliegende MAP-Datei zur Visualisierung und Strukturierung der Geodaten aus dem
drahtlosen Sensornetzwerk, die in einer Datenbank gespeichert sind, besteht aus drei
Objektebenen. Jede Ebene stellt nach Hake et al. [59] eine der drei graphischen Grundelemente
UMN Mapserver und Apache Webserver
62
Punkt, Linie und Fläche dar. Die oberste Ebene beinhaltet die Darstellung der Sensorknoten als
Punktsignaturen. Darunterliegend der Grundriss als Liniensignatur zur Visualisierung der
Räumlichkeiten, indem das drahtlose Sensornetzwerk installiert ist. Die 3. und unterste Ebene,
wird als Flächensignatur zur Darstellung der Temperaturverteilung im Raum benutzt. Als
zusammengesetztes Kartenbild geben die einzelnen Ebenen eine komplexe graphische Struktur
wieder (Abb. 36).
Abb. 36: Ebenenhierarchie der MAP-Datei.
UMN Mapserver und Apache Webserver
63
Zur Verdeutlichung dieses Abschnittes sollen anschließend Programmfragmente aus der MAPDatei aufgezeigt werden.
//Grundlegende Definitionen zu Beginn.
MAP
NAME 'sensorgis' //Name der Karte, die der UMN Mapserver generiert.
STATUS ON
PROJECTION //Art der Projektion, die auf die Karte angewandt werden soll.
'init=epsg:31467'
END
SIZE 350 400 //Größe des Ausgabeformats der Karte in Pixel
EXTENT 3260750 5221045 3950844 6131575 //Die Bounding Box zur
Eingrenzung der zu verwendenden Daten. Die Angabe erfolgt duch geographische
Koordinaten.
UNITS meters
//Pfadangaben zu den Shapefiles, Symbolen und Schriften.
SHAPEPATH 'data/'
SYMBOLSET'/var/data/webapps/sensorgis/symbols/symbset.sym'
FONTSET '/var/data/webapps/sensorgis/symbols/fonts.fnt'
IMAGECOLOR 255 255 255
...
//Deklaration des Layers Sensorknoten als Punktsignatur.
LAYER
NAME "Sensorknoten"
TYPE POINT
STATUS ON
//Die Verbindung zur Datenbank und der benötigten Koordinaten der Sensorknoten.
CONNECTIONTYPE postgis
CONNECTION "user=postgres dbname=sensorgis host=212.79.172.184"
DATA "the_geom from tbl_koordinaten using SRID=31467"
CLASS
UMN Mapserver und Apache Webserver
64
//Festlegung des Designs des Sensorknoten.
NAME 'Sensorknoten'
STYLE
SYMBOL "circle" //Sensorknoten wird als Kreis dargestellt.
COLOR 255 0 0 //Rot.
SIZE 12
END #STYLE
END #CLASS
END #LAYER
...
5.1.3.1.2 WMS
Ein Web Map Service (WMS) regelt den Austausch bzw. die Kartenanfrage zwischen dem
Nutzer mit einem Internet-Browser und dem Mapserver, der Zugriff auf die Geodaten hat.
Der WMS ist ein Standard der von dem Open Geospatial Consortium (OGC) [64] festgelegt
wurde. Das OGC ist ein internationaler Zusammenschluss von Vertretern aus dem
gewerblichen, öffentlichen und universitären Bereich, deren Ziel es ist offene, plattform-, netzund programmunabhängige Spezifikationen zu etablieren, welche einen weltweiten Austausch
von raumbezogenen Informationen und Dienstleistungen ermöglichen [64].
Die Intention des WMS ist eine Schnittstelle zu schaffen, die sowohl für den Client als auch für
den Mapserver zur Verfügung stehen soll. Zur Kommunikation zwischen Mapserver und Client
wird das HTTP-Protokoll verwendet und auf Basis des XML-Formats die Daten übertragen
(XML: Extensible Markup Language). Die aktuellste Version ist 1.1.1, welche größtenteils vom
UMN Mapserver seit der Version 3.5 unterstützt wird. Dabei müssen zwei Varianten von
Anfragen beantwortet werden können:
UMN Mapserver und Apache Webserver
getCapabilities
65
Diese Anfrage liefert ein XML-Dokument zurück, das allgemeine
Informationen, sogenannte Metadaten, über den Aufbau und die
darzustellenden Objekte der MAP-Datei beschreibt. Dazu gehören, wie
schon in Kapitel 5.1.3.1.1 angesprochen, der Koordinatenausschnitt
(Boundig Box), das Projektionssystem, die verwendeten Ebenen etc..
getMap
Erfolgt auf die getCapabilities Anfrage eine gültige Antwort, kann mit
dem GetMap Aufruf eine Karte als Rasterbild angefordert werden.
Der Aufbau einer solchen Anfrage richtet sich nach den Richtlinien eines HTTP-Request und
kann als URL in der Browserleiste eingegeben werden. In der URL haben neben den üblichen
HTTP-Restriktionen (keine Leerzeichen, Sonderzeichen etc.) folgende Zeichen eine spezielle
Aufgabe:
?
Kennzeichnung des beginnenden WMS.
&
Separator der einzelnen Parameter des WMS.
=
Wertzuweisung eines Parameter.
Um nun einen OGC-konformen getMap Aufruf an den UMN Mapserver senden zu können,
muss die MAP-Datei den Spezifikationen eines WMS angepasst werden. Dazu gehören u.a.
notwendige Metadaten in bestimmten Sektionen einzelner Objekte. Am Beispiel von
SensorGIS ein WMS-kompatibler URL-Aufruf an den UMN Mapserver:
http://212.79.172.14/cgi-bin/mapserv48
? map=/var/data/webapps/sensorgis/sensorgis.map
& VERSION=1.1.1 //Welche Version des WMS
& REQUEST=GetMap
& SERVICE=WMS
& LAYERS=grundrisshsr,sensorkn
& SRS=EPSG:31467 //Welches Projektionsystem
& BBOX=3260709.772727273,6130960,3261400.227272727,6131580
& WIDTH=490&HEIGHT=440
& FORMAT=image/png
UMN Mapserver und Apache Webserver
66
In einer Zeile und ohne Leerzeichen geschrieben, bewirkt dieser Aufruf, dass der UMN
Mapserver ein georeferenziertes Rasterbild der Sensorknoten und des Grundrisses als PNG
(Portable Network Graphics im Browserfenster zurückgibt (Abb. 37).
Abb. 37: Rasterbild mit Grundriss und Sensorknoten nach einem getMap-Aufruf.
Zu näheren technischen Informationen zu WMS, WMS kompatible MAP-Datei und OGC und
deren weiteren Spezifikationen wird weiterführende Literatur empfohlen [53,55,60,65].
5.1.3.2 PostgreSQL mit PostGIS: Geographische Datenbank
PostgreSQL mit PostGIS: Geographische Datenbank
PostgreSQL ist ein objektrelationales Datenbankmanagementsystem (ORDBMS), dass
ursprünglich an der Universität Berkeley entwickelt wurde. Es wird als das „fortschrittlichste
Open-Source-Datenbanksystem der Welt“ bezeichnet [55,65,66].
PostgreSQL erlaubt die Speicherung von atomaren Daten und berechtigt den Nutzer eigene
Datentypen, Operatoren und Funktionen zu definieren. Aus dieser Möglichkeit heraus wurde
PostGIS entwickelt, das eine räumliche Erweiterung zur Speicherung und Verwaltung von
Geodaten bietet.
PostgreSQL mit PostGIS: Geographische Datenbank
67
Durch die zusätzlichen Datentypen, Operatoren und Funktionen kann PostgreSQL mit PostGIS
als ein zentrales Datenbank-Backend für GIS-Applikationen eingesetzt werden, da Geo- und
Sachdaten gemeinsam verwaltet werden. Die Unterstützung von Analysefunktionen (Buffer(),
Contains(), Intersect() etc.) und der Möglichkeit Metadaten über Geo-Objekte zu verwalten,
gehört ebenfalls zu den Leistungsmerkmalen. Nach OGC (Open Geospatial Consortium) ist
somit ein konformes Geodatenmodell vorhanden, dass den Spezifikationen des Simple Features
Specification for SQL entspricht [64].
5.1.3.2.1 Geodatenmodell in PostGIS
PostGIS ist die räumliche Erweiterung von PostgreSQL und genügt dabei dem Standard eines
OGC-konformen Geodatenmodell (Simple Features Specification for SQL) [64]. Dieser
Standard umfasst drei grundlegende Bedingungen:
Geo-Objekttypen
Die Geo-Objekttypen enthalten Informationen zu den Koordinaten,
zum
Geometrietyp
und
zur
Projektion,
in
welchem
Projektionssystem die Koordinaten gültig sind. Die Geometrie des
Objektes kann durch sieben Varianten festgelegt werden: POINT,
LINESTRING,
POLYGON,
MULTILINESTRING,
MULTIPOINT, MULTIPOLYGON, GEOMETRYCOLLECTION.
Die Geo-Objekttypen können in zwei Formaten dargestellt werden:
Dem WKB (Well-Known-Binary), das als Binärcode vorliegt oder
dem WKT (Well-Kown Text), das durch alphanumerische Zeichen
dargestellt wird. Die Speicherung erfolgt bei beiden Formaten im
Binärcode.
PostgreSQL mit PostGIS: Geographische Datenbank
68
Funktionen zur Analyse Die momentan installierte Version 1.1.1 auf dem SensorGISund Manipulation
Server stellt insgesamt 302 Funktionen und 17 Operatoren zur
von Geo-Objekten
Verfügung. Exemplarisch soll anhand der Funktion EXTENT() die
Bounding Box der Koordinaten der Sensorknoten wiedergegeben
werden:
SELECT
EXTENT
(the_geom)
FROM
tbl_Koordinaten.
Tbl_Koordinaten ist die Tabelle und the_geom ist die Spalte, in
der
die
geographischen
Koordinaten
der
Sensorknoten
abgespeichert sind. Die Ausgabe der Koordinaten sieht wie folgt
aus: BOX3D(3260750 5221045 3950844 6131575).
Metadaten-Tabellen
Die Metadaten-Tabellen geometry_columns und spatial_ref_sys
machen Meta-Angaben über die vorhanden Projektionssysteme
und deren EPSG- Code.
5.1.3.2.2 Sensordatenmodellierung
In diesem Abschnitt soll das zugrundeliegende Datenmodell beschrieben werden, dass bei der
Speicherung der Daten aus dem drahtlosen Sensornetzwerk angewandt wurde.
Um Redundanz in der Datenbank zu vermeiden, ist es nicht sinnvoll alle Informationen der
Sensorknoten in einer Tabelle abzuspeichern, sondern in unterschiedliche Tabellen aufzuteilen.
Die Grundlage hierfür ist die Trennung zwischen den Informationen zu den Sensorknoten und
den Meßdaten. Da die Sensorknoten immer stationär installiert werden, sind die Informationen
zu den Sensorknoten statische Werte. Da durchaus die Aussicht besteht, die Einsatzorte der
Sensorknoten zu variieren, erfolgte nochmals die Trennung in zwei Tabellen. Eine Tabelle
speichert dabei die geographischen Positionen der Sensorknoten und die zweite Tabelle MetaInformationen über die Sensorknoten (Abb. 38). Darin können Angaben über die verfügbaren
Sensoren, den Zeitpunkt der Inbetriebnahme oder sonstige relevante Informationen gespeichert
werden.
PostgreSQL mit PostGIS: Geographische Datenbank
69
Abb. 38: Sensordatenmodell.
Client - Schnittstelle zum Benutzer
Dagegen enthält die Tabelle der Meßwerte dynamische Daten, die jeweils nur für einen
bestimmten Zeitpunkt gelten. Für jeden Sensortyp ist eine Tabelle vorhanden. Jede Tabelle
setzt sich aus der ID, dem Zeitpunkt der Messung und dem Zeitpunkt der Speicherung in der
Datenbank zusammen. Der eigentliche Wert des Sensor wird bei den Temperaturwerten als
Skalar gespeichert, bei den restlichen Sensoren als Boolean, da diese Sensoren, wie schon in
den vorigen Kapiteln angesprochen, nur zwischen zwei Zuständen unterscheiden können.
Abbildung 39 stellt das zugrundeliegende ER-Modell von SensorGIS dar.
Abb. 39: ER-Modell von SensorGIS.
Client - Schnittstelle zum Benutzer
70
5.1.3.3 Client - Schnittstelle zum Benutzer
Client - Schnittstelle zum Benutzer
Aus der Sicht des Endanwenders bietet der Client (Internet-Browser) die einzige Schnittstelle
zu den erfassten Daten. Daraus ergibt sich die Notwendigkeit einen Client zu entwickeln, der
einen einfachen, intuitiven und interaktiven Zugang zum geographischen Informationssystem
SensorGIS bietet.
Die graphische Schnittstelle oder GUI (Graphic User Interface) wurde nach den
Designkriterien von Ben Shneiderman entwickelt [68]. Diese Kriterien wurden nicht speziell
für geographische Informationssysteme aufgestellt, sondern sind vielmehr allgemeingültige
Anforderungen an eine GUI zur visuellen Exploration des Informationsraumes bzw. im Fall
dieser Arbeit, des geographischen Informationsraumes. Aus seinen Forschungsarbeiten ergeben
sich im wesentlichen fünf Direktive die eine graphische Oberfläche erfüllen muss:
Direktive I:
Die Selektion von detaillierten Informationen soll durch den Einsatz von Zoom-Funktionen
erfolgen. In der digitalen Kartographie gehört die Nutzbarkeit solcher Funktionen zu den
Basiswerkzeugen, um einen Interessenbereich der Karte zu vergrößern oder zu verkleinern. In
SensorGIS
wurden
vier
unterschiedliche
Zoomwerkzeuge
implementiert.
Durch
stufengeregeltes Ein- und Auszoomen um den Mittelpunkt der Karte (Abb. 40a/b), durch direkte
Auswahl mittels eines Auswahlrechtecks (Abb. 40c) und einem Button, der den
Ausgangsmaßstab wiederherstellt (Abb. 40d). Ebenso wird ein Werkzeug zur Verfügung
gestellt, dass ein verschieben (pan) des Darstellungsbereiches im gleichen Maßstab erlaubt
(Abb. 40e).
Abb. 40a:
Abb. 40b:
Abb. 40c:
Abb. 40d:
Einzoomen.
Auszoomen.
Auswahlrechteck.
Ausgangsmaßstab.
Abb. 40e: Pan.
Client - Schnittstelle zum Benutzer
71
Direktive II:
Nach Shneiderman ist eine weitere Prämisse, dass während der Interaktion mit der graphischen
Oberfläche der Nutzer einen Überblick über das gesamte System behalten sollte. Bei SensorGIS
wird diese Anforderung durch die Darstellung im Kartenfenster verwirklicht. Zur Umsetzung
wurde eine separate Übersichtskarte implementiert, die dem Nutzer einen Überblick seiner
momentanen Position skizziert, egal in welcher Zoomstufe er sich befindet. Das separate
Kartenfenster befindet sich immer im Ausgangsmaßstab, in dem alle Informationen dargestellt
werden. Beim detaillierten Zoomen in die Karte wird der Kartenausschnitt mit einem Rechteck
dargestellt (Abb.41). Damit behält der Nutzer in jeder Zoomstufe den Überblick und kann
Korrelationen der detaillierten Informationen der Hauptkarte mit der geographischen Position
in der Übersichtskarte wahrnehmen.
Abb. 41: Übersichtskarte mit rotem Rechteck, das den
Darstellungsbereich in der Hauptkarte markiert.
Direktive III:
Wenn ein Nutzer Detailinformationen über ein Objekt bekommen möchte, sollte er über die
Funktionalität Details-on-Demand diese auch bekommen. SensorGIS bietet diese zusätzlichen
Informationen durch Verwendung des Info-Buttons (Abb. 42a) und darauffolgender Auswahl
eines Sensorknotens im Kartenfenster an. Der UMN Mapserver rechnet daraufhin die
Pixelkoordinaten im Kartenfenster in geographische Koordinaten um. Innerhalb eines
Toleranzbereichs wird nun der passende Sensorknoten in der Datenbank selektiert und
detaillierte Informationen, wie Messdaten und Meta-Information (Abb. 42b), in einem PopupFenster angezeigt. Diese Möglichkeit, Informationen durch Auswahl eines Objektes in der
Karte, wird nach OGC als Feature Info Request bezeichnet und gehört auch zu den
Anforderungen eines WMS.
Client - Schnittstelle zum Benutzer
Abb. 42a: Button für die
72
Abb. 42b: Popup-Fenster mit Metadaten zum Sensorknoten mit der ID 1.
Funktionalität Details-onDemand.
Direktive IV:
Eine Filter-Funktion ist nach Shneiderman notwendig, um bestimmte Inhalte des
Informationsraums durch Herausfiltern zu kontrollieren, damit der Nutzer schneller auf seine
Interessen fokussieren kann. Wie in Kapitel 5.1.3.1.1 beschrieben wurde, werden die
notwendigen Informationen zur Erzeugung der einzelnen Ebenen sequentiell aus der Datenbank
entnommen, um daraus ein einheitliches Rasterbild zu generieren.
Es ist es auch möglich dem UMN Mapserver mitzuteilen, dass er zur Erstellung des
Rasterbildes nur bestimmte Ebenen benutzen soll. Dazu beschriftet der Client die Ebenen und
der Nutzer kann durch Auswahl von Häkchen bestimmen, welche Ebenen er angezeigt haben
möchte (Abb. 43).
Abb. 43: Filterfunktion der Ebenen.
Client - Schnittstelle zum Benutzer
73
Direktive V:
Die von Shneiderman formulierte Relate-Funktion soll zur Visualisierung von Korrelationen
zwischen Objekten dienen. In SensorGIS wird versucht, einen gesetzmäßigen Zusammenhang
auf der Grundlage der einzelnen Temperaturmessungen zu finden. Die Umsetzung erfolgt in
Form einer Interpolation der Temperaturwerte und deren geographischer Position im Raum. Als
Ergebnis bekommt der Nutzer ein Rasterbild der Temperaturverteilung im Raum (Abb. 44).
Damit werden die einzelnen Messwerte in einem Gesamtkontext visuell aufbereitet.
Es ist auch möglich, viele Messungen, über einen durch den Nutzer bestimmten Zeitraum zu
aggregieren, um anhand der neuen Daten ein Bild zu interpolieren, das einen Überblick
langzeitlicher Variabilitäten geben kann.
Abb. 44: Rasterbild der Temperaturverteilung in einem Raum durch Interpolation aus vier Messungen.
Nachdem eine Interpolation erfolgte, kann das Rasterbild georeferenziert unter die Ebenen der
Sensorknoten und des Grundrisses eingefügt werden (Abb. 45). Nach Bollmann et al. [54]
ergibt sich durch die topographischen Kartengrundlage der Sensorknoten und des Grundrisses
in Verbindung mit Sachverhalten aus der natürlichen Umwelt eine thematische Karte. Dabei
unterstützt die topographische Kartengrundlage den Bezug zum Georaum und die Verortung
der thematischen Darstellungsschicht der Temperaturenkarte.
Client - Schnittstelle zum Benutzer
74
Abb. 45: Thematische Karte der Temperaturverteilung in einem Raum mit Angabe der minimalen und
maximale Temperatur durch eine Legende.
Die technische Umsetzung der Interpolation wird in Kapitel 5.1.4 beschrieben.
Zur temporalen Exploration der Daten wurde mittels der Programmbibliothek JpGraph für
PHP ein Werkzeug entwickelt, das durch Angabe eines Zeitraums dem Nutzer die Daten in
Form eines Diagramms visualisiert (Abb. 47). Des Weiteren ist in SensorGIS eine JavaApplikation implementiert, die eine Animation aus den Temperaturenkarten erstellt. Dabei wird
in einem Zyklus von einer Stunde automatisch eine Temperaturenkarte generiert. Die JavaApplikation nutzt die letzten 24 Rasterbilder. Daraus ergibt sich eine Animation der
Temperaturveränderung der letzten 24 Stunden.
In einem Intervall von 60 Sekunden werden die sieben aktuellsten Temperaturmessungen der
vorhandenen Sensorknoten angezeigt (Abb. 46).
Client - Schnittstelle zum Benutzer
75
Abb. 46: Darstellung der aktuellen Temperaturmessungen.
Abb. 47: Temperaturdiagramm eines Sensorknotens.
5.1.3.3.1 Mapbender
„Die Mapbender Software ist eine modulare, webbasierte, plattformunabhängige, serverseitig
in PHP implementierte WebGIS Client Suite“ [53].
Der Mapbender wurde benutzt, da er eine komfortable Entwicklungsumgebung bereitstellt, um
daraus, auf Basis der OGC Kompatibilitätsvorschriften, Kartendienste zur erstellen, verwalten
und
konfigurieren zu können. Dazu werden die gängigsten Werkzeuge, wie Zoom, Pan,
Ebenenauswahl etc. zur Verfügung gestellt und können dann vom Entwickler modifiziert,
Client - Schnittstelle zum Benutzer
76
eingebunden oder gelöscht werden (Abb. 48).
Der Mapbender wurde außerdem als zentrale Schnittstelle genutzt, um die einzelnen Elemente
in einem Client zusammenzuführen. Dazu gehören u.a. die fünf Direktive des vorigen
Abschnittes und die Implementierung eines WMS. Das fertige Frontend von SensorGIS ist in
Abbildung 49 dargestellt.
Abb. 58: Graphische Oberfläche des Mapbenders zur Verwaltung der einzusetzenden Werkzeuge in
SensorGIS.
Client - Schnittstelle zum Benutzer
77
Abb. 49: Frontend von SensorGIS. Erstellt mit Mapbender.
5.1.4 Kopplung von GRASS GIS und WebGIS
Kopplung von GRASS GIS und WebGIS
Damit es möglich ist, die Daten in der Datenbank in ein Rasterbild im Dateiformat zu
interpolieren, bedarf es der Hinzunahme eines ausgereiften GIS-Programms. Solch eine
anspruchsvolle Aufgabe verlangt einen intelligenten Algorithmus, der durch den UMN
Mapserver oder die Funktionalitäten von PostGIS nicht erbracht werden kann. Das Credo, dass
zur Umsetzung der ganzen Arbeit Open-Source-Software verwendet wird, musste bei der Wahl
eines passenden GIS-Produktes auch gewährleistet werden. Die Wahl fiel zu Gunsten des
Desktop-GIS GRASS aus. GRASS steht für Geographic Resources Analysis Support System und
ist ein modulares Informationssystem mit raster- und vektororientierten Funktionalitäten. Die
Entwicklug von GRASS GIS begann Anfang der 70er bei den Behörden der USA, die damit ihre
Kopplung von GRASS GIS und WebGIS
78
geographischen Daten speichern und bearbeiten konnten. Aktuell wird GRASS GIS unter der
Schirmherrschaft des ITC (Istituto Trentino di Cultura) in Italien koordiniert, vertrieben und
entwickelt [58].
GRASS GIS wurde ursprünglich für UNIX-Plattformen entwickelt. D.h., Befehle zum
Ausführen von GIS-Funktionalitäten müssen in der GRASS Konsole immer noch zeilenmäßig
eingegeben werden. Daraus ergibt sich das Prinzip der Modularität. Jeder Befehl stellt ein
eigenes Modul dar, das unabhängig von den Anderen nach einem Aufruf abgearbeitet wird.
Eine ausführliche Beschreibung von GRASS GIS und dessen verfügbaren Module bieten
Neteler & Mitsava in ihrem Buch Open Source GIS: A GRASS GIS approach [60].
Da GRASS GIS als Desktop-GIS entwickelt wurde, musste eine Möglichkeit gefunden werden,
die Interpolation über das Internet ausführen zu können. Der Ablauf einer Interpolation ist
hierbei immer der gleiche. Zuerst müssen die geforderten Positionen und Temperaturwerte der
Sensorknoten aus der Datenbank abgefragt werden, um im zweiten Schritt eine Vektorkarte
entwickeln zu können. Danach kann eine Interpolation erfolgen, welche als Ergebnis ein
GRASS eigenes Rasterformat generiert, das im letzten Arbeitsschritt in ein PNG (Portable
Network Graphics) Grafikformat umgewandelt wird. Diesen Ablauf über das Internet zu
automatisieren ist mit der Skriptsprache PHP möglich. Dazu muss serverseitig GRASS GIS
gestartet sein und das PHP-Programm wartet in einer Endlosschleife auf hereinkommende
Anfragen. Wenn ein Nutzer eine Temperaturkarte der aktuell verfügbaren Werte generieren
möchte, selektiert PHP diese Werte und die Positionen der Sensorknoten aus der Datenbank
und speichert sie in einer neuen Tabelle. PHP kann mit der Funktion system() die einzelnen
Module starten, wobei GRASS GIS die Daten aus der soeben gefüllten Tabelle bezieht.
Beispielgebend ist der Aufruf:
system("v.in.db table=tbl_tmp x=x y=y z=z key=sid output=v_tmp1"), der die Anweisung gibt,
die Daten aus der Datenbank zu erfassen und neu zu speichern. Die eigentliche Interpolation
wird durch den Befehl system("v.surf.idw input=v_tmp1 output=r_tm col=z") gestartet. Der
Interpolationsalgorithmus IDSW (Inverse distance weighted average) wurde hierbei genutzt.
Nachdem GRASS GIS die Interpolation abgeschlossen hat, kann der UMN Mapserver mit Hilfe
einer Worldfile, die den Koordinatenbezug mit den anderen Inhalten herstellt (Grundriss,
Sensorknoten), die Temperaturenkarte georeferenziert darstellen. Den Ablauf zur Erstellung
und Wiedergabe einer thematischen Karte stellt Abb. 50 dar.
Kopplung von GRASS GIS und WebGIS
Abb. 50: Schematische Darstellung des internen Ablaufs zur Erstellung einer thematischen Karte.
Ausblick
79
Ausblick
80
6 Ausblick
Ausblick
Mit SensorGIS wurde eine Plattform geschaffen, die es erlaubt Daten aus einem drahtlosen
Sensornetzwerk entgegenzunehmen, zu speichern, aufzubereiten und zu visualisieren. Daraus
ergibt sich ein breites Spektrum an Verbesserung- und Erweiterungsmöglichkeiten, die in
diesem Abschnitt kurz skizziert werden sollen.
Ein nach OGC standardisierten Prozess der Datenerfassung aus einem drahtlosen
Sensornetzwerk wurde nicht realisiert. OGC hat dafür Sensor Web Enablement erarbeitet, eine
Standardisierungsinitiative für einen einfachen, schnellen Austausch und Analyse von
Sensordaten in komplexen Netzwerken. Diese Standardisierung beinhaltet unter anderem die
Bereitstellung eines XML-Schemas mit der Bezeichnung Sensor Model Language (SensorML)
das definiert, wie die geometrischen, dynamischen und beobachteten Charakteristika eines
Sensors übermittelt werden sollen. SensorML ist ein allgemeines Schema, das zur Beschreibung
jeglicher Sensorplattformen, wie Satelliten oder drahtgebundenen Sensornetzwerken, fungieren
soll. Diese Anforderung an ein drahtloses Sensornetzwerk bedeutet, dass es zusätzliche
Rechenleistung und Bandbreite benötigt, um die Daten standardisiert aufzubereiten und durch
das Netzwerk senden zu können. Deshalb wurde darauf verzichtet, den Datenfluss im
drahtlosen Netzwerk auf Basis des SensorML-Schema zu standardisieren. Es wäre jedoch
möglich gewesen das SensorML-Schema beim eGate/WEB zu implementieren, damit die Daten
vor der Speicherung auch anderen Nutzern standardisiert zugänglich gemacht werden. Dies
hätte jedoch bedeutet, ein zusätzliches Programm für den eGate/WEB zu entwickeln und wurde
bisher nicht umgesetzt.
Mit SensorGIS ist es bisher nicht möglich über das Internet mit dem drahtlosen Sensornetzwerk
zu interagieren, um z.B. die Sensorknoten neu zu konfigurieren oder auf Wunsch des Nutzers
eine Messung zu ermöglichen. Eine solche Implementierung wurde mehrmals versucht
umzusetzen, jedoch aufgrund von Schwierigkeiten der Schnittstellenprogrammierung zwischen
dem eGate/WEB und dem SensorGIS-Server zunächst nicht weiter verfolgt.
Die graphische Darstellung der Netzstruktur und die Integration einer Alarm-Funktion, die bei
Überschreitung eines bestimmten Grenzwertes eine E-mail an den Nutzer schickt, sind weitere
Möglichkeiten, um das System zu erweitern.
Ausblick
81
Bei der Darstellung der thematischen Karte sollte GRASS GIS mit einer Verschneidung der
Temperaturenkarte und des Grundrisses, erweitert werden (Abb. 51). Dadurch wäre eine
realitätsnährere Darstellung der Temperaturverteilung im Raum gewährleistet. Auch das
zugrundeliegende Farbspektrum der Temperaturenkarte ist nicht optimal und sollte mit
kognitiveren Farben generiert werden. Das momentane Spektrum basiert auf den Farben des
Regenbogens und erschwert die Assoziation von kalt zu warm (Abb. 51).
Abb. 51: Durch eine Verschneidung der Temperaturkarte mit dem Grundriss würde der schwarz
gekennzeichnete Bereich entfallen. Der schwarze Pfeil stellt einen Gradienten von kalt nach warm dar.
Fazit
Fazit
82
7 Fazit
Fazit
Aktuelle Informationen sind eines der wichtigsten Wirtschaftsgüter des 21. Jahrhunderts und
auf dem Weg zu richtigen Entscheidungen für Politiker und andere Entscheidungsträger
unerlässlich.
Dynamische Phänomene automatisiert zu erfassen und darzustellen, ist das Gebot der Zeit und
mit SensorGIS problemlos möglich. Vor dem Hintergrund der globalen Herausforderungen im
Bereich Klima, Naturkatastrophen, Handel und Verkehr ist SensorGIS eine interessante Option
für einen dynamischen Austausch von physikalischen Informationen aus unserer Umwelt. Auch
wenn die zugrundeliegenden Techniken von SensorGIS vorhanden sind und zuverlässig
funktionieren, erschließt sich das Potenzial noch nicht völlig, solange sich SensorGIS nicht mit
einer realen, thematischen Fragestellung bewähren kann.
Das
Ziel
der
Diplomarbeit
war
die
Referenzimplementierung
eines
webbasierten,
geographischen Informationssystem, dass einen simultanen Datenfluss aus einem drahtlosen
Sensornetzwerk ermöglicht. Durch Implementierung der Plattform SensorGIS wurde solch eine
Anbindung umgesetzt. Zusätzlich verfügt diese Plattform über GIS-Funktionalitäten um eine
visuelle Exploration der Daten zu gestatten. Konzeptionell fußt die visuelle Repräsentation der
geographischen Daten auf Spezifikationen des OGC.
Literaturverzeichnis
83
Literaturverzeichnis
[1] Bill, R. & D. Fritsch (1991): Grundlagen der Geoinformationssysteme, Band 1: Hardware,
Software und Daten. Wichmann, Heidelberg.
[2] Fürst, D., et al. (1996): Umweltinformationssysteme - Problemlösungskapazitäten für den
vorsorgenden Umweltschutz und politische Funktion. Beiträge zur räumlichen Planung 46,
Hannover.
[3] Grünreich, D. (1992): Aufbau von Geo-Informationssystemen im Umweltschutz mit Hilfe
von ATKIS. In: Güpnther, O., Schulz, K.-P., Seggelke, J. (Hrsg.): Umweltanwendungen
geographischer Informationssysteme. Karlsruhe.
[4] Paulsen, H. & Riegger, U. (2006): SensorGIS – Geodaten in Echtzeit. Vsl. GeoBIT Juli
2006, abcverlag, Heidelberg.
[5] Schiller, J. H. (2005): Sensornetze überwachen die Ostsee. Computer Systems &
Telematics, Freie Universität Berlin, http://www.elfenbeinturm.net/archiv/2004b/13.html
am 26.04.2006.
Teil I:
Drahtlose Sensornetzwerke
[6] Abdelzaher, T., et al. (2005): Communication Architecture and Programming Abstractions
for Real-Time Embedded Sensor Networks, erschienen in Handbook of Sensor Networks,
Editiert von Ilyas, M. und Mahgoub, I., CRC Press, Boca Raton, London, New York,
Washington.
[7] Ahmann, P. (2004): Individuelle ortsabhängige RFID-Navigation. Diplomarbeit am
Fachbereich Geowissenschaften, Studiengang Geoinformatik, Westfälischen WilhelmsUniversität Münster, http://ifgi.unimuenster.de/downloads/diplomarbeiten_intern/Ahmann/wieurziwezriwzreiwertwertuewrt.pd
f am 18.04.2006.
Literaturverzeichnis
84
[8] Akyildiz, I.F., et al. (2001): Wireless sensor networks: a survey. Georgia Institute of
Technology, Atlanta, USA, http://www.ece.gatech.edu/research/labs/bwn/sensornets.pdf am
18.04.2006.
[9] Anwander, M., (2005): Comparison of TDMA and contention based MAC protocols on
embedded sensor boards (ESB). Master Thesis an der Universität von Bern, Institut für
Informatik und angewandte Mathematik,
http://www.iam.unibe.ch/~rvs/teaching/seminar/seminar_jun_2005_anwander.pdf am
29.04.2006.
[10] COMMON-Sense Net: COMMON-Sense Net deployment at CEDT (Centre for
Electronics Design and Technology). Indian Institute of Science,
http://www.commonsensenet.in/index.php am 05.05.2006.
[11] Dunkels, A., (2005): Towards TCP/IP for Wireless Sensor Networks. Swedish Institute of
Computer Science, Stockholm, Schweden, http://eprints.sics.se/72/01/dunkels05towards.pdf
am 17.04.2006.
[12] Dunkels, A., (2005): The uIP Embedded TCP/IP Stack. Swedish Institute of Computer
Science, Stockholm, Schweden, http://www.sics.se/~adam/uip/index.html am 29.04.2006.
[13] Dunkels, A., et al. (2004): Connecting Wireless Sensornets with TCP/IP Networks.
Swedish Institute of Computer Science, Stockholm, Schweden,
http://www.sics.se/~adam/wwic2004.pdf am 17.04.2006.
[14] Dunkels, A., et al. (2004): The Design and Implementation of an IP-based
Sensor Network for Intrusion Monitoring. Swedish Institute of Computer Science, Stockholm,
Schweden, http://www.sics.se/~adam/sncnw2004.pdf am 29.04.2006.
[15] Dunkels, A., Alonso, J. und Voigt, T. (2004): Making TCP/IP Viable for Wireless Sensor
Networks. Swedish Institute of Computer Science, Stockholm, Schweden,
http://www.sics.se/~adam/ewsn2004.pdf am 29.04.2006.
Literaturverzeichnis
85
[16] Embedded Workbench Kickstart: Entwicklungsumgebung für den MSP 430 von IAR.
http://focus.ti.com/docs/toolsw/folders/print/msp430toolarchive.html am 30.05.2006.
[17] Feeney, L. M., et al. (2004): An integrated approach to developing sensor network
solutions. Swedish Institute of Computer Science, Stockholm, Schweden,
http://www.sics.se/~lmfeeney/Files/sanpa04_slides.pdf am 17.04.2006.
[18] Hänselmann, T. (2006): Sensornetworks. Institut für Informatik, Universität Mannheim,
http://www.informatik.uni-mannheim.de/~haensel/sn_book/sensor_networks.pdf am
18.04.2006.
[19] Heidemann, J., et al. (2001): An energy-efficient mac protocol for wireless sensor
networks. IEEE Infocom New York, USA.
[20] Hesse, A. (2006): Entwurf und Implementierung einer Testumgebung zur Anbindung von
Sensornetzwerken an IP-basierte Kommunikationssysteme. Diplomarbeit an der Fakultät für
Elektrotechnik und Informationstechnik, Technische Universität Ilmenau, http://zack1.etechnik.tu-ilmenau.de/~webkn/STUD-DIPLOM/DIPLOMREFERAT/aufgabenstellungsonsornetzwerke.pdf am 17.04.2006.
[21] IEEE Computer Society (2003): Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (LR-WPAN's),
erschienen in IEEE Standard for Information technology – Telecommuncations and
Information Exchange between systems – Local and Metropolitan area networks,
http://standards.ieee.org/catalog/olis/lanman.html am 22.06.2006.
[22] Intanagonwiwat, C., et al. (2000): Directed Diffusion for Wireless Sensor Networking.
Computer Science Department, University of Southern California, Los Angeles, USA,
http://www.isi.edu/~johnh/PAPERS/Intanagonwiwat02b.pdf am 25.04.2006.
[23] Internet 1: Smart Dust von der Universität Berkeley, USA, http://www.nanotech-now.com
am 06.05.2006.
Literaturverzeichnis
86
[24] Internet 2: BTnode von der Universität Zürich, Schweiz, http://www.btnode.ethz.ch am
06.05.2006.
[25] Internet 3: Embedded Sensor Board der Firma Scatterweb, Berlin,
http://www.scatterweb.net am 06.05.2006..
[26] Internet 4: SensorWebs, USA, http://sensorwebs.jpl.nasa.gov am 08.05.2006.
[27] Internet 5: Great Duck Island, USA, http://www.greatduckisland.net am 08.05.2006.
[28] Jerschow, Y. I. (2005): Routing- und Protokollierungsdienste für Kleinstrechner.
Lehrstuhl für Rechnernetze, Heinrich-Heine-Universität Düsseldorf, http://www.cn.uniduesseldorf.de/publications/library/Jerschow2005a.pdf am 17.04.2006.
[29] Karl, H. & Willig, A. (2005): Protocols and Architectures for Wireless Sensor Networks.
John Wiley & Sons Ltd., West Sussex.
[30] Kumar, R., Ganeriwal, S. und Srivastava, M. B. (2003): Timing-sync protocol for sensor
networks. Proceedings of the 1st international Conference on Embedded networked Sensor
Systems, Los Angeles, USA,
http://www.ee.ucla.edu/~saurabh/publications/Sensyspaper03.PDF am 25.06.2006.
[31] Manges, W. (2000): Wireless Sensor Network Topologies. Sensors,
http://www.sensorsmag.com/articles/0500/72/main.shtml am 16.04.2006.
[32] Mattern, P. (2001): Smart Dust. Fachseminar „Mobile Computing“, ETH Zürich,
http://www.vs.inf.ethz.ch/edu/SS2001/MC/beitraege/11-smartdust-rep.pdf am 18.04.2006.
[33] Mattern, F. & Römer K. (2003): Drahtlose Sensornetze. Institut für Pervasive Computing,
ETH Zürich, http://www.gi-ev.de/service/informatiklexikon/informatiklexikondetailansicht/meldung/35/ am 26.04.2006.
Literaturverzeichnis
87
[34] Mirza, D., Owrang, M. und Schurgers, C. (2005): Energy-efficient Wakeup Scheduling for
Maximizing Lifetime of IEEE 802.15.4 Networks. Proceedings of the 1st international
Conference on Wireless Internet (WICON'05),
http://fleece.ucsd.edu/~curts/papers/WICON05.pdf am 22.06.2006.
[35] MoteLab1: Tabelle der eingesetzten Sensorknoten. Harvard Network Sensor Testbed,
Harvard University, USA, http://motelab.eecs.harvard.edu/motes-status.php am 04.05.2006.
[36] MoteLab2: Karte mit Senorknoten. Harvard Network Sensor Testbed, Harvard University,
USA, http://motelab.eecs.harvard.edu/motes-info.php am 04.05.2006.
[37] MoteLab3: Harvard Network Sensor Testbed. Harvard University, USA,
http://motelab.eecs.harvard.edu/index.php am 04.05.2006.
[38] mspgcc: C-Compiler für den MSP 430 Mikrocontroller. http://mspgcc.sourceforge.net/ am
30.05.2006.
[39] Ritter, H., et al. (2005): ScatterWeb - Low Power Sensor Nodes and Energy Aware
Routing. Proceedings of the 38th Annual Hawaii International Conference on System
Sciences (HICSS'05), Hawaii, USA,
http://csdl2.computer.org/comp/proceedings/hicss/2005/2268/09/22680286c.pdf am
29.04.2006.
[40] Römer, K., et al. (2005): Time Synchronization and Calibration in Wireless Sensor
Networks. Research Group For Distributed Systems, ETH Zürich, Schweiz,
http://www.vs.inf.ethz.ch/publ/papers/wsn-time-book.pdf am 25.06.2006.
[41] ScatterWeb: ScatterWeb Software für drahtlose Sensornetzwerke. http://www.inf.fuberlin.de/inst/ag-tech/scatterweb_net/software/index.html am 01.04.2006.
[42] SensorWebs: Karte mit Sensorknoten. NASA/JPL Sensor Webs Project, Huntington
Botanical Gardens, http://sensorwebs.jpl.nasa.gov/resources/images/map_hunt_5_lo.jpg am
04.05.2006.
Literaturverzeichnis
88
[43] Su, W., Cayirci, E. und Akan, Ö. B. (2005): Overview of Communication Protocols for
Sensor Networks, erschienen in Handbook of Sensor Networks, Editiert von Ilyas, M. und
Mahgoub, I., CRC Press, Boca Raton, London, New York, Washington.
[44] Van Dam, T. & Langendeon, K. (2003): An adaptive energy-efficient Mac Protocol for
Wireless Sensor Networks. Proceedings of the 1st international Conference on Embedded
networked Sensor Systems, Los Angeles, USA.
[45] Voigt, T., et al. (2005): Experimental Evaluation of Lifetime Bounds for Wireless Sensor
Networks. Swedish Institute of Computer Science, Stockholm, Schweden,
http://www.sics.se/~thiemo/ewsn2005.pdf am 29.04.2006.
[46] Voigt, T., et al (2003): Solar-aware Routing in Wireless Sensor Networks. 9th International
IEEE Symposium on Computers and Communications (ISCC), Alexandria, Griechenland,
http://www.sics.se/~thiemo/PWC2003.pdf am 29.04.2006.
[47] Welsh, M., Swieskowski, P. und Werner-Allen, G. (2005): MoteLab: A wireless Sensor
Network Testbed. Division of Engineering and Applied Sciences, Harvard University, USA,
http://www.eecs.harvard.edu/~mdw/papers/motelab-spots05.pdf am 05.05.2006.
[48] Wermke, M. (2005): Entwicklung eines kostengünstigen Sensornetzwerkes für Monitoring
Aufgaben. Diplomarbeit am Studiendepartment Informatik an der Hochschule für
Angewandte Wissenschaften Hamburg, http://users.informatik.hawhamburg.de/~ubicomp/arbeiten/diplom/wermke.pdf am 16.04.2006.
[49] Wikipedia: Mikrocontroller. http://de.wikipedia.org/wiki/Mikrocontroller am 15.04.2006.
[50] Wikipedia: OSI-Modell. http://de.wikipedia.org/wiki/Osi-modell am 17.04.2006.
[51] Wikipedia: Sensornetz. http://de.wikipedia.org/wiki/Sensornetz am 26.04.2006.
[52] Zhao, F. & Guibas, L. (2004): Wireless sensor networks: an information processing
approach,
Elsevier-Morgan Kaufmann, Boston.
Literaturverzeichnis
89
Teil 2:
Verarbeitung und Visualisierung von Messdaten aus drahtlosen Sensornetzwerken
[53] Adams, T., et al: Praxishandbuch WebGIS mit freier Software, UMN Mapserver,
PostgreSQL/PostGIS, Avein, Mapbender. Gemeinschaftsprojekt von CCGIS und terrestris,
http://www.mygeo.info/skripte/Praxishandbuch_WebGIS_Freie_Software.pdf am
12.05.2006.
[54] Bollmann, Jürgen und Wolf Günter Koch (Hrsg.) (2001/02): Lexikon der Kartographie
und Geomatik. 1/2 Bd., Spektrum Akademischer Verlag, Heidelberg, Berlin.
[55] Eisentraut, P. (2005): PostgreSQL – Das fortschrittlichste Open-Source Datenbanksystem.
http://developer.postgresql.org/~petere/marketing/flyers/pgflyer_v05.pdf am 31.05.2006.
[56] Fischer, T. (2003): UMN Mapserver, Handbuch und Referenz. MapMedia GmbH, Berlin.
[57] Grassmuck, V. (2004): Freie Software - Zwischen Privat- und Gemeineigentum.
Bundeszentrale für politische Bildung, Bonn.
[58] GRASS GIS: Offizielle Seite von GRASS GIS. http://grass.itc.it/ am 31.05.2006.
[59] Hake, G., et al. (2002): Kartographie, Visualisierung raum-zeitlicher Informationen. De
Gruyter, Berlin.
[60] Kropla, B. (2005): Beginning MapServer, Open Source GIS Development. Apress, New
York.
[61] Mitchell, T. (2005): Web Mapping Illustrated. O'Reilly Media, USA.
[62] Momjian, B. (2001): PostgreSQL: Einführung und Konzepte. Addison-Wesley, München.
[63] Netler, M. & Mitasova, H., (2004): Open Source GIS: A GRASS GIS Approach. Springer
Verlag, New York.
Literaturverzeichnis
90
[64] Open Geospatial Consortium (OGC): http://www.opengeospatial.org/ am 15.05.2006.
[65] PostgreSQL: http://postgres.de/ am 16.05.2006.
[66] Plank Clemens: Open Source-Software in der Medizin-IT. Seminar Medizin-Telematik,
WS 2005/06, Universität Tübingen, http://net.informatik.unituebingen.de/fileadmin/RI/teaching/seminar_medizin/ws0506/vortraege/plank.pdf am
31.05.2006
[67] Ramakrishnan, R & Gehrke, J. (2003): Database Management Systems, Third Edition.
McGraw-Hill Companies, New York.
[68] Shneiderman, B. (1996): The Eyes Have It: A Task by Data Type Taxonomy for
Information Visualizations. Department of Computer Science, Human-Computer Interaction
Laboratory and Institute for Systems Research, University of Maryland, USA,
http://www.sims.berkeley.edu:8000/courses/is247/f05/readings/Shneiderman_EyesHaveIt_
VL96.pdf am 17.05.2006.
[69] Shneiderman, B. & Kules, B. (2003): Designing a Metadata-Driven Visual Information
Browser for Federal Statistics. Department of Computer Science, Human-Computer
Interaction Laboratory and Institute for Systems Research, University of Maryland, USA,
http://www.digitalgovernment.org/dgrc/dgo2003/cdrom/PAPERS/metadata/kules_shneider
man.pdf am 17.05.2006.
[70] Wikipedia: Apache Webserver. http://de.wikipedia.org/wiki//Apache_%28Webserver%29
am 12.05.2006.
[71] Woltering, J. (2005): Interaktive Karten auf Basis Geographischer Informationssysteme.
Diplomarbeit für den Studiengang Wirtschaftsinformatik an der Universität Paderborn,,
www.carto.net/papers/jan_woltering/jan_woltering_interakt_html_karten_20050806.pdf am
12.05.2006.