Diplomarbeit ” Konzeption und Evaluierung eines energieeffizienten

Diplomarbeit
Konzeption und Evaluierung eines
”
energieeffizienten
Sensornetzwerks anhand realer
Sensorknoten“
Universität Karlsruhe (TH)
Fakultät für Informatik
Institut für Technische Informatik (ITEC)
Lehrstuhl für Eingebettete Systeme (CES)
Prof. Dr. Jörg Henkel
Autor: Sebastian Kobbe
Referent: Prof. Dr. Jörg Henkel
Betreuer: Dipl.-Technoinf. Dominic Hillenbrand, Dipl.-Inform. Thomas Ebi
15.04.2008 - 14.10.2008
Chair for Embedded Systems
Ich versichere hiermit wahrheitsgemäß die Arbeit, bis auf die dem Aufgabensteller bereits bekannte Hilfe, selbständig angefertigt, alle benutzten Hilfsmittel vollständig und
genau angegeben und alles kenntlich gemacht zu haben, was aus Arbeiten anderer unverändert oder mit Abänderung entnommen wurde.
Karlsruhe,
. . . . . . . . . . . 14.10.2008
..........................................................................
Ort, Datum
(Sebastian Kobbe)
Danksagung
An dieser Stelle möchte ich mich bei allen Personen bedanken, die mich bei der Erstellung dieser Arbeit direkt oder indirekt unterstützt haben.
Mein Dank gilt hierbei Prof. Dr. Jörg Henkel für die Bereitstellung des spannenden
und herausfordernden Themas dieser Diplomarbeit.
Großer Dank gilt Herrn Frank Krause der ehemaligen Betty TV AG für die Bereitstellung der in dieser Arbeit verwendeten Hardwareplattform sowie meinem Betreuer, Dipl.-Technoinf. Dominic Hillenbrand, der mit viel Engagement und hilfreichen
Ratschlägen meine Diplomarbeit betreut hat.
Für die Unterstützung in der letzten Phase dieser Arbeit möchte ich mich besonders
bedanken bei meiner Freundin Monika, meiner Schwester Daniela, meinen Eltern sowie
Heiko Reese und Dipl.- Inform. Thomas Ebi.
I
II
Inhaltsverzeichnis
Danksagung
I
1 Einleitung und Motivation
1.1 Sensorknoten und Sensornetze . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Vorgehensweise beim Entwurf . . . . . . . . . . . . . . . . . . .
1.2.2 Gründe und Probleme dieser Vorgehensweise . . . . . . . . . . .
1.2.3 Ansätze zur Verbesserung der Situation . . . . . . . . . . . . . .
1.3 Zielsetzung dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Stichwortartige Auflistung der Fähigkeiten und Funktionen des
entworfenen Systems . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Ähnliche Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Aufbau dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
2
2
4
4
5
2 Systemvision und Einsatzmöglichkeiten
2.1 Systemvision . . . . . . . . . . . . . .
2.2 Einsatzmöglichkeiten . . . . . . . . .
2.2.1 Datensammlung . . . . . . . .
2.2.2 Bildübertragung . . . . . . . .
2.2.3 Positionsbestimmung . . . . .
5
6
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
11
12
3 Analyse und Anforderungsspezifikation
3.1 Funktionale Anforderungen . . . . . . . .
3.2 Nicht-funktionale Anforderungen . . . . .
3.3 Gegebenheiten . . . . . . . . . . . . . . . .
3.3.1 Hardwareplattform . . . . . . . . .
3.3.2 Messung der Leistungsaufnahme . .
3.3.3 Messung der Abstrahlcharakteristik
3.3.4 Software . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
16
17
20
22
28
28
.
.
.
.
31
31
31
34
35
4 Systementwurf
4.1 Softwarearchitektur . . . . . . . . .
4.1.1 Architektur der Firmware .
4.1.2 Aufteilung des Speichers . .
4.1.3 Architektur der Anwendung
III
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.2
4.3
Software Deployment . . . . . . . . . . . . . . . . . . .
4.2.1 Übertragung über die serielle Schnittstelle . . .
4.2.2 Übertragung per Funk . . . . . . . . . . . . . .
4.2.3 Bindeglied Firmware / Anwendung . . . . . . .
Netzwerkarchitektur und Protokolle . . . . . . . . . . .
4.3.1 Grundlegende Datenübertragung . . . . . . . .
4.3.2 Protokoll der kabellosen Softwareaktuallisierung
4.3.3 Nachbarschaftsbeziehung . . . . . . . . . . . . .
4.3.4 Signalisierung und Routenmanagement . . . . .
4.3.5 Netzweite Datenübertragung . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Implementierung und Testumgebung
5.1 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2 Ansteuerung des Funkchips . . . . . . . . . . . . . . . .
5.1.3 Automatische Codeerzeugung für Anwendungsaustausch
5.1.4 Software-Update Protokoll . . . . . . . . . . . . . . . . .
5.1.5 Routenauswahl und -bewertung . . . . . . . . . . . . . .
5.1.6 Nachrichtenbündelung . . . . . . . . . . . . . . . . . . .
5.2 Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Behandlung von Fehlern auf dem Datenpfad . . . . . . .
5.2.2 Zeitsynchronisierung . . . . . . . . . . . . . . . . . . . .
5.2.3 Übertragungseffizienz und Belastbarkeit . . . . . . . . .
5.2.4 Positionsbestimmung . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
44
44
44
47
47
49
54
55
62
.
.
.
.
.
.
.
.
.
.
.
.
69
69
69
75
76
81
84
88
93
95
95
98
101
6 Zusammenfassung und Ausblick
103
6.1 Erreichtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
IV
1 Einleitung und Motivation
Durch den Fortschritt der Technik ist es heutzutage möglich, leistungsfähige und preiswerte Mikrocomputer zu produzieren. Werden diese mit Sensoren versehen und mit
einer Kommunikationsschnittstelle ausgestattet, so spricht man von Sensorknoten“.
”
Mehrere solcher Sensorknoten bilden – sofern sie untereinander vernetzt werden – ein
Sensornetz“.
”
Werden Sensorknoten in andere – nicht unbedingt rechenorientierte – Objekte integriert, so spricht man von eingebetteten Systemen“ 1 . Als Beispiel hierfür sei ein in eine
”
Kaffeetasse integrierter Sensorknoten genannt, welcher unter anderem die Temperatur
des Inhalts der Tasse messen und diese anderen Geräten über eine Infrarotverbindung
mitteilen kann[1].
Schwerpunkt dieser Arbeit ist der Entwurf einer neuen Sensorknoten-Plattform aufgrund einer gegeben Hardware-Plattform sowie die Kommunikation zwischen den einzelnen Knoten und der Aufbau einer selbstorganisierten, energieeffizienten Vernetzung.
1.1 Sensorknoten und Sensornetze
Es folgt eine kurze Einführung in das Thema Sensorknoten und -netze. Für eine tiefer
gehende Vorstellung des Themas und eine Analyse der typischen Probleme, welche
beim Entwurf und Einsatz auftreten, sei beispielsweise auf das Buch Wireless Sensor
”
Networks“[2] verwiesen.
1.1.1 Eigenschaften von Sensorknoten
Ein klassischer Sensorknoten ist ein mit begrenzten Ressourcen ausgestattetes System.
Eine besondere Eigenschaft eines Sensorknotens ist es, dass er sowohl über Sensoren
Daten erfassen kann, als auch in einem Netzwerk mit anderen Sensorknoten in Verbindung steht. Er verfügt über eine endliche Energieversorgung, geringe Rechenleistung
und beschränkte Speicherkapazität. Die Kommunikation erfolgt typischerweise kabellos. Die Herausforderung beim Entwurf eines solchen Sensorknotens liegt darin, die zur
1
Nicht jeder Sensorknoten stellt ein eingebettetes System dar, ebenfalls muss nicht jedes eingebettete
System ein Sensorknoten sein.
1
Kapitel 1. Einleitung und Motivation
Verfügung stehenden Ressourcen optimal zu nutzen, so dass sich unter Berücksichtigung
der zu erfüllenden Aufgabe eine möglichst lange Laufzeit des Knotens ergibt.
1.1.2 Eigenschaften von Sensornetzen
Ein Sensornetzwerk besteht aus einer (größeren) Anzahl einzelner Sensorknoten. Diese Knoten sind über ein Netzwerk miteinander verbunden und ermöglichen es so –
obwohl jeder einzelne Knoten an sich nicht mächtig ist – komplexe und räumlich verteilte Aufgaben zu lösen. Zu den wichtigsten Eigenschaften, welche beim Entwurf eines
Sensornetzwerkes berücksichtigt werden müssen, zählt die Energieeffizienz der Kommunikation sowie eine geschickte Aufteilung der Systemlast auf alle beteiligten Knoten, um
so eine insgesamt möglichst optimale Leistung und Laufzeit des Systems zu erreichen.
1.2 Ausgangssituation
Die Beschreibung der Ausgangssituation soll zeigen, wie ein solches Sensornetz entworfen wird und welche Probleme hierbei auftreten können. Diese möglichen Probleme
wiederum dienen als Motivation für die Zielsetzung und Vorgehensweise dieser Arbeit.
1.2.1 Vorgehensweise beim Entwurf
Oftmals wird ein Sensornetzwerk nur in einer hohen Abstraktionsebene entworfen. Es
wird ein Modell der einzelnen Knoten, des Kommunikationsmediums sowie des gesamten Netzes angefertigt und diese Modelle werden dann entweder getrennt oder zeitgleich
simuliert. Viele Arbeiten beschränken sich ausschließlich auf die Simulation von Protokollen und Sensornetzen. Teilweise werden Ergebnisse veröffentlicht, von denen nicht
bekannt ist, ob diese in der Realität ebenfalls zutreffen. Abbildung 1.1 zeigt die Schritte
eines solchen Entwurfs.
1.2.2 Gründe und Probleme dieser Vorgehensweise
Einer der Gründe für diese Vorgehensweise beim Entwurf ist der Aufwand, welcher mit
der Fertigung, Programmierung und Platzierung von mehreren Hundert Sensorknoten
verbunden ist. Ebenfalls können die unter Umständen nicht unerheblichen Kosten2 für
die benötigte Anzahl an Sensorknoten eingespart werden. Eine einfache Simulation ohne
Berücksichtigung von spezifischen Eigenschaften der Zielhardware und Modellierung
der Umgebung ist daher in der Regel schneller und einfacher, als eine reale Umsetzung.
2
Ein MICA2[3]-Knoten kostet beispielsweise über 100e
2
1.2. Ausgangssituation
a) Messung und Modellparametrisierung
realer Knoten
b) Simulation
simulierter Knoten
?
c) Realität?
reale Umgebung
Abbildung 1.1: Üblicher Entwurf eines Sensornetzes. a) Ein Modell der Knoten und der
Umwelt wird angefertigt. Aufgrund von Messungen mit einigen Knoten
wird dieses Modell parametrisiert. b) Aufgrund dieses Modells wird ein
großes Sensornetz entworfen und simuliert. c) Nicht bekannt ist, ob das
so entworfene Netz auch in der Realität funktioniert.
Problematisch ist hierbei jedoch die Modellierung und Simulation der Funkschnittstelle,
welche stark von der jeweiligen Umgebung abhängig ist. Ein einmal angefertigtes und
parametrisiertes Modell trifft nur auf genau die Umgebung und den Zeitpunkt zu,
in der bzw. an dem das Modell angefertigt wurde. Objekte in der Umgebung, deren
Materialeigenschaften und sogar Wettereinflüsse können die Resultate stark verändern.
Insbesondere bei kabellosen Netzen ist es somit zwar möglich, ein in der Theorie gut
funktionierendes System zu entwerfen, nicht bekannt ist jedoch, ob dieses dann in
einer realen Implementierung mit sich laufend ändernden Eigenschaften der Umgebung
ebenfalls noch zufriedenstellend seine Aufgabe erfüllen kann – bekannt ist nur, dass das
Netz unter den zu einem bestimmten Zeitpunkt gemessenen Parametern und unter der
Annahme eines bestimmten Modells funktioniert.
Dies liegt in der Natur der drahtlosen Kommunikation begründet. Zwar sind die theoretischen und mathematischen Modelle zur Simulation der Ausbreitung von Funkwellen
und deren Wechselwirkung mit der Umgebung bekannt, es ist jedoch nahezu unmöglich,
ein exaktes Modell der sich ggf. ständig ändernden Umgebung abzubilden. Der Aufwand, ein solches Modell zu erstellen ist in etwa vergleichbar mit einer realen Implementierung und anschließender Evaluierung in der Zielumgebung.
Es lassen sich hierbei in einem gewissen Rahmen Parallelen zum sog. Raytracing aus
dem Bereich der Computergraphik ziehen. Hierbei müssen die von einer Kamera3 aufgenommenen Lichtstrahlen4 einzeln rückverfolgt und ggf. reflektiert, gestreut und absorbiert werden. Es lassen sich mit dieser Vorgehensweise fotorealistische Graphiken
erzeugen, sofern genügend Rechenzeit zur Verfügung gestellt wird.
3
4
Die Kamera entspricht dem Empfänger
Funkwellen niedriger Frequenz verhalten sich zwar nicht exakt wie Lichtstrahlen, mathematische
Modelle zur Berechnung der Wellenausbreitung existieren jedoch entsprechend.
3
Kapitel 1. Einleitung und Motivation
Die Berechnung einer korrekten Simulation der Funkwellen und eine zeitlich korrekte
Simulation der Sensorknotenhardware ist – wie das Raytracing – sehr rechenaufwendig, was direkt zum nächsten Problem führt: zur Simulation der Knoten und der
Kommunikation zwischen den Knoten steht nur eine begrenzte Zeit zur Verfügung. Um
die Simulation zu beschleunigen werden oft vereinfachende Annahmen getroffen, welche in der Realität nicht zutreffen. Nur so wird die Simulation eines gesamten Netzes
über eine längere Zeitspanne hinweg praktisch möglich. So wird beispielsweise die (eigentlich kontinuierliche) Zeit in diskrete Ereignisse unterteilt und statt einer mathematisch und physikalisch korrekten Simulation der Funkwellenausbreitung erfolgt nur eine
Modellierung eines ggf. mit Störungen behafteten Kanals zwischen jeweils zwei Knoten. Diese Art der Simulation eignet sich gut für kabelgebundene Netze mit bekannten
Eigenschaften, jedoch weniger für ein kabelloses Netzwerk mit unbekannten Wechselwirkungen der einzelnen Knoten untereinander und unerwarteten Störungen.[4, 5]
1.2.3 Ansätze zur Verbesserung der Situation
Netzwerksimulatoren wie OMNeT++“ und ns-2“ können über spezielle Sensornetz”
”
werk-Erweiterungen wie z.B. Castalia“ einen (mit Störungen behafteten) Funkka”
nal nachbilden[6, 7, 8]. Die wirklichen Einflüsse der Sensorknoten untereinander, der
Umgebung sowie die der Kommunikation auf unterschiedlichen Kanälen wird jedoch
nicht korrekt dargestellt. Solche Erweiterungen eines Simulators für diskrete Ereignisse
erhöhen zwar die Aussagekraft einer Simulation, können eine reale Implementierung
jedoch nicht ersetzen. Die Autoren von Castalia gestehen in ihrem Paper From Si”
mulation to Real Deployments in WSN and Back“ [9] ein, dass die Ergebnisse der
Simulation von Castalia mit denen einer realen Implementierung nicht zufriedenstellend übereinstimmen. Zum Einsatz kamen im realen Test lediglich neun TelosB[10]
Knoten, welche in einer 7000 m2 großen Halle platziert wurden.
1.3 Zielsetzung dieser Arbeit
Zielsetzung dieser Arbeit ist es, eine zuverlässig außerhalb eines Simulators funktionierende Implementierung eines Sensornetzwerkes zu erstellen. Das Netzwerk besteht
aus bis zu 200 identischen Knoten und soll verschiedene Szenarien (siehe Kapitel 2.2)
erfolgreich absolvieren können. Hierzu zählt insbesondere, dass die Knoten ohne besonders vorgegebenes Wissen über die Umgebung eigenständig eine Vernetzung aufbauen sollen und eine energieeffiziente Kommunikation über einen längeren Zeitraum
hinweg aufrecht erhalten sollen. Besonderheiten eines Sensornetzwerkes, wie beispielsweise der Ausfall von einzelnen Knoten und andere, unerwartete Störungen, sollen die
Gesamtfunktionalität des Netzes nicht stärker als unbedingt notwendig beeinflussen.
Die Leistungsfähigkeit der Implementierung soll protokolliert und dargestellt werden.
4
1.3. Zielsetzung dieser Arbeit
a) Grundlagen
b) Entwicklung
realer Knoten
c) Realität!
reale Umgebung
Abbildung 1.2: Ansatz in dieser Arbeit. a) Grundlagen, wie Wake-on-Radio“, werden
”
mit wenigen Knoten entwickelt. b) Grundlegende Protokolle werden
mit einigen Knoten in einer realen Umgebung entworfen und getestet
c) Erprobung und Verbesserung des Netzes mit vielen Knoten in einer
realen Umgebung
1.3.1 Vorgehensweise
Da das Sensornetz einwandfrei außerhalb von Simulatoren funktionieren soll, wurde
konsequent auf reale Hardware in natürlichen Umgebungen zurückgegriffen. Auf eine
zusätzliche Simulation wurde – aus Zeitgründen – verzichtet. Abbildung 1.2 visualisiert
in groben Schritten, wie vorgegangen wurde.
Zunächst wurden grundlegende Funktionen (die Firmware zur Ansteuerung der Peripherie und insbesondere des Funkchips) entwickelt. Hierbei kam eine kleine Anzahl von
Knoten zum Einsatz. Nachdem diese grundlegenden Funktionen einsatzbereit waren,
wurde ein Multihop-Protokoll entworfen. Anhand einer größeren Anzahl von Knoten
wurde dieses iterativ verbessert. Anschließend wurde aus einer großen Anzahl von Knoten ein Netz gebildet und die Parameter des Protokolls optimiert.
Auf diesem finalen großen Netz wurden dann die bereits angesprochenen Anwendungsszenarien ausgeführt, protokolliert und ausgewertet. Alle in dieser Arbeit entstandenen
Ergebnisse basieren also auf realen Messungen und Beobachtungen mit echter Hardware in natürlichen Umgebungen! Neben einigen anderen Kleinigkeiten ist dies der
wesentliche Unterschied zu anderen, nur theoretisch beschriebenen Sensornetzen.
1.3.2 Stichwortartige Auflistung der Fähigkeiten und Funktionen
des entworfenen Systems
Das Sensornetz, welches in dieser Arbeit entwickelt wurde und vorgestellt wird, beinhaltet einige Besonderheiten, welche es zum Teil in anderen Netzen in dieser Form
nicht5 gibt. Stichpunktartig werden diese hier vorgestellt:
5
Kapitel 1. Einleitung und Motivation
ˆ Auswahl der Route auf Anwendungsebene wählbar nach: vorhandenen Energiereserven, Latenz, Bandbreite O
ˆ Kommunikation auf mehreren Kanälen zur Reduzierung der Kollisionen während
der Datenübertragung und dadurch mehr verfügbare Übertragunskapazität im
Netz O
ˆ Dynamische Bewertung von Kanälen und Vermeidung von potentiell gestörten
oder belegten Kanälen ( Blacklisting“) O
”
ˆ Adaptive Anpassung der Datenrate und Sendeleistung zwischen zwei Nachbarn
zur Optimierung des Energieverbrauchs und der Zuverlässigkeit O
ˆ Selbstorganisierende, netzweite (Multihop) Kommunikation ohne zentrale Infrastruktur. Jeder Knoten im Netz ist gleichwertig O
ˆ Mehrere Routen zu verschiedenen Zielen mit automatischer Umgehung lokaler
Störungen O
ˆ Vermeidung von Routen, welche über Knoten mit geringem Batterieladestand
führen zur Optimierung der Gesamtlaufzeit O
ˆ Netzweit synchrone Zeit mit einer Genauigkeit besser als einer Sekunde O
ˆ Store- and Forward Nachrichtenweiterleitung mit automatischer Bündelung der
Nachrichten O
ˆ Aufteilung der Systemsoftware in zwei Komponenten (Anwendung und Firmware), welche unabhängig voneinander weiter entwickelt werden können mit automatischer Erzeugung des Schnittstellencodes O
ˆ Gleichzeitige Software-Aktualisierung aller Knoten per Funk O
ˆ Automatische Protokollierung des Systemverhaltens O
1
2
3
4
5
6
7
8
9
10
11
12
1.3.3 Ähnliche Arbeiten
Ein Vergleich dieser Arbeit mit anderen Veröffentlichungen ist schwer möglich. Zum
Einen wird eine Hardwareplattform eingesetzt, welche zwar sehr kostengünstig und
leistungsfähig ist, in der Welt der Sensorknoten bisher jedoch nicht bekannt ist. Zum
Anderen werden Sensornetze in der Regel für genau eine Aufgabe passend entworfen.
Es gibt nicht ein Netz bzw. ein Protokoll, welches alle Probleme und Aufgaben lösen
kann[11, 12, 13]. Vielmehr wurde in dieser Arbeit eine neue Basisinfrastruktur ( 10 , 11 ,
12 ) geschaffen, welche es ermöglicht, verschiedene Protokolle zu implementieren und
diese in Tests in einer echten, nicht simulierten, Umgebung miteinander zu vergleichen!
OO
O
6
1.4. Aufbau dieser Arbeit
OOOOO
Das in dieser Arbeit entworfene und implementierte Routing- und Nachrichtenweiterleitungsprotokoll enthält einige neue5 ( 1 , 2 , 3 , 4 , 9 ) und bereits in anderen
Arbeiten implementierte ( 5 , 6 , 7 ) Ideen, welche die Leistungsfähigkeit und Effizienz
eines Sensornetz verbessern können. Im Paper Routing Techniques in Wireless Sensor
”
Networks: A Survey“[11] wird ein sehr guter Überblick über bestehende Protokolle für
kabellose Sensornetze gegeben.
OOO
1.4 Aufbau dieser Arbeit
Der Aufbau dieser Arbeit soll es dem Leser ermöglichen, die getroffenen Entwurfsentscheidungen nachzuvollziehen und das entworfene System zu verstehen. Hierzu erfolgt
zunächst eine grobe Beschreibung der Systemvision und der Einsatzszenarien (Kapitel
2). Nachdem das Gesamtsystem vorgestellt wurde, folgt eine Analyse der Anforderungen und der Gegebenheiten (Kapitel 3). Der Systementwurf an sich soll zeigen, wie
diese Anforderungen umgesetzt werden können und stellt die im Rahmen dieser Arbeit
entstandenen Protokolle vor (Kapitel 4). Anschließend wird beschrieben, wie der Entwurf umgesetzt wurde. Es wird die Implementierung von Teilkomponenten vorgestellt,
beschrieben wie das System getestet wurde und die Ergebnisse dieser Tests präsentiert
(Kapitel 5). Abschließend folgt eine kurze Zusammenfassung des Erreichten sowie ein
Ausblick auf das, was das System in Zukunft noch alles leisten könnte (Kapitel 6).
5
Eine umfangreiche Literaturrecherche ergab, dass diese Konzepte bisher nicht verwendet werden.
Aufgrund der Vielzahl von Veröffentlichungen zu Sensornetzen und der aktuell fortlaufenden Forschung kann natürlich nicht ausgeschlossen werden, dass es nicht auch andere Entwürfe mit diesen
Ideen gibt.
7
Kapitel 1. Einleitung und Motivation
8
2 Systemvision und
Einsatzmöglichkeiten
Nachdem in der Einleitung das Ziel dieser Arbeit bereits kurz angeschnitten wurde, folgt nun eine ausführlichere Beschreibung der Vision des gesamten Systems. Um
zu zeigen, was das System leisten soll bzw. kann, werden mehrere verschiedene Einsatzmöglichkeiten vorgestellt. Diese werden im Verlauf der Arbeit immer wieder aufgegriffen und teilweise auch implementiert.
2.1 Systemvision
Vor dem eigentlichen Entwurf und der Implementierung steht die Vision für das gesamte Sensorknotennetzwerk. Ziel ist es, ein aus vielen identischen Knoten bestehendes,
selbstorganisierendes und energieeffizientes Netzwerk aufzubauen. Die einzelnen Knoten könnten also beispielsweise von einem Flugzeug abgeworfen werden, sich zufällig
verteilen und anschließend eigenständig vernetzen (Abbildung 2.1). Es wird – sofern
möglich – Rücksicht darauf genommen, dass die Knoten nur über eine endliche Energieversorgung verfügen und eine möglichst lange Laufzeit erreicht werden soll. Das
System soll in der Grundversion die Anforderungen von gängigen Einsatzszenarien für
ein Sensorknotennetz erfüllen und sich über dies für Spezialfälle optimieren lassen.
2.2 Einsatzmöglichkeiten
Um zu zeigen, dass das in dieser Arbeit entwickelte System nicht nur eine theoretische Funktion erfüllt, soll an drei real existierenden Beispielen gezeigt werden, welche
Aufgaben ein Sensornetz übernehmen kann.
Das erste Beispiel Datensammlung“ ist das typische Szenario für ein Sensornetzwerk.
”
Jeder einzelne Knoten sammelt Daten, verarbeitet diese und schickt sie durch das
Netzwerk an eine zentrale oder ggf. mehrere Datensenken[14, 15].
Etwas spezieller ist das zweite Beispiel Bildübertragung“. Hier sollen die von mit
”
Kameras ausgestatteten Sensorknoten erzeugten und ggf. vorverarbeiteten Bilder mit
möglichst hoher Bandbreite durch das Netz geschickt werden. Dieses Szenario könnte
9
Kapitel 2. Systemvision und Einsatzmöglichkeiten
Abbildung 2.1: Ein aus vielen identischen, zufällig verteilten Knoten bestehendes Netz.
Beispielsweise könnten Knoten von einem Flugzeug abgeworfen werden
(lila), sich zufällig verteilen und dann, nachdem sie gelandet sind, zu
einem Netz zusammenschließen (rot).
beispielsweise im Hyperion Netzwerk[16, 17, 18, 19], welches ebenfalls an der Universität
Karlsruhe entworfen wurde, auftreten.
Das dritte Beispiel Positionsbestimmung“, gibt den Knoten neben der reinen Da”
tenverarbeitung und -weiterleitung eine weitere Funktionalität: Die Abschätzung der
eigenen Position anhand der gemessenen Signalstärke anderer Knoten im Netz.
2.2.1 Datensammlung
Als erste Einsatzmöglichkeit wurde die Aufgabe gewählt, viele kleine Datenpakete (also
beispielsweise Sensormesswerte) von vielen verschiedenen Knoten im Netz zu sammeln
und zu einer zentralen Datensenke zu übertragen. Die Daten können und/oder sollen
auf dem Weg von der Quelle zur Senke ggf. verarbeitet und zusammengefasst werden.
Dies ist vielfach die Standardanforderung, welche mit einem Sensornetz in Verbindung
gebracht wird. Dementsprechend gibt es viele Beispiele, bei denen eine solche Art von
Netz benötigt wird.
Ein Einsatzgebiet ist beispielsweise die Messung von Umweltdaten. Dies müssen nicht
unbedingt nur einfache Temperaturwerte sein sondern können auch Messungen der
seismischen Aktivität eines Vulkans sein[20]. Ebenfalls vorstellbar ist ein über eine
ganze Stadt verteiltes Sensornetz[21], welches die Luftverschmutzung misst und diese
Information an eine zentrale Verkehrsleitstelle oder öffentliche Informationstafeln weiterleitet. Auch für militärische Zwecke kommen Sensornetze dieser Art zum Einsatz.
Hierbei geht es dann jedoch in der Regel weniger um reine Umweltdaten. Auch taktisch
10
2%,'+%&6!,'+!%,&%!3%&8=%!?4'D.;+E=&3!-%'!I&%)3,%9%)4)8=D.'!-%)!9%)'D.,%-%&%&!M(07("
&%&+%&!%,&%'!$%&'()*&(+%&'!=&%)2;''2,D.!NO,22PQRB!$(2D.%!S%''=&3%&!',&-!%,&!1%'%&+2,"
D.%'!M),+%),=0!=0!4%,!-%)!?='18.2!9(&!M(07(&%&+%&6!?23(),+.0%&!=&-!-%)%&!T072%"
2.2. Einsatzmöglichkeiten
0%&+,%)=&3!4%EU32,D.!,.)%'!I&%)3,%9%)4)8=D.'6!-,%!V%4%&'E%,+!%,&%'!48++%),%4%+),%4%&%&!
$%&'()'!E=!08W,0,%)%&B!
!
!
Abbildung 2.2: Szenario Kamerasensorknotennetzwerk
(aus [16])
?44,2-=&3!@"@!
I,&!*80%)848',%)+%'!$%&'()&%+E1%)*!
J%,! -%0!Informationen
80! XY.8,)! <()!können
I04%--%-!
$5'+%0'Z!
,&! -%)! I&+1,D*2=&3!
4%<,&-2,D.%&!
relevante
so ohne
feste >YI$A!
Infrastruktur
erfasst und weitergeleitet
$%&'()*&(+%&!XO57%),(&Z!.8&-%2+!%'!',D.!=0!%,&%!0,+!%,&%0!M80%)80(-=2!=&-!%,&%0!
werden.
H=&*D.,7!8='3%'+8++%+%!:28++<()06!-,%!E=!0%.)%)%&!%,&!?)%82!EBJB!%,&%&!',D.%).%,+'*),+,"
'D.%&!
J%)%,D.!
U4%)18D.%&!
'(2D.%&! :28++<()0!
9,%2%!
Ein
weiteres
Beispiel
– wenn'(22B!
auchJ%,0!
mit I&+1=)<!
mehreren%,&%)!
Datensenken
– ist die '7,%2%&!
HausautomaH8*+()%&!%,&%![(22%B!/&+%)!8&-%)%0!0=''!-,%![%D.%&2%,'+=&3!-%)!:28++<()0!8&3%0%''%&!
tisierung.
Statt einer aufwendigen Verkabelung mit zentraler Steuerung wie dies meist
8='3%2%3+!
'%,&! =0!
J,2-9%)8)4%,+=&3'8=<384%&6!
M(00=&,*8+,(&'7)(+(*(22%!
üblich
ist, könnte
diese
Aufgabe von einem Sensornetz
übernommen werden.=&-!
Die8&-%)%!
einzel?=<384%&!,&!?&3),<<!&%.0%&!E=!*G&&%&B!T0![8.0%&!3,2+!%'6!9%)'D.,%-%&%!$(Y!9%)32%,"
nen
Knoten würden hierbei zusätzlich mit Aktoren ausgestattet, um in Abhängigkeit
D.%&!
E=! *G&&%&!Beobachtungen
=0! %,&%! 3=+%! J828&D%!
E1,'D.%&!
I&%)3,%9%)4)8=D.!
J%)%D.&=&3%&!
von bestimmten
Ereignisse
auslösen
zu können. Als <U)!
mögliches
Ereignis
sei das Ein- und Ausschalten der Beleuchtung in Abhängigkeit von der Anwesenheit von
Personen
im Raum genannt. Über das Netzwerk
!
"!#!"! könnten Knoten benachbarte Knoten
informieren,
dass
sich
Personen
auf
den
Raum zubewegen, damit diese dann bereits
!
ein optimales Umfeld für die erwarteten Personen vorbereiten können. Visionen wie
diese werden bereits seit vielen Jahren unter dem Überbegriff Ubiquitous Computing“
”
erforscht.[22, 23]
2.2.2 Bildübertragung
Das zweite gewählte Szenario entspricht der Aufgabe, eine große Datenmenge – also
beispielsweise ein Bild – durch das Netz zu transportieren. Es sind hierbei also kurze
Pfade mit möglichst hoher Bandbreite zu wählen.
Hyperion Kamerasensorknoten
Die ebenfalls an der Universität Karlsruhe entwickelte Hyperion Plattform bietet ein
flexibles Entwicklungs- und Messumfeld für die Entwicklung von Sensorknoten. Ziel ist
11
Kapitel 2. Systemvision und Einsatzmöglichkeiten
Abbildung 2.3: Einsatzszenario Positionsbestimmung“ (aus [24])
”
es, für zukünftige Sensorknoten, welche mehr als das Erfassen einfacher Umweltparameter wie z.B. der Temperatur leisten können, Entwurfsentscheidungen sowohl in Hardals auch in Software zu treffen und zu bewerten. Als ein mögliches Entwurfsszenario
wurde ein Kamerasensorknotennetzwerk (Abbildung 2.2) zur automatischen, verteilten
Überwachung eines sicherheitskritischen Bereichs vorgeschlagen. Alle hierzu notwendigen Komponenten (Kamera, leistungsfähige Hardware und ein Funkmodem) stehen zur
Verfügung[19]. Da bei den Hyperion Sensorknoten der gleiche Funkchip verbaut wird
wie in dieser Arbeit, bieten es sich an, die beiden Netze miteinander in Verbindung zu
bringen. Die Hyperion Sensorknoten könnten in das in dieser Arbeit entwickelte Netz
eingebunden werden und als Datenquelle dienen.
2.2.3 Positionsbestimmung
Als drittes Beispiel für den Einsatz eines Sensornetzes wird ein Location Aware Disa”
ster Aid Network“ vorgestellt[24]. Es handelt sich hierbei um ein selbstorganisierendes1
Sensornetz, welches beispielsweise in einem Katastrophenfall mit vielen Verletzten zum
Einsatz kommen kann. Es soll es den Rettungskräften erleichtern, einen Überblick über
die Situation zu bekommen und zu behalten. Ähnliches wird mit bereits existierenden
Sensoren für Herzfrequenz, Blutsauerstoffgehalt und EKG2 auch von der Havard Universität mit dem Projekt CodeBlue“ aufbauend auf den MICA2, MICAz und Telos
”
1
2
außer der Platzierung der festen Knoten und die Bekanntgabe deren Position
Elektrokardiogramm (EKG) heißt auf Deutsch Herzspannungskurve. Es zeigt die Kontraktionen
des Herzmuskels an.
12
2.2. Einsatzmöglichkeiten
Sensorknoten angestrebt.[25, 3, 26, 10]
Es werden einige wenige Knoten an bestimmten, bekannten und festen Positionen platziert, bei allen weiteren Knoten handelt es sich um mobile Knoten, welche beispielsweise an Patienten und Rettungskräften angebracht werden. Zusätzliche Routingknoten3 können die Verfügbarkeit des Netzes verbessern. Anhand der Signalstärke der
Pakete der festen Knoten können bzw. sollen die mobilen Knoten ihre eigene Position
abschätzen. Zusammen mit Vitalwerten (beispielsweise die Herzfrequenz, ...) wird die
geschätzte Position der Patienten dann an die Knoten der Rettungskräften übermittelt.
Diese können dann erkennen, welcher Patient in der Nähe ist bzw. dringend behandelt
werden muss. Die Informationen werden ebenfalls an die Rettungszentrale weitergeleitet, welche dann notwendigen Entscheidungen über den Einsatz der zur Verfügung
stehenden Kräfte und Resourcen treffen kann und muss. Abbildung 2.3 zeigt die verschiedenen Knotenarten und deren Zusammenspiel. Aufgrund zeitlicher und technischer
Einschränkungen (siehe Kapitel 5.2.4) wurde diese Funktion in dieser Arbeit jedoch
nicht umgesetzt.
3
Knoten, welche keine andere Funktion zur Verfügung stellen als eine Verbindung zwischen zwei
ansonsten zu weit auseinander liegenden Knoten zu ermöglichen
13
Kapitel 2. Systemvision und Einsatzmöglichkeiten
14
3 Analyse und
Anforderungsspezifikation
Nachdem die Systemvision vorgestellt wurde, wird nun beschrieben, welche Anforderungen für eine erfolgreiche Umsetzung notwendig sind. Hierbei wird unterschieden in
funktionale- und nicht-funktionale Anforderungen. Primäres Ziel ist die Umsetzung der
funktionalen Anforderungen, wobei wo immer möglich auch versucht wird, die nichtfunktionalen Anforderungen zu berücksichtigen. Anschließend werden die Gegebenheiten vorgestellt. Hierbei handelt es sich um die Hardwareplattform, welche im Detail
vorgestellt wird sowie um die eingesetzten Softwarekomponenten. Das nächste Kapitel
zeigt, wie der Entwurf der Umsetzung dieser Anforderungen erfolgt ist.
3.1 Funktionale Anforderungen
Die funktionalen Anforderungen spezifizieren, was das gesamte System und jeder einzelne Knoten im Netz leisten können muss. Diese Anforderungen werden aus der Systemvision und den Einsatzszenarien abgeleitet.
Autonome Vernetzung und Selbstorganisation
Jeder Knoten ist, bis auf eine eindeutige Identifizierungsnummer, identisch. Es
ist im Voraus nicht bekannt, welche Topologie das Netz haben wird noch welcher
Knoten sich wo im Netz befindet. Das System muss folglich ohne externe Hilfe
in der Lage sein, die Topologie zu erkunden und eine Vernetzung der Knoten
untereinander zu organisieren. Grundsätzlich kann jeder Knoten im Netz eine
Datenquelle bzw. eine -senke sein.
Multihop Kommunikation
Aufgrund physikalischer Beschränkungen der Funkkommunikation kann im Normalfall – bei einer räumlich verteilten Topologie – nicht jeder Knoten jeden anderen Knoten direkt erreichen. Dennoch wird gefordert, dass jeder Knoten Nachrichten mit jedem anderen Knoten austauschen kann. Hierzu ist eine Weiterleitung
der Nachrichten über einen oder ggf. mehrere Zwischenknoten (= Hops“) not”
wendig. Die möglichen Pfade durch das Netz sind im Voraus nicht bekannt und
15
Kapitel 3. Analyse und Anforderungsspezifikation
müssen selbst gefunden werden. Das Netz soll in der Lage sein, Nachrichten, welche auf ihrem Pfad durch das Netz gleiche Teilstrecken zurücklegen, automatisch
zusammenzufassen.
Kabelloses Software Deployment
Damit die Erprobung, Evaluation und Fehlerbehebung effizient erfolgen kann,
ist es notwendig, dass die Anwendungssoftware geändert bzw. getauscht werden
kann. Damit die – möglicherweise in einer Test- und Messumgebung untergebrachten – Knoten nicht einzeln an eine Basisstation angeschlossen werden müssen,
soll dieser Austausch kabellos erfolgen können. Sofern möglich sollen hierbei viele
Knoten gleichzeitig aktualisiert werden.
Laufzeitprotokollierung
Damit das Geschehen auf den einzelnen Knoten nach der Durchführung eines
Testaufbaus ausgewertet und überprüft werden kann, ist es notwendig, die relevanten Informationen während der Laufzeit zu sammeln und zu speichern, damit
diese am Ende des Versuchs zur Verfügung stehen. Damit nicht jeder Knoten einzeln zum Auslesen der Informationen an eine Basisstation angeschlossen werden
muss, soll dies auch über den Funkweg erfolgen können.
Zeitsynchronisierung
Insbesondere für die spätere Auswertung des Laufzeitprotokolls ist es wichtig,
eine netzweit einheitliche Zeitbasis zu etablieren.
3.2 Nicht-funktionale Anforderungen
Bei den nicht-funktionalen Anforderungen handelt es sich um Eigenschaften, welche
nicht auf den ersten Blick als Funktion wahrgenommen werden. Vielmehr handelt es
sich hierbei um (wünschenswerte) Eigenschaften, welche das Verhalten des Systems
beeinflussen.
Ausfalltoleranz
In einem Sensornetzwerk muss immer damit gerechnet werden, dass einzelne Knoten ausfallen. Das System muss hierauf reagieren können und solange es möglich
ist die Funktion aufrecht erhalten bzw. schrittweise zurückfahren1 .
Energieeffizienz
Ziel ist eine möglichst ungestörte Übertragung bei geringer Sendeleistung und hoher Datenrate, so dass nur wenige Übertragungswiederholungen erfolgen müssen
1
Ein solches Verhalten wird auch als graceful degradation“, also in etwa sanfte Verschlechterung“
”
”
bezeichnet.
16
3.3. Gegebenheiten
und die Zeit, in welcher Sender und Empfänger aktiv sind, kurz gehalten wird.
Hierzu soll die zum Senden verwendete Datenrate und die Sendeleistung adaptiv
angepasst werden. Potentiell gestörte Kanäle sollen bei der Übertragung vermieden werden. Bei der Wahl von Pfaden durch das Netz sollen Knoten bevorzugt
werden, deren Energievorrat noch nicht erschöpft ist und zu denen eine gute Verbindung besteht. Wann immer ein Knoten nichts zur Gesamtfunktionalität des
Systems beizutragen hat und auch keine internen Aufgaben zu erledigen hat, soll
er in einen Energiesparmodus wechseln.
3.3 Gegebenheiten
Bereits gegeben war die Hardware, ursprünglich einmal eine interaktive Fernbedienung
mit dem Namen Betty“[27]. Das Betty-Set war aus mehreren Teilkomponenten aufge”
baut: Ein Adapter zum Anschluss an den Fernseher um zu erkennen, welcher Sender
und welche Sendung gerade angesehen wird, ein Modem zum Anschluss an das Telefonnetz um Verbindung zum Betty-Server aufbauen zu können und natürlich die Fernbedienung selbst. Die Teilkomponenten standen per Funk miteinander in Verbindung.
In dieser Arbeit wird nur die Fernbedienung selbst (die sog. Head Unit“) eingesetzt,
”
da diese bereits für den Betrieb mit Akkus vorbereitet war. Sie steht vielen kommerziell angebotenen Sensorknotenplattformen in nichts nach und bietet Features“ – wie
”
beispielsweise ein leistungsfähiges LCD – welche über das üblicherweise Vorhandene
hinausgehen.
Die Betty wurde von der Swisscom AG beworben als interaktive Fernbedienung. Die
Markteinführung erfolgte 2006 (Schweiz) bzw. 2007 (Deutschland). Sie bot Quizspiele, Abstimmungen, Umfragen, Informationen und Werbung begleitend zum Fernsehprogramm einiger Fernsehsender. Leider verlief die Markteinführung nicht mit dem
gewünschten Erfolg (nur etwa 100.000 verkaufte Exemplare statt den über 500.000
geplanten). Der Geschäftsbetrieb wurde Ende 2007 eingestellt.
Da die Betty Fernbedienung den gleichen Funkchip wie der am Institut entwickelte
Hyperion Sensorknoten verwendet, bot es sich an, die Fernbedienungen zur Erweiterung des Hyperion-Netzes zu verwenden. Aufgrund einer Nachfrage beim (ehemaligen)
deutschen Betreiber konnte eine komplette Palette mit etwa 200 Betty-Sets zu akademischen Zwecken zur Verfügung gestellt werden. Die Fernbedienung wurde zwar nicht
dazu entworfen, als Sensorknoten zu dienen, aufgrund der verbauten Komponenten
eignet sie sich hierfür jedoch gut. Details zur Hardware werden im Unterkapitel 3.3.1
näher beschrieben. Als Grundgerüst für die Software wurde die Open Source Firmware
Boop“[28] verwendet. Details hierzu folgen im Unterkapitel 3.3.4.
”
17
Kapitel 3. Analyse und Anforderungsspezifikation
Abbildung 3.1: Übersicht Hardwareplattform Diagramm
Echtzeituhr
i²c
Funkchip
(Chipcon cc1100)
SPI
Flash Speicher
(2 MByte NOR)
CPU
(32 Bit ARM7)
UART
GPIO
JTAG
pwm
Audio
LCD
(160x128 Pixel)
IR
18
3.3. Gegebenheiten
Abbildung 3.2: Übersicht Hardwareplattform Foto
Funk
IR
LCD
RTC
Audio
0,1 Ohm
Messwid.
2,5 Volt
Linearregler
Flash
CPU
GPIO und UART
Schaltregler
19
Kapitel 3. Analyse und Anforderungsspezifikation
3.3.1 Hardwareplattform
Abbildung 3.1 zeigt ein Blockschaltbild der eingesetzten Hardwareplattform, Abbildung
3.2 ein Foto von beiden Seiten der Platine. Es folgt nun eine kurze Vorstellung der
einzelnen Komponenten:
Prozessor 32Bit ARM (NXP LPC2220 - ARM7TDMI-S)
Als Prozessor kommt der Microcontroller LPX2220 von NXP zum Einsatz. Er
verfügt über 64kByte internes SRAM und ein externes Speicherinterface. Es handelt sich um eine 32bit ARM7 Architektur. Die Taktrate kann zwischen 10MHz
bis 70Mhz2 gewählt werden. Ein fest integrierter Bootloader ermöglicht es, Software über die serielle Schnittstelle einzuspielen. Die typische Peripherie (gängige
Schnittstellen, JTAG3 , Timer, Counter, PWM4 , ...) eines Microcontrollers steht
zur Verfügung. Um Energie zu sparen, können einzelne Komponenten des Controllers deaktiviert werden. Neben der Variation der Taktfrequenz kann der Chip
in einen Idle“ und einen Power-Down“ Mode versetzt werden, um den Energie”
”
bedarf zu minimieren.
Flash Speicher 2 Mbyte NOR (EON en29lv800)
Als Festspeicher sind zwei Flashbausteine mit je 8 Mbit verbaut. Sie sind als
512k*16Bit5 organisiert und über einen parallelen Bus mit den Prozessor verbunden. Der Speicher ist in mehrere Sektoren eingeteilt, welche sich separat löschen
lassen.
Funkchip 433 Mhz, 500kbps, +10dBm Sendeleistung (TI/Chipcon CC1100)
Der Funkchip CC1100 ist ein hoch integrierter Baustein mit vielen Funktionen,
welche ihn für den Einsatz in einem Sensorknoten prädestinieren. Er enthält ein
Modem und einen UHF Transceiver für die Frequenzbereiche 300-348 MHz, 400464 MHz und 800-928 Mhz6 . Die Datenrate kann bis zu 500kbps (kilo bits per second) betragen. Die Ausgangsleistung kann in einem großen Bereich von -30dBm
bis +10dBm eingestellt werden. Pakethandling“ wird im gewissen Rahmen di”
rekt von der Hardware unterstützt. Die Anbindung an den Prozessor erfolgt über
SPI7 . Der Funkchip verfügt neben einem Power-Down“ auch über einen Idle“
”
”
2
Im Rahmen dieser Arbeit wird zwischen 10MHz, 20MHz und 40MHz umgeschaltet – je nach Bedarf
der Anwendung
3
JTAG steht für Joint Test Action Group“ und bezeichnet ein Standardinterface zum Testen und
”
Debuggen von Hardware direkt in der Schaltung
4
Bei der Pulsweitenmodulation (engl. Pulse Width Modulation, abgekürzt PWM) wird die Ein- und
Ausschaltzeit eines Rechtecksignals bei fester Grundfrequenz variiert. Hierdurch lässt sich grob
gesagt die während einer kurzen Periode abgegebene Energie steuern
5
512k*16Bit bedeutet 524288 einzeln adressierbare Wörter je 16Bit
6
Im Rahmen dieser Arbeit wurde das in Deutschland lizenzfrei zugelassene ISM Band von 433,05434,79 MHz verwendet. ISM steht hierbei für Industrial, Scientific, and Medical
7
Serial Peripheral Interface – Serielles Bus-System (Motorola)
20
3.3. Gegebenheiten
und einen Wake-on-Radio“ Modus. Im Wake-on-Radio Modus lauscht der Funk”
chip vollautomatisch periodisch in den Kanal. Wenn er ein Paket empfängt weckt
er über einen Interrupt den möglicherweise abgeschalteten Prozessor. Durch das
Abschalten aller Komponenten der Plattform während dieses Modus kann der
durchschnittliche Energiebedarf stark gesenkt werden.
Echtzeituhr (Philips PCF8563)
Obwohl im verwendete Microcontroller bereits eine Echtzeituhr integriert ist, ist
ein separater Echtzeituhrenchip verbaut. Der Chip ist über den I2 C8 -Bus Dies
bringt verschiedene Vorteile. Zu nennen sei hier beispielsweise die von der PLL
des Controllers unabhängige Funktion. Es ist möglich, in regelmäßigen Intervallen
oder zu bestimmten Zeitpunkten einen Interrupt auslösen zu lassen, beispielsweise
um periodische Aktivitäten durchzuführen oder um den Microcontroller aus dem
Power-Down Mode zu wecken. Dies hilft, öfter in den Power-Down Mode zu
wechseln und trägt somit – obwohl der zusätzliche Chip mehrere 100 W benötigt
– zur Reduzierung des durchschnittlichen Energiebedarfs bei.
µ
LCD 160 x 128 Pixel (SSD1854)
Als sehr hilfreich bei der Beobachtung und Tests des Netzes hat sich das kleine
LCD an jedem der Knoten erwiesen. Im Vergleich zu den beschränkten Möglichkeiten9 der meisten kommerziell verfügbaren Sensorknoten macht es die BettyFernbedienung zum Luxusknoten. Es stellt 160x128 Pixel in vier Graustufen dar
und verfügt über eine LED Hintergrundbeleuchtung. Sowohl die Hintergrundbeleuchtung als auch der Displaycontroller können vollständig deaktiviert werden,
um keine unnötige Energie zu verbrauchen. Die Hintergrundbeleuchtung kann
auch zur einfachen Signalisierung von Betriebszuständen dienen (Blinken, An,
Aus, ...).
Audio über PWM4
Einer der PWM Ausgänge des Micocontrollers wird über einen Audioverstärker
und -filter auf einen kleinen Lautsprecher ausgegeben. Es ist somit möglich, nahezu beliebige Töne auszugeben. Um Speicherplatz für hierzu nötige Samples
zu sparen wird die PWM nur genutzt, um einfache Signaltöne in verschiedenen
Frequenzen zu erzeugen. Diese lassen sich beispielsweise dazu verwenden, Fehler akustisch zu melden oder um auf den Knoten aufmerksam zu machen. Der
Audioverstärker- und Filterchip lässt sich durch den Microcontroller vollständig
deaktivieren, so dass keine Energie benötigt wird, sofern kein Signalton ausgegeben wird.
8
Inter-Integrated Circuit – Serielles Bus-System (Philips). Auch bekannt unter TWI (Two Wire
Interface)
9
meist nur einige wenige LED in verschiedenen Farben
21
Kapitel 3. Analyse und Anforderungsspezifikation
Infrarot – nicht verwendet –
Da es sich bei der Hardware eigentlich um eine TV-Fernbedienung handelt, verfügt sie über eine Infrarotdiode, welche sowohl Infrarotsignale aussenden als auch
empfangen kann. Die notwendige analoge Verstärkerschaltung, um die Signale
auch digital auswerten zu können, ist vorhanden. Da sich das Sensornetz dieser
Arbeit auf die Funkschnittstelle beschränkt, kommt die Fähigkeit, Infrarotsignale
senden und empfangen zu können, nicht zum Einsatz. Die analoge Hardware wird
daher so angesteuert, dass möglichst kein Strom fließt und somit keine unnötige
Energie verbraucht wird.
Schnittstellen zur Erweiterung
Zur Erweiterung der Plattform stehen verschiedene, gängige Schnittstellen (SPI,
I2 C, UART10 , JTAG) zur Verfügung. An den Bus, an welchem die Flashbausteine und das Display angeschlossen sind, lassen sich über dies hinaus weitere
Geräte wie beispielsweise Sensoren anschließen, welche nicht über eine der seriellen Schnittstellen verfügen. Für einfache Aufgaben stehen noch einige Pins des
Controllers für GPIO11 -Zwecke zur Verfügung. Für zukünftige Entwicklungen stehen also viele Möglichkeiten offen.
Stromversorgung Zwei NiMH Akkus mit 1,2 Volt, 700mAh
Die Energiequelle der Knoten besteht aus jeweils zwei handelsüblichen 1,2 Volt
AAA NiMH Akkus mit 700mAh. Über einen Schaltregler wird die Versorgungsspannung von 3,0 Volt generiert. Leider arbeitet dieser Schaltregler den Messungen nach zu urteilen nicht optimal, da selbst wenn alle abschaltbaren Komponenten deaktiviert sind noch immer etwa 5mA fließen. Um reproduzierbare
Messergebnisse zu bekommen, wurde ein Knoten mit einem Netzteil ausgestattet. Über einen 2,5 Volt Linearregler wird die Spannung von zwei vollen Akkus
simuliert.
3.3.2 Messung der Leistungsaufnahme
Da alle Versuche auf real existierender Hardware ausgeführt werden, war es nicht notwendig, ein genaues Modell der Sensorknoten für eine Simulation anzufertigen. Dennoch sind einige Systemparameter vermessen worden. Hierbei handelt es sich um die
Leistungsaufnahme unter verschiedenen Betriebsmodi sowie die Abstrahlcharakteristik
der Antenne der Sensorknoten.
Die Leistungsaufnahme der Hardware wurde über einen 0,1 Ohm Messwiderstand (siehe
Abbildung 3.2) bei einer Versorgungsspannung von 3,0 Volt gemessen. Angegeben sind
die Verbrauchswerte in Milliwatt. Die gemessenen Betriebsmodi werden im Folgenden
10
Universal Asynchronous Receiver Transmitter, Kompatibel zu RS-232, welches einen Standard für
eine serielle Schnittstelle bezeichnet
11
General Purpose Input/Output – Universal verwendbare Ein-/Ausgabe
22
3.3. Gegebenheiten
200
175
Funkchip
Grundsystem
150
mW
125
100
75
50
25
0
Power down
CPU idle
CPU 10 MHz
CPU 40 MHz
CPU 20 MHz
RF idle
RX (idle)
TX (-30 dBm)
TX (0 dBm)
RX (active)
TX (-15 dBm)
TX (10 dBm)
Abbildung 3.3: Übersicht über die Messwerte der Leistungsaufnahme des Systems
während verschiedener Betriebsmodi.
zum besseren Verständnis kurz beschrieben, Abbildung 3.3 zeigt eine Übersicht über
die jeweiligen Leistungsaufnahmen dieser Systemzustände. Die Messwerte könnten beispielsweise dazu verwendet werden, ein Modell zur Simulation des Sensorknotens anzufertigen. Sie dienen ebenfalls einer groben Abschätzung der möglichen Energieeffizienz
des Systems. Abbildung 3.4 zeigt den Verlauf der Batteriespannung (Entladekurve) eines aktiven und eines passiven Knotens. Der aktive Knoten sendet hierbei pro Sekunde
ein Paket bei voller Sendeleistung aus. Der passive Knoten führt, außer der periodischen
Messung der Batteriespannung und dem Abspeichern dieser im Flash, keine anderen
Aktionen durch. Die übrige Zeit befinden sich beide Knoten in einem Power-Down
Mode.
In der folgenden Auflistung der gemessenen Systemzustände ist die Angabe des Verbrauchs in mW immer die Gesamtaufnahme des Systems.
Power down 11mW
Im Power down“ Mode sind alle Komponenten soweit dies möglich ist vollständig
”
abgeschaltet bzw. in einem ultra low Power“ Mode. Der Microcontroller lässt sich
”
nur noch über externe Interrupts wecken, da alle internen Komponenten deaktiviert sind und nicht mit einem Takt versorgt werden. Bevor die CPU nach einem
Weckvorgang wieder zur Verfügung steht, vergeht eine kurze Zeit, bis sich die
Takterzeugung eingeschwungen hat. Aktiv ist lediglich ein kleiner Rest analoger
Schaltung sowie der Schaltregler, welche sich um die Umwandlung der Batteriespannung in stabile 3,0 Volt kümmert. Aus nicht nachvollziehbaren Gründen
benötigt ein Sensorknoten in diesem Zustand dennoch 11mW und schränkt damit
die längste zu erwartende Laufzeit eines Knotens nicht unerheblich ein. Die zwei
Akkus haben eine Nennkapazität von 700mAh bei 1,2 Volt (entspricht 1,68Wh).
Es ergibt sich somit eine rechnerisch maximale Laufzeit von etwa 6 Tagen. Praktisch wurden nur etwa 5 Tage erreicht (siehe Abbildung 3.4), was möglicherweise
23
Kapitel 3. Analyse und Anforderungsspezifikation
damit zu erklären ist, dass die Akkus nicht sonderlich hochwertig sind. Die erreichbare Laufzeit reicht dennoch für alle praktischen Tests des Netzes aus.
CPU idle 30mW
Bei der CPU idle“ Messung befindet sich der Microcontroller im Idle-Zustand.
”
Hierbei handelt es sich um eine Vorstufe zum Power Down Mode, aus dem die
CPU sehr schnell geweckt werden kann. Die interne Peripherie und Takterzeugung läuft – im Gegensatz zum Power Down Mode – weiter. Alle außerhalb des
Controllers befindlichen Komponenten der Plattform befinden sich (wie zuvor)
im Zustand der kleinstmöglichen Leistungsaufnahme.
CPU 10 MHz 69mW
Für diese Messung führt der Microcontroller eine Endlosschleife aus. Er ist hierbei
voll aktiv und wendet keinerlei Methoden zur Senkung des Energiebedarfs an.
Die Taktfrequenz der CPU beträgt 10 MHz. Alle weiteren Komponenten der
Plattform sind deaktiviert.
CPU 20 MHz 108mW
Als Taktrate für die CPU sind bei dieser Messung 20MHz gewählt, alles Weitere
entspricht der vorausgehenden Messung.
CPU 40 MHz 153mW
Als Taktrate für die CPU sind bei dieser Messung 40MHz gewählt, alles Weitere
entspricht der vorausgehenden Messung. Es ist offensichtlich, dass für eine energieeffiziente Implementierung die CPU so oft wie nur möglich im Power-Downbzw. Idle-Zustand sein sollte. Sofern die CPU die meiste Zeit auf andere Komponenten wartet, sollte die kleinstmögliche Taktfrequenz gewählt bzw. – sofern
möglich – in den Idle-Zustand gewechselt werden. Für die vierfache Rechenleistung wird nur etwa doppelt12 so viel Leistung benötigt. Da die Plattform mit
Akkus betrieben wird, kann es dennoch sinnvoll sein, auch für aufwändige Berechnungen die Taktfrequenz nicht zu erhöhen. Der höhere Strom über einen
kürzeren Zeitraum kann die Akkus stärker belasten als der niedrigere Strom über
einen längeren Zeitraum[29, 30, 31]. In der Regel sind jedoch keine aufwändigen
Berechnungen auf den Knoten durchzuführen.
RF idle 18mW
Die RF idle“ Messung entspricht der Power down“-Messung mit dem Unter”
”
schied, dass der Funkchip als einzige Komponente nicht abgeschaltet ist. Er befindet sich in einem Bereitschaftsmodus, aus welchem er schnell damit beginnen
kann zu senden oder zu empfangen. Die 18mW setzen sich zusammen aus 11mW
für das System und zusätzlichen 7mW für den Funkchip.
12
Der CPU-Kern benötigt zwar vier mal so viel Strom, die restlichen aktiven Komponenten des Mikrocontrollers benötigen jedoch immer den gleichen Strom, sofern die CPU aktiv ist – unabhängig
von der Taktfrequenz des CPU-Kerns!
24
3.3. Gegebenheiten
RX (idle) 79mW
Bei der RX (idle)“ Messung befindet sich das System an sich im Power down“
”
”
Modus, der Funkchip jedoch ist aktiv und empfangsbereit. Erneut werden 11mW
für das System benötigt, der Funkchip benötigt 68mW.
RX (active) 154mW
Empfängt der Funkchip ein Paket eines anderen Knotens, so steigt die Leistungsaufnahme des Funkchips geringfügig auf 85mW an. Zusätzlich muss die CPU
geweckt werden, so dass diese sich prinzipiell in einer Endlosschleife befindet und
die Daten des Funkchips entgegen nimmt. Die Taktfrequenz der CPU beträgt
hierbei 10 MHz (dementsprechend 69mW für das System).
TX (-30dBm, -15dBm, 0dBm, +10dBm) 110mW bis 191mW
Beim Senden (TX) eines Pakets ist sowohl der Mikrocontroller als auch der Funkchip aktiv. Die Leistungsaufnahme hierbei ist abhängig von diversen Faktoren,
den größten Einfluss hat die gewählte Sendeleistung. Gezeigt sind Messungen bei
-30dBm, -15dBm, 0dBm und +10dBm Sendeleistung13 – der Funkchip benötigt
hierbei jeweils 41mW, 47mW, 86mW und 122mW. Der Mikrocontroller befindet
sich wieder in einer Endlosschleife um den Funkchip mit Daten zu versorgen und
benötigt hierzu bei 10MHz 69mW. Bemerkenswert ist hierbei, dass die Leistungsaufnahme beim Empfangen eines Pakets in etwa vergleichbar ist mit dem Senden
eines Pakets bei 0dBm Ausgangsleistung. Bei geringerer Sendeleistung wird zum
Empfangen mehr Energie benötigt als zum Senden!
Anhand der Messwerte ist zu erkennen, dass die Plattform nicht optimal für den Betrieb
eines Sensorknotens geeignet ist. Dies war im Voraus nicht bekannt. Die kleinstmögliche
Leistungsaufnahme liegt bei 11mW, zu erwarten wären hier Werte im Bereich von wenigen Mikrowatt gewesen. Die Plattform eignet sich aufgrund der Hardwarekonfiguration
dennoch hervorragend zur Entwicklung und Evaluierung eines Sensornetzes, ein produktiver Betrieb über mehrere Monate hinweg ist jedoch nicht erreichbar. Die hohe
Leistungsaufnahme in den aktiven Betriebsmodi macht es über dies hinaus einfach
zu beurteilen, wie effizient das System mit den vorhandenen Resourcen umgeht. Eine nicht energieeffiziente Implementierung wäre bereits nach wenigen Stunden nicht
mehr einsatzbereit, je effizienter14 die Implementierung ist, desto längere Laufzeiten
des gesamten Sensornetzes15 können erzielt werden.
25
Kapitel 3. Analyse und Anforderungsspezifikation
2,8
2,75
Passiver Knoten
Aktiver Knoten
Batteriespannung [V]
2,7
2,65
2,6
2,55
2,5
2,45
2,4
2,35
2,3
2,25
2,2
0
30
Zeit [h]
116
Abbildung 3.4: Entladekurve eines aktiven und eines passiven Knotens. Der aktive
Knoten sendet hierbei pro Sekunde ein Paket bei voller Sendeleistung
aus. Der passive Knoten führt, außer der periodischen Messung der
Batteriespannung und dem Abspeichern dieser im Flash, keine anderen
Aktionen durch. Die übrige Zeit befinden sich beide Knoten in einem
Power-Down Mode.
26
3.3. Gegebenheiten
b) Messung
a) Modell
Messpunkte
Empfangsbereich
Störbereich
Abbildung 3.5: Abstrahlcharakteristik von Sensorknoten: a) bei der Simulierung häufig
zum Einsatz kommendes Modell[32, 33] und b) eine reale Messung der
in dieser Arbeit verwendeten Antenne. Der Empfangsbereich entspricht
der Umgebung um den Knoten, in dem eine Datenübertragung möglich
ist. Im Störbereich ist eine Übertragung nicht mehr möglich, es werden
jedoch u.U. Übertragungen anderer Knoten gestört!
27
Kapitel 3. Analyse und Anforderungsspezifikation
3.3.3 Messung der Abstrahlcharakteristik
Abbildung 3.5 zeigt die gemessene Abstrahlcharakteristik der in den Sensorknoten verbauten Antennen. Als Vergleich ist zusätzlich das üblicherweise in Simulationen zum
Einsatz kommende Modell einer idealen Antenne dargestellt. Im Modell nimmt die Signalstärke in alle Richtungen gleichmäßig ab. Man nimmt einen Kreis16 rund um den
Knoten an, in welchem eine Kommunikation möglich ist (Empfangsbereich) sowie einen
Bereich, in welchem zwar keine Kommunikation mehr erfolgen kann, das ausgesendete
Signal jedoch andere Knoten bei ihrer Kommunikation stören könnte (Störbereich). Bei
der Messung stellte sich heraus, dass bei der richtigen Hardware der Signalwert nicht
in alle Richtungen rund um den Sensorknoten im gleichen Maße abnimmt17 . Gemessen wurde in einem gleichmäßigen Raster rund um einen sendenden Knoten. Bestimmt
wurde jeweils, ob eine Übertragung möglich ist und welche Signalstärke gemessen wurde. In der Grafik ist nur die Aussage Empfang möglich“ dargestellt. Um die Messung
”
durchführen zu können, wurde ein Knoten mit einer Rundstrahlantenne ausgestattet,
deren Empfindlichkeit nahezu dem Modell entspricht. Wäre die Messung ebenfalls mit
der originalen Antenne der Knoten durchgeführt worden, würde die Graphik noch weiter vom Modell abweichen. Ähnliche Ergebnisse bei der Messung an MICA2-Knoten[3]
werden im Paper Impact of Radio Irregularity on Wireless Sensor Networks“[33] vor”
gestellt.
3.3.4 Software
Als Grundlage für die Entwicklung der Software wurde die Open Source Firmware
Boop“[28] verwendet, welche als primäres Ziel hat, eine möglichst komfortable Uni”
versalfernbedienung aus der Betty-Hardware zu machen. Offensichtlich haben die Entwicklung eines Sensorknotens und die Entwicklung einer Universalfernbedienung ein
deutlich voneinander abweichendes Ziel. Dies führte dazu, dass die gegebene Firmware
im ersten Schritt auf grundlegende Funktionen reduziert wurde und nicht benötigter
Code, wie beispielsweise das Benutzerinterface, entfernt wurde. Das übrig gebliebene
Gerüst wurde als Grundlage für die weitere Entwicklung verwendet. Neu hinzugefügt
wurden Funktionen zur Ansteuerung des Funkchips, der Verwaltung des Energiebedarfs
und zur Interaktion mit dem Watchdog.
13
dBm ist ein logarithmisches Leistungsmaß mit der Bezugsgröße 1mW. -30dBm entsprechen daher
0.001 mW, -15dBm etwa 0.03mW, 0dBm 1mW und 10dBm 10mW
14
bei gleicher Leistung
15
einzelne Knoten können unter Umständen bereits vorzeitig ausfallen ohne dass dies die Gesamtfunktionalität einschränkt!
16
Eigentlich wäre eine Kugel das richtige Modell, in der Simulation wird das Netz jedoch oft in nur
einer Ebene zweidimensional dargestellt.
17
Da die Antenne im Gehäuse mehrfach gefaltet ist, wäre eine gleichmäßige Abstrahlcharakteristik
eher erstaunlich gewesen.
28
3.3. Gegebenheiten
Boop“ steht unter der GPL18 3.0. Obwohl in dieser Arbeit nicht mehr viel der ur”
sprünglichen Codebasis verwendet wird, gilt sie als abgeleitetes Werk und steht aufgrund der Lizenzbedingungen somit ebenfalls unter der GLP 3.0. Eine Kopie der GPL
3.0 ist in der Codebasis enthalten und kann ebenfalls unter [34] nachgelesen werden.
Die nötigen Werkzeuge zur Übersetzung der Software von C bzw. Assembler in Maschinencode stellt die Ronetix Toolchain“[35] in der Version 4.1.1 bereit. Diese enthält
”
die GNU-Tools für ARM (Compiler, Assembler, Linker und diverse Tools) sowie die
newlib“ Bibliothek. Hierbei handelt es sich um eine für den Einsatz auf eingebetteten
”
Systemen optimierte Standard-C-Bibliothek.
18
GNU General Public License
29
Kapitel 3. Analyse und Anforderungsspezifikation
30
4 Systementwurf
Nachdem das System und die einzelnen Komponenten in den vorherigen Kapiteln bereits vorgestellt wurden, erfolgt nun eine Beschreibung des Entwurfs und der Architektur.
Es wird zunächst gezeigt, wie die auf den einzelnen Knoten laufende Software aufgebaut
ist und welche Besonderheiten sie bietet. Anschließend wird gezeigt, wie die Software
unter den Knoten verteilt wird. Abschließend folgt eine Beschreibung der Architektur der Kommunikation im gesamten System zwischen den Knoten. Die verwendeten
Protokolle werden im Detail vorgestellt.
4.1 Softwarearchitektur
Für die Software wurde eine zweigeteilte Architektur gewählt. Sie besteht aus einem
fest auf jedem Knoten installierten Teil (im Weiteren Firmware“ genannt) sowie ei”
nem austauschbarem Teil (im Weiteren Anwendung“ genannt). Die Firmware stellt
”
die Basisfunktionalität zur Verfügung. In der Anwendung werden weitergehende Funktionen und das Verhalten der Sensorknoten implementiert. Abbildung 4.1 zeigt einen
groben Überblick über die zweigeteilte Architektur.
Es folgt nun zunächst die Architektur der Firmware. Anschließend wird die Architektur
der Hauptanwendung1 beschrieben. Im folgenden Unterkapitel Software Deployment“
”
(4.2) werden dann die Mechanismen vorgestellt, welche den Austausch und die Verteilung der Anwendung ermöglichen.
4.1.1 Architektur der Firmware
Die Firmware stellt eine solide Basis für die Entwicklung von Anwendungen für das
Sensornetzwerk dar. Sie erfüllt prinzipiell vier Aufgaben: die Hardware Abstraktion, einen Callback Mechanismus, eine umfangreiche RF Komponente und das
Softwareupdate.
Das Softwareupdate wird im Unterkapitel 4.2 im Detail vorgestellt, hier folgt eine kurze
Beschreibung der übrigen Funktionen der Firmware.
1
Neben dieser gibt es mehrere kleine Testanwendungen, deren Ergebnisse jedoch in die Hauptanwendung eingeflossen sind.
31
Anwendung
Kapitel 4. Systementwurf
Sensornetz- und Knotenlogik
Laufzeitprotokoll
Energieverwaltung
Ereignisverarbeitung
Schnittstelle zur Firmware (Pointertabelle)
Firmware
Hardware Abstraktion
Callback Mechanismus
RF Komponente
ADC
RTC
Paket Empfangen
Power
IRQ
Paket Senden
Watchdog
Timer
Chip Konfigurieren
Flash
LCD
Wake on Radio
Software Update
Audio
STDIO
Hardware
Abbildung 4.1: Grober Überblick über die zweigeteilte Softwarearchitektur. Gezeigt
werden die wesentlichen Komponenten der Firmware und der Anwendung.
32
4.1. Softwarearchitektur
Hardwareabstraktion
Damit sich der Entwurf der auf dem Sensorknoten laufenden Anwendung quasi vollständig auf die Programmlogik konzentrieren kann, wird von der Firmware eine große
Menge an Funktionen angeboten, um einfach auf die Hardware des Knotens zugreifen zu können. Der Zugriff auf die Hardware erfolgt hierbei über normale Funktionsaufrufe. Um beispielsweise die Spannung der Stromversorgung (und somit dem Ladezustand der Akkus) abzufragen, genügt es, die entsprechende Funktion aufzurufen.
Selbstverständlich kann die jeweilige Anwendung auch direkt auf die Hardware zugreifen, sofern dies nötig ist.
Callback“ Mechanismus
”
Damit die Anwendung nicht ständig aktiv nachfragen muss, ob neue zu verarbeitende
Ereignisse vorliegen, bietet es die Firmware an, für bestimmte Ereignisse eigene Funktionen2 anzumelden, welche dann aufgerufen werden, wenn das Ereignis auftritt. Da
die Ereignisse überwiegend von der Hardware ausgelöst werden (und zwar auch dann,
wenn die CPU in einem Stromsparzustand ist), trägt diese Vorgehensweise auch zum
Energiesparen bei.
Die Firmware verwaltet hierzu eine Liste mit Funktionspointern. Wenn ein Ereignis
auftritt, welches einen Callback“ auslösen kann, wird statt des direkten Sprungs auf
”
den Funktionspointer eine Wrapper-Funktion aufgerufen. Diese überprüft dann, ob das
Sprungziel überhaupt existiert und eine gültige Callback-Funktion“ ist und führt erst
”
dann den Sprung aus. Über bestimmte Funktionen kann die Anwendung ihre eigenen
Funktionen in diese Liste eintragen lassen. Es ist somit nicht nötig, alle möglichen Call”
backs“ in der Anwendung zu implementieren. Es müssen nur die von der Anwendung
benötigten Funktionen implementiert und registriert werden.
RF Komponente
Da die Ansteuerung des Funkchips von jeder Anwendung benötigt wird (und auch von
der Firmware selbst zur Durchführung des kabellosen Softwareupdates), wurde eine
komplette Softwarekomponente zur Konfiguration und Verwendung des Funkchips in
der Firmware implementiert.
Die API3 der Komponente erlaubt es, Pakete mit einer Länge von bis zu 64kByte zu
senden und zu empfangen. Ebenfalls unterstützt wird der Wake-on-Radio“ Mechanis”
mus (siehe 3.3.1 und 4.3.1). Über die bereits vorgestellte Callback-Schnittstelle kann die
2
3
Die aufgerufenen Funktionen werden Callback-Funktionen“ genannt.
”
API steht für engl. application programming interface, deutsch: Schnittstelle zur Anwendungs”
programmierung“. Im weiteren Sinne wird die Schnittstelle jeder Bibliothek (Library) als API
bezeichnet.
33
Kapitel 4. Systementwurf
0x80000000
0x80020000
0x80040000
0x80060000
0x82000000
Firmware
Anwendung
temporäre Anwendung
Logdaten
Nachrichtenindex
0x80070000
Nachrichtenwarteschlange
Konfiguration
Flash 0
0x820f0000
Flash 1
Abbildung 4.2: Aufteilung des Flashspeichers. Der erste Baustein wird verwendet, um
die Firmware und die Anwendung abzulegen. Zusätzlicher Platz ist reserviert um eine temporäre Anwendung während des Anwendungsupdates anzulegen. Der restliche zur Verfügung stehende Speicherplatz wird
für eine Nachrichtenwarteschlange samt dazugehörigem Index verwendet. Im zweiten Baustein wird, außer eines kleinen Bereichs für Konfigurationsdaten, nur das Protokoll der Laufzeit abgelegt.
Anwendungen eingehende Pakete zur Bearbeitung entgegennehmen. Einstellungen wie
beispielsweise Datenrate, Sendeleistung und Übertragungskanal können über einfache
highlevel Funktionsaufrufe vorgenommen werden.[19][36]
Bei jedem empfangenen Paket wird von der Firmware zunächst eine Vorfilterung durchgeführt. Handelt es sich um ein Software-Update“-Paket oder ein Reset“-Paket, wird
”
”
dieses direkt verarbeitet. Andernfalls wir das Paket zur weiteren Verarbeitung der Anwendung übergeben. Nicht für die Anwendung bestimmte Pakete bekommt diese somit
nicht zu sehen.
4.1.2 Aufteilung des Speichers
Der Programmcode wird komplett im Flash abgelegt und aus diesem ausgeführt, so
dass das SRAM (nahezu) komplett für dynamische Daten zur Verfügung steht. Für
weniger dynamische Daten wird der Flashspeicher genutzt. Da der Flash-Speicher seine
Daten auch ohne Energieversorgung behält, können so über einen längeren Zeitraum
gesammelte Daten zur späteren Auswertung gespeichert werden.
34
Sensornetzknotenanwendung
4.1. Softwarearchitektur
Implementierung der
verschiedenen Szenarien
Kanal- und Knotenbewertung
Aufgabenverwaltung
Routing und Routenverwaltung
Nachrichtenverwaltung und
-verarbeitung
Energieverwaltung
Laufzeitprotokoll
Ereignisverarbeitung
Schnittstelle zur Firmware (Pointertabelle)
Abbildung 4.3: Teilkomponenten der Hauptanwendung
Die (im Verhältnis zum SRAM) Menge an zur Verfügung stehendem Speicher wird neben der Protokollierung auch dazu genutzt, eine energieeffiziente Nachrichtenweiterleitung im gesamten Netzwerk zu etablieren. Nachrichten müssen pro Hop nur ein einziges
Mal übertragen werden und stehen somit bei jedem Knoten im Datenpfand im Falle
einer nötigen Übertragungswiederholung zur Verfügung und müssen nicht über den
gesamten Pfad erneut übertragen werden. Wie genau dieser Mechanismus funktioniert
und zum Energiesparen beitragen kann, wird in den folgenden Kapiteln beschrieben.
Die Aufteilung des Speichers der beiden Flashbausteine auf die jeweiligen Komponenten
des Sensorknotens ist in Abbildung 4.2 dargestellt.
4.1.3 Architektur der Anwendung
Es wurden mehrere Anwendungen, welche auf den Sensorknoten ausgeführt werden
können, entwickelt. Diese dienten im Wesentlichen der Erprobung der Schnittstelle An”
wendung / Firmware“ und der Entwicklung von neuen Funktionen. Die Erkenntnisse,
welche mit diesen Testanwendungen gesammelt wurden, kommen in der Sensorknotenund Routinganwendung zum Einsatz. Im weiteren Verlauf dieser Arbeit ist immer diese Hauptanwendung gemeint. Abbildung 4.3 zeigt die Teilkomponenten dieser Anwendung, welche im Folgenden vorgestellt werden.
35
Kapitel 4. Systementwurf
a)
b)
gestörte Kanäle
c)
Abbildung 4.4: Beispiel für eine Anwendung: Messung der Belegung des 433MHz Frequenzbereiches. a) und b) mit einem Störsender aus 1,5m bzw. 15m
Entfernung. c) zeigt das ungestörte Spektrum. Die grau hinterlegten
Kanäle sind die von der Software als belegt“ bewerteten und würden
”
bei einer Datenübertragung vermieden.
Beispiel für eine Testanwendung
Als ein Beispiel für eine Testanwendung sei die Scanner“ Anwendung genannt. Um die
”
Belegung des Frequenzspektrums der Funkmodems anzuzeigen, wird dieses in gleichmäßigen Schritten schnell abgetastet und die gemessenen Signalpegel auf dem Display angezeigt. Abbildung 4.4 zeigt Bilder des Displays. Teilbild a) und b) zeigen das
Spektrum eines Störsenders4 aus etwa 1,5m und 15m Entfernung. Teilbild c) zeigt das
ungestörte Spektrum. Die grau hinterlegten Kanäle sind die von der Software als be”
legt“ bewerteten und würden bei einer Datenübertragung vermieden. Das Ergebnis
dieses Tests führte dazu, dass der Frequenzbereich in sechs statt zunächst 16 geplanten Kanälen eingeteilt wurde. Erkenntnisse aus dieser Anwendung sind direkt in die
Kanalbewertungskomponente der Hauptanwendung eingeflossen.
Implementierung der verschiedenen Szenarien
Für die drei verschiedenen Szenarien (siehe Kaptiel 2.2) werden zwar unterschiedliche
Vorgänge auf den einzelnen Knoten durchgeführt, das Basissystem ist jedoch bei allen
identisch. Es wurde daher nicht für jedes Szenario eine eigene Anwendung entwickelt,
sondern eine Teilkomponente der Anwendung kümmert sich um die Umsetzung der
Aufgaben und bietet ein Benutzerinterface, über welches über die serielle Schnittstelle
auf das Verhalten der Knoten Einfluss genommen werden kann. Zusätzlich können diverse Informationen (Routingtabelle, Nachrichtenwarteschlange, ...) über den internen
Status der Knoten lokal ausgegeben oder über das Netz von anderen Knoten angefordert werden.
4
Die Basisstation eines 433 MHz Funkkopfhörer-Sets
36
4.1. Softwarearchitektur
Kanal- und Knotenbewertung
Die Kanal- und Knotenbewertung besteht aus zwei voneinander unabhängigen Komponenten. Die Kanalbewertung basiert auf der bereits unter 4.1.3 vorgestellten Testanwendung. Die Abtastung der Kanäle erfolgt jedoch nicht kontinuierlich sondern nur in
größeren Abständen. Aufgrund dieser Abtastung wird für jeden Kanal dynamisch unter Berücksichtigung der anderen Kanäle eine Bewertung erstellt. Immer dann, wenn
ein Kanalwechsel erfolgt, wird zunächst diese Bewertung überprüft, um so potentiell gestörte Kanäle zu vermeiden. Durch die größeren Pausen zwischen den einzelnen
Überprüfungen der Kanäle werden eher langfristige Störungen, wie zum Beispiel der
bereits genannte Funkkopfhörer, erkannt. Kurzfristige Störungen müssen durch Empfangsbestätigungen und Sendewiederholungen ausgeglichen werden.
Die Knotenbewertung greift genau hier ein. Bei jeder nötigen Sendewiederholung wird
die Bewertung eines Knotens herabgesetzt, bei jeder erfolgreichen Empfangsbestätigung
erhöht. Aufgrund dieser Bewertung wird dann adaptiv die Einstellung des Funkchips für
die nächste Übertragung gewählt. Bei einer schlechten Bewertung wird die Datenrate
reduziert und die Sendeleistung erhöht, bei einer guten Bewertung die Sendeleistung
reduziert und die Datenrate erhöht.
Die Kombination aus einer dynamischen Bewertung der Übertragungskanäle und der
ständigen Anpassung der Sendeleistung und Datenrate ermöglicht es, Verbindungen mit
niedriger Fehlerrate aufzubauen und somit unnötige Sendewiederholungen einzusparen.
Durch die Reduktion der Sendeleistung und Erhöhung der Datenrate wird bei guten
Verbindungen über dies hinaus die benötigte Energie für die Übertragung reduziert.
Die benötigte Energie für die Übertragung einer Nachricht lässt sich Abschätzen durch
die Nachrichtenlänge (in Byte), der Datenrate (in Bit pro Sekunde), die Sendeleistung
(in Watt), den Grundverbrauch des aktiven Systems (ebenfalls in Watt) sowie der
Anzahl der Übertragungswiederholungen n:
EÜbertragung = n ∗
Nachrichtenlänge
∗ (PSendeleistung + PGrundleistung )
Datenrate
Aufgabenverwaltung
Damit Knoten mehrere Aufgaben gleichzeitig erfüllen können, werden diese nicht immer
gleich bearbeitet, wenn sie durch einen anderen Knoten oder die Anwendung selbst in
Auftrag gegeben werden. Stattdessen erfolgt die Bearbeitung und Beantwortung von
Anfragen asynchron. Die Aufgaben werden dazu in eine Warteschlange eingefügt. Durch
die Aufteilung in Teilaufgaben können so mehrere Aufgaben parallel bearbeitet werden
– in etwa vergleichbar mit dem Scheduler eines Betriebssystems.
Für jede Aufgabe kann eine Wartezeit angegeben werden, bis die Bearbeitung erfolgt.
Durch zufällige Wartezeiten kann eine gewisse zeitliche Entzerrung von ausgehenden
37
Kapitel 4. Systementwurf
Typ
Timeout
betr. Route ID
Node ID
Sequenz Nr.
Fehlercounter
Leseposition
Freigabeposition Schreibposition
zu bearbeitende Aufgaben
neue Aufgaben
freier Speicher
Abbildung 4.5: Verwaltung der Aufgaben in einem Ringbuffer. Es werden drei Zeiger (Leseposition, Freigabeposition und Schreibposition) verwendet, um
den Zugriff auf die Datenstruktur zu koordinieren. Die Bedeutung des
Inhalts eines einzelnen Eintrags ist im gewissen Rahmen abhängig vom
Aufgabentyp, dargestellt sind die zur Verfügung stehenden Felder.
Paketen erreicht werden. Nicht erfolgreich erledigte Aufgaben können einfach wieder in
die Warteschlange eingefügt werden. Über den selben Mechanismus können Timeouts
verwaltet werden oder periodische Aufgaben abgewickelt werden.
Die Speicherung und Verwaltung der Aufgaben erfolgt in einem Ringbuffer. Mit jedem
durch die Echtzeituhr ausgelösten Interrupt werden – sofern vorhanden – alle neuen
Aufgaben zur Verarbeitung freigegebenen. Die freigegebenen Aufgaben werden dann
nach und nach bearbeitet. Während dieses Abarbeitungsschrittes neu anfallende Aufgaben werden erst im nächsten Schritt freigegeben und bearbeitet. Aufgaben, deren
Wartezeit noch nicht abgelaufen ist, werden wieder an das Ende des Buffers angefügt.
Abbildung 4.5 zeigt den Aufbau dieser Verwaltungsstruktur.
Diese zentrale Aufgabenverwaltung und -abarbeitung führt die Teilkomponenten der
Anwendung zusammen und hat einen großen Einfluss auf die Funktion und das Verhalten der einzelnen Knoten.
Routing und Routenverwaltung
Jeder Knoten kann mehrere Routen zu mehreren verschiedenen Zielen verwalten. Routen werden erst dann gesucht bzw. aufgebaut, wenn sie auch benutzt werden sollen –
38
4.1. Softwarearchitektur
Source Prev Target Next Length Seq. Nr DR
SL
a)
1
1
2
255
32 1234 NONE NONE
b) 1
0
3
3
1
8214 MAX MIN
c)
1
0
100
3
4
4382 MED LOW
d) 4
3
55
255
30 8215 NONE NONE
e) 255 255 255 255
0
0
0
0
Bat.
255
92
50
255
0
Routenwahl
Flags Errors Rating Path
0x01
0
0/0
1
0x10
1
9/1 1,3
0x02
0
0/0 1,3..
0x01
0
0/0 4,3,1
0x00
0
0/0
0
Nachbarschafts Bewertung
Abbildung 4.6: Aufbau der Routingtabelle. Grün hinterlegt sind die Spalten, die zur
Routingwahl verwendet werden. Die blau hinterlegten Spalten dienen
der adaptiven Anpassung von Datenrate und Sendeleistung zwischen
zwei Nachbarn. Dargestellt sind einige Einträge aus Sicht vom Knoten
mit der Nummer 1: a) Route-Request von Knoten 1 zu Knoten 2. b)
Nachbarschaft zu Knoten 3. c) Bestehende Route zu Knoten 100 über
4 Hops. d) Route-Request von Knoten 4 zu Knoten 55, welches über 3
bei 1 eingegangen ist. e) Nicht verwendeter Eintrag.
es handelt sich hierbei also um reaktives Routing. Nicht verwendete Routen werden
nach einer bestimmten Zeit automatisch aus dem Bestand gelöscht. Als Basis für das
Routing wurde das AODV-Protokoll (AdHoc On Demand Distance-Vector)[37] verwendet.5 Da das AODV-Protokoll nur eine einzige Route pro Ziel vorsieht, konnte es nicht
vollständig übernommen werden. Durch die diversen Änderungen ist eigentlich ein neues Routingprotokoll entstanden, welches im Unterkapitel 4.3.4 im Detail beschrieben
wird. Das Protokoll sucht und findet, sofern vorhanden, mehrere schleifenfreie Pfade
zum Ziel. Die Routenwahl kann durch die Anwendung in der Form beeinflusst werden,
dass entweder Routen mit niedriger Latenz, Routen mit hoher Bandbreite oder Routen
mit einer guten Energieeffizienz6 gewählt werden. Lokal auftretende Probleme auf dem
Pfad werden, soweit möglich, lokal behoben. Nur dann, wenn kein alternativer Pfad
zum Ziel gewählt werden kann, wird das Problem an den vorausgehenden Knoten (und
somit ggf. bis zur Quelle zurück) gemeldet. Parallel zur Verwaltung und Organisation
der Routen werden viele der gesendeten Pakete zur netzweiten Zeitsynchronisation mit
einem Zeitstempel versehen.
Zur knoteninternen Verwaltung der Routen wird eine einfache Tabelle verwendet. Der
Aufbau dieser Tabelle ist in Abbildung 4.6 dargestellt. Nicht verwendete Tabelleneinträge werden durch eine nicht existierende Zieladresse (255) gekennzeichnet. Da relativ
wenig Speicher zur Verfügung steht und der Prozessor vergleichsweise schnell arbeitet,
5
Zusätzlichen Einfluss hatten The Pulse Protocol“[38] und das Directed Diffusion“ Protokoll[39]
”
”
für kabellose Sensornetze.
6
Die Energieeffizienz bedeutet hierbei auch, dass vorzugsweise Knoten gewählt werden, welche über
einen vollen Akku verfügen.
39
Kapitel 4. Systementwurf
wurde auf eine effizientere (im Sinne von CPU-Zyklen) Verwaltung der Einträge verzichtet.7 Es fand also eine Abwägung zwischen nötigem Speicherbedarf und zur Verfügung
stehenden Prozessorzyklen statt.
Nachrichtenverwaltung und -verarbeitung
Als Nachrichten werden all die Datenpakete bezeichnet, die von einem Knoten (Quelle) zu einem anderen Knoten (Ziel) durch das Netz weitergeleitet werden sollen. Bevor
eine Nachricht durch das Netz geschickt werden kann, muss zuvor durch das Routingprotokoll mindestens ein Pfad durch das Netz gefunden werden. Um den Signalisierungsaufwand gering zu halten, werden Nachrichten, welche den jeweils gleichen
nächsten Knoten auf ihrem Pfad haben, automatisch zusammengefasst und gemeinsam übertragen. Im Abschnitt 4.3.5 wird diese netzweite Datenübertragung im Detail
vorgestellt.
Da für größere Datenmengen das RAM der Knoten nicht ausreicht, werden die Nachrichten im Flash abgelegt. Da ggf. viele Nachrichten gleichzeitig verwaltet werden
müssen, werden auch die notwendigen Daten zur Nachrichtenverwaltung im Flash abgelegt. Gegenüber der Verwaltung im RAM hat dies diverse Nachteile. Um diese Nachteile
etwas zu kompensieren, werden die möglicherweise dynamischen Anteile dieses Indexes
im RAM abgelegt, nur die garantiert statischen Anteile werden ins Flash geschrieben.
Sollten bei der Weiterleitung der Nachrichten auf Ihrem Weg zum Ziel Probleme auftreten, so wird diese Art der quasi dauerhaften Speicherung zum Vorteil. Tritt ein Fehler
auf und kann die Nachricht nicht weiter in Richtung Ziel geleitet werden, so muss der
auf dem Pfad vorausgehende Knoten nur darüber in Kenntnis gesetzt werden, dass
die Nachricht nicht zugestellt werden konnte8 – eine erneute Übertragung der Nachricht auf dem Pfad zurück oder gar von der Quelle ausgehend ist nicht nötig, da die
Daten noch vorliegen. Der Knoten, der über das Problem informiert wurde, kann die
Nachricht dann entweder auf einem anderen Weg zum Ziel leiten oder – falls dies nicht
möglich ist – ebenfalls seinen Vorgänger informieren.
Regelmäßig wird überprüft, ob noch ausstehende Nachrichten zu bearbeiten sind. Wenn
ja, erfolgt die nötige Behandlung. Sind keine weiteren Nachrichten zu bearbeiten,
erfolgt, sofern der zur Verfügung stehende Speicherbereich im Flash einen gewissen
Schwellwert unterschritten hat, eine Freigabe von neuem Speichern, indem alte Nachrichten gelöscht werden. Da der Flashspeicher nur sektorweise gelöscht werden kann,
kann diese Freigabe erst dann erfolgen, wenn alle im entsprechenden Sektor gespeicherten Nachrichten bearbeitet wurden. Bereits bearbeitete aber noch nicht gelöschte
Nachrichten werden durch ein entsprechendes Flag gekennzeichnet9 .
7
Zur Optimierung vorstellbar wäre es, eine Menge verketteter Listen pro Ziel zu verwenden. Zweifelhaft ist es jedoch, ob die hierzu notwendige dynamische Speicherverwaltung und der geringfügig
höhere Speicherbedarf die eingesparten Prozessorzyklen rechtfertigt.
8
Zur Identifizierung der Nachricht genügt das Tupel (Quellknoten, Zielknoten, Sequenznummer)
9
Einzelne Bits können im Flash jederzeit von 1 auf 0 gesetzt werden. Ein Schreibvorgang von 0 nach
40
4.1. Softwarearchitektur
Energieverwaltung
Eine geschickte Verwaltung bzw. Minimierung des Energiebedarfs der einzelnen Knoten
ist, neben dem Design der Protokolle für einen energieeffizienten Betrieb des Sensornetzes, unabdingbar.
Energie gespart werden kann, indem die CPU, der Funkchip oder beides in einen Energiesparmodus versetzt wird. Die CPU selbst kann hierzu entweder (nahezu) vollständig
deaktiviert werden ( Power-Down-Mode“) oder in einen Schlafzustand ( Idle“) wech”
”
seln, aus dem sie sehr schnell wieder aufwachen kann. Zusätzlich kann die Taktfrequenz
der jeweils aktuellen Aufgabe angepasst werden10 . Der Funkchip verfügt ebenfalls über
einen Power-Down- und einen Idle-Modus. Als weitere Möglichkeit kann ein Wake-onRadio Modus gewählt werden, in dem der Funkchip eigenständig periodisch aufwacht,
das Medium abhört und – sofern ein Paket eingeht – die CPU über einen Interrupt
wecken kann. Geht während der Lauschphase kein Paket ein, wechselt der Funkchip
wieder zurück in den Power-Down-Mode.
Die Kombination aus Wake-on-Radio und Power-Down-Mode der CPU ist der Grundzustand, der eine optimale Laufzeit bei gleichzeitiger Erreichbarkeit ermöglicht. Es ist
die Aufgabe der Anwendung, diesen Zustand so oft wie es nur möglich ist zu erreichen.
Der Funkchip signalisiert über einen Interrupt eingehende Daten und weckt hierüber
die CPU, um diese entgegenzunehmen und entsprechend zu verarbeiten. Durch den
jede Sekunde von der Echtzeituhr ausgelösten Interrupt wird der Prozessor überdies
regelmäßig geweckt. Liegt keine Aufgabe vor und ist keine Nachricht zu verschicken,
so wechselt die CPU sofort wieder in den Energiesparmodus. Die CPU wird somit nur
einmal pro Sekunde kurz geweckt, wenn keine Aktivitäten im Netz stattfinden.
Da zuerst die funktionalen Anforderungen des Netzes im Vordergrund standen, wurden diese Energiesparmechanismen nicht alle vollständig integriert. Es sind – bis auf
die zur Nachbarschaftserkennung notwendige Bake – alle Funktionen darauf vorbereitet, den Wake-on-Radio Mechanismus zu verwenden. Aufgrund der vielen notwendigen
Aufweckpakete führt dies jedoch bei mehreren Knoten, welche sich in gegenseitiger
Reichweite befinden, zu einer zu starken Belegung des Signalisierungskanals und somit
zu einer schlechten Gesamtperformance des Netzes. Um das Problem zu umgehen, sind
daher alle Knoten grundsätzlich empfangsbereit. Bei einem Wake-on-Radio Zyklus von
0,5 Sekunden müssen im Durchschnitt für 0,25 Sekunden Weckpakete geschickt werden, bis der Partner geweckt ist. Bei einer Datenrate von 100kbps und einer mittleren
Paketgröße von 15 Byte für ein typisches Signalisierungspaket können stattdessen theoretisch über 400 Signalisierungsvorgänge erfolgen! Der Prozessor wird jedoch dennoch,
wann immer keine Aufgaben zu bearbeiten sind, in einen Energiesparmodus versetzt.
Bei häufigem Verkehr auf dem Signalisierungskanal ist somit die Energieeffizienz höher,
10
1 ist jedoch ausgeschlossen.
Zur Wahl der Taktfrequenz stehen 10, 20 und 40 MHz zur Verfügung. Es hat sich jedoch herausgestellt, dass für die reinen Sensorknotenaufgaben 10 MHz Takt ausreichend ist. Lediglich für
rechenintensive Aufgaben würde es sich ggf. lohnen, den Takt zu erhöhen!
41
Kapitel 4. Systementwurf
obwohl jeder einzelne Knoten mehr Energie benötigt, um den Funkchip jederzeit Empfangsbereit zu halten. Diese Energie wird jedoch beim Senden der Nachrichten wieder
eingespart, da es mit höherer Wahrscheinlichkeit nicht zu Kollisionen kommt. Bei einer Konfiguration des Netzes, in welcher wenig Signalisierungsverkehr erfolgt, wäre die
Wake-on-Radio“-Variante im Sinne der Energieeffizienz vorzuziehen.
”
Laufzeitprotokollierung
Damit das Verhalten der Sensorknoten nach der Ausführung eines Versuches ausgewertet und analysiert werden kann, werden wichtige Systemparameter, wie Beispielsweise
die aktuelle Versorgungsspannung oder die Anzahl der ein- und ausgehenden Pakete der
Funkschnittstelle, in regelmäßigen Abständen direkt ins Flash geschrieben. Die Daten
gehen somit auch nicht verloren, wenn die Energieversorgung unterbrochen wird. Hierzu
steht nahezu der gesamte zweite Flashbaustein zur Verfügung. Bei einem Schreibintervall von zehn Sekunden und 52 Byte pro Eintrag11 können so Protokolle zu Versuchen,
welche über zwei Tage am Stück andauern mit einer guten zeitlichen Auflösung abgespeichert werden. Da die Versuche, die im Rahmen dieser Arbeit durchgeführt wurden,
meist nur wenige Stunden dauerten, wurde das Schreibintervall auf eine Sekunde herabgesetzt, um detailliertere Auswertungen erstellen zu können.
Damit nach der Durchführung eines Versuchs nicht alle Knoten einzeln ausgelesen
werden müssen, ist eine Funktion implementiert, welche einen komprimierten Auszug
des Logfiles an einen im Voraus bestimmten Knoten verschicken kann. Der Versand
der Daten kann entweder gezielt angefordert werden oder simultan bei allen Knoten
durch das Überschreiten einer bestimmten Zeitmarke ausgelöst werden. Zum Versand
der Daten kommt das normale Nachrichtenübertragungsprotokoll zum Einsatz. Der
Zielknoten muss sich also nicht in direkter Reichweite befinden.
Ereignisverarbeitung
Die Ereignisverarbeitung ist dafür zuständig, angefallene Interrupts zu verarbeiten.
Hierzu zählt der Interrupt der Echtzeituhr und des Funkchips.
Die Echtzeituhr löst jede Sekunde einen Interrupt aus. Die Firmware verwendet diesen
Interrupt, um die Systemzeit mit der Zeit der Echtzeituhr abzugleichen. Anschließend
wird der entsprechende Ereignishandler der Anwendung aufgerufen. Dieser wird für
verschiedene Zwecke genutzt. So wird das aktuelle Laufzeitprotokoll in den Flashspeicher geschrieben und zurückgesetzt. Es kann bestimmt werden, wie viele Sekunden
verstreichen, bis dies erfolgt. Die Bake, welche zur Nachbarschaftserkennung versendet
wird, wird durch den gleichen Mechanismus ausgelöst, mit dem Unterschied, dass die
11
Dies entspricht der Protokollierung der Versorgungsspannung, der Systemzeit, besonderen Ereignissen und einer detaillierten Aufschlüsselung der Funkschnittstelle
42
4.2. Software Deployment
a)
b)
Sensorknoten
Master Sensorknoten
PC mit akt. Software
Kabelverbindung
Funkübertragung
Abbildung 4.7: Software Deployment Varianten: a) an einzelne Knoten über die serielle
Schnittstelle und b) Übertragung an viele Knoten gleichzeitig per Funk.
zu verstreichende Zeit nach jeder Aktion (zufällig) neu bestimmt wird. Die letzte Aktion, die von diesem Ereignis ausgelöst wird, ist die Freigabe der bisher angefallenen
Aufgaben und Nachrichten zur Bearbeitung. Durch diese periodische Freigabe wird,
wie bereits beschrieben, eine schrittweise Abarbeitung erreicht.
Nicht explizit von der Anwendung erwartete Pakete werden vom Funkchip empfangen
und lösen ebenfalls einen Interrupt aus. Die Firmware nimmt diesen Interrupt entgegen
und leistet einige Vorverarbeitung, wie beispielsweise Adress- und Prüfsummenchecks.
Handelt es sich um ein an den aktuellen Knoten adressiertes Paket, wird der Pakethandler aufgerufen, welcher sich um die weitere Bearbeitung des Pakets kümmert. Aufgrund
des Pakettyps wird unterschieden, wie das Paket verarbeitet werden muss. So werden
beispielsweise Routinganfragen und -antworten angenommen und zur weiteren Verarbeitung in die Aufgabenliste geschrieben. Als ein anderes Beispiel sei der Weckvorgang
eines anderen Knotens zum Nachrichtenaustausch genannt.
4.2 Software Deployment
Der Austausch bzw. die Verteilung der Anwendung zur Laufzeit ist eine bedeutende
Funktion der Firmware bzw. des Systems und wird daher hier besonders hervorgehoben.
Die Verteilung kann entweder kabelgebunden über die serielle Schnittstelle oder kabellos
über Funk erfolgen. Die Firmware bietet sowohl die Unterstützung dafür, die auf dem
Knoten installierte Anwendung an (mehrere) andere Knoten zu schicken, als auch eine
neue Anwendung von einem anderen Knoten per Funk zu empfangen. Abbildung 4.7
visualisiert die beiden Möglichkeiten der Übertragung neuer Software.
Es werden nun zunächst die beiden Varianten (kabelgebunden, kabellos) vorgestellt.
Anschließend wird gezeigt, wie diese zweigeteilte Architektur aus fester Firmware und
43
Kapitel 4. Systementwurf
austauschbarer Anwendung zusammengehalten und ermöglicht wird.
Das Paper Updating Software in Wireless Sensor Networks: A Survey“[40] bietet einen
”
guten Überblick über verschiedene Verfahren des Software Deployments in anderen
kabellosen Sensornetzen sowie Sensornetzen im Allgemeinen.
4.2.1 Übertragung über die serielle Schnittstelle
Bei der Übertragung der Anwendung über die serielle Schnittstelle kommt das bereits
in der Studienarbeit Entwurf und Implementierung der Infrastruktur für den FPGA”
basierten Sensorknoten Hyperion“[19] entworfene Protokoll zum Einsatz, das dort im
Bootloader implementiert war. Auf eine zu tiefgehende Beschreibung wird daher hier
verzichtet. Wichtigster Unterschied ist, dass die Anwendung nicht in das RAM kopiert,
sondern direkt in den Flashspeicher geschrieben wird. Die Daten werden paketweise
übertragen und jedes Paket einzeln über eine Prüfsumme auf Übertragungsfehler untersucht. Nach vollständiger Übertragung erfolgt zusätzlich eine Überprüfung der gesamten Daten. Übertragungsfehler sind somit höchst unwahrscheinlich. Dadurch, dass
die Daten direkt in den Flashspeicher geschrieben werden, ist der Vorgang nur einmal nötig und muss nicht bei jedem Neustart der Plattform erfolgen. Nach leichten
Anpassungen konnte auch die in Java geschriebene GUI12 , welche die Gegenseite des
Protokolls implementiert, weiter verwendet werden.
4.2.2 Übertragung per Funk
Für die Übertragung über Funk wurde ein neues Protokoll entworfen, welches per
Broadcast alle Knoten in Reichweite des Senders gleichzeitig aktualisieren kann. Die
übertragene Anwendung wird nur dann aktiv, wenn sie sowohl vollständig als auch
korrekt beim Empfänger angekommen ist. Falls die Übertragung nicht erfolgreich war,
bleibt die ursprüngliche Anwendung aktiv. Bereits aktuelle Softwareversionen werden
nicht überschrieben. Dies ermöglicht es, das Softwareupdate von mehreren Standorten
im Einsatzgebiet des Sensornetzes mehrfach auszuführen, um so alle Knoten zu erreichen und zu aktualisieren. Eine detaillierte Beschreibung dieses Übertragungsvorganges
folgt im Unterkapitel 4.3.2.
4.2.3 Bindeglied Firmware / Anwendung
Die Firmware stellt, wie bereits beschrieben, eine grundlegende Funktionalität zur
Verfügung. Hierzu zählt unter anderem auch die embedded C Laufzeitumgebung new”
lib“ mit den typischen Funktionen wie memcpy() oder printf().
12
Graphical User Interface, englisch für grafische Benutzeroberfläche
44
4.2. Software Deployment
Hardware Abstra ktion
ADC
RTC
Power
IRQ
WD
Timer
Flash
LCD
Audio
STDIO
„Callbacks“
RF Komponente
App. Code
Paket Empfangen
Paket Senden
Konfigurier en
Software Update
Wake on Radio
Firmware.elf
h
#!/usr/bin/perl
@WISHLIST=(„puts“,
...)
Konvertier-Skript
Header Files
Sensornetz- und Knotenlogik
c
Laufzeitprotokoll
Energieverwaltung
Ereignisverarbeitung
Schnittste lle zur Firmware (Pointe rtabelle )
App.elf
Generierter Code
Abbildung 4.8: Automatische Codeerzeugung: Aus der ELF-Datei der Firmware und
den Headerdateien erzeugt das Konvertier-Skript neuen Code. Dieser
wird zusammen mit dem eigentlichen Anwendungscode kompiliert und
ergibt so die ELF-Datei der Anwendung. Der automatisiert erzeugte
Code enthält im Wesentlichen Pointer auf die Funktionen der Firmware.
Problematik
Alle in der Firmware implementierten Funktionen sollen in der Anwendung transparent
genutzt werden können. Um das Speicherabbild der austauschbaren Anwendung klein
zu halten, war es ebenfalls notwendig, die Funktionen der Laufzeitumgebung nach außen
hin zur Verfügung zu stellen. Weiterhin ist es erstrebenswert, in der Firmware angelegte
Datenstrukturen, welche die Firmware an sich nicht benötigt, in der Anwendung nutzen
zu können. Hierzu zählt beispielsweise der Sende- und Empfangspuffer für die Pakete
des Funkchips.
Gewählte Lösung
Um das Problem zu lösen, werden in der Firmware bereits vorhandene Funktionen
in der Anwendung nicht noch einmal abgelegt, sondern nur jeweils ein Pointer auf
die entsprechende Funktion. Die Tabelle mit den Funktionspointern ist nicht Bestandteil der Firmware. Stattdessen wird (automatisiert) neuer Programmcode erzeugt, der
im Wesentlichen aus Funktionspointern und Konstanten besteht13 . Dieser neue Programmcode kann dann normal übersetzt und gegen die Anwendung gelinkt werden.
Abbildung 4.8 zeigt die hierzu nötigen Schritte. Eine Besonderheit dieses Ansatzes
13
Eine Alternative wäre es gewesen, die Funktionen der Firmware an statische Adressen zu linken und
dann diese Adressen aus der Anwendung direkt anzuspringen. Aufgrund der Vielzahl der möglichen
Funktionen ist dies jedoch nicht praktikabel. Alternativ könnte die Firmware eine Tabelle mit allen
in ihr vorhandenen Funktionen verwalten – mit dem Nachteil, dass alle benötigten Funktionen
im Voraus bekannt sein müssen und nachträglich keine weiteren Funktionen hinzugefügt werden
können!
45
Kapitel 4. Systementwurf
ist es, dass zum Zeitpunkt der Übersetzung der Firmware nicht bekannt sein muss,
welche Funktionen später wirklich von der Anwendung genutzt werden. Wird eine weitere Funktion benötigt, so ist es ausreichend, diese im Skript14 , welches sich um die
automatische Codeerzeugung kümmert, in die entsprechende Liste einzutragen. Die
Funktionspointertabelle ist am Ende Bestandteil der Anwendung.
Das Schöne an dieser Lösung ist, dass die Anwendung so programmiert werden kann,
als wären die Funktionen der Firmware Bestandteil der Anwendung. Die komplette Einbindung der Funktionen der Firmware über die Funktionspointer wird vom Compiler15
übernommen. Es ist lediglich die statische Tabelle mit den Funktionspointern nach der
Übersetzung der Firmware (automatisiert) zu erzeugen. Details zur Implementierung
werden im Abschnitt 5.1.3 beschrieben.
Potentielle Möglichkeiten
Die Trennung von Anwendungslogik und Hardwarezugriffen würde es theoretisch ermöglichen, die echte Hardware samt Firmware gegen einen Simulator auszutauschen.
Statt einer auf Prozessorzyklen genauen Simulation könnten so die highlevel Funktionsaufrufe simuliert werden – verbunden mit einem erheblichen Geschwindigkeitsvorteil.
Vorstellbar wäre auch eine direkte Anbindung der Anwendungslogik an einen bereits
bestehenden Simulator. Hierfür müsste eine entsprechende Übersetzungssoftware entworfen werden, welche die Schnittstellen des Simulators an die Schnittstellen der Firmware anpasst. Beides ist im Rahmen dieser Arbeit nicht erfolgt, da es das primäre Ziel
war, eine außerhalb von Simulatoren funktionierende Realisierung eines Sensornetzes
zu erstellen.
Eine ähnliche Art der Simulation wird für Sensornetze, welche TinyOS als Grundlage
verwenden, mit Hilfe des Simulators TOSSIM angeboten. Hierbei wird die Anwendungssoftware nicht mit den Bibliotheken des TinyOS-Betriebsystems zusammen übersetzt,
sondern mit denen des TOSSIM Simulators. Der Simulator stellt hierzu die gleichen
Schnittstellen wie das eigentliche Betriebssystem bereit. Der gleiche Programmcode
kann somit entweder direkt auf echter Hardware ausgeführt werden oder in einem simulierten Umfeld zum Einsatz kommen.[41, 42, 43, 3]
14
In der Variable @WISHLIST des Perl-Skripts make fptrs.pl werden die zu exportierenden Funktionen
gelistet.
15
Die Entwickler des Compilers diese Art der Programmierung leider nicht berücksichtigt. Bei einigen
direkt in den Compiler eingebauten Funktionen wie memset kam es zu Problemen. Um diesen
Fehler im Compiler zu umgehen, wurden eingebaute Funktionen im Compiler deaktiviert und
problematische Funktionen sowohl in der Anwendung als auch in der Firmware implementiert.
46
4.3. Netzwerkarchitektur und Protokolle
Preamble
Sync Länge Ziel Quelle Typ
n*8 Bit
32 Bit
8 Bit
8 Bit
8 Bit
16bit Länge
(optional)
16 Bit
8 Bit
Hardware
Nutzdaten
Länge * 8 Bit
Software
crc-16
16 Bit
Hardware
Abbildung 4.9: Minimaler Aufbau eines Paketes. Das 16 Bit breite Längenfeld wird nur
verwendet, wenn die Paketlänge nicht durch 8 Bit angegeben werden
kann. In diesem Fall wird das reguläre Feld auf 255 gesetzt und die
wirkliche Länge im breiteren Längenfeld gespeichert. Dies reduziert den
Overhead für kleine Pakete und ermöglicht dennoch Pakete mit einer
Länge von bis zu 64 kByte.
4.3 Netzwerkarchitektur und Protokolle
Nachdem nun die Architektur der Software vorgestellt wurde, werden die verwendeten
Protokolle und Möglichkeiten der Datenübertragung zwischen zwei oder mehr Knoten
dargestellt. Es folgt die Beschreibung der grundlegenden Datenübertragung zwischen
zwei Knoten bis hin zur netzweiten Kommunikation. Es werden hierbei immer zuerst die
verwendeten Pakete vorgestellt. Anschließend wird gezeigt, wie diese Pakete verwendet
werden.
4.3.1 Grundlegende Datenübertragung
Die grundlegende Datenübertragung findet immer direkt zwischen zwei (1:1) oder mehr
(1:n) Knoten statt. Es werden keine anderen Knoten verwendet, um Daten weiterzuleiten, wenn zwei Knoten nicht in gegenseitiger Reichweite sind.
Für jedes übertragene Paket ist ein bestimmtes Format vorgegeben, das in Abbildung
4.9 gezeigt ist. Es besteht aus den direkt vom Funkchip erzeugten Feldern (in der Abbildung blau gekennzeichnet), den in jedem Paket immer gleichen und festen Kopfdaten
(in der Abbildung gelb und grün) sowie den eigentlichen Nutzdaten (rot). Die Felder
sind in Reihenfolge ihrer Platzierung:
ˆ Preamble (n*8 Bit): Eine Sequenz von abwechselnd Nullen und Einsen um den
Empfänger auf den Sender zu synchronisieren. Dieses Feld kann beliebig lang sein
und wird direkt vom Funkchip erzeugt.
ˆ Syncword (32 Bit): Ein bestimmtes Bitmuster, welches dem Empfänger anzeigt,
dass die Datenübertragung beginnt.
47
Kapitel 4. Systementwurf
Wake-On-Radio Paket 0x06 Weckgrund
8 Bit
Wake-On-Radio ACK-Paket 0x05 Weckgrund Signalst.
8 Bit
Zielkanal
8 Bit
Generisches ACK-Paket 0x05
8 Bit
Prüfsumme
32 Bit
P
S 1/3/4 Z
Q
Typ
Nutzdaten
crc
Abbildung 4.10: Aufbau der direkt von der Firmware verwendeten Pakete.
ˆ Länge (8 Bit): Bei Paketen bis zu 254 Byte Länge (Nutzdaten + Paketkopf)
wird hier direkt die Länge des Paketes angegeben. Falls das Paket länger sein
sollte, wird der Wert auf 255 gesetzt und die Länge in einem 16 Bit breiten Feld
angegeben.
ˆ Ziel (8 Bit): Bei gerichteter Kommunikation wird hier direkt die Knoten-ID des
Empfängers angegeben. Andere Knoten, die ein Paket empfangen, welches nicht
direkt an sie adressiert ist, können, direkt nachdem sie dieses Byte gelesen haben,
den Empfangsvorgang abbrechen und das Paket verwerfen. Bei an alle Knoten
gerichteten Paketen wird das Feld auf 255 gesetzt.
ˆ Quelle (8 Bit): Enthält die Knoten-ID des Absenders
ˆ Typ (8 Bit): Dieses Feld wird verwendet, um anzuzeigen, welche Art von Nutzdaten im Paket enthalten sind.
ˆ Optionales Längenfeld (16 Bit): Bei langen Paketen wird dieses Feld verwendet,
um die tatsächliche Größe anzugeben. Bei Paketen bis zu 254 Byte Länge ist
dieses Feld nicht vorhanden.
ˆ Nutzdaten (0..64kByte): Dieses Feld enthält die eigentlichen Nutzdaten, die von
Pakettyp zu Pakettyp unterschiedlich sind und im Folgenden noch genauer vorgestellt werden.
ˆ Prüfsumme (16 Bit): Direkt in der Hardware des Funkchips wird eine 16 Bit
Prüfsumme (crc-16) berechnet und beim Senden automatisch an das Paket angefügt. Beim Empfangen wird diese Prüfsumme überprüft. Schlägt der Prüfsummentest fehl, wird das Paket verworfen.
Direkt von der Firmware verwendet werden drei Pakettypen. Hierbei handelt es sich
zum einen um das ACK“-Paket, mit welchem die Empfangsroutine automatisch ein
”
48
4.3. Netzwerkarchitektur und Protokolle
eingegangenes Paket bestätigen kann. Es wird hierbei eine einfache 32Bit Prüfsumme
verwendet, um das bestätigte Paket zu identifizieren. Zum anderen kann ein Knoten
einen anderen Knoten über Funk wecken. Hierzu wird das Wake-on-Radio“-Paket
”
mehrmals in kurzen Abständen geschickt. Im Wake-on-Radio“-Paket wird ein Grund
”
angegeben, warum der andere Knoten geweckt werden soll. Wird eines dieser Pakete
empfangen, wird dieser Empfang mit einem Wake-on-Radio ACK“-Paket bestätigt.
”
Das Wake-on-Radio ACK“-Paket beinhaltet, neben einer Bestätigung des Weckgrun”
des, den Messwert der Signalstärke des Wake-on-Radio“-Paketes sowie den Kanal,
”
auf welchen gewechselt werden soll, um die weitere Kommunikation durchzuführen.
Abbildung 4.10 zeigt den Aufbau dieser drei Pakettypen.
Abbildung 4.11 zeigt, welche Möglichkeiten mit den bisher vorgestellten Pakettypen
umgesetzt werden können:
ˆ Broadcast Kommunikation: Ein Sender, viele Empfänger
ˆ Unicast Kommunikation: Ein Sender, ein Empfänger
ˆ Bestätigte Unicast Kommunikation: Ein Sender, ein Empfänger. Dem Sender wird
der Empfang einer Nachricht bestätigt.
ˆ Wake-on-Radio: Ein Knoten kann einen (oder alle) anderen Knoten aus einem
energiesparendem Schlafzustand wecken, um anschließend beliebige Daten auszutauschen
4.3.2 Protokoll der kabellosen Softwareaktuallisierung
Für die kabellose Softwareaktualisierung wurde ein einfaches Protokoll entworfen, welches sich die Möglichkeiten und Eigenschaften der Broadcast Kommunikation zu Nutze
macht, um viele Knoten gleichzeitig zu aktualisieren.
Da im Voraus nicht bekannt ist, welche Knoten überhaupt das Update empfangen, kann
keine bestätigte Übertragung verwendet werden. Stattdessen werden die Pakete vorsorglich mehrfach verschickt16 . Zusätzlich kommen negative Bestätigungen ( NACK17“)
”
zum Einsatz, die dem Sender anzeigen, dass bei mindestens einem Empfänger Fehler aufgetreten sind. Der Sender kann dann einfach ab der Position, welche ihm im
NACK“-Paket mitgeteilt wurde, die Übertragung wiederholen.
”
Alle Pakete, die für das Softwareupdate verwendet werden, haben den gleichen Typ
(0x04), so dass die Firmware beim Empfang eines solchen Paketes direkt zu den UpdateRoutinen wechseln kann. Innerhalb der Nutzdaten findet eine weitere Aufspaltung statt.
Das Update verläuft in mehreren Phasen, für jede Phase werden die entsprechenden
Pakete verwendet. Die Phasen sind:
16
17
In der aktuellen Implementierung wird jedes Paket 10 mal verschickt.
NACK ist die Abkürzung für not acknowledged (= Ablehnung)
49
Kapitel 4. Systementwurf
Knoten B
Knoten A
Knoten C
Nachricht
Nachricht
Nachricht
a) Broadcast
Nachricht
b) Unicast
Nachricht
c) Unicast
bestätigt
ACK (Nachricht)
d) Wake-onRadio
WoR (C)
WoR (C)
ACK (WoR)
Broadcast
Empfangsbereit
inaktiv („Idle“)
Unicast
Sender aktiv
irrelevant
Abbildung 4.11: Darstellung, der von der Firmware angebotenen Möglichkeiten, der
Paketübertragung: a) Broadcast an alle Empfänger im Empfangsbereich. b) Unicast an einen bestimmten Empfänger. c) Unicast an einen
bestimmten Empfänger mit Empfangsbestätigung. d) Weckvorgang
eines Knotens via Wake-on-Radio“.
”
50
4.3. Netzwerkarchitektur und Protokolle
Finish
FINISH ID Flags
0x05
0x05
crc32 Anw.
0xFF
8 Bit
Nack
NACK ID
0x04
0x04
32 Bit
NACK-Position
0xFF
32 Bit
Data
DATA ID
0x03
Setup
0x03
Daten Position
Daten
32 Bit
1..512 Byte
0xFF
SETUP ID Flags
0x02
0x02
Gesamtlänge
crc32 Anw.
crc32 Firmware
32 Bit
32 Bit
32 Bit
0xFF
8 Bit
Prepare
PREP ID
0x01
0x01
Timesync (µS)
0xFF
24 Bit
32 Bit
P
S
L 0xFF Q 0x04
L16
Nutzdaten
crc
Abbildung 4.12: Aufbau der für das kabellose Softwareupdate verwendeten Pakete.
1. Phase: Vorbereitung ( Prepare“-Pakete):
”
Zeitsynchronisation der Knoten mit einer Genauigkeit im Microsekunden Bereich.
Eine gemeinsame Zeitbasis wird für das spätere Protokoll benötigt.
2. Phase: Konfiguration ( Setup“-Pakete):
”
Mitteilung der Länge der zu übertragenden Software sowie die Prüfsumme der
zu übertragenden Software (damit Knoten, welche bereits die aktuelle Software
empfangen haben, diese nicht erneut empfangen müssen) und die Prüfsumme der
Firmware (um sicherzustellen, dass die Firmware kompatibel zur neuen Software
ist).
3. Phase: Datenübertragung ( Data“-Pakete und Nack“-Pakete):
”
”
Übermittlung der neuen Software in mehreren Teilstücken. Übertragungsfehler
können durch NACK“-Pakete angezeigt werden.
”
4. Phase: Abschluss ( Finish“-Pakete):
”
Abschließende Überprüfung, ob die Übertragung fehlerfrei war
Abbildung 4.13 zeigt einen theoretischen Durchlauf des Softwareupdates mit einem
sendenden ( Masterknoten“) und zwei empfangenden Knoten ( Slaveknoten“). In der
”
”
Darstellung sind mehrere Vereinfachungen getroffen, um sie übersichtlich zu halten. So
51
Kapitel 4. Systementwurf
Zeit
Empfänger A
Sender
Empfänger B
Wake
-10
-5
Prepare
0
Setup
A
Data (0..2)
10
15
Data (3..5)
20
25
B
NACK (3)
ACK
Data (4..6)
30
35
Data (13..15)
100
105
110
Finish
115
NACK (0)
120
Data (0..2)
125
E
C
F
Finish
210
215
D
G
220
Abbildung 4.13: Ablauf der Softwareaktualisierung über Funk. Die blau hinterlegten
Punkte entsprechen den, im Text beschriebenen, Situationen. Um die
Grafik übersichtlich zu halten, sind nur zwei Empfänger angegeben – es
könnten jedoch Hunderte sein! Ebenfalls werden nicht alle möglichen
Fehlersituationen, mit denen das Protokoll umgehen kann, gezeigt.
52
4.3. Netzwerkarchitektur und Protokolle
werden die mehrfach übertragenen Pakete nur als eine logische“ Übertragung darge”
stellt. Außerdem wird mit jedem Data“-Paket nur je ein Byte übertragen – in der
”
Wirklichkeit sind es je 512 Byte. Da die Daten per Broadcast verteilt werden, ist die
Anzahl der Knoten nach oben theoretisch unbeschränkt. Es sind mehrere Marken (blaue
Punkte) in der Grafik eingefügt, auf welche in der folgenden Beschreibung des Ablaufs
näher eingegangen wird. Die Marken werden im folgenden Text durch X gekennzeichnet.
Zunächst werden alle Knoten im Empfangsbereich geweckt. Hierbei kommt der Wake”
on-Radio“ Mechanismus zum Einsatz. Als Weckgrund wird Softwareupdate“ ange”
geben, so dass der empfangende Knoten direkt in den Update-Modus wechseln kann.
Anschließend folgt die Prepare-Phase, in welcher die Uhren aller Knoten gleichzeitig auf Null gesetzt werden A . Ab diesem Punkt ticken die Uhren aller Empfänger
und des Senders synchron. Nach dieser Synchronisation beginnt die Setup-Phase. Den
Empfängern der Software wird mitgeteilt, wie lang diese ist und wie Ihre Prüfsumme
ist. Diese Prüfsumme wird verwendet, um zu überprüfen, ob die Software nicht bereits
aktuell ist. Sollte die Software bereits aktuell sein, nimmt der Knoten nicht weiter am
Update teil und wird daher auch keine (unnötigen) NACK“-Pakete verschicken. Dies
”
ermöglicht es, das Update von mehreren Positionen im Einsatzgebiet hintereinander
auszuführen, um eventuelle Distanzprobleme zu umgehen. Das Setup“-Paket enthält
”
ebenfalls die Prüfsumme der aktuellen Firmware. Die Überprüfung auf die aktuelle
Firmware muss erfolgen, da die Anwendung Pointer enthält, welche auf Funktionen in
der Firmware verweisen. Sollten diese Pointer nicht stimmen, so wäre das Verhalten
des Knotens nicht mehr definiert.
Nachdem die Setup-Phase abgeschlossen ist, beginnt die Datenübertragung. Hierbei
wird die Zeit aufgeteilt in eine Master Periode“ und eine Slave Periode“. Beide Pe”
”
rioden sind jeweils fünf Sekunden lang. Während der Master Periode“ verschickt der
”
Knoten, von welchem das Update ausgeht, Datenpakete. Nachdem die fünf Sekunden
um sind18 , beginnt die Slave Periode“. Sollte einer der Empfänger ein Problem festge”
stellt haben, so hat er nun während dieser Periode die Möglichkeit, ein NACK“-Paket
”
an den Sender zu schicken. Das NACK“-Paket enthält die letzte einwandfrei empfan”
gene Position. Der Empfang des NACK“-Paketes wird bestätigt B . In der nächsten
”
Master Periode“ wird der Sender dann die Daten ab der niedrigsten gemeldeten Po”
sition verschicken.
Nachdem alle Daten übertragen wurden, wird den empfangenden Knoten über das
Finish“-Paket noch einmal die Prüfsumme der neuen Anwendung mitgeteilt. Diese
”
können dann überprüfen, ob die Übertragung erfolgreich war. Wenn die Übertragung
erfolgreich war, zieht sich der Knoten zurück und wird sich nach einer gewissen Zeit
neu starten und somit die neue Software zur Ausführung bringen C . Sollte es zu
Übertragungsfehlern gekommen sein, so schickt der Knoten, der ein Problem festgestellt
hat, ein NACK“-Paket, welches als Position den Wert 0 führt D . Der Masterknoten
”
18
In der Tat werden nur vier der fünf Sekunden zur Datenübertragung genutzt um Probleme mit
eventuell abdriftenden Uhren im Voraus zu vermeiden
53
Kapitel 4. Systementwurf
Nachbarschafts Information 0x0E DR
SL
8 Bit
8 Bit
Bake 0x0F res. Bat.
8 Bit
8 Bit
P
S
5/8
Z
Q
Typ
Seq. Nr.
16 Bit
max. Datenrate
Bat. DR:
SL: min. Sendeleistung
8 Bit
Seq. Nr.
Systemzeit
16 Bit
32 Bit
Nutzdaten
crc
Abbildung 4.14: Aufbau der Pakete, die zum Erstellen der Nachbarschaftsbeziehungen
verwendet werden.
wird daraufhin die Übertragung ab dem Start wiederholen. E Verläuft dieser Durchlauf
fehlerfrei F , so wird kein NACK“-Paket verschickt und auch der Masterknoten nach
”
einer Weile neu gestartet werden G .
Die für die Übertragung benötigte Zeit lässt sich einfach abschätzen. Unter der Annahme, dass keine Übertragungswiederholung nötig ist, besteht sie aus einem konstanten
Anteil (Weckvorgang, Zeitsynchronisierung, Initialisierung, Abschluss) sowie einem von
der Datenmenge DUpdate abhängigem Anteil.
Die Robustheit der Übertragung kann durch die Variation der Anzahl n der pro Übertragungseinheit wiederholt gesendeten Pakete beeinflusst werden. In der aktuellen
Implementierung werden die Pakete jeweils 10 mal verschickt. Um den empfangenden
Knoten genügend Zeit zu geben, die Daten in den Flashspeicher zu kopieren, wird
jeweils 100ms gewartet, bevor neue Daten geschickt werden.
TÜbertragung
DUpdate ∗ n + DDelay
= TWake + TSync + TInit +
∗ TIntervall + TFinish
Datenrate ∗ 4s
DDelay = (100ms ∗ Datenrate) ∗
DUpdate
≈ 6 ∗ DUpdate
DNachricht
"
TÜbertragung
#
DUpdate ∗ (10 + 6)
∗ 10s + 10s
≈ 5s + 7s + 5s +
250000 Bit
∗ 4s
s
Die Übertragung eines 55000 Byte großen Softwareupdates würde somit in etwa 27s +
7 ∗ 10s = 107s benötigen.
4.3.3 Nachbarschaftsbeziehung
Da – im Gegensatz zum Softwareupdate – bei der weiteren Kommunikation immer eine
gerichtete und bestätigte Datenübertragung stattfindet, ist es für die Knoten wichtig
54
4.3. Netzwerkarchitektur und Protokolle
zu wissen, welche Nachbarn in Funkreichweite liegen. Hierfür werden von allen Knoten
in zufälligen Abständen Baken“-Pakete per Broadcast verschickt. Die Bake enthält
”
Informationen über die aktuelle Sequenznummer des Knotens, den Ladezustand der
Batterie und der Systemzeit. Mit diesen Informationen kann bei einem bereits bekannten Nachbarn eine Aktualisierung der Routingtabelle erfolgen. Zusätzlich dient die Bake
der Zeitsynchronisation. Hierfür wird vor dem Aussenden der Bake gewartet, bis die
Hardware Echtzeituhr einen Sekundenumbruch anzeigt. Die empfangene Systemzeit
wird mit der eigenen Systemzeit verglichen. Ist die Zeit in der Bake bereits gleich weit
oder weiter fortgeschritten, wird die Zeit aus der Bake übernommen. Die Systemzeit
breitet sich mit dieser Vorgehensweise nach und nach, rund um den Knoten mit der
bisher am weitesten fortgeschrittenen Zeit, im gesamten Netz aus. Abbildung 4.14 zeigt
den Aufbau der verwendeten Pakete.
Wird eine Bake von einem bisher unbekannten Knoten empfangen, folgt der Aufbau
einer beidseitigen Nachbarschaftsbeziehung.
Der Aufbau der Nachbarschafsbeziehung erfolgt in drei Phasen:
1. Phase: Wecken
Wecken des neuen Nachbarn und gemeinsamer Wechsel auf einen anderen Übertragungskanal
2. Phase: Nachbarschafts Information senden
Bestätigte Übertragung eines Nachbarschafts Information“-Paketes an den neu”
en Nachbarn
3. Phase: Nachbarschafts Information empfangen
Empfang des Nachbarschafts Information“-Paketes des neuen Nachbarn
”
Nach diesen drei Schritten wechseln die Knoten wieder zurück auf den Signalisierungskanal. Durch den Austausch der Nachbarschafs Informations“-Pakete wird sicherge”
stellt, dass sich beide Knoten gegenseitig empfangen können. Gleichzeitig einigen sich
die Knoten auf eine für zukünftige Datenübertragungen zu verwendende Datenrate und
Sendeleistung. Diese ist jedoch nicht fest, sondern wird kontinuierlich angepasst und
daher vor jeder Datenübertragung noch einmal abgeglichen.
4.3.4 Signalisierung und Routenmanagement
Der nächste Schritt zur netzweiten Datenübertragung ist zunächst einmal der eigentliche Aufbau des Netzes und dem Finden und Verwalten von Pfaden durch dieses Netz.
55
Kapitel 4. Systementwurf
Als Grundlage für den Entwurf des hierzu nötigen Protokolls wurde das AODV-Protokoll (AdHoc On Demand Distance-Vector)[37] verwendet.19 Da dieses Protokoll jedoch
nicht alle gewünschten Anforderungen erfüllen kann, wurde es um die Möglichkeit,
mehrere Pfade zu einem einzigen Ziel behandeln zu können erweitert. Hierzu waren
einige tiefgehende Änderungen notwendig. Dennoch wird vor der Beschreibung des in
dieser Arbeit entworfenen Protokolls AODV kurz vorgestellt.
Herkömmliche Distance-Vector Protokolle
Die Grundlegende Idee von Distance-Vector Protokollen ist es, dass jeder Knoten eine
eigene Routingtabelle führt und Routingentscheidungen lokal trifft. In der Tabelle ist
unter Anderem eingetragen, welcher Knoten als nächstes zu wählen ist, um einen Weg
zum gewünschten Ziel zu finden und mit welchen Kosten dieser Weg verbunden ist.
Bei herkömmlichen Distance-Vector Protokollen ist beispielsweise die Entfernung zum
Ziel das Entscheidungskriterium, nach welchem ein Pfad ausgewählt wird. Die Tabellen
mit allen bekannten Zielen werden hierbei in regelmäßigen Abständen an alle anderen
Knoten geschickt, damit diese wiederum entscheiden können, ob sie den entsprechenden
Knoten bei der Wahl eines Pfades zu einem Ziel verwenden können. Nach einiger Zeit
etabliert sich auf jedem Knoten im Netz eine Tabelle mit (ggf. mehreren) möglichen
Pfaden zu allen Zielen im Netz. Es werden hierbei jedoch immer alle Pfade zu allen
Knoten aufgebaut, was bei Änderungen im Netz eine nicht unerhebliche Menge an
Signalisierungsverkehr verursacht. In RFC 1058[44] wird das Routingprotokoll RIP“
”
im Detail beschrieben. Hierbei handelt es sich um ein im Internet eingesetztes DistanceVector Routingprotokoll.
Oftmals ist es nicht für jeden Knoten notwendig, alle Pfade zu allen Zielen zu kennen. Insbesondere für Systemen mit geringen Ressourcen (was typischerweise für alle
Sensornetze zutrifft) bedeutet diese Vielzahl an Informationen und der nötige Signalisierungsverkehr eine hohe Belastung. Ein herkömmliches Distance-Vector Protokoll ist
somit für ein Sensornetz eher ungeeignet.
Das AdHoc on Demand Distance-Vector Protokoll
Das AODV-Protokoll wurde dafür entworfen, um in einem mobilen Netz eine Route
zu einem Zielknoten zu finden, wenn sie benötigt wird. Es eignet sich daher besser für
ein Sensornetz, da nicht immer alle Pfade aufgebaut werden – wenn sie nicht benötigt
werden. Über dies hinaus berücksichtigt das Protokoll, dass im Voraus nicht bekannt
ist, welche Knoten verwendet werden können. Routen werden von einem Knoten über
Route-Request (RREQ)“-Pakete von allen seinen Nachbarn angefordert. Ein Knoten,
”
der ein solches RREQ“-Paket empfängt, leitet das RREQ“ (ebenfalls an alle seine
”
”
19
Zusätzlichen Einfluss hatten The Pulse Protocol“[38] und das Directed Diffusion“ Protokoll[39]
”
”
für kabellose Sensornetze.
56
4.3. Netzwerkarchitektur und Protokolle
Nachbarn) solange weiter, bis es das Ziel oder einen Knoten, der bereits einen Pfad
zum Ziel hat, erreicht. Von diesem Knoten (bzw. dem Ziel) aus wird dann über ein
Route-Reply (RREP)“-Paket direkt per Unicast auf dem besten Weg zum Ursprung
”
des RREQ“-Paketes zurück, der Pfad durch das Netz etabliert. Jeder Knoten merkt
”
sich jeweils nur einen Pfad zum Ziel. Eine Sequenznummer im RREP“-Paket wird
”
verwendet um anzuzeigen, wie aktuell“ der Pfad ist. Hat ein Knoten bereits einen
”
aktuelleren Pfad, verwirft er das RREP“-Paket.[37]
”
Dadurch, dass das gesamte Netz mit dem RREQ“-Paket geflutet wird (bzw. nicht das
”
gesamte, da über einen TTL20 -Wert vorgegeben wird, wie viele Schritte das RREQ“”
Paket weiter gesendet werden soll), wird, sofern es einen Pfad zum Ziel gibt, dieser auf
jeden Fall gefunden. Als positiv zu bewerten ist hierbei, dass nach dem anfänglichen
Fluten des Netzes nur noch wenig Signalisierungsverkehr anfällt. Durch die Verwendung
der Sequenznummer kann sichergestellt werden, dass keine Schleifen entstehen. Nicht
mehr fehlerfrei funktionierende Routen können über Fehler-Pakete ( RERR“) anderen
”
Knoten mitgeteilt werden. Da nur wirklich benötigte Routen aufgebaut werden, kann
die Verwaltung auch auf Systemen mit beschränkten Ressourcen effektiv durchgeführt
werden. Insbesondere für Szenarien, bei denen es eine zentrale Datensenke gibt, würde
sich das AODV-Protokoll für ein Sensornetz gut eignen.
Entwurf des Routingprotokolls dieser Arbeit
Wie in der Einführung bereits geschrieben, basiert das in dieser Arbeit entworfene
Routingprotokoll auf AODV. Es wurde jedoch etwas erweitert und verändert, um dem
Einsatz in einem Sensornetz besser zu entsprechen.
Da immer mit dem Ausfall von Knoten gerechnet werden muss, ist es vorteilhaft, mehrere Routen zu einem Ziel bereitstehen zu haben, für den Fall, dass die eigentlich
präferierte Route nicht mehr verfügbar ist. Das Vorhandensein von mehreren Routen zum Ziel erlaubt es überdies, verschiedene Kostenfunktionen zur Wahl des jeweils
nächsten Schrittes anzubieten. In dieser Arbeit angeboten werden Kostenfunktionen,
die entweder Routen mit möglichst hoher Bandbreite, niedriger Latenz oder mit einer
guten Energieeffizienz auswählen. Nach wie vor liegt die Entscheidung über den jeweils
nächsten Schritt bei jedem Knoten für sich. Dieser Schritt wird, unter Verwendung
einer der Kostenfunktionen, aus der Routingtabelle gewählt.
Der Aufbau, der zum Einsatz kommenden Pakete ( RREQ“, RREP“ und RERR“),
”
”
”
ist in Abbildung 4.15 dargestellt. Es handelt sich hierbei um die gleichen Pakettypen,
die auch vom AODV Protokoll verwendet werden. Ihr Inhalt wurde jedoch erweitert,
um die Anforderungen an das neue Protokoll erfüllen zu können.
Der Aufbau und die Verarbeitung von Route-Request (RREQ)“-Paketen wurde na”
hezu unverändert aus dem AODV Protokoll übernommen. Sollte ein Knoten RREQ“”
20
Time-to-live: verhindert, dass Pakete endlos lange von Knoten zu Knoten weitergeleitet werden,
indem der Wert bei jeder Weiterleitung decrementiert wird
57
Kapitel 4. Systementwurf
DR: max. mögliche Datenrate
SL: min. nötige Sendeleistung
Route Error Paket 0x12 Knotenliste
(RERR)
n*8 Bit
Route Reply Paket 0x11 Ziel Hops Seq. Start Seq. Flags
(RREP)
8 Bit
16 Bit
DR
8 Bit
16 Bit
32 Bit
(minimal)
(local)
(local)
(local)
8 Bit
8 Bit
32 Bit
16 Bit
SL Bat. Bat. Zeit Seq. kompl. Pfad
4 Bit
4 Bit
(local)
(local)
n*8 Bit
(local)
Route Request Paket 0x10 Ziel TTL Seq. Start Flags Bat. Seq. Zeit
(RREQ)
8 Bit
8 Bit
16 Bit
8 Bit
32 Bit
8 Bit
16 Bit
32 Bit
P
S
L
Z
Q
Typ
Nutzdaten
crc
Abbildung 4.15: Aufbau der für das Verwalten von Routen verwendeten Pakete
( RREQ“, RREP“ und RERR“).
”
”
”
Pakete von zwei oder mehr verschiedenen Knoten zum gleichen Ziel bekommen, so
werden diese Routing-Anfragen zwar in der Routingtabelle gespeichert, das RREQ“”
Paket wird jedoch nur ein einziges Mal weitergeleitet. In Verbindung mit dem TTL-Feld
dämmt diese Vorgehensweise das Fluten des Netzes durch RREQ“-Pakete ein.
”
Die Route-Reply (RREP)“-Pakete wurden um verschiedene Felder erweitert, welche
”
für die Berechnung der Kostenfunktionen notwendig sind. Dies ist die maximal auf dem
gesamten Pfad mögliche Datenrate21 , die hierzu minimal benötigte Sendeleistung22 sowie die geringste Batteriespannung auf dem Pfad. Da bei mehreren gleichzeitig zugelassenen Pfaden zu einem Ziel die Sequenznummer alleine nicht mehr ausreicht, um
Schleifen zu erkennen, wird der komplette Pfad bis zum Ziel mitgeschickt. Sollte ein
Knoten ein RREP“-Paket erhalten und sich selbst in diesem Pfad wiederfinden so
”
wird das Paket verworfen.
RREP“ und RREQ“ enthalten zusätzliche Informationen über den Zustand des Kno”
”
tens, der diese verschickt hat. Die Informationen dienen dazu, die entsprechenden Einträge in der Routingtablle des Empfängers zu aktuallisieren.
Das Route-Error (RERR)“-Paket wurde in der Form erweitert, dass es eine gesamte
”
Liste von Knoten enthalten kann, welche ab sofort über den Absender des Paketes nicht
mehr zu erreichen sind.
Die Abbildungen 4.16, 4.17 und 4.18 zeigen, wie ein Knoten, der ein RREQ“-, RREP“”
”
oder RERR“-Paket empfängt dieses verarbeitet. Abbildung 4.20 zeigt exemplarisch,
”
wie eine Route durch ein (kleines) Netz gefunden wird.
21
22
Also die Datenrate des niedrigsten Teilstücks
Das Teilstück, welches die höchste Sendeleistung benötigt, bestimmt diesen Wert
58
4.3. Netzwerkarchitektur und Protokolle
Behandlung eines eingehenden Route-Request“-Paketes
”
Empfängt ein Knoten ein Route-Request“-Paket von einem anderen Knoten, so über”
prüft er zunächst, ob nicht genau dieses Route-Reqeust bereits vorliegt. Diese Überprüfung dient im Wesentlichen der Begrenzung der Anzahl der später gefundenen Routen. Es werden also nicht immer alle möglichen Pfade gefunden und verfolgt. Anschließend wird überprüft, ob der Knoten nicht selbst das Ziel der Anfrage ist. Es kann zwar
eigentlich nicht vorkommen, dass der Knoten selbst das Ziel ist, die korrekte Antwort
ist in diesem Fall jedoch das Aussenden eines Route-Reply“-Paketes.
”
Wenn das Paket durch diese beiden Tests gekommen ist, folgt die wichtigste Fallunterscheidung: Befindet sich bereits ein Eintrag in meiner Routingtabelle, der zum gleichen
Ziel führt? Falls nein, wird die neue Anfrage in der Routingtabelle gespeichert und zur
weiteren Verarbeitung an alle anderen Nachbarn weitergeleitet.
Falls sich bereits Einträge in der Routingtabelle befinden, so werden diese alle nacheinander darauf untersucht, ob sie geeignet sind, die Anfrage zu beantworten (bestehende
Route zum Ziel bzw. Nachbarknoten). In diesem Fall wird ein Route-Reply an den
anfragenden Knoten verschickt. Andernfalls wird weiter unterschieden, ob es sich beim
Ursprungsknoten der bereits vorhandenen Anfrage um den gleichen Knoten handelt,
wie in der aktuellen Anfrage. Falls ja, wird der Eintrag aktualisiert, falls nein, wird ein
neuer Eintrag angelegt. In beiden Fällen wird überprüft, ob die Reichweite (TTL) der
neuen Anfrage größer ist, als die der bereits vorhandenen. Falls ja, wird das RouteRequest an alle anderen Nachbarn weitergeleitet.
Behandlung eines eingehenden Route-Reply“-Paketes
”
Beim Empfang eines Route-Reply“-Paketes erfolgen zunächst einige Kontrollen, die
”
dazu führen könnten, dass das Paket verworfen werden muss ( Bin ich Ziel dieses
”
Route-Replys?“, Enthält der Pfad eine Schleife?“, Wurde genau dieses Route-Reply
”
”
bereits verarbeitet?“). Wurde das Paket nicht verworfen, so wird die neue Route in die
Routingdatenbank übernommen. Anschließend wird überprüft, ob der Knoten noch
offene Routing Anfragen von anderen Knoten zu dem neuen Ziel vorliegen hat. Falls
ja, so wird jede dieser offenen Anfragen mit einem Route-Reply“-Paket beantwortet
”
und das Timeout dieser offenen Anfrage reduziert. Die Anfrage wird nicht direkt aus
der Datenbank gelöscht, da für den Fall, dass weitere Route-Reply“-Pakete zu dieser
”
Anfrage eingehen, diese ebenfalls (für eine gewisse Zeit) beantwortet werden können.
Dieser Mechanismus dient wieder dazu, zwar mehrere verschiedene Pfade zum Ziel
durch das Netz zu finden, jedoch nicht zwangsweise alle.
Behandlung eines eingehenden Route-Error“-Paketes
”
Route-Error“-Pakete werden verwendet, wenn ein Knoten selbst feststellt, dass er
”
keine Verbindung mehr zu einem Ziel hat, zu welchem er zuvor noch eine Verbindung
59
Kapitel 4. Systementwurf
Abbildung 4.16: Behandlung eines eingehenden Route-Request“-Paketes
”
Liegt genau dieses Route-Request bereits vor?
(Ziel, seq. Nr)
nein
ja
Bin ich das Ziel?
Paket verwerfen
nein
ja
Habe ich eine Route zum Ziel oder bereits
ein anderes Route-Request zum Ziel?
nein
Route-Reply verschicken
ja
Route-Request an alle anderen
Nachbarn weiterleiten!
Ausführen für alle Einträge in der
Routingtabelle zum Ziel
Ist das Ziel mein Nachbar
oder habe ich eine bestehende Route zum Ziel?
nein
ja
Handelt es sich um einen
anderen Ursprungsknoten?
Route-Reply verschicken
nein
ja
Eintrag in Routingtabelle aktualisieren.
Neuen Request-Eintrag in Routingtabelle.
Request TTL größer als bisher?
ja
Route-Request an alle anderen
Nachbarn weiterleiten!
60
4.3. Netzwerkarchitektur und Protokolle
Abbildung 4.17: Behandlung eines eingehenden Route-Reply“-Paketes
”
Bin ich das Ziel dieses Route-Replys?
nein
ja
Enthält der Pfad eine Schleife?
nein
Paket verwerfen
ja
Wurde genau dieses Route-Reply bereits
verarbeitet?
nein
Paket verwerfen
ja
Neue Route in Routingtabelle übernehmen
Paket verwerfen
Hatten wir überhaupt (mind.) ein aktives
Route-Request zu diesem Ziel?
nein
ja
Ausführen für alle offenen
Route-Requests zum Ziel
keine weitere Aktion
Route-Reply weiterleiten
Timeout des Request-Eintrag in Routingtabelle
auf MULTI_ROUTE_TIMEOUT setzen
61
Kapitel 4. Systementwurf
hatte. Da durch den Verlust eines Nachbarn ggf. viele Knoten auf einmal nicht mehr
erreicht werden können, wird im Fehlerpaket eine ganze Liste von Knoten angegeben,
die ab sofort nicht mehr erreichbar sind.
Empfängt ein anderer Knoten ein solches Paket, so markiert er zunächst einmal alle
Routen, welche den Absender des Paketes als nächsten Hop haben, als ungültig, sofern
sie einen der als unerreichbar markierten Knoten als Ziel haben oder deren Pfad einen
solchen Knoten beinhaltet. Sollte der Knoten nach dieser Kennzeichnung ebenfalls bestimmte Ziele nicht mehr erreichen können (also keine Alternativrouten vorliegen),
verschickt er ebenfalls Route-Error“-Pakete an seine Nachbarn.
”
4.3.5 Netzweite Datenübertragung
Mit Hilfe der durch den Routingalgorithmus gefundenen Pfade durch das Netz, kann
nun auch ein netzweiter Austausch von Daten erfolgen. Bevor Daten zu einem Zielknoten übertragen werden, muss zunächst eine Route zu diesem gefunden werden. Die Daten werden anschließend an den, auf dem Pfad zum Ziel, nächsten Knoten übertragen.
Dieser behandelt die so empfangenen Daten dann genauso, bis die Daten beim Zielknoten ankommen. Es findet eine so genannte Store and Forward“ Nachrichtenweiterlei”
tung statt. Der absendende Knoten kann im Voraus nicht wissen, welchen Weg durch
das Netz die Daten nehmen werden, er kann jedoch wählen, aufgrund welcher Kostenfunktion (Latenz, Bandbreite oder Netzenergie) der jeweils nächste Schritt gewählt
wird.
Fehlerbehandlung
Die Nachrichten werden für eine gewisse Zeit bei allen auf dem Pfad liegenden Knoten
gespeichert. Sollte es sich herausstellen, dass ein Knoten eine Nachricht nicht zustellen kann, so meldet er diesen Fehler mit einer kurzen Fehlermeldung auf dem bisher
zurückgelegten Pfad zurück. Da jeder Knoten auf dem Pfad die Nachricht noch in seinem Speicher abgelegt hat, muss die Nachricht nicht erneut übertragen werden. Sobald
einer der Knoten auf dem Pfad eine alternative Route zum Ziel hat, wird diese eingeschlagen. Der nicht erfolgreiche Zweig wird als ungültig markiert – falls nötig kommt
es hierbei auch zum Versand von Route-Error“-Paketen durch das Routingprotokoll.
”
Um dieses Zurückwandern auf dem Pfad zu ermöglichen, wird in jeder Nachricht der
bisher zurückgelegte Pfad protokolliert. Hierdurch wird zusätzlich verhindert, dass sich
die Nachricht auf einem Kreis durch das Netz bewegt. Zusätzlich wird angegeben, wie
viele Schritte die Nachricht höchstens gehen soll, bis sie verworfen wird.
62
4.3. Netzwerkarchitektur und Protokolle
Abbildung 4.18: Behandlung eines von Knoten A“ eingehenden Route-Error“”
”
Paketes.
Ausführen für alle nicht mehr über
Knoten X erreichbaren Knoten Y
Route zu oder über Knoten Y via X
in Routingtabelle als ungültig markieren
Habe ich eine weitere Route mit gleichem
Ziel über einen anderen Knoten?
nein
ja
Fehlerflag auf true setzen
weiter...
Fehlerflag gesetzt?
nein
keine weitere Aktion
ja
Route-Error Paket mit einer Liste aller nicht mehr
über mich erreichbaren Knoten an alle meine
Nachbarn verschicken
63
Kapitel 4. Systementwurf
Ursprung, Ziel
A
G, [DFG], A
Nachbarschaft
B
A, G
Route Request
Route Reply
Ziel, Pfad, Ursprung
C
Routingtabelle
A)
B:
C:
D:
G:
D
Route Error
E
X
[XYZ]
B
C
D
-?-
F
Knoten mit ID X
Hindernis
G
.....
Nicht mehr erreichbare Knoten
Inhalt der Nachricht
Abbildung 4.19: Legende der Signalisierung und Routenmanagement Grafik
a)
b)
A, G
A
B
A, G
A)
B:
C:
D:
G:
B
C
D
-?-
A, G
C
D
F
c)
A)
B:
C:
D:
G:
G:
E
A
B
C
D
d)
A)
B:
C:
D:
G:
G:
G:
G:
E
G, [FG], A
F
B
C
D
-?DG
G
A, G
A
B
C
D
E
A, G
A, G
G
G, [EG], A
B
C
D
-?DG
A)
B:
C:
D:
G:
G:
G, [DG], A
F
G
G, [BEG], A
B
C
D
-?DG
BEG
CFG
A
B
C
D
E
G, [CFG], A
F
G
Abbildung 4.20: Suchen und Finden einer Route im Netz: Knoten A fordert eine Route
zum Knoten G an. Es sind hierbei die logischen Schritte dargestellt
und nicht unbedingt die zeitlich exakte Abfolge. Im grauen Kasten ist
die Routingtabelle von Knoten A im jeweiligen Schritt gezeigt.
64
4.3. Netzwerkarchitektur und Protokolle
Prio RS
4 Bit
4 Bit
Länge
Typ
Flags
Quelle
Ziel
16 Bit
4 Bit
9 Bit
8 Bit
8 Bit
Daten 0x15
Länge
Seq. Nr. TTL
16 Bit
Nachrichtenkopf
n/a
0 Bit
0 Bit
P
0..32 Byte
0..512 Byte
Data Finish 0x16 n/a
0 Bit
8 Bit
Nachricht
0 / 16 Bit
Data Setup 0x14 n/a
Pfad
DR
SL
Systemzeit
8 Bit
8 Bit
32 Bit
S
L
Z
Q
Typ
L16
Nutzdaten
crc
DR: Datenrate
SL: Sendeleistung
RS: Routen Style
Abbildung 4.21: Aufbau der zum Nachrichtenaustausch verwendeten Pakete. (DATASETUP, DATA und DATAFINISH)
Ablauf des Nachrichtenaustauschs
Abbildung 4.21 zeigt die beim Austausch von Nachrichten zwischen zwei benachbarten
Knoten zum Einsatz kommenden Pakete. Abbildung 4.22 zeigt, wie dieser Nachrichtenaustausch in mehreren Phasen abläuft:
1. Phase: Partner wecken
Mit Hilfe des direkt von der Firmware angebotenen Wake-on-Radio“-Mechanis”
mus wird der Partner, zu dem Daten übertragen werden sollen geweckt.
2. Phase: Übertragungsparameter aushandeln
Nachdem der Partner geweckt wurde, wechseln beide Knoten auf einen anderen
Kanal, um dort die eigentliche Datenübertragung durchzuführen. Zuvor einigen
sie sich jedoch noch auf eine gemeinsame Datenrate ( Data Setup“-Pakete) und
”
konfigurieren ihre Funkchips entsprechend.
3. Phase: Nachrichtenaustausch von A nach B
Es folgt die gebündelte Übertragung aller Nachrichten in der Warteschlange, deren Ziel ebenfalls über den geweckten Knoten erreicht werden kann ( Data“”
Pakete) . Nachdem alle Nachrichten übertragen wurden, wird abschließend ein
Data Finish“-Paket gesendet.
”
65
Kapitel 4. Systementwurf
Knoten A
Knoten B
WoR
Phase 1:
Partner wecken
ACK
DATA SETUP
Phase 2:
Übertragungskanal wechseln
und Übertragungsparameter
aushandeln
ACK
DATA SETUP
ACK
Phase 3a:
Übertragung „Hinrichtung“
DATA
ACK
*) es sind hier nur zwei Nachrichten
dargestellt. Es könnten jedoch
dutzende sein!
DATA*
ACK
DATA FINISH
ACK
Phase 3b:
Abschluss „Hinrichtung“
DATA*
Phase 4a:
Übertragung „Rückrichtung“
ACK
*) nur, wenn überhaupt Nachrichten
zur Übertragung auf dem Rückweg
ausstehen!
DATA*
ACK
DATA FINISH
Phase 4b:
Abschluss „Rückrichtung“
ACK
Abbildung 4.22: Ablauf des Nachrichtenaustauschs zwischen zwei benachbarten
Knoten. Dargestellt ist nur der logische Ablauf, ggf. nötige
Übertragungswiederholungen sind nicht gezeigt!
66
4.3. Netzwerkarchitektur und Protokolle
4. Phase: Nachrichtenaustausch von B nach A
Die 4. Phase entspricht der 3. Phase, mit dem Unterschied, dass nun Knoten B alle
Nachrichten seiner Warteschlange an A überträgt, deren Pfad über A verläuft.
Liegt keine solche Nachricht vor, sendet Knoten B nur ein Data Finish“-Paket,
”
um die Übertragung zu beenden.
Nach der Übertragung der Daten wechseln beide Knoten wieder auf den Signalisierungskanal. Empfangene Nachrichten werden ggf. verarbeitet.
Die gebündelte Übertragung aller ausstehenden Nachrichten über den gleichen Partner
dient der Erhöhung der Energieeffizienz des Sensornetzes. Der Partner muss nur ein
einziges Mal geweckt werden, um gleich eine ganze Menge von Daten zu übertragen.
Insbesondere bei Netzen, bei denen es nur eine zentrale Datensenke gibt, wirkt sich
diese Bündelung aus.
Sofern einer der beiden Knoten Nachrichten empfangen hat, die nicht an ihn adressiert waren, wird er diese entsprechend seiner Routingtabelle weiterleiten. Liegt keine Route zum Ziel vor, so wird zunächst versucht, eine Route zum Ziel zu finden.
Glückt dies innerhalb einer vorgegebenen Zeitspanne nicht, so wird die Nachricht als
unzustellbar gekennzeichnet und dem Knoten, von welchem die Nachricht empfangen
wurde, eine kurze Fehlermeldung zugeschickt. Dieser kann dann – sofern er noch über
eine alternative Route verfügt – die Nachricht auf einem anderen Weg zum Ziel erneut verschicken. Liegt keine alternative Route vor, so wird die Fehlermeldung entlang
des bisher zurückgelegten Pfades in Richtung Quelle weitergeleitet. Über die Angabe einer maximalen Anzahl von solchen Schritten kann angegeben werden, ab wann
eine Nachricht endgültig verworfen werden soll. In Abbildung 4.23 ist diese MultihopNachrichtenweiterleitung in einem kleinen Netz beispielhaft dargestellt.
67
Kapitel 4. Systementwurf
a)
A
C
B
G
D
d)
A
A
h)
G
A
E
B
G
D
i)
C
G
D
A
A
E
E
C
E
B
G
D
G
F
B
f)
B
D
C
D
A
A
C
E
C
E
B
G
D
G
c)
F
B
e)
B
g)
A
C
E
C
D
A
b)
F
E
C
B
G
D
E
Fehlermeldung
möglicher Pfad
Nachricht
verwendeter Pfad
F
ausfallender Knoten
Datensenke
G
„normaler“ Knoten
Datenquelle
G
erfolgloser Pfad
Abbildung 4.23: Übermittlung einer Nachricht von Knoten A zu Knoten G: In Teilbild c) fällt ein auf dem Pfad liegender Knoten aus. Die Nachricht
in Teilbild d) kann daher nicht zugestellt werden. In Teilbild e) wird
nur eine kurze Fehlermeldung auf dem Pfad zurückgeschickt, nicht
jedoch die gesamte Nachricht. Da Knoten B einen alternativen Pfad
kennt, wählt er diesen, ansonsten wäre die Fehlermeldung einen weiteren Schritt auf dem Pfad zurückgeschickt worden. Teilbild i) Zeigt
den verwendeten Pfad, der auch in der Nachricht vermerkt ist. Knoten B merkt sich, dass die Route über C fehlerhaft ist und würde bei
folgenden Nachrichten direkt den Weg über D wählen.
68
5 Implementierung und
Testumgebung
Nachdem der Entwurf und die Architektur des Systems vorgestellt wurde, wird nun
gezeigt, wie dieser Entwurf umgesetzt und getestet wurde. Daran anschließend werden
verschiedene Testergebnisse vorgestellt und diskutiert.
5.1 Implementierung
Aufgrund der Größe der Codebasis (über 22000 Zeilen C-Code sowie mehrere Tausend Zeilen Java) ist es nicht möglich, jedes Detail vorzustellen. Stattdessen werden –
nach einer Gesamtübersicht – einige Punkte der Implementierung herausgegriffen und
stellvertretend vorgestellt. Auf eine Beschreibung der Implementierung der Java-GUI
wird verzichtet, da diese nahezu unverändert aus der Studienarbeit Entwurf und Im”
plementierung der Infrastruktur für den FPGA-basierten Sensorknoten Hyperion“[19]
übernommen wurde.
5.1.1 Übersicht
In Abbildung 5.1 ist die Verzeichnisstruktur der Implementierung dargestellt. Sie teilt
sich im Wesentlichen in drei Punkte auf: In den Unterordnern jars, gnu und ces ist der
Java-Code abgelegt, der für die GUI notwendig ist. Im Unterordner firmware ist der
gesamte Quellcode der Firmware sowie das Skript zum Erzeugen der Funktionspointertabellen abgelegt. Im Unterordner app sind die diversen Testanwendungen sowie die
Hauptanwendung abegelegt.
Bedeutung der Unterordner der Firmware
watchdog Verfügbarkeit des Systems bei Fehlern wiederherstellen
Im Unterordner watchdog sind all die Funktionen untergebracht, welche zur Initialisierung und Verwendung des Watchdogs des Microcontrollers notwendig sind.
69
Kapitel 5. Implementierung und Testumgebung
/
app
jars
simple
gnu
getopt
Java-GUI
monitor
io
scanner
rf_test
ces
power_test
terminal
logtool
firmware
entladekurve
watchdog
dauerbake
lowpower
Hauptanwendung
cc1100
syslog.c
sensornode
flash
display
audio
adc
serial
rtc
aus „boop“-Firmware übernommen bzw. angepasst
interrupt
lcdlog.c
channel_rater.c
rate_nachbar.c
route.c
route_data.c
bitmap.c
fptrs.c
main.c
Abbildung 5.1: Übersicht über das Verzeichnis der implementierten Software. Mit Ausnahme der Hauptanwendung sind nur die Unterordner und nicht die
Dateien gezeigt.
70
5.1. Implementierung
Um zu verhindern, dass der Sensorknoten durch die Hardware automatisch neu
gestartet wird, muss regelmäßig die Funktion feedWatchdog aufgerufen werden1 .
lowpower Beeinflussung der Energieaufnahme
Alle vom Microcontroller angebotenen Möglichkeiten zur Reduzierung der Leistungsaufnahme, können durch die Funktionen im Unterordner lowpower direkt
verwendet werden. Der Energiebedarf der externen (analogen) Beschaltung des
Microcontrollers wird durch die Wahl einer geschickten Belegung der I/O-Pins minimiert. Sollte die Anwendung einmal mehr Rechenleistung benötigen, so stehen
Funktionen zur Verfügung, um ggf. die Taktfrequenz des Prozessors zu erhöhen
und danach wieder zu senken.
cc1100 Ansteuerung des Funkchips
Funktionen um den Funkchip zu konfigurieren und Pakete zu senden bzw. zu
empfangen, sind im Unterordner cc1100 abgelegt. Die Ansteuerung des Funkchips
wird später noch im Detail vorgestellt.
sensornode Software Deployment und Callback“-Interface
”
Im Unterordner sensornode befinden sich sowohl die Funktionen des Software
Deployments, als auch das Callback“-Interface. Das Protokoll, welches zur ka”
bellosen Softwareaktualisierung verwendet wird, ist hier implementiert. Im Unterkapitel 5.1.4 wird diese Implementierung vorgestellt.
interrupt Konfiguration der Interrupts
Der Code für die Konfiguration der Interrupts wurde aus der boop“-Firmware
”
übernommen. Es stehen Funktionen zur Verfügung, um Interrupts global ein bzw.
aus zu schalten. Zusätzlich können einzelne Interruptquellen des Interruptcontrollers des Prozessors aktiviert bzw. deaktiviert werden.
flash Flashbaustein schreiben/löschen
Um den Flashspeicher beschreiben bzw. löschen zu können, ist es notwendig, diesem bestimmte Signale zukommen zu lassen. Die Funktionen in diesem Unterordner, die ebenfalls aus der boop“-Firmware übernommen wurden, kümmern sich
”
um diese Signale und bieten es an, komplette Blöcke oder einzelne Wörter in das
Flash zu schreiben und Sektoren zu löschen. Da die Flashbausteine am Speicherinterface des Prozessors angeschlossen sind, können Lesezugriffe ohne besondere
Vorkehrungen direkt erfolgen.
display Text- und Zeichenfunktionen für das LCD
Umfangreiche Funktionen, um einfache Grafiken und Text auf dem Display auszugeben, befinden sich im Unterordner display. Die Funktionen entstammen der
1
Aktuell ist der Watchdog so eingestellt, dass dies mindestens ein mal pro Minute erfolgen muss.
Ansonsten wird der Knoten zurückgesetzt und neu gestartet.
71
Kapitel 5. Implementierung und Testumgebung
boop“-Firmware. Unterstützt wird das Zeichnen von Linien, Rechtecken, Kreisen
”
und natürlich einzelnen Bildpunkten. Es stehen mehrere Schriftarten in verschiedenen Größen zur Auswahl. Ausgegeben werden können einzelnen Buchstaben
oder komplette Zeichenketten.
audio PWM Audio-Erzeugung
Die ursprünglich in der boop“-Firmware vorhande Möglichkeit, Audio-Samples
”
auszugeben, wurden vollständig entfernt. Stattdessen liegen nun Funktionen vor,
welche einfache Signaltöne mit wählbarer Frequenz und Dauer ausgeben. Da die
Signale direkt vom PWM Controller erzeugt werden, ist es ebenfalls möglich, die
Ausgabe im Hintergrund erfolgen zu lassen. Die Anwendung muss bzw. sollte2
sich jedoch darum kümmern, die Ausgabe nach einiger Zeit wieder zu beenden.
adc Analog/Digital-Wandler
Wie bei der Audioausgabe wurden die umfangreichen Funktionen der boop“”
Firmware gegen eine sehr einfache Funktion ausgetauscht. Sie liefert lediglich
den Messwert der Akkuspannung durch den Analog/Digital-Wandler zurück.
serial Serielle Schnittstelle
In der ursprünglichen boop“-Firmware wurden nicht die üblichen Ausgabefunk”
tionen wie puts oder printf verwendet, sondern stattdessen im Unterordner
serial diverse Funktionen zur Ausgabe auf der seriellen Schnittstelle implementiert. Diese werden nicht weiter verwendet, übernommen wurden jedoch, nach
kleineren Anpassungen, die Funktionen zur Konfiguration der seriellen Schnittstelle des Microcontrollers. Um die Funktionen der newlib“ zur Ausgabe ver”
wenden zu können, mussten eigene Syscalls implementiert werden, die die Einbzw. Ausgabe direkt auf der Hardware ausführen. Diese Syscalls werden von den
Funktionen der newlib“ zur Ausgabe verwendet.
”
rtc Echtzeituhr
Um die Möglichkeit, die Systemzeit in Sekunden verwalten zu können erweitert, wurden die Funktionen der boop-Firmware zur Ansteuerung der Echtzeituhr
übernommen. Hierbei werden die Werte der aktuellen Sekunde, Minute und Stunde einfach aufaddiert3 , um den Wert der Systemzeit in Sekunden verwenden zu
können. Die Systemzeit ist also maximal einen Tag lang verwendbar, was jedoch
im Rahmen der durchgeführten Tests vollkommen ausreichend ist. Für längere
Testdurchläufe wäre es problemlos möglich, auch den aktuellen Tag bzw. Monat
zur Berechnung der Zeit hinzuzufügen.
2
Es steht ein 1 Watt Leistungsverstärker für die Tonausgabe zur Verfügung. Die Signaltöne sind
daher gut wahrnehmbar, benötigen jedoch dementsprechend viel Energie.
3
Systemzeit = Sekunden + 60 ∗ (Minuten + 60 ∗ Stunden)
72
5.1. Implementierung
Testanwendungen im Unterordner app
simple Einfache Minimalanwendung
Die Anwendung enthält alle Funktionen, die mindestens notwendig sind, um Programmcode zu erzeugen, welcher zusammen mit der Firmware ausgeführt werden
kann. Sie war der Startpunkt für den Entwurf der austauschbaren Anwendungen
und entspricht dem typischen hello world“-Programm.
”
monitor Überwachung des Singalisierungskanals
Das monitor-Programm empfängt kontinuierlich die auf dem Signalisierungskanal
übertragenen Pakete und zeigt dann auf dem LCD Informationen über das aktuell
empfangene Paket an. Ein kurzes Blinken der Hintergrundbeleuchtung signalisiert
den Empfang eines Pakets. Zusammen mit dem Programm dauerbake wurde so
die Abstrahlcharakteristik der Antennen gemessen (siehe Kapitel 3.3.3).
scanner Überwachung des gesamten Frequenzbereichs
Bei der Entwicklung der Grundlagen der dynamischen Kanal-Bewertung entstand
dieses Programm, das die zur Verfügung stehenden Übertragungskanale in schneller Folge abtastet und den gemessenen Signalpegel in Form eines Balkens pro Kanal auf dem LCD darstellt. Längerfristige Störungen können so erkannt werden
und die dynamische Vermeidung von gestörten Kanälen gut visualisiert werden
(siehe Abbildung 4.4).
rf test Testumgebung für die Funktionen des Funkchips
Um die von der Firmware angebotenen Möglichkeiten zur Konfiguration des Funkchips zu testen und neue Funktionen zu entwickeln, steht die rf test-Anwendung
zur Verfügung. Alle Funktionen können über eine einfache Kommandozeile aufgerufen und verwendet werden.
power test Messung des Energiebedarfs
Um den Energiebedarf der Plattform unter bestimmten Bedingungen messen zu
können, wurde die power test-Anwendung geschrieben. Die verschiedenen Situationen können so jederzeit künstlich hervorgerufen und reproduzierbar gemessen
werden.
logtool Entwicklungsumgebung für das Systemlog
Das logtool dient zum Auslesen bzw. Schreiben des Systemlogs. Im Unterordner
sind zusätzlich diverse Perl-Skripte enthalten, die die Ausgabe des Systemlog in
CSV-Dateien4 umwandeln.
4
Comma-Separated Values. Diese Dateien können dann z.B. zur Erzeugung von Diagrammen verwendet werden.
73
Kapitel 5. Implementierung und Testumgebung
11000
Software Update
Ansteuerung Funkchip
Hardwareabstraktion, ...
Nachrichtenübermittlung
Routing
Verwaltung, ...
10000
Zeilen Programmcode
9000
8000
7000
6000
5000
4000
3000
2000
1000
0
Firmware
Hauptanwendung
übrige Anwendungen
Abbildung 5.2: Verteilung der über 22000 Zeilen Programmcode auf Firmware, Hauptanwendung und die übrigen Anwendungen.
entladekurve Anfertigen der Entladekurven
Die entladekurve Anwendung ist eine Kombination der power test- und der
logtool-Anwendung und dient dem Anfertigen von Entladekurven. Hierzu wird
das System in einen bestimmten Zustand versetzt und regelmäßig der Ladezustand des Akkus in das Systemlog geschrieben.
dauerbake Permanentes Aussenden eines Pakets
Zum Bestimmen der Reichweite der Sensorknoten sowie dem Ausmessen der Abstrahlcharakteristik dient diese Anwendung. Sie besteht im Wesentlichen aus einer
Endlosschleifen, in welcher ein kurzes Datenpaket verschickt wird (siehe Kapitel
3.3.3).
In Abbildung 5.2 ist dargestellt, welchen Anteil an Zeilen Programmcode die Komponenten Firmware“, Hauptanwendung“ und die Test-Anwendungen“ haben. Bei der
”
”
”
Firmware sind die beiden Teilkomponenten zur Ansteuerung des Funkchips“ und zur
”
Durchführung des Software-Updates“ gesondert hervorgehoben. Bei der Hauptanwen”
dung die Teilkomponenten Routing“ und Nachrichtenübermittlung“.
”
”
Es folgt nun eine detaillierte Vorstellung einiger ausgewählter Punkte der Implementierung.
74
5.1. Implementierung
Abbildung 5.3: Verschiedene Zugriffsarten auf die Register des Funkchips[36]
5.1.2 Ansteuerung des Funkchips
Der Funkchip wird über SPI5 an den Microcontroller angebunden. Auf der Seite des
Microcontrollers wird das SPI durch den SSP6 -Controller in Hardware realisiert. Die
Datenrate über den SPI-Bus zum Funkchip kann bis zu 10Mbps betragen und ist somit
deutlich schneller als die eigentliche Datenübertragung auf dem Funkweg.
Der Funkchip wird über diverse Konfigurationsregister für den gewünschten Betriebsmodus eingestellt. Der Zugriff auf die Register erfolgt, indem zunächst die Adresse und
anschließend die Daten über den SPI-Bus übertragen werden. Die komplette Konfiguration kann in einem Burst“ ohne Adressierung der einzelnen Register erfolgen. Befehle
”
(wie z.B. Beginn der Funkübertragung, Reset, ...) werden über bestimmte Adressen
mit so genannten Strobes“ übermittelt. Für die zu sendenden bzw. zu empfangenen
”
Daten stehen je ein 64 Byte großer FIFO7 Buffer zur Verfügung. Die verschiedenen
Zugriffsarten auf die Register sind in Abbildung 5.3 dargestellt.
Die genaue Beschreibung der Bedeutung der einzelnen Register ist im Datenblatt des
Funkchips gut beschrieben[36]. Damit bei der Entwicklung von Anwendungen für den
Sensorknoten solche Details nicht berücksichtigt werden müssen, wurde eine Reihe von
Funktionen geschrieben, die sich darum kümmern, den Funkchip so zu konfigurieren,
wie es gewünscht ist. Hierzu ist dann nur ein einzelner Funktionsaufruf notwendig, der
umfangreiche Zugriff auf die Register des Funkchips kann entfallen – Wissen über die
nötigen Registerwerte ist nicht notwendig.
Neben vielen anderen Funktionen zählt hierzu insbesondere:
ˆ Funkchip initialisieren (cc1100_init(void))
ˆ Sendeleistung einstellen (cc1100_SetPower(unsigned char power))
ˆ Übertragungskanal wählen (cc1100_SetChannel(unsigned char channel))
5
Serial Peripheral Interface
Synchronous Serial Port
7
First In First Out: Elemente werden in genau der Reihenfolge abgerufen, in der sie zuvor abgelegt
wurden.
6
75
Kapitel 5. Implementierung und Testumgebung
ˆ Datenratenprofil wählen (cc1100_WriteProfile(unsigned char ProfileNr))
ˆ Pakete verschicken (SendPacket(unsigned char adr, unsigned char typ,
int length, unsigned char* daten))
ˆ Pakete empfangen (ReceivePacket(int pkt_timeout, int max_length,
unsigned char* daten, packet_stat_t* stat))
Die Funktion, mit welcher das Datenratenprofil“ gewählt werden kann, verwendet hier”
bei gleich einen ganzen Satz verschiedener Register, um eine zur gewünschten Datenrate passende Modulation und Filtereinstellungen einzustellen. Diese und die Funktionen
zum Senden bzw. Empfangen von Paketen wurden mit einigen Veränderungen und
Anpassungen aus der Studienarbeit Entwurf und Implementierung der Infrastruktur
”
für den FPGA-basierten Sensorknoten Hyperion“[19] übernommen. Sie wurden dort
bereits im Detail beschrieben.
5.1.3 Automatische Codeerzeugung für Anwendungsaustausch
In Abbildung 4.8 wurde bereits der Ablauf gezeigt, welcher notwendig ist, um eine
auf der Firmware ausführbare Anwendung zu erzeugen. Hierbei wird aus der fertig
übersetzten Firmware, zusammen mit den Headerfiles der Firmware und der newlib“,
”
neuer Programmcode erzeugt, welcher dann zusammen mit dem Code der Anwendung
compiliert wird. Es wird nun das Skript, das den neuen Programmcode erzeugt, vorgestellt.
Es handelt sich hierbei um das Perl-Skript make fptrs.pl, welches direkt im Ordner
der Firmware abgelegt ist. Beim Aufruf des Makefiles wird es automatisch aufgerufen,
nachdem die Firmware neu übersetzt wurde.
Am Anfang des Skripts sind einige Konfigurationsmöglichkeiten gegeben. Wichtig sind
hierbei:
@INC PATH: Das Array @INC PATH enthält eine Liste von Pfaden, in welchen nach Headerfiles gesucht werden soll. Wichtig ist hierbei sowohl das Verzeichnis .“ 8 als
”
auch das Verzeichnis, in welchem die Headerfiles der C-Bibliothek abgelegt sind.
Wenn weitere Bibliotheken verwendet werden, so müssten deren Pfade ebenfalls
in diesem Array eingetragen werden.
7
8
@INC_PATH=(".","/opt/armtool/4.1.1/arm-elf/include");
.“ ist das aktuelle Arbeitsverzeichnis. Da das Skript im Ordner der Firmware abgelegt ist, befinden
”
sich also hier die Headerfiles der Firmware.
76
5.1. Implementierung
@WISHLIST: Im Array @WISHLIST werden all die Funktionen angegeben, welche in der
Firmware enthalten sind und in der Anwendung genutzt werden sollen. Für das
Skript und die spätere Anwendung macht es keinen Unterschied, ob die Funktion
direkt in der Firmware implementiert ist oder aus der C-Bibliothek entnommen
wird. Wichtig ist hierbei nur, dass die Funktion im Speicherabbild der Firmware
enthalten ist. Dies ist in der Regel der Fall, sobald die Funktion von der Firmware selbst einmal verwendet wurde. Die Signatur9 der Funktionen muss nicht
mit angegeben werden, diese wird vollautomatisch aus den Headerfiles extrahiert.
9
@WISHLIST=("feedWatchdog", "printf", "ReceivePacket", "SendPacket");
@VARLIST: Ähnlich, wie im Array @WISHLIST zu exportierende Funktionen angegeben
werden, werden im Array @VARLIST Variablen aufgelistet, die später global zur
Verfügung stehen sollen. Im Unterschied zur Funktionsliste muss die Signatur der
Variablen jedoch mit angegeben werden.
25
@VARLIST =("unsigned char TxBuffer[]", ..., "unsigned int SysTime");
Das Skript verwendet den Befehl nm“ der GNU Development Tools, um eine Liste der
”
Symbole der Firmware ausgeben zu lassen. Diese Liste besteht aus allen in der Firmware
verwendeten Funktionen und globalen Variablen. Ausgegeben wird das Tripel (Adresse,
Typ, Name). Beispiel:
~/workspace/betty/firmware> nm boop_rom.elf
[...]
8000595c T cc1100_SetChannel
80005568 T cc1100_SetPacketLength
80005574 T cc1100_SetPacketMode
800054b0 T cc1100_SetPower
[...]
Der Typ T“ gibt an, dass es sich hierbei um eine Funktion handelt, welche im Textseg”
ment abgelegt ist. Dies trifft auf alle Funktionen zu, welche exportiert werden sollen.
Für jeden Eintrag des Typs T“ in der Tabelle wird überprüft, ob der Name im Array
”
@WISHLIST enthalten ist:
9
Eine Signatur definiert die formale Schnittstelle einer Funktion. Sie besteht aus dem Namen der
Funktion, der Anzahl, Reihenfolge und Typen ihrer Parameter und dem Typ des oder der Funktionsrückgabewerte.
77
Kapitel 5. Implementierung und Testumgebung
123
124
@map = split("\n",‘nm $ELF_FILE‘);
for ($i=@map; $i>0; $i--) {
125
if ($map[$i] =~ /^(.*) T (.*)/) { # Symbol ist Funktion im Textsegment
$adr=$1; $name=$2;
126
127
128
if (grep (/^$name$/, @WISHLIST)) { # Funktion soll exportiert werden
129
130
# Funktionssignatur suchen
131
132
}
133
}
134
135
}
In diesem Fall sind bereits die Adresse der Funktion und der Funktionsname bekannt.
Es fehlt die Funktionssignatur, welche jedoch aus den Headerfiles extrahiert werden
kann. Hierfür setzt das Skript die GNU Werkzeuge find“ und grep“ ein, um in den
”
”
im Array @INC PATH angegebenen Pfaden zunächst rekursiv alle Headerfiles zu suchen
und anschließend in diesen Headerfiles nach dem Namen der Funktion zu suchen:
137
138
139
while ($x<@INC_PATH && not $found) {
$shell="for file in ‘find ".$INC_PATH[$x]." -iname \"*.h\"‘; do grep $name
\$file; done;";
@fundstellen = split("\n",‘$shell‘);
140
# untersuchen, ob etwas von dem Gefundenem auf das passt, was wir gerne
hätten..
141
142
$x++;
143
144
}
Die Ausgabe des Shellbefehls sieht beispielsweise aus wie folgt:
~/workspace/betty/firmware> for file in ‘find . -iname "*.h"‘; do
grep cc1100_SetChannel $file; done;
void cc1100_SetChannel(BYTE channel);
Jeder zurückgegebene Treffer wird zunächst mit Hilfe von regulären Ausdrücken so bereinigt, dass er der Form Typ Name (Signatur)“ entspricht. Ein einfacher regulärer
”
Ausdruck zerlegt dieses Ergebnis in die Variablen $f typ, $f name und $f sig. Der
dann so gefundene Name wird mit dem gesuchten Namen verglichen. Falls beide übereinstimmen, stehen alle Informationen zur Verfügung, die nötig sind, um den gewünsch-
78
5.1. Implementierung
ten Funktionspointer zu erstellen:
142
143
144
145
146
147
foreach(@fundstellen) {
# cleanup.. libc
$_ =~ s/(.*?)(\s*)(\*)?_EXFUN\((.*?)(\s*?),(\s*?)(.*?)\)/$1$3 $4$7/g;
$_ =~ s/_PTR/void*/g;
$_ =~ s/extern(\s*)//g;
$_ =~ s/\(_VOID\)/\(void\)/g;
148
# typ name (sig)
$_ =~ /(unsigned |)(.*?)(\s+)(.*?)(\s*)\((.*?)\)/;
$f_typ=$1.$2;
$f_name=$4;
$f_sig=$6;
149
150
151
152
153
154
if ($f_name eq $name) {
$sig=$f_sig;
$typ=$f_typ;
$found="true";
last; # foreach-Schleife beenden
}
155
156
157
158
159
160
161
}
Hierzu wird für jede Funktion zunächst ein neuer Pointertyp definiert. Jeder neue Typ
bekommt den Namen AUTOGEN fptr, zusammen mit einer durchlaufenden Nummer.
Dieser neue Typ wird zusammen mit einem externen Funktionspointer dieses Typs in
die neue Headderdatei geschrieben. In der neuen C-Datei wird dem Funktionspointer
dann die Adresse der Funktion zugewiesen:
172
173
174
175
176
$genid++;
print H_DATEI "typedef $typ(*_AUTOGEN_fptr_$genid)($sig);\n";
print H_DATEI "extern _AUTOGEN_fptr_$genid const $name;\n\n";
print C_DATEI
"_AUTOGEN_fptr_$genid const $name=(_AUTOGEN_fptr_$genid)0x$adr;\n";
Das Bereitstellen der globalen Variablen erfolgt ähnlich. Wieder wird der Befehl nm“
”
verwendet, um eine Liste der Symbole zu bekommen. Interessant sind diesmal jedoch
die Symbole des Typs B“. Dies sind die im BSS Segment, also dem Bereich der uninitia”
lisierten Daten, abgelegten globalen Variablen. Um die Variablen in den Anwendungen
normal“ nutzen zu können, reicht es nicht aus, einen Pointer auf die Variable bereit zu
”
stellen. Stattdessen wird mittels #define erwirkt, dass der C-Präprozessor die Variablennamen durch direkte Speicherzugriffe austauscht. Hierbei wird unterschieden, ob
es sich um ein Array oder einen Skalar handelt und entsprechender Code generiert:
79
Kapitel 5. Implementierung und Testumgebung
233
234
235
236
237
if ($array) { # bei der Variable handelt es sich bereits um einen Pointer
print H_DATEI "#define $name ((($typ*) 0x$adr))\n";
} else {
print H_DATEI "#define $name (*(($typ*) 0x$adr))\n";
}
Beispielcode
An kurzen Stücken des (automatisch generiertem) Quellcodes soll die Funktionsweise
demonstriert werden. Listing 5.1 zeigt einen Ausschnitt aus der Datei fptrs.h, in welcher die aus den Funktionssignaturen automatisch definierten Pointer erzeugt wurden.
Listing 5.3 zeigt den entsprechenden Ausschnitt aus der Datei fptrs.c, in der den
Pointern die Werte zugewiesen werden. Listing 5.4 zeigt, wie diese Funktionspointer
dann in einer Anwendung beispielsweise eingesetzt werden könnten. Es ist kein Unterschied zu einem Aufruf der Funktionen in einem normalen Programm zu erkennen!
112
113
typedef int(*_AUTOGEN_fptr_29)(void);
extern _AUTOGEN_fptr_29 const rand;
114
115
116
typedef int(*_AUTOGEN_fptr_30)(const char *);
extern _AUTOGEN_fptr_30 const puts;
117
118
119
typedef int(*_AUTOGEN_fptr_31)(const char *, ...);
extern _AUTOGEN_fptr_31 const printf;
Listing 5.1: Automatisch erzeugte Funktionspointer in der Datei fptrs.h
270
271
272
#define packet_stat (*((packet_stat_t *) 0x40002144))
#define TxBuffer (((unsigned char *) 0x40001d44))
#define SysTime (*((unsigned int *) 0x40001610))
Listing 5.2: Globale Variablen in der Datei fptrs.h
76
77
78
_AUTOGEN_fptr_29 const rand=(_AUTOGEN_fptr_29)0x80009d2c;
_AUTOGEN_fptr_30 const puts=(_AUTOGEN_fptr_30)0x80009cfc;
_AUTOGEN_fptr_31 const printf=(_AUTOGEN_fptr_31)0x80009c1c;
Listing 5.3: Automatisch erzeugte Funktionspointer in der Datei fptrs.c
1
#include "fptrs.h" // stdio.h wird *nicht* eingebunden!
2
3
4
sprintf(TxBuffer,"String!");
printf("Hallo Welt. Zufallszahl: %d. String: %s\n",rand(), TxBuffer);
Listing 5.4: Beispielcode einer Anwendung
80
5.1. Implementierung
5.1.4 Software-Update Protokoll
Der genaue Ablauf der Datenübertragung während des Softwareupdates wurde bereits
in Unterkapitel 4.3.2 beschrieben. Dieser Ablauf wird hier nicht wiederholt. Stattdessen
werden einige Detaillösungen anhand von Auszügen aus dem Quellcode, bzw. diesem
entsprechenden Darstellungen, vorgestellt.
Sowohl der Programmcode des Protokolls des Senders als auch der Empfänger ist in
der Datei soft update.c im Unterordner sensornode der Firmware implementiert.
Initiale Zeitsynchronisierung
Die Zeitsynchronisierung zu Beginn des Softwareupdates ist für das spätere Protokoll
wichtig, da die zur Verfügung stehende Zeit aufgeteilt wird in eine Hälfte, in welcher
der Masterknoten aktiv ist und eine Hälfte, in der die Slaveknoten ggf. aktiv werden
dürfen. In Listing 5.5 ist der Code gezeigt, welcher vom Master verwendet wird, um
die Zeitsynchronisierung durchzuführen. Listing 5.6 zeigt entsprechend, wie ein solches
Paket ausgewertet wird, nachdem es empfangen wurde.
Die Vorgehensweise ist hierbei prinzipiell einfach gehalten. Der Sender schickt über
einen gewissen Zeitraum hinweg durchgängig Softwareupdate/Prepare“-Pakete. Diese
”
enthalten einen Countdown (in Mikrosekunden), welcher den Zeitpunkt der Synchronisation anzeigt. Empfängt ein Knoten ein solches Paket, wechselt er in den Softwareupdate-Modus und wartet dann genau die angegebene Zeit in Mikrosekunden. Anschließend setzt er seine Systemzeit auf Null. Das Paket dient neben der Zeitsynchronisation
noch dazu, allen Knoten in Empfangsreichweite anzuzeigen, dass ein Softwareupdate
durchgeführt werden soll. Der Countdown ist daher mit 7 Sekunden deutlich länger
gewählt, als es für eine reine Zeitsynchronisation notwendig wäre.
1
timer_stopwatch_start(); /* Setzt den Hardware-Timer zurück und konfiguriert
ihn so, dass er jede Mikrosekunde inkrementiert wird */
2
3
int SyncIn=7000000; /* 7 Sekunden Vorlaufzeit. Die Pakete dienen nicht nur
der Zeitsynchronisierung, sondern auch dazu, alle Knoten in
Empfangsreichweite in den Softwareupdate-Modus zu versetzen */
4
5
while(SyncIn>20000) { /* Da der Knoten eine gewisse Zeit benötigen, das
Paket zu senden macht es keinen Sinn, bis 0 herunter zu zählen! */
6
7
SyncIn=7000000-T0TC; /* T0TC ist direkt das Register des Hardware-Timers
und enthält die ab dem Aufruf von timer_stopwatch_start(); vergangene
Zeit in Mikrosekunden */
8
9
10
TxBuffer[6]=(SyncIn&0xFF000000)>>24; // den 32 Bit Wert auf
TxBuffer[7]=(SyncIn&0x00FF0000)>>16; // vier Bytes aufteilen
81
Kapitel 5. Implementierung und Testumgebung
11
12
TxBuffer[8]=(SyncIn&0x0000FF00)>>8;
TxBuffer[9]=(SyncIn&0x000000FF);
13
14
SendPacket(ALL_NODES, TYP_UPDATE , 10, TxBuffer);
15
16
17
18
19
20
feedWatchdog(); /* Verhindern, dass der Watchdog den Knoten neu startet */
}
while(T0TC<7000000); /* Warten, bis T0TC genau 7000000 ist */
setSysTime(0);
/* Systemzeit auf 0 setzen. Dies erfolgt bei allen Knoten
in Reichweite synchron! */
timer_stopwatch_stop();
Listing 5.5: Zeitsynchronisierung des Softwareupdates (Master)
1
timer_stopwatch_start(); /* Mit diesem Paket wird die Zeit synchronisiert.
Wir messen daher die Zeit, welche benötigt wird, um das Paket bis zur
Synchronisierung zu verarbeiten. Insbesondere die Ausgabe auf dem Display
benötigt einige Millisekunden! */
2
3
4
5
6
7
setBacklight(true); lcd_enable(true); lcd_fill(0);
set_font(BOLDDOUBLEFONT);
draw_string(0, 48, "SW UPDATE!", 3, DRAW_PUT);
draw_string(0, 88, "(prepare)", 3, DRAW_PUT);
update_host = packet_stat.FromNode;
8
9
10
11
12
13
puts("-I- \"PREPARE\" Paket bekommen. Stelle Funkchip um auf MAX_POWER bei
250kbps");
puts("-I- Synchronisiere Uhr!");
int SyncIn= (RxBuffer[6]<<24) + (RxBuffer[7]<<16) + (RxBuffer[8]<<8) +
RxBuffer[9]-timer_stopwatch_stop();
sleep(SyncIn); /* Schläft die angegebene Zeit in Mikrosekunden */
setSysTime(0); /* Systemzeit auf 0 setzen. */
Listing 5.6: Zeitsynchronisierung des Softwareupdates (Slave)
Implementierung des Protokolls
Das Übertragungsprotokoll, das unmittelbar nach der Zeitsynchronisierung durchlaufen
wird, ist in zwei Hauptschleifen – je eine für den Sender und eine für die Empfänger –
implementiert. Die beiden Schleifen sind in Abbildung 5.5 dargestellt. Beide Schleifen
enthalten einen entscheidenden Punkt, an welchem überprüft wird, ob zum aktuellen
Zeitpunkt der Sender oder die Empfänger aktiv sein dürfen. In den mit breiterem
Rahmen dargestellten Abschnitten erfolgt die eigentliche Abwicklung des Protokolls.
82
5.1. Implementierung
a)
b)
c)
Abbildung 5.4: Bildschirmfotos
Durchlaufs
d)
während
eines
e)
erfolgreichen
f)
Softwareupdate-
Sender
Empfänger
(Zeit mod 10) < 4 ?
Paket verarbeiten
nein
ja
(Zeit mod 10) < 6 ?
Empfange NACK
Pakete
ggf. NACK
verarbeiten
nein
ggf. NACK
versenden
Daten Senden
ja
Paket empfangen
nein
ja
Abbildung 5.5: Hauptschleifen der Implementierung des Protokolls für den Sender und
die Empfänger
83
Kapitel 5. Implementierung und Testumgebung
Hauptschleife des Senders
In der Hauptschleife des Senders wird zunächst überprüft, ob der Sender überhaupt Daten übertragen darf. Hierzu wird die Systemzeit modulo 10 zur Entscheidung verwendet. Liegt der Wert in der ersten Hälfte (0 bis 3), so darf
der Sender Daten verschicken. Liegt der Wert darüber (4 bis 9), so lauscht der
Sender, ob einer der Empfänger Probleme bei der Übertragung hat und daher
NACK-Pakete verschickt. Hierbei liegt eine gewisse Asymmetrie vor: Die Sendezeit beträgt vier Sekunden, die Empfangszeit sechs Sekunden. Diese Sekunde
Puffer“ dient dazu, dass auf keinen Fall ein Datenpaket von einem NACK-Paket
”
gestört werden kann. Sollte der Sender mindestens ein NACK-Paket empfangen
haben, so wird dieses vor der Übertragung von neuen Daten berücksichtigt und
die Übertragungsposition entsprechend angepasst.
Hauptschleife der Empfänger
Beim Empfänger erfolgt zunächst die Bearbeitung des eingegangenen Paketes,
bevor auch hier anhand der Systemzeit unterschieden wird, wie weiter verfahren
wird. Liegt der Wert der Systemzeit modulo 10 im Bereich zwischen 6 und 9,
so darf der Knoten ggf. NACK-Pakete verschicken. Andernfalls (im Bereich zwischen 0 und 5) lauscht der Knoten nach einem neuen Paket. Geht innerhalb eines
gewissen Zeitfensters ein solches ein, so wird es verarbeitet, andernfalls beginnt
er – in Abhängigkeit der Systemzeit – von Neuem zu lauschen. Auch hier liegt
wieder eine Asymmetrie vor (4 Sekunden mögliche Zeit zum Senden, 6 Sekunden
lang wird empfangen), um eine Störung von Datenpaketen durch NACK-Pakete
zu verhindern.
In Abbildung 5.6 ist der Zustandsautomat gezeigt, der die Behandlung der eingehenden
Nachrichten anhand des Protokolls steuert. Abbildung 5.4 zeigt einige Bildschirmfotos,
welche einen erfolgreichen Durchlauf des Softwareupdates bei einem der Empfänger
dokumentieren.
5.1.5 Routenauswahl und -bewertung
Wie Routen durch das Netz gefunden werden können, wurde im Entwurfskapitel 4.3.4
bereits relativ nah an der wirklichen Implementierung beschrieben. Es wird nun hier
im Detail vorgestellt, wie die Auswahl der gefundenen Routen aus der Routingtabelle
heraus durchgeführt wird.
Der Entsprechende Code hierzu ist in der Hauptanwendung in der Datei route.c in
der Funktion doGetRoute implementiert. Die Funktion bewertet alle in der Tabelle eingetragenen Routen zum gewünschten Ziel anhand einer auswählbaren Kostenfunktion
und gibt die Route mit der besten Bewertung zurück. Es können Knoten angegeben
werden, die auf gar keinen Fall auf der Route liegen dürfen bzw. nicht der nächste
Knoten auf dem Pfad sein dürfen. Dieses Blacklisting“ von Knoten ist notwendig, um
”
84
5.1. Implementierung
Prepare
Start
Prepare
Erwarte Setup
Setup
CRC Check
CRC okay
eingehende
Nachricht
Finish
Finalzustand
Daten
CRC Fehler
Data, Setup
Erfolg
Zustand
Fehlschlag
Startzustand
Abbildung 5.6: Zustandsautomat des Empfängers für die Behandlung eingehender Pakete des Softwareupdates
Routen, welche eine Schleife bilden würden, auf jeden Fall auszuschließen bzw. für den
Fall, dass ein zuvor gewählter Pfad nicht erfolgreich war und stattdessen ein anderer Pfad ausgegeben werden soll. Die beiden Blacklisten werden in Form von Bitmaps
übergeben — entsprechende Funktionen um Bitmaps auf ein Array aus 32bit Werten
abzubilden, sind in der Datei bitmap.c implementiert. Sofern die Blacklisten nicht verwendet werden sollen, kann die Funktion getRoute verwendet werden, die ihrerseits die
Funktion doGetRoute aufruft, jedoch weniger Parameter benötigt.
Anhand des kompletten Quellcodes der Funktion wird nun gezeigt, wie über die Routingtabelle iteriert wird, eine Route als tauglich überprüft und anschließend bewertet
wird.
Die Parameter der Funktion sind einigermaßen selbsterklärend: Zielknoten steht für
den Knoten, welcher das Ziel der Route darstellt. Route style bestimmt die Bewertungsfunktion, die verwendet werden soll. Es steht hierbei LOW LATENCY ROUTE,
HIGH BANDWIDTH ROUTE und BEST NETWORK POWER ROUTE zur Verfügung. Die beiden
übergebenen Arrays dienen als Speicher für die Bitmaps, die die Information enthalten,
welche Knoten nicht auf dem Pfad liegen sollen. Zur Iteration über die Routingtabelle
wird eine einfache while-Schleife verwendet, die Variable rid gibt die gerade aktuell
beobachtete Zeile in der Tabelle an.
1840
unsigned short doGetRoute(unsigned char Zielknoten, unsigned char
route_style, unsigned int NextHop_Blacklist[], unsigned int
Path_Blacklist[]) {
1841
85
Kapitel 5. Implementierung und Testumgebung
1842
1843
1844
1845
unsigned short rid=0;
int best_rating=0;
unsigned short best_rating_route=NO_ROUTE;
int rating;
1846
1847
1848
while(rid < MAX_ROUTES) {
Bevor eine Route bewertet wird, wird zunächst überprüft, ob die Route überhaupt das
richtige Ziel hat und nicht bereits in einem Fehlerzustand geführt wird. Zusätzlich wird
direkt überprüft, ob der nächste Knoten auf dem Pfad nicht in der NextHop Blacklist
geführt ist.
1849
1850
1851
1852
1853
if(routes[rid].target == Zielknoten &&
routes[rid].nexthop != 0 && // Unused Slot
routes[rid].nexthop != 255 && // Route-Request
!(routes[rid].flags & ROUTE_ERROR) && // nur funktionsfähige Routen
(NextHop_Blacklist == NULL || !checkBit(NextHop_Blacklist, routes[rid
].nexthop))) {
Sofern der bereits zurückgelegte Pfad bekannt ist – also beispielsweise bei einer Nachrichtenweiterleitung – wird überprüft, ob eine Schleife entstehen würde, sofern die
aktuell in Position rid gespeicherte Route ausgewählt werden würde. Hierzu muss
für jeden einzelnen Knoten auf dem weiteren Pfad überprüft werden, ob er in der
Path Blacklist eingetragen ist. Ist dies der Fall, so würde eine Schleife entstehen und
die Route kann nicht verwendet werden. Die Variable rokay wird auf false gesetzt und
die weitere Untersuchung des Pfades abgebrochen. Nur wenn nach dieser Überprüfung
rokay noch true ist, wird die Route bewertet.
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
unsigned char rokay=true;
if(Path_Blacklist != NULL) { // kompletten Pfad überprüfen
unsigned char i;
for (i=0; i<routes[rid].hopcount; i++) {
if(checkBit(Path_Blacklist, routes[rid].pfad[i])) {
rokay=false; // diese Route würde eine Schleife erzeugen
break;
}
}
}
if (rokay) { // keine Schleife im Pfad
Die Bewertung der Route basiert auf der, auf dem Pfad zur Verfügung stehenden Bandbreite, dem minimalen Akkupegel, der Anzahl der Hops sowie der benötigten minimalen
86
5.1. Implementierung
Sendeleistung. Für die Bewertung werden diese Parameter so normalisiert, dass sie jeweils im Bereich zwischen 0 und 200 liegen10 . Hierbei bedeutet 200 am schlechtesten und
0 am besten. Diese normalisierten Werte werden dann, je nach gewählter Bewertungsfunktion, unterschiedlich gewichtet. So ist beispielsweise bei der LOW LATENCY ROUTE
der Hopcount die wichtigste Eigenschaft. Die anderen Parameter werden dennoch in
der Bewertung berücksichtigt, um bei Routen mit gleicher Länge eine Wahl treffen zu
können. Ist die Bewertung der aktuellen Route besser als die bisher beste Route, so
wird die aktuelle Route zur besten Route bestimmt.
// Die Bewertung basiert auf:
// Bandbreite
routes[rid].min_datarate // 3 ... 10
// Akkupegel
routes[rid].bat_level
// 1 ... 200
// Hopcount
routes[rid].hopcount
// 1 ... 31
// Sendeleistung
routes[rid].min_power
// 1 ... 10
rating=1000000;
// Bewerte Route..
switch(route_style) {
case LOW_LATENCY_ROUTE:
rating -= 300 * ((int)routes[rid].hopcount *7);
rating -= 1 * (200-(int)routes[rid].bat_level);
rating -= 1 * ((int)routes[rid].min_power*20);
rating -= 20 * ((10-(int)routes[rid].min_datarate)*20);
break;
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
case HIGH_BANDWIDTH_ROUTE:
rating -= 30 * ((int)routes[rid].hopcount *7);
rating -= 1 * (200-(int)routes[rid].bat_level);
rating -= 1 * ((int)routes[rid].min_power*20);
rating -= 100 * ((10-(int)routes[rid].min_datarate)*20);
break;
1880
1881
1882
1883
1884
1885
1886
default:
case BEST_NETWORK_POWER_ROUTE:
rating -= 20 * ((int)routes[rid].hopcount *7);
rating -= 100 * (200-(int)routes[rid].bat_level);
rating -= 20 * ((int)routes[rid].min_power*20);
rating -= 1 * ((10-(int)routes[rid].min_datarate)*20);
break;
}
1887
1888
1889
1890
1891
1892
1893
1894
1895
10
Die Wahl dieses Bereichs wurde getroffen, da dies die effektive Auflösung des A/D-Wandlers, welcher
die Versorgungsspannung misst, ist. Dieser misst zwar mit 10 Bit, ab dem Messwert 800 ist der
Akku jedoch erschöpft, Werte über 1000 sind zwar theoretisch möglich, kommen beim Einsatz
von Akkus jedoch nicht vor. Es wird daher der Messwert mit dem Offset 800 verwendet, um den
aktuellen Ladezustand abzuschätzen.
87
Kapitel 5. Implementierung und Testumgebung
if (rating > best_rating) {
best_rating=rating;
best_rating_route=rid;
}
1896
1897
1898
1899
Nachdem die Bewertung der aktuellen Route abgeschlossen ist, wird der nächste Eintrag in der Routingtabelle bewertet, so lange, bis alle Routen der Tabelle bewertet
wurden. Sobald dies der Fall ist, wird die beste gefundene Route zurückgegeben. Wurde
überhaupt keine Route gefunden, so ist der Rückgabewert noch mit NO ROUTE initialisiert.
} // Route ohne Schleife
} // Route verwendbar
1900
1901
1902
rid++;
} // Hauptschleife
1903
1904
1905
return best_rating_route;
1906
1907
}
5.1.6 Nachrichtenbündelung
Die Behandlung eingehender Nachrichten, die Verwaltung der aktuell vorhandenen
Nachrichten sowie das Aussenden von weiterzuleitenden Nachrichten ist in der Datei
route data.c der Hauptanwendung implementiert. Die Implementierung des Nachrichtendienstes ist stark mit der Implementierung des Routingprotokolls verwoben.
Beispielsweise die Mechanismen zur Aufgaben- und Timeoutverwaltung werden gemeinsam verwendet.
Der Nachrichtendienst stellt die Funktion addMessage zur Verfügung. Ein Anwendungsprogramm braucht nur diese Funktion aufrufen, um eine Nachricht zuverlässig
zu einem anderen Knoten zu verschicken. Alles Weitere (finden der Route, Behandlung
von Fehlern, ...) wird automatisch durchgeführt. Die Verarbeitung von eingegangenen
Nachrichten kann in der Funktion processLocalMessages implementiert werden, die
immer dann aufgerufen wird, wenn unbearbeitete Nachrichten für den lokalen Knoten
in der Nachrichtenwarteschlange eingetragen sind.
In den Unterkapiteln 4.1.3 und 4.3.5 wurde bereits beschrieben, wie die Nachrichten
verwaltet und verschickt werden. Anhand von Auszügen aus dem Quellcode wird hier
nun das Detail vorgestellt, wie die gebündelte Übertragung von Nachrichten, welche
den gleichen nächsten Schritt auf ihrem Pfad haben, umgesetzt wurde.
Die Bündelung der Nachrichten wird durch die beiden Funktionen SendMsgs und getNextNexthopMessage erreicht, die nun beide vorgestellt werden. Die Funktion Send-
88
5.1. Implementierung
Msgs dient hierbei der Übermittlung der Nachrichten zu einem Nachbarn und wird
aufgerufen, nachdem der Nachbar geweckt, der Übertragungskanal gewechselt, sowie
die Datenrate ausgehandelt wurde. Mit Hilfe der Funktion getNextNexthopMessage
werden dann alle Nachrichten, welche den gleichen nächsten Schritt auf Ihrem Pfad
haben, zusammen verschickt.
Als Parameter benötigt die Funktion SendMsgs die Nummer der Route, welche die Verbindung zum Nachbarknoten beschreibt.
977
unsigned char SendMsgs(unsigned short nrid) {
978
979
980
unsigned char NextHop=routes[nrid].target;
unsigned char retVal=false;
981
982
983
unsigned short iterator=0xFFFF;
unsigned char count=10;
Die Bündelung der Nachrichten erfolgt in einer while-Schleife, die über die Nachrichten
iteriert, deren nächster Schritt auf dem Pfad der aktuelle Partner ist. Hierzu wird die
Variable iterator verwendet, um einerseits anzuzeigen, welche Nachricht gerade verarbeitet wird, andererseits dient sie der Funktion getNextNexthopMessage dazu, die
jeweils nächste Nachricht zu finden. Die Schleife wird so lange durchlaufen, bis keine
Nachricht mehr über den Nachbarn zu verschicken ist.
984
while((iterator=getNextNexthopMessage(NextHop, iterator+1)) != NO_MSG) {
Innerhalb der Schleife wird die gefundene Nachricht dann in ein Paket kopiert und
anschließend an den Nachbarn geschickt. Nach jeder Übertragung wird je nach Ergebnis die Funktion updateNachbarGood oder updateNachbarBad verwendet, um die
Verbindung zum Nachbarknoten zu bewerten und dadurch die Sendeleistung und die
Datenrate dynamisch anzupassen. Während einer bestehenden Verbindung erfolgt keine Anpassung der Datenrate, da der hierzu notwendige Signalisierungsvorgang nicht im
Protokoll enthalten ist. Stattdessen erfolgt die Anpassung der Datenrate beim nächsten
Nachrichtenaustausch mit diesem Nachbarn.
985
986
987
988
// Paket zusammenbauen..
if ( !memcpy(TxBuffer,
&data_route_index[iterator],
sizeof(data_route_index_t))) {
989
puts("<SendMsgs> Fehler beim Koperen (Struct)");
990
991
return false;
992
993
}
89
Kapitel 5. Implementierung und Testumgebung
994
if(data_route_index[iterator].length >= DRQ_MSG_SIZE) {
995
printf("<SendMsgs> Nachricht ist größer als erlaubt (%d)!!\n",
data_route_index[iterator].length);
996
997
return false;
998
999
}
1000
1001
unsigned char hdr_length=getHeaderLength(&data_route_index[iterator]);
1002
1003
1004
1005
1006
1007
1008
TxBuffer[hdr_length]=0xFF; // Schutzbyte...
if((hdr_length+1)%2) {
// um die Nachricht später bequem ins Flash kopieren zu können, muss
sie an einer graden "Wortgrenze" beginnen..
hdr_length++;
TxBuffer[hdr_length]=0xFF; // weiteres Schutzbyte...
}
1009
1010
1011
1012
if ( !memcpy(&TxBuffer[hdr_length+1],
((unsigned char*)(DRQ_BASE+DRQ_MSG_SIZE*iterator)),
data_route_index[iterator].length )) {
1013
puts("<SendMsgs> Fehler beim Kopieren (data)");
1014
1015
return false;
1016
1017
}
1018
1019
sleep(100000); // warten, bis der andere Knoten bereit ist
1020
1021
1022
1023
1024
count=50;
while(--count) {
if(SendPacket(NextHop, TYP_DATA | BESTAETIGT,
data_route_index[iterator].length+hdr_length+1, TxBuffer)) {
1025
markSlotSent(iterator); // Nachricht als gesendet markieren
updateNachbarGood(nrid); // Verbindung zum Nachbarn ist gut
if(msg_rid != NO_ROUTE) {
updateRouteUsed(msg_rid); // Timeout der Route zurücksetzen
}
break; // Übertragung dieser Nachricht abgeschlossen
1026
1027
1028
1029
1030
1031
1032
} else { // Paket konnte nicht verschickt werden
updateNachbarBad(nrid); // Verbindung zum Nachbarn ist schlecht
}
sleep(50000); // Zeit lassen, um Daten ins Flash zu schreiben
1033
1034
1035
1036
1037
}
90
5.1. Implementierung
if(!count) {
puts("<SendMsgs> Senden fehlgeschlagen !!!!!!");
break; // Nach 50 Versuchen konnte eine Nachricht nicht zugestellt
werden. Es macht keinen Sinn, weitere Nachrichten zu verschicken!
}
1038
1039
1040
1041
1042
}
1043
Nachdem alle Nachrichten verschickt wurden, wird noch ein DATAFINISH“-Paket
”
verschickt, um anzuzeigen, dass die Übertragung in dieser Richtung nun abgeschlossen
ist. Anschließend wird die bestehende Verbindung genutzt, um ggf. Daten in Rückrichtung zu übertragen. Sind keine Daten auf der Rückrichtung zu übertragen bzw.
wurden diese bereits zuvor übertragen, so wird die Verbindung nach der Übermittlung
des DATAFINISH“-Paketes geschlossen und beide Knoten wechseln zurück auf den
”
Signalisierungskanal.
sleep(100000);
1044
1045
puts("<SendMsgs> Sende DATAFINISH");
count=50;
while(--count) {
if(SendPacket(NextHop, TYP_DATAFINISH | BESTAETIGT , 1, TxBuffer)) {
retVal=true;
break;
}
sleep((rand()%19000)+10000);
}
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
return retVal;
1056
1057
}
Da die eigentliche Bündelung der Nachrichten in der Funktion getNextNexthopMessage
erfolgt, wird diese nun ebenfalls vorgestellt. Als Parameter benötigt Sie den Knoten
nexthop, über welchen der Pfad einer Nachricht als nächsten Schritt laufen soll. Die Variable iterator start wird verwendet, um den bisherigen Fortschritt der gebündelten
Übertragung zu berücksichtigen.
531
532
533
unsigned short getNextNexthopMessage(unsigned char nexthop, unsigned short
iterator_start) {
unsigned irqstat=disableIRQ();
msg_rid=NO_ROUTE;
534
535
unsigned short slot=max(iterator_start, dri_lesezeichen.first_waiting); //
nicht weiter "unten" anfangen zu suchen als dies eigentlich nötig ist
91
Kapitel 5. Implementierung und Testumgebung
536
537
538
539
unsigned char max_prio=0;
unsigned short max_prio_msg=NO_MSG;
unsigned short rid;
540
541
unsigned int Blacklist[8]; // 8*32 = 256
Das Durchsuchen der Nachrichten erfolgt in einer einfachen Schleife. Alle Nachrichten
ab der angegebenen Startposition werden überprüft, ob sie zur Übertragung über den
gewünschten nächsten Schritt geeignet sind. Zusätzlich wird sichergestellt, dass sich
keine Schleife auf dem Datenpfad bildet.
542
while(slot < dri_lesezeichen.next_unused) {
543
544
MsgPathToBlacklist(Blacklist, slot);
545
546
rid=NO_ROUTE;
547
548
549
550
551
552
553
554
555
556
557
if(// Slot ist überhaupt in Verwendung
slotUsed(slot) &&
// und noch nicht abgeschlossen
slotWaiting(slot) &&
// und noch nicht gesendet
(!checkBit(SlotSentBitmap,slot)) &&
// und es gibt eine Route zum Ziel..
((rid=getDatapathRoute(data_route_index[slot].target, data_route_index
[slot].route_style, Blacklist))!= NO_ROUTE && ((routes[rid].flags&
ROUTE_REPLY) || (routes[rid].flags&NEIGHBOUR_ESTABLISHED))) &&
// und der nächste Schritt auf der gefundenen Route ist der Gesuchte?
(routes[rid].nexthop == nexthop)) {
Sofern die Nachricht zur Übertragung geeignet ist, wird überprüft, ob eine Startposition zum Durchsuchen des Nachrichtenspeichers angegeben wurde. Falls dies der Fall
ist, wird die gefundene Nachricht auf jeden Fall als Rückgabewert der Funktion gespeichert und es werden keine weiteren Nachrichten untersucht. Wurde keine Startposition
angegeben, so werden alle ausstehenden Nachrichten untersucht und letztendlich die
Nachricht mit der höchsten Priorität zurückgeliefert. Dadurch, dass beim ersten Aufruf
der Funktion bei einer Übertragung immer keine Startposition angegeben wird, wird sichergestellt, dass die Nachricht mit der höchsten Priorität immer zuerst verschickt wird.
558
559
560
561
if(iterator_start == 0) {
if (data_route_index[slot].priority > max_prio) {
max_prio=data_route_index[slot].priority;
max_prio_msg=slot;
92
5.2. Testdurchführung
562
msg_rid=rid;
563
}
} else {
msg_rid=rid;
max_prio_msg=slot;
break;
}
564
565
566
567
568
}
slot++;
569
570
}
571
572
// Durchsuchen des Nachrichtenspeichers abgeschlossen
573
574
restoreIRQ(irqstat);
// gibt die älteste Nachricht mit der höchsten Priorität zurück -- oder,
wenn "iterator_start" verwendet wird, die jeweils nächste Nachricht,
deren Pfad ebenfalls über "nexthop" läuft
return max_prio_msg;
575
576
577
578
}
5.2 Testdurchführung
Bei allen im Weiteren beschriebenen Versuchen kam ein Netz aus 30 Knoten zum Einsatz, die in einem Gitter von 5*6 Knoten ausgelegt waren. Abbildung 5.7 zeigt ein Foto
eines solchen Versuchsaufbaus. Die Knoten liegen hierbei direkt auf dem Erdboden,
welcher einen Großteil der abgestrahlten Energie absorbiert. Zum Schutz der Hardware
vor eventueller Feuchtigkeit wurde eine handelsübliche Plastiktüte verwendet (Abbildung 5.8). Somit ist es möglich, auf einem relativ kleinen Testfeld ein Netz aus 30
Knoten unterzubringen. Diese Art des Aufbaus wurde aus praktischen Gründen, wie
beispielsweise der Auf- und Abbauzeit, gewählt. Die Reichweite der einzelnen Knoten
ist durch die Platzierung direkt auf dem Boden durch die Reduktion der Sendeleistung
gut auf wenige Meter beschränkbar. Typischerweise sind bei diesem Aufbau bei minimaler Sendeleistung somit nur die direkten Nachbarn auf dem Funkweg zu erreichen.
Zum Vergleich: Bei eine Platzierung zwei Meter über dem Boden und mit einer Rundstrahlantenne ausgestattet, liegt die Reichweite im Bereich von etwa 200 Metern[19]
– ein so aufgebautes Netz aus nur 30 Knoten könnte bei einem Knotenabstand von
150 Metern etwa 32 Quadratkilometer, also die Fläche von etwa 100 Fußballfeldern11 ,
abdecken!
Es werden nun die durchgeführten Versuche vorgestellt und anschließend deren Ergebnisse gezeigt und diskutiert.
11
Ein Fußballfeld hat typischerweise die Fläche von 68m ∗ 105m = 7140m2 = 0, 007km2
93
Kapitel 5. Implementierung und Testumgebung
Abbildung 5.7: Testnetz aus 30 Knoten
Abbildung 5.8: Knoten bei einem realen Test
94
5.2. Testdurchführung
5.2.1 Behandlung von Fehlern auf dem Datenpfad
Der erste durchgeführte Versuch soll die Fähigkeit des Routingprotokolls und der Nachrichtenweiterleitung aufzeigen, mit Ausfällen von Knoten zurecht zu kommen und alternative Routen zu finden und zu verwenden. Hierzu wurde zunächst das vollständige
Netz aus 30 Knoten aufgebaut. Ein Knoten dient als Nachrichtenquelle (Q), einer als
Nachrichtensenke (S). Teilabbildung 5.9.a) zeigt den initialen Aufbau des Netztes und
die Platzierung der Quelle bzw. Senke. Den Knoten liegen im Voraus keine Information
über den Aufbau des Netzes vor! Alle Routen durch das Netz wurden mit Hilfe des
bereits vorgestellten Routingprotokolls gefunden. Die vorgestellten Ergebnisse basieren
auf einem realen Versuch.
Versuchsdurchführung und Ergebnis
Um das Routingprotokoll auf seine Leistungsfähigkeit zu testen, wurde dem System
zunächst eine gewisse Zeit gelassen, einen Pfad durch das Netz zu finden. Der gefundene
Pfad ist jeweils durch Pfeile in den Teilbildern gezeigt. Es wurden dann jeweils ein oder
mehrere auf dem Pfad liegende Knoten deaktiviert und dann protokolliert, welcher
Pfad neu gefunden wurde. Die ausgefallenen Knoten werden zunächst rot in der Grafik
dargestellt und anschließend entfernt. Das Ergebnis des Versuchs ist in Abbildung 5.9
gezeigt.
Ergebnisbewertung
Der Ausfall von Knoten, die auf dem Datenpfad liegen, führt nicht dazu, dass die
Verbindung zusammenbricht. Das System hat bewiesen, dass es mit dem Ausfall von
Knoten umgehen kann und – sofern möglich – alternative Routen durch das Netz finden
kann, um die Daten zuzustellen.
5.2.2 Zeitsynchronisierung
Um zu überprüfen, wie gut die Echtzeituhren der Sensorknoten (unmittelbar) nach
einer Synchronisierung übereinstimmen, wurde das Interrupt-Signal der Echtzeituhr12
auf einen GPIO-Pin gelegt. An diesem Pin (von zwei verschiedenen Knoten) wurde ein
hochwertiges Oszilloskop13 angeschlossen. Das Oszilloskop wurde so eingestellt, dass es
automatisch die fallenden Flanken im Signal erkennt und dann den zeitlichen Versatz
beider Flanken berechnet. Direkt nach der Synchronisierung wurde so ein Wert von
40 s gemessen – dies entspricht in etwa einer Periode des 32kHz Quarzes der Echtzeituhr! Abbildung 5.10 zeigt ein Bildschirmfoto des Oszilloskops. Es wurde der bereits in
µ
12
13
Dieses wird immer genau dann ausgelöst, nachdem die Uhr um eine Sekunde fortgeschritten ist
Agilent MSO6054A Mixed Signal Oscilloscope
95
Kapitel 5. Implementierung und Testumgebung
a)
b)
Q
S
c)
Q
S
Q
S
Q
S
d)
Q
S
f)
e)
Q
S
Q Datenquelle
nicht verwendeter
Knoten
S Datensenke
Knoten auf Route
ausgefallener
Knoten
Abbildung 5.9: Experiment Behandlung von Fehlern auf dem Datenpfad“ in einem
”
Netz aus 30 Knoten. Die Teilabbildungen zeigen jeweils das noch aktive
Netz (blau, grün), die in diesem Schritt ausgefallenen Knoten (rot) und
den Datenpfad, welcher automatisch gefunden wurde (Pfeile).
96
5.2. Testdurchführung
µ
Abbildung 5.10: Gemessenes Interrupt-Signal der Echtzeituhr von zwei Knoten unmittelbar nach einer Synchronisierung. Die Genauigkeit von 40 s entspricht etwas über einer Periode des 32768Hz Quarzes der Uhr.
97
Kapitel 5. Implementierung und Testumgebung
Listing 5.5 und 5.6 vorgestellte Code des Softwareupdates zur Synchronisierung verwendet.
Ergebnisbewertung
Leider driften die Uhren recht schnell wieder voneinander ab, so dass nach wenigen Minuten bereits ein zeitlicher Versatz im zweistelligen Millisekundenbereich messbar ist.14
Im normalen Betrieb des Sensornetzes kommt diese aufwendige Synchronisierung daher nicht zum Einsatz. Einerseits würde sie die Knoten zu lange blockieren, anderseits
müsste sie zu oft durchgeführt werden, um eine so genaue Synchronisierung aufrecht
zu erhalten. Die Systemzeit von benachbarten Knoten ist – trotz einer weniger aufwendigen Synchronisierung – dennoch hinreichend synchron. Eine exakte Messung mit
dem Oszilloskop im gesamten Netz ist nicht möglich, da dieses im Freien auf der Wiese
aufgebaut wird und sich über eine zu große Fläche erstreckt. Über das gesamte Netz
hinweg wird jedoch stets die gleiche Zeit auf dem Display ausgegeben, was bedeutet,
dass das gesamte Netz mit einer Genauigkeit von besser als 1 Sekunde synchronisiert
ist.
5.2.3 Übertragungseffizienz und Belastbarkeit
Um die Effizienz und Leistungsfähigkeit bei der Übertragung von Daten durch das Netz
bewerten zu können, wurde das Netz verschiedenen Auslastungstests unterzogen. Die
Testdurchläufe wurden in dem bereits beschriebenen Netz, bestehend aus 30 Knoten,
durchgeführt. Abbildung 5.11 zeigt den Aufbau der Tests mit dem jeweiligen Ergebnis.
Es werden drei verschiedene Netzkonfigurationen untersucht. In der ersten Messung
(Abbildung 5.11.a) werden Daten von einem Knoten diagonal durch das Netz zu einem
anderen Knoten geschickt. Im zweiten Test (Abbildung 5.11.b) werden Daten von fünf
Knoten an einen Knoten geschickt. Im dritten Durchlauf (Abbildung 5.11.c) werden
Daten von fünf Knoten an fünf andere Knoten geschickt. Die Knoten befinden sich
hierbei jeweils über Kreuz“ auf der gegenüberliegenden Seite des Netzes.
”
Versuchsdurchführung
Je nach der Knoten-Identifikationsnummer und dem aktuellem Versuch verhält sich
die Software der Knoten etwas unterschiedlich. Hierbei wird unterschieden in drei Arten von Knoten: Datenquellen (grün), Routingknoten (blau) und Datensenken (gelb).
Nachdem die Software auf den Knoten verteilt wurde, läuft der Test vollautomatisch
ab. Die Datenquellen verschicken periodisch Daten über das Netz an die Datensenken.
Jeder Knoten protokolliert hierbei zu jedem Zeitpunkt, wie viele Bytes er gesendet
14
Dies ist vergleichbar mit einer normalen Quarzuhr: Bei einer typischen Abweichung von nur 3
Sekunden am Tag entspricht dies pro Minute immerhin 3s/(24 ∗ 60) ≈ 2ms
98
5.2. Testdurchführung
a)
Bytes gesendet
Bytes empfangen
b)
c)
Abbildung 5.11: Messung der Übertragungseffizienz und der Belastbarkeit des Netzes
und wie viele er empfangen hat. Nach zehn Minuten wird der Test beendet und alle
Knoten schicken die letzten drei Minuten ihres Logfiles an einen Knoten, an dem ein
PC angeschlossen ist, um die Daten entgegen zu nehmen. Nach der Durchführung des
Tests werden die Logfiles aller Knoten zu einem zusammengefasst, indem für jeden
Zeitpunkt jeweils die Summe der gesendeten und empfangenen Bytes gebildet wird.
Anhand eines Vergleichs der beiden Summen lässt sich dann erkennen, wie effizient die
Daten übertragen wurden.
Im Idealfall, also in einem ungestörten Netz, in welchem nur je zwei Knoten zum gleichen Zeitpunkt Daten austauschen, liegt das Verhältnis von gesendeten und empfangenen Daten bei etwa 1,0. Eine Nachricht durch ein ansonsten ruhendes Netz zu leiten
ist also sehr effizient. Diese Effizienz nimmt mit steigender Anzahl von gleichzeitig
aktiven Knoten ab. Der Versuch soll zeigen, wie stark die Effizienz leidet, wenn regelmäßig Nachrichten in das Netz eingespeist werden und somit immer eine Teilmenge
der Knoten15 gleichzeitig Daten übertragen möchte. Im ersten Versuch sind dies etwa
5-6 Knoten, im zweiten und dritten Versuch ist etwa die Hälfte der Knoten gleichzeitig
aktiv!
Ergebnisbewertung
Je höher die Belastung des Netzes ist, also je mehr Knoten gleichzeitig aktiv sind,
desto mehr Kollisionen gibt es. Unterschieden werden kann hierbei in logische“ Kol”
lisionen und physikalische“ Kollisionen. Bei den logischen“ Kollisionen befindet sich
”
”
15
Die Teilmenge entspricht den Knoten, die auf dem Pfad bzw. den Pfaden durch das Netz liegen
99
Kapitel 5. Implementierung und Testumgebung
ein Knoten gerade zum Datenaustausch mit einem anderen Knoten auf einem anderen Übertragungskanal. Ein dritter Knoten kann somit nicht mit einem der beiden
Knoten kommunizieren. Er probiert also Pakete zu verschicken, welche nicht ankommen. Bei den physikalischen“ Kollisionen übertragen mindestens zwei Knoten zeit”
gleich auf dem gleichen Übertragungskanal Daten, was zur Zerstörung beider Pakete
führt. Aufgrund des eingesetzten Kanalzugriffsverfahrens16 und Verwendung mehrerer
Übertragungskanäle ist die Anzahl der physikalischen“ Kollisionen eher gering.
”
Im ersten Versuch, in dem nur einer der Knoten regelmäßig Daten an einen anderen
Knoten über das Netz verschickt hat, beträgt das Verhältnis etwa 0,5. Es werden also
im Schnitt doppelt so viele Daten übertragen wie empfangen. Bei fünf aktiven Datenquellen sinkt das Verhältnis bereits auf 0,35, bei der Übertragung über Kreuz liegt
es noch immerhin bei 0,34. Bei einem ausgelasteten Netz sind also im Schnitt drei
Übertragungswiederholungen pro Paket notwendig. Für eine Reduzierung dieser logi”
schen“ Kollisionen wäre einiges an Aufwand – verbunden mit weiterem Overhead – zu
treiben17 . Es wurde hierbei ein Tradeoff zwischen diesem Overhead und der Möglichkeit,
den Kommunikationspartner direkt beim ersten Versuch zu erreichen, getroffen.
Erfreulicher ist jedoch, dass immer alle Daten bei Ihrem Ziel angekommen sind. Im
zweiten Versuch konnte die Bündelung von Nachrichten auf dem Pfad gut nachvollzogen werden. Der folgende Ausschnitt der von Knoten 29“ über die serielle Schnittstelle
”
ausgegebenen Statusmeldungen zeigt, wie während einer Datenübertragung vier Nachrichten von drei unterschiedlichen Knoten übertragen wurden. Es kommt hierbei das
unter 4.3.5 beschriebene Protokoll zum Nachrichtenaustausch zum Einsatz. Der Austausch der Nachrichten erfolgt zwischen den DATASETUP“- und DATAFINISH“”
”
Meldungen.
<handleIncomingMsgs> geweckt worden von Knoten 20! Kanal: 2
<handleIncomingMsgs> DATASETUP (speed 7, power 6) abgeschlossen.
Beginne mit Datenaustausch!
<addMessage> neue Nachricht von: 34 für: 29
<addMessage> neue Nachricht von: 34 für: 29
<addMessage> neue Nachricht von: 32 für: 29
<addMessage> neue Nachricht von: 30 für: 29
<ReceiveMsgs> DATAFINISH Paket erhalten!
<handleIncomingMsgs> Sende nun ausgehende Nachrichten
<SendMsgs> Sende DATAFINISH
<handleIncomingMsgs> Übertragung abgeschlossen, zurück auf den
Signalisierungskanal
16
Es wird ein CSMA-Verfahren eingesetzt. Das Medium wird immer abgehört, bevor Daten übertragen
werden. Nur wenn der Kanal frei ist, wird der Sender aktiviert. Diese Funktion ist direkt in Hardware im Funkchip implementiert und wird aktiv genutzt.
17
Beispielsweise ein Zugriffsverfahren in der Art von Token-Ring oder ein TDMA-Verfahren
100
5.2. Testdurchführung
Signalstärke / Abstand (indoor)
150
140
140
130
130
120
120
110
110
100
100
90
90
80
80
70
70
60
-8
-7
-6
-5
-4
-3
-2
-1
0
1
2
3
4
5
Drehung um die eigene Achse
150
6
7
8
60
0°
45°
90°
135°
180°
225°
270°
315°
Abbildung 5.12: Messung der Signalstärke eines Knotens in Abhängigkeit zur Entfernung und der Ausrichtung des Knotens innerhalb eines Gebäudes
5.2.4 Positionsbestimmung
Wie in Kapitel 2.2.3 bereits angesprochen wurde, ist die Abschätzung der eigenen Position in einem Sensornetz für manche Aufgaben bzw. auch Protokolle wichtig. Es wurde
daher untersucht, ob mit minimalem Aufwand eine solche Abschätzung, aufgrund der
gemessenen Signalstärke von einigen festen Knoten im Inneren eines Gebäudes, zufriedenstellend funktioniert.
Aufgrund der Ausbreitungseigenschaften von Funkwellen und beispielsweise Reflektionen an Wänden ist die gemessene Signalstärke nicht immer direkt abhängig von der
Entfernung zum Sender[45]. Abbildung 5.12 zeigt das Ergebnis einer solchen Messung
(linkes Teilbild). Zu erkennen ist hierbei kein auswertbarer Zusammenhang zwischen
Signalstärke und Entfernung.
Zusätzlich wurde der empfangende Knoten einmal um seine eigene Achse gedreht. Aufgrund der nicht idealen Eigenschaften der Antenne (siehe Kapitel 3.3.3) schwankt die
gemessene Stärke des Signals um etwa 10 Prozent!
Da die Messwerte kein zufriedenstellendes Ergebnis versprachen, wurde auf eine weitere Untersuchung verzichtet. Es sei jedoch darauf hingewiesen, dass durchaus eine
Abschätzung möglich ist, welcher Referenzknoten der Naheste“ ist. Mit aufwändigeren
”
Verfahren ist auch eine genauere Abschätzung der eigenen Position durchaus möglich.
Der Hersteller Texas Instruments bietet beispielsweise einen auf ZigBee basierenden
Funkchip an (CC2430), welcher eine Positionsabschätzung aufgrund der Signalstärke
in Hardware unterstützt[46, 47].
101
Kapitel 5. Implementierung und Testumgebung
102
6 Zusammenfassung und Ausblick
Zum Schluss dieser Arbeit wird noch einmal zusammenfassend beschrieben, was erreicht
wurde. Anschließend werden Möglichkeiten gezeigt, wie man die entwickelte Sensorknotenplattform und die Sensornetzanwendung in Zukunft nutzen könnte.
6.1 Erreichtes
Aufbauend auf der Hardware einer interaktiven Fernbedienung, wurde zunächst eine neue Plattform für die praktische Evaluation von Sensornetzen entwickelt. Hierzu
wurde die gesamte Softwarebasis, die nötig ist, um eine Sensornetzanwendung zu entwickeln1 , auf vielen Knoten gleichzeitig zur Ausführung zu bringen2 und anschließend
auszuwerten3 , entworfen und implementiert.
Diese Softwarebasis wurde dann genutzt, um ein neu konzipiertes Sensornetz-Routingprotokoll in einer solchen Sensornetzanwendung umzusetzen und auf einer größeren
Anzahl von Sensorknoten in einer natürlichen Umgebung auszuführen. Das Routingprotokoll beinhaltet einige neue Ideen, um den Aufbau des Netzes sowie die Weiterleitung
von Nachrichten durch das Netz, möglichst energieeffizient zu gestalten.
Die entwickelte Sensornetzanwendung ermöglicht eine selbstorganisierte Vernetzung der
Knoten bei einer beliebigen Topologie des Netzes. Lokale Probleme im Netz werden automatisch erkannt und (sofern möglich) umgangen. Es ist grundsätzlich ein Datenaustausch zwischen zwei beliebigen Knoten im gesamten Netz möglich. Bei der Verwendung
von gemeinsam genutzten Pfaden (z.B. bei einer zentralen Datensenke), erfolgt eine automatische Bündelung von Nachrichten, um die Anzahl der Weckvorgänge möglichst
gering zu halten. Die Sendeleistung und die Datenrate werden ständig adaptiv angepasst, um den Energiebedarf einer Übertragung zwischen zwei benachbarten Knoten so
gering wie möglich zu halten. Die Wahl der verwendeten Routen durch das Netz kann
auf Anwendungsebene beeinflusst werden, so dass entweder Pfade mit hoher Bandbreite, niedriger Latenz oder hohem Energievorrat der Knoten auf dem Pfad bevorzugt
werden. Bei mehreren möglichen Pfaden werden immer der Energievorrat der Knoten,
die benötige Sendeleistung sowie die mögliche Datenrate auf dem Pfad berücksichtigt.
Die Datenübertragung zwischen je zwei Nachbarn erfolgt auf mehreren verschiedenen
1
Hardware-Abstraktion, Funktionen für den Versand bzw. Empfang von Datenpaketen, ...
Kabelloses Software Deployment
3
Laufzeitprotokollierung, Messung der Akkuspannung, ...
2
103
Kapitel 6. Zusammenfassung und Ausblick
Übertragungskanälen, wobei diese dynamisch bewertet und potentiell gestörte Kanäle
gemieden werden. Dies alles reduziert die Wahrscheinlichkeit von Übertragungsfehlern
und somit die Anzahl der nötigen Übertragungen und steigert damit die Energieeffizienz des gesamten Netzes.
In mehreren Versuchen wurde untersucht, ob und wie die Softwarebasis sowie die darauf aufsetzende Sensornetzanwendung funktioniert. Alle Ergebnisse waren zufriedenstellend. Die vor dem Entwurf gesetzten Anforderungen an das Gesamtsystem wurden
erfüllt.
6.2 Ausblick
Die in dieser Arbeit entwickelte Sensornetzanwendung ist nur eine Möglichkeit für den
Einsatz der neu entwickelten, auf der Betty TV-Fernbedienung basierenden, Sensorknotenplattform sowie der entworfenen Protokolle. Von den vielen potentiellen Verwendungszwecken seien hier nur ein paar genannt:
Dank der umfangreichen Laufzeitprotokollierung würde es sich anbieten, mehrere verschiedene Sensornetz-Protokolle auf der Plattform zu implementieren und diese anschließend miteinander zu vergleichen. Vorstellbar wäre es auch, eine Kompatibilitätsschicht zu implementieren, um die für andere Plattformen entworfenen Protokolle mit
geringem Aufwand ausführen und miteinander vergleichen zu können. Hierdurch könnte
insbesondere auch gezeigt werden, wie stark sich die im jeweiligen Protokoll vorgesehenen Möglichkeiten zur Steigerung der Energieeffizienz tatsächlich auswirken.
Ebenfalls vorstellbar wäre es, die vorhandene Hardwareabstraktion dazu zu nutzen,
die Sensornetzanwendung in einer simulierten Umgebung auszuführen. Eine parallele
Ausführung der gleichen Anwendung in der Realität könnte dazu genutzt werden, das
Modell der Simulation besser an die echte Umgebung anzupassen bzw. die Güte der
Simulation zu beurteilen.
Eine weitere Möglichkeit wäre es, die Routing-Knoten“, die im Routingprotokoll des
”
Hyperion-Sensornetzwerkes vorgesehen sind[17], mit Hilfe der in dieser Arbeit entstandenen Sensorknotenplattform zu realisieren4 .
Letztendlich ist es natürlich auch möglich, das in dieser Arbeit entstandene Protokoll
und die Sensorknoten-Basis weiter zu entwickeln. Insbesondere die im Moment bei Bedarf zufällig ausgelösten Weckvorgänge könnten zur Steigerung der Effizienz bei einem
stark ausgelasteten Netz besser koordiniert werden. Bei einem schwach ausgelasteten
Netz5 besteht hierzu jedoch eigentlich kein Handlungsbedarf.
4
Genaugenommen war diese Überlegung der Anlass zu dieser Arbeit, da beide Plattformen über eine
kompatible Funkschnittstelle verfügen und die Betty-Fernbedienungen vergleichsweise preiswert
sind. Leider war das Hyperion-Sensornetzwerk selbst nicht weit genug fortgeschritten, um eine
praktische Evaluation zu ermöglichen.
5
In der Regel wird ein Sensornetz nur gelegentlich Daten übertragen.
104
Abbildungsverzeichnis
1.1
1.2
2.1
2.2
2.3
3.1
3.2
3.3
3.4
3.5
Üblicher Entwurf eines Sensornetzes. a) Ein Modell der Knoten und der
Umwelt wird angefertigt. Aufgrund von Messungen mit einigen Knoten
wird dieses Modell parametrisiert. b) Aufgrund dieses Modells wird ein
großes Sensornetz entworfen und simuliert. c) Nicht bekannt ist, ob das
so entworfene Netz auch in der Realität funktioniert. . . . . . . . . . .
Ansatz in dieser Arbeit. a) Grundlagen, wie Wake-on-Radio“, werden
”
mit wenigen Knoten entwickelt. b) Grundlegende Protokolle werden mit
einigen Knoten in einer realen Umgebung entworfen und getestet c) Erprobung und Verbesserung des Netzes mit vielen Knoten in einer realen
Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ein aus vielen identischen, zufällig verteilten Knoten bestehendes Netz.
Beispielsweise könnten Knoten von einem Flugzeug abgeworfen werden
(lila), sich zufällig verteilen und dann, nachdem sie gelandet sind, zu
einem Netz zusammenschließen (rot). . . . . . . . . . . . . . . . . . . .
Szenario Kamerasensorknotennetzwerk (aus [16]) . . . . . . . . . . . .
Einsatzszenario Positionsbestimmung“ (aus [24]) . . . . . . . . . . . .
”
Übersicht Hardwareplattform Diagramm . . . . . . . . . . . . . . . . .
Übersicht Hardwareplattform Foto . . . . . . . . . . . . . . . . . . . .
Übersicht über die Messwerte der Leistungsaufnahme des Systems während
verschiedener Betriebsmodi. . . . . . . . . . . . . . . . . . . . . . . . .
Entladekurve eines aktiven und eines passiven Knotens. Der aktive Knoten sendet hierbei pro Sekunde ein Paket bei voller Sendeleistung aus.
Der passive Knoten führt, außer der periodischen Messung der Batteriespannung und dem Abspeichern dieser im Flash, keine anderen Aktionen
durch. Die übrige Zeit befinden sich beide Knoten in einem Power-Down
Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abstrahlcharakteristik von Sensorknoten: a) bei der Simulierung häufig
zum Einsatz kommendes Modell[32, 33] und b) eine reale Messung der
in dieser Arbeit verwendeten Antenne. Der Empfangsbereich entspricht
der Umgebung um den Knoten, in dem eine Datenübertragung möglich
ist. Im Störbereich ist eine Übertragung nicht mehr möglich, es werden
jedoch u.U. Übertragungen anderer Knoten gestört! . . . . . . . . . . .
105
3
5
10
11
12
18
19
23
26
27
Abbildungsverzeichnis
4.1
Grober Überblick über die zweigeteilte Softwarearchitektur. Gezeigt werden die wesentlichen Komponenten der Firmware und der Anwendung.
4.2 Aufteilung des Flashspeichers. Der erste Baustein wird verwendet, um
die Firmware und die Anwendung abzulegen. Zusätzlicher Platz ist reserviert um eine temporäre Anwendung während des Anwendungsupdates
anzulegen. Der restliche zur Verfügung stehende Speicherplatz wird für
eine Nachrichtenwarteschlange samt dazugehörigem Index verwendet. Im
zweiten Baustein wird, außer eines kleinen Bereichs für Konfigurationsdaten, nur das Protokoll der Laufzeit abgelegt. . . . . . . . . . . . . . .
4.3 Teilkomponenten der Hauptanwendung . . . . . . . . . . . . . . . . . .
4.4 Beispiel für eine Anwendung: Messung der Belegung des 433MHz Frequenzbereiches. a) und b) mit einem Störsender aus 1,5m bzw. 15m
Entfernung. c) zeigt das ungestörte Spektrum. Die grau hinterlegten
Kanäle sind die von der Software als belegt“ bewerteten und würden
”
bei einer Datenübertragung vermieden. . . . . . . . . . . . . . . . . . .
4.5 Verwaltung der Aufgaben in einem Ringbuffer. Es werden drei Zeiger
(Leseposition, Freigabeposition und Schreibposition) verwendet, um den
Zugriff auf die Datenstruktur zu koordinieren. Die Bedeutung des Inhalts
eines einzelnen Eintrags ist im gewissen Rahmen abhängig vom Aufgabentyp, dargestellt sind die zur Verfügung stehenden Felder. . . . . . .
4.6 Aufbau der Routingtabelle. Grün hinterlegt sind die Spalten, die zur
Routingwahl verwendet werden. Die blau hinterlegten Spalten dienen
der adaptiven Anpassung von Datenrate und Sendeleistung zwischen
zwei Nachbarn. Dargestellt sind einige Einträge aus Sicht vom Knoten
mit der Nummer 1: a) Route-Request von Knoten 1 zu Knoten 2. b)
Nachbarschaft zu Knoten 3. c) Bestehende Route zu Knoten 100 über
4 Hops. d) Route-Request von Knoten 4 zu Knoten 55, welches über 3
bei 1 eingegangen ist. e) Nicht verwendeter Eintrag. . . . . . . . . . . .
4.7 Software Deployment Varianten: a) an einzelne Knoten über die serielle
Schnittstelle und b) Übertragung an viele Knoten gleichzeitig per Funk.
4.8 Automatische Codeerzeugung: Aus der ELF-Datei der Firmware und
den Headerdateien erzeugt das Konvertier-Skript neuen Code. Dieser
wird zusammen mit dem eigentlichen Anwendungscode kompiliert und
ergibt so die ELF-Datei der Anwendung. Der automatisiert erzeugte
Code enthält im Wesentlichen Pointer auf die Funktionen der Firmware.
4.9 Minimaler Aufbau eines Paketes. Das 16 Bit breite Längenfeld wird nur
verwendet, wenn die Paketlänge nicht durch 8 Bit angegeben werden
kann. In diesem Fall wird das reguläre Feld auf 255 gesetzt und die
wirkliche Länge im breiteren Längenfeld gespeichert. Dies reduziert den
Overhead für kleine Pakete und ermöglicht dennoch Pakete mit einer
Länge von bis zu 64 kByte. . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 Aufbau der direkt von der Firmware verwendeten Pakete. . . . . . . . .
106
32
34
35
36
38
39
43
45
47
48
Abbildungsverzeichnis
4.11 Darstellung, der von der Firmware angebotenen Möglichkeiten, der Paketübertragung: a) Broadcast an alle Empfänger im Empfangsbereich.
b) Unicast an einen bestimmten Empfänger. c) Unicast an einen bestimmten Empfänger mit Empfangsbestätigung. d) Weckvorgang eines
Knotens via Wake-on-Radio“. . . . . . . . . . . . . . . . . . . . . . . . 50
”
4.12 Aufbau der für das kabellose Softwareupdate verwendeten Pakete. . . . 51
4.13 Ablauf der Softwareaktualisierung über Funk. Die blau hinterlegten Punkte entsprechen den, im Text beschriebenen, Situationen. Um die Grafik
übersichtlich zu halten, sind nur zwei Empfänger angegeben – es könnten
jedoch Hunderte sein! Ebenfalls werden nicht alle möglichen Fehlersituationen, mit denen das Protokoll umgehen kann, gezeigt. . . . . . . . . . 52
4.14 Aufbau der Pakete, die zum Erstellen der Nachbarschaftsbeziehungen
verwendet werden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.15 Aufbau der für das Verwalten von Routen verwendeten Pakete ( RREQ“,
”
RREP“ und RERR“). . . . . . . . . . . . . . . . . . . . . . . . . . . 58
”
”
4.16 Behandlung eines eingehenden Route-Request“-Paketes . . . . . . . . 60
”
4.17 Behandlung eines eingehenden Route-Reply“-Paketes . . . . . . . . . . 61
”
4.18 Behandlung eines von Knoten A“ eingehenden Route-Error“-Paketes. 63
”
”
4.19 Legende der Signalisierung und Routenmanagement Grafik . . . . . . . 64
4.20 Suchen und Finden einer Route im Netz: Knoten A fordert eine Route
zum Knoten G an. Es sind hierbei die logischen Schritte dargestellt und
nicht unbedingt die zeitlich exakte Abfolge. Im grauen Kasten ist die
Routingtabelle von Knoten A im jeweiligen Schritt gezeigt. . . . . . . . 64
4.21 Aufbau der zum Nachrichtenaustausch verwendeten Pakete. (DATASETUP, DATA und DATAFINISH) . . . . . . . . . . . . . . . . . . . . . 65
4.22 Ablauf des Nachrichtenaustauschs zwischen zwei benachbarten Knoten.
Dargestellt ist nur der logische Ablauf, ggf. nötige Übertragungswiederholungen
sind nicht gezeigt! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.23 Übermittlung einer Nachricht von Knoten A zu Knoten G: In Teilbild
c) fällt ein auf dem Pfad liegender Knoten aus. Die Nachricht in Teilbild
d) kann daher nicht zugestellt werden. In Teilbild e) wird nur eine kurze
Fehlermeldung auf dem Pfad zurückgeschickt, nicht jedoch die gesamte
Nachricht. Da Knoten B einen alternativen Pfad kennt, wählt er diesen,
ansonsten wäre die Fehlermeldung einen weiteren Schritt auf dem Pfad
zurückgeschickt worden. Teilbild i) Zeigt den verwendeten Pfad, der auch
in der Nachricht vermerkt ist. Knoten B merkt sich, dass die Route über
C fehlerhaft ist und würde bei folgenden Nachrichten direkt den Weg
über D wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1
5.2
Übersicht über das Verzeichnis der implementierten Software. Mit Ausnahme der Hauptanwendung sind nur die Unterordner und nicht die
Dateien gezeigt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verteilung der über 22000 Zeilen Programmcode auf Firmware, Hauptanwendung und die übrigen Anwendungen. . . . . . . . . . . . . . . . .
107
70
74
Abbildungsverzeichnis
5.3
5.4
5.5
Verschiedene Zugriffsarten auf die Register des Funkchips[36] . . . . . . 75
Bildschirmfotos während eines erfolgreichen Softwareupdate-Durchlaufs 83
Hauptschleifen der Implementierung des Protokolls für den Sender und
die Empfänger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.6 Zustandsautomat des Empfängers für die Behandlung eingehender Pakete des Softwareupdates . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.7 Testnetz aus 30 Knoten . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.8 Knoten bei einem realen Test . . . . . . . . . . . . . . . . . . . . . . . 94
5.9 Experiment Behandlung von Fehlern auf dem Datenpfad“ in einem Netz
”
aus 30 Knoten. Die Teilabbildungen zeigen jeweils das noch aktive Netz
(blau, grün), die in diesem Schritt ausgefallenen Knoten (rot) und den
Datenpfad, welcher automatisch gefunden wurde (Pfeile). . . . . . . . . 96
5.10 Gemessenes Interrupt-Signal der Echtzeituhr von zwei Knoten unmittelbar nach einer Synchronisierung. Die Genauigkeit von 40 s entspricht
etwas über einer Periode des 32768Hz Quarzes der Uhr. . . . . . . . . . 97
5.11 Messung der Übertragungseffizienz und der Belastbarkeit des Netzes . . 99
5.12 Messung der Signalstärke eines Knotens in Abhängigkeit zur Entfernung
und der Ausrichtung des Knotens innerhalb eines Gebäudes . . . . . . 101
µ
108
Literaturverzeichnis
[1] H.-W. Gellersen, M. Beigl, H. Krull. The MediaCup: Awareness Technology embedded in an Everyday Object. Technical report, 1th Int. Sym. Handheld and
Ubiquitous Computing (HUC99) Karlsruhe, 1999.
[2] Raghavendra, S. Cauligi, Sivalingam, M. Krishna; Znati, Taieb (Eds.). Wireless
Sensor Networks. Number 978-1-4020-7883-5. Springer, 2005.
[3] Crossbow. MICA2 Wireless Measurement System.
[4] M. Youssef, N. El-Sheimy. Wireless Sensor Network: Research vs. Reality Design
and Deployment Issues. In CNSR ’07: Proceedings of the Fifth Annual Conference
on Communication Networks and Services Research, pages 8–9, Washington, DC,
USA, 2007. IEEE Computer Society.
[5] Y. Wen, W. Zhang, R. Wolski and N. Chohan. Simulation-based augmented reality
for sensor network development. In SenSys ’07: Proceedings of the 5th international
conference on Embedded networked sensor systems, pages 275–288, New York, NY,
USA, 2007. ACM.
[6] C. Mall, A. Suri, V. Kunchakarra, S. S. Iyengar, R. Kannan, A. Durresi and S.
Sastry. OMNeT++ Discrete Event Simulation System.
[7] R. Wilson R. Villa and Fabio Crestani. Network Simulator ns-2. In Proceedings
of IPMU 2004, International Conference on Information Processing and Management of Uncertainty in Knowledge-Based Systems, pages 528–535, 2004.
[8] H. N. Pham, D. Pediaditakis, and A. Boulis. Castalia: A Simulator for WSN.
http://castalia.npc.nicta.com.au/.
[9] H. N. Pham, D. Pediaditakis, and A. Boulis. From Simulation to Real Deployments
in WSN and Back. Networks and Pervasive Computing program, National ICT
Australia, 2007.
[10] Crossbow. TelosB Mote Plattform.
[11] J. N. Al-karaki, A. E. Kamal. Routing Techniques in Wireless Sensor Networks:
A Survey. IEEE Wireless Communications, 2004.
[12] G. Ács, L. Buttyán. A Taxonomy of Routing Protocols for Wireless Sensor Networks, 2007.
109
Literaturverzeichnis
[13] J. Park, S. Sahni. Maximum Lifetime Routing In Wireless Sensor Networks, 2005.
[14] A. Manjeshwar, D.P. Agrawal. TEEN: a routing protocol for enhanced efficiency in
wireless sensor networks. IEEE Parallel and Distributed Processing Symposium.,
Proceedings 15th International, 2001.
[15] W. R. Heinzelman, A. Chandrakasan, H. Balakrishnan. Energy-efficient Communication Protocols for Wireless Microsensor Networks. Proc. Hawaaian Int’l Conf.
on Systems Science, 2000.
[16] T. Armstrong, M. Mende. Konzeption und Entwurf einer FPGA-basierten
Sensorknoten-Entwicklungsplattform. Diplomarbeit, Universität Karlsruhe (TH),
2007.
[17] M. Fischer. Konzeption eines energieeffizienten Protokolls für ein Kamerasensornetzwerk. Diplomarbeit, Universität Karlsruhe (TH), 2007.
[18] D. Dueck. Anbindung eines CMOS Bildsensor an den Hyperion-Sensorknoten.
Studienarbeit, Universität Karlsruhe (TH), 2007.
[19] S.Kobbe. Entwurf und Implementierung der Infrastruktur für den FPGA-basierten
Sensorknoten Hyperion. Studienarbeit, Universität Karlsruhe (TH), 2007.
[20] W. Allen, G. Lorincz, K. Ruiz, M. Marcillo, O. Johnson, J. Lees, J. Welsh, M. Div.
of Eng. & Appl. Sci., Harvard Univ., Cambridge, MA, USA. Deploying a wireless
sensor network on an active volcano. In Internet Computing, IEEE, volume 10,
Issue: 2, pages 18– 25. 2006.
[21] R. Murty, G. Mainland, I. Rose, A. R. Chowdhury, A. Gosain, J. Bers, and M.
Welsh. CitySense: A Vision for an Urban-Scale Wireless Networking Testbed.
In Proceedings of the 2008 IEEE International Conference on Technologies for
Homeland Security, Waltham, MA. 2008.
[22] R. Kistler, A. Klappoth, p.a. media Verlag. Das Haus, das vordenkt. 2007.
[23] R. Kistler, S. Knauth and A. Klapproth, Lucerne University of Applied Sciences
and Arts. EnerBee - Example of an Advanced Metering Infrastructure based on
ZigBee, 2008.
[24] A. Chandra-Sekaran, G. Flaig, C. Kunze, W. Stork, K. D. Müller-Glaser. Efficient Resource Estimation During Mass Casualty Emergency Response Based on
a Location Aware Disaster Aid Network. European Conference on Wireless Sensor
Networks Bologna Italy. Lecture Notes in Computer Science, Springer Berlin /
Heidelberg, 2008.
[25] M. Welsh D. Malan, T. Fulford-jones and Steve Moulton. Codeblue: An ad hoc
sensor network infrastructure for emergency medical care. In In International
Workshop on Wearable and Implantable Body Sensor Networks, 2004.
110
Literaturverzeichnis
[26] Crossbow. MICAz Wireless Measurement System.
[27] Artikel der Zeitschrift Stern über die Betty TV Fernbedienung. http://www.
stern.de/computer-technik/technik/:TV-Fernbedienungen-Daten-Betty/
596541.html.
[28] Boop: Open Source Firmware für die Betty Fernbedienung. http://bettyhacks.
com/wiki/index.php/Boop.
[29] M. Pedram, Q. Wu. Design Considerations for Battery-Powered Electronics, 1999.
[30] D. Panigrahi, C. Chiasserini, S. Dey, R. Rao and K. Lahiri. Battery Life Estimation
of Mobile Embedded Systems. In Proc. Int. Conf. VLSI Design, pages 55–63, 2001.
[31] R. Rao, S. Vrudhula, S. Rakhmatov, University of Arizona. Battery modeling for
energy aware system design, 2003.
[32] M. Zuniga, B. Krishnamachari. Analyzing the transitional region in low power
wireless links. In In First IEEE International Conference on Sensor and Ad hoc
Communications and Networks (SECON, pages 517–526, 2004.
[33] G. Zhou, T. He, S. Krishnamurthy and J. A. Stankovic. Impact of Radio Irregularity on Wireless Sensor Networks. In in MobiSYS ’04: Proceedings of the
2nd international conference on Mobile systems, applications, and services, pages
125–138. ACM Press, 2004.
[34] Free Software Foundation. GNU General Public License 3.0, 2007. http://www.
gnu.org/licenses/gpl-3.0.html.
[35] Ronetix Cross Development Toolchain (arm-elf-4.1.1, newlib).
ronetix.at/software.html.
http://www.
[36] Chipcon/Texas Instruments. CC1100 Low-Cost Low-Power Sub- 1 GHz RF Transceiver.
[37] E. Belding-Royer C. Perkins and S. Das. Ad hoc On-Demand Distance Vector
(AODV) Routing. RFC 3561 (Experimental), 2003.
[38] B. Awerbuch, D. Holmer and H. Rubens. The pulse protocol: Energy efficient
infrastructure access. Proceedings of IEEE INFOCOM 2004, Hong Kong, China,
2004.
[39] D. Estrin R. Govindan. Directed diffusion: A scalable and robust communication
paradigm for sensor networks. pages 56–67, 2000.
[40] S. Brown, Dept. of Computer Science, National University of Ireland, Maynooth,
C.J. Sreenan, Mobile & Internet Systems Laboratory, Dept. of Computer Science,
University College Cork, Ireland. Updating software in wireless sensor networks:
A survey, 2006. Technical Report UCC-CS-2006-13-07.
111
Literaturverzeichnis
[41] P. Levis, N. Lee, M. Welsh and D. Culler. TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications.
[42] P. Levis and N. Lee. TOSSIM: A Simulator for TinyOS Networks, 2003.
[43] P. Levis, S. Madden, J. Polastre, R. Szewczyk, A. Woo, D. Gay, J. Hill, M. Welsh,
E. Brewer and David Culler. Tinyos: An operating system for sensor networks. In
in Ambient Intelligence. Springer Verlag, 2004.
[44] C.L. Hedrick. Routing Information Protocol. RFC 1058 (Historic), 1988. Updated
by RFCs 1388, 1723.
[45] K. Srinivasan and P. Levis. RSSI is Under Appreciated. In Proceedings of the
Third Workshop on Embedded Networked Sensors (EmNets), 2006.
[46] R. Grossmann, J. Blumenthal, F. Golatowski and D. Timmermann. Localization
in Zigbee-based Sensor Networks.
[47] Chipcon/Texas Instruments. CC2430 System-on-Chip Solution for 2.4 GHz IEEE
802.15.4 / ZigBee.
[48] NXP. UM10114 Volume 1: LPC2210/2220 User Manual.
[49] Networked and Embedded Systems Lab (NESL) at UCLA. SOS: an operating
system for mote-class wireless sensor networks.
112