Diplomarbeit ? Konzeption und Evaluierung eines ... - CES

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

Inhaltsverzeichnis 

Danksagung I 

1 Einleitung und Motivation 1 

1.1 Sensorknoten und Sensornetze . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.2.1 Vorgehensweise beim Entwurf . . . . . . . . . . . . . . . . . . . 2 

1.2.2 Gründe und Probleme dieser Vorgehensweise . . . . . . . . . . . 2 

1.2.3 Ansätze zur Verbesserung der Situation . . . . . . . . . . . . . . 4 

1.3 Zielsetzung dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

1.3.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.3.2 Stichwortartige Auflistung der Fähigkeiten und Funktionen des 

entworfenen Systems . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.3.3 Ähnliche Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . 6 

1.4 Aufbau dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2 Systemvision und Einsatzmöglichkeiten 9 

2.1 Systemvision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2 Einsatzmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2.1 Datensammlung . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.2 Bildübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.2.3 Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . 12 

3 Analyse und Anforderungsspezifikation 15 

3.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . 16 

3.3 Gegebenheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

3.3.1 Hardwareplattform . . . . . . . . . . . . . . . . . . . . . . . . . 20 

3.3.2 Messung der Leistungsaufnahme . . . . . . . . . . . . . . . . . . 22 

3.3.3 Messung der Abstrahlcharakteristik . . . . . . . . . . . . . . . . 28 

3.3.4 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

4 Systementwurf 31 

4.1 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

4.1.1 Architektur der Firmware . . . . . . . . . . . . . . . . . . . . . 31 

4.1.2 Aufteilung des Speichers . . . . . . . . . . . . . . . . . . . . . . 34 

4.1.3 Architektur der Anwendung . . . . . . . . . . . . . . . . . . . . 35 

III

4.2 Software Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

4.2.1 Übertragung über die serielle Schnittstelle . . . . . . . . . . . . 44 

4.2.2 Übertragung per Funk . . . . . . . . . . . . . . . . . . . . . . . 44 

4.2.3 Bindeglied Firmware / Anwendung . . . . . . . . . . . . . . . . 44 

4.3 Netzwerkarchitektur und Protokolle . . . . . . . . . . . . . . . . . . . . 47 

4.3.1 Grundlegende Datenübertragung . . . . . . . . . . . . . . . . . 47 

4.3.2 Protokoll der kabellosen Softwareaktuallisierung . . . . . . . . . 49 

4.3.3 Nachbarschaftsbeziehung . . . . . . . . . . . . . . . . . . . . . . 54 

4.3.4 Signalisierung und Routenmanagement . . . . . . . . . . . . . . 55 

4.3.5 Netzweite Datenübertragung . . . . . . . . . . . . . . . . . . . . 62 

5 Implementierung und Testumgebung 69 

5.1 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

5.1.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

5.1.2 Ansteuerung des Funkchips . . . . . . . . . . . . . . . . . . . . 75 

5.1.3 Automatische Codeerzeugung für Anwendungsaustausch . . . . 76 

5.1.4 Software-Update Protokoll . . . . . . . . . . . . . . . . . . . . . 81 

5.1.5 Routenauswahl und -bewertung . . . . . . . . . . . . . . . . . . 84 

5.1.6 Nachrichtenbündelung . . . . . . . . . . . . . . . . . . . . . . . 88 

5.2 Testdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

5.2.1 Behandlung von Fehlern auf dem Datenpfad . . . . . . . . . . . 95 

5.2.2 Zeitsynchronisierung . . . . . . . . . . . . . . . . . . . . . . . . 95 

5.2.3 Übertragungseffizienz und Belastbarkeit . . . . . . . . . . . . . 98 

5.2.4 Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . 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 Kosten 2 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

a) Messung und Modellparametrisierung 

1.2. Ausgangssituation 

b) Simulation c) Realität? 

? 

realer Knoten simulierter Knoten 

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 Kamera 3 aufgenommenen 

Lichtstrahlen 4 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 Die Kamera entspricht dem Empfänger 

4 Funkwellen niedriger Frequenz verhalten sich zwar nicht exakt wie Lichtstrahlen, mathematische 

Modelle zur Berechnung der Wellenausbreitung existieren jedoch entsprechend. 

3


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 Sensornetzwerk-Erweiterungen 

wie z.B. ” Castalia“ einen (mit Störungen behafteten) Funkkanal 

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 Simulation 

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 m 2 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 c) Realität! 

realer Knoten 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 

nicht 5 gibt. Stichpunktartig werden diese hier vorgestellt: 

5


Auswahl der Route auf Anwendungsebene wählbar nach: vorhandenen Energiereserven, 

Latenz, Bandbreite 1 

Kommunikation auf mehreren Kanälen zur Reduzierung der Kollisionen während 

der Datenübertragung und dadurch mehr verfügbare Übertragunskapazität im 

Netz 2 

Dynamische Bewertung von Kanälen und Vermeidung von potentiell gestörten 

oder belegten Kanälen ( ” Blacklisting“) 3 

Adaptive Anpassung der Datenrate und Sendeleistung zwischen zwei Nachbarn 

zur Optimierung des Energieverbrauchs und der Zuverlässigkeit 4 

Selbstorganisierende, netzweite (Multihop) Kommunikation ohne zentrale Infrastruktur. 

Jeder Knoten im Netz ist gleichwertig 5 

Mehrere Routen zu verschiedenen Zielen mit automatischer Umgehung lokaler 

Störungen 6 

Vermeidung von Routen, welche über Knoten mit geringem Batterieladestand 

führen zur Optimierung der Gesamtlaufzeit 7 

Netzweit synchrone Zeit mit einer Genauigkeit besser als einer Sekunde 8 

Store- and Forward Nachrichtenweiterleitung mit automatischer Bündelung der 

Nachrichten 9 

Aufteilung der Systemsoftware in zwei Komponenten (Anwendung und Firmware), 

welche unabhängig voneinander weiter entwickelt werden können mit automatischer 

Erzeugung des Schnittstellencodes 10 

Gleichzeitige Software-Aktualisierung aller Knoten per Funk 11 

Automatische Protokollierung des Systemverhaltens 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! 

6

1.4. Aufbau dieser Arbeit 

Das in dieser Arbeit entworfene und implementierte Routing- und Nachrichtenweiterleitungsprotokoll 

enthält einige neue 5 ( 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. 

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


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 Datenverarbeitung 

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 ?44,2-=&3!@"@! 

(aus [16]) 

I,&!*80%)848',%)+%'!$%&'()&%+E1%)*! 

relevante J%,! -%0! Informationen 80! XY.8,)! YI$A! Infrastruktur ,&! -%)! I&+1,D*2=&3! erfasst und weitergeleitet 

4%


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 Disaster 

Aid Network“ vorgestellt[24]. Es handelt sich hierbei um ein selbstorganisierendes 1 

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 EKG 2 auch von der Havard Universität 

mit dem Projekt ” CodeBlue“ aufbauend auf den MICA2, MICAz und Telos 

1 außer der Platzierung der festen Knoten und die Bekanntgabe deren Position 

2 Elektrokardiogramm (EKG) heißt auf Deutsch Herzspannungskurve. Es zeigt die Kontraktionen 

des Herzmuskels an. 

12

Sensorknoten angestrebt.[25, 3, 26, 10] 

2.2. Einsatzmöglichkeiten 

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 Routingknoten 

3 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


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“) notwendig. 

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ückfahren 1 . 

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 aufgebaut: 

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


Abbildung 3.1: Übersicht Hardwareplattform Diagramm 

Echtzeituhr 

Flash Speicher 

(2 MByte NOR) 

LCD 

(160x128 Pixel) 

i²c 

CPU 

(32 Bit ARM7) 

18 

Funkchip 

(Chipcon cc1100) 

pwm 

SPI 

UART 

GPIO 

JTAG 

Audio 

IR

Funk 

2,5 Volt 

Linearregler 

RTC 

Flash 

CPU 

Abbildung 3.2: Übersicht Hardwareplattform Foto 

Schaltregler 

IR 

Audio 

0,1 Ohm 

Messwid. 

19 

GPIO und UART 


LCD


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 70Mhz 2 gewählt werden. Ein fest integrierter Bootloader ermöglicht es, Software 

über die serielle Schnittstelle einzuspielen. Die typische Peripherie (gängige 

Schnittstellen, JTAG 3 , Timer, Counter, PWM 4 , ...) 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 Energiebedarf 

zu minimieren. 

Flash Speicher 2 Mbyte NOR (EON en29lv800) 

Als Festspeicher sind zwei Flashbausteine mit je 8 Mbit verbaut. Sie sind als 

512k*16Bit 5 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, 400- 

464 MHz und 800-928 Mhz 6 . 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 direkt 

von der Hardware unterstützt. Die Anbindung an den Prozessor erfolgt über 

SPI 7 . Der Funkchip verfügt neben einem ” Power-Down“ auch über einen ” Idle“ 

2Im Rahmen dieser Arbeit wird zwischen 10MHz, 20MHz und 40MHz umgeschaltet – je nach Bedarf 

der Anwendung 

3JTAG steht für Joint Test Action Group“ und bezeichnet ein Standardinterface zum Testen und 

” 

Debuggen von Hardware direkt in der Schaltung 

4Bei 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 

5512k*16Bit bedeutet 524288 einzeln adressierbare Wörter je 16Bit 

6Im Rahmen dieser Arbeit wurde das in Deutschland lizenzfrei zugelassene ISM Band von 433,05- 

434,79 MHz verwendet. ISM steht hierbei für Industrial, Scientific, and Medical 

7Serial Peripheral Interface – Serielles Bus-System (Motorola) 

20


und einen ” Wake-on-Radio“ Modus. Im Wake-on-Radio Modus lauscht der Funkchip 

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 I 2 C 8 -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 100W 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öglichkeiten 

9 der meisten kommerziell verfügbaren Sensorknoten macht es die Betty- 

Fernbedienung 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 PWM 4 

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. 

8Inter-Integrated Circuit – Serielles Bus-System (Philips). Auch bekannt unter TWI (Two Wire 

Interface) 

9meist nur einige wenige LED in verschiedenen Farben 

21


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, 

I 2 C, UART 10 , 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 GPIO 11 -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 

10Universal Asynchronous Receiver Transmitter, Kompatibel zu RS-232, welches einen Standard für 

eine serielle Schnittstelle bezeichnet 

11General Purpose Input/Output – Universal verwendbare Ein-/Ausgabe 

22

mW 

200 

175 

150 

125 

100 

75 

50 

25 

0 

Power down 

Funkchip 

Grundsystem 

CPU 10 MHz CPU 40 MHz 

CPU idle 

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


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. 


Als Taktrate für die CPU sind bei dieser Messung 20MHz gewählt, alles Weitere 

entspricht der vorausgehenden Messung. 


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 doppelt 12 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 Unterschied, 

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

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 Sendeleistung 13 – 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 effizienter 14 die Implementierung ist, desto längere Laufzeiten 

des gesamten Sensornetzes 15 können erzielt werden. 

25


Batteriespannung [V] 

2,8 

2,75 

2,7 

2,65 

2,6 

2,55 

2,5 

2,45 

2,4 

2,35 

2,3 

2,25 

2,2 

Zeit [h] 

Passiver Knoten 

Aktiver Knoten 

0 30 

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

a) Modell b) Messung 

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


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 Kreis 16 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 abnimmt 17 . 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] vorgestellt. 

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 Universalfernbedienung 

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. 

13dBm ist ein logarithmisches Leistungsmaß mit der Bezugsgröße 1mW. -30dBm entsprechen daher 

0.001 mW, -15dBm etwa 0.03mW, 0dBm 1mW und 10dBm 10mW 

14bei gleicher Leistung 

15einzelne Knoten können unter Umständen bereits vorzeitig ausfallen ohne dass dies die Gesamtfunktionalität 

einschränkt! 

16Eigentlich wäre eine Kugel das richtige Modell, in der Simulation wird das Netz jedoch oft in nur 

einer Ebene zweidimensional dargestellt. 

17Da die Antenne im Gehäuse mehrfach gefaltet ist, wäre eine gleichmäßige Abstrahlcharakteristik 

eher erstaunlich gewesen. 

28


” Boop“ steht unter der GPL18 3.0. Obwohl in dieser Arbeit nicht mehr viel der ursprü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


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 einem 

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 Hauptanwendung 1 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 Hauptanwen- 

dung eingeflossen sind. 

31

Kapitel 4. Systementwurf 

Firmware Anwendung 

Hardware Abstraktion 

ADC 

Power 

Watchdog 

Flash 

Audio 

Sensornetz- und Knotenlogik 

Laufzeitprotokoll Energieverwaltung Ereignisverarbeitung 

Schnittstelle zur Firmware (Pointertabelle) 

RTC 

IRQ 

Timer 

LCD 

STDIO 

Callback Mechanismus 

Software Update 

Hardware 

RF Komponente 

Paket Empfangen 

Paket Senden 

Chip Konfigurieren 

Wake on Radio 

Abbildung 4.1: Grober Überblick über die zweigeteilte Softwarearchitektur. Gezeigt 

werden die wesentlichen Komponenten der Firmware und der Anwendung. 

32

Hardwareabstraktion 

4.1. Softwarearchitektur 

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 Funktionen 

2 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 ” Callbacks“ 

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 API 3 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“ Mechanismus 

(siehe 3.3.1 und 4.3.1). Über die bereits vorgestellte Callback-Schnittstelle kann die 

2 Die aufgerufenen Funktionen werden ” Callback-Funktionen“ genannt. 

3 API steht für engl. application programming interface, deutsch: ” Schnittstelle zur Anwendungsprogrammierung“. 

Im weiteren Sinne wird die Schnittstelle jeder Bibliothek (Library) als API 

bezeichnet. 

33


0x80000000 

0x80020000 

0x80040000 

0x80060000 

0x80070000 

Firmware 

Anwendung 

temporäre Anwendung 

Nachrichtenindex 

Nachrichtenwarteschlange 

Flash 0 

Logdaten 

Konfiguration 

Flash 1 

0x82000000 

0x820f0000 

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 

Implementierung der 

verschiedenen Szenarien 

Aufgabenverwaltung 

Nachrichtenverwaltung und 

-verarbeitung 

Schnittstelle zur Firmware (Pointertabelle) 


Kanal- und Knotenbewertung 

Routing und Routenverwaltung 

Energieverwaltung 

Laufzeitprotokoll Ereignisverarbeitung 

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 ” Anwendung 

/ 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


b) c) 

a) gestörte Kanäle 

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örsenders 4 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 ” belegt“ 

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

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: 

 

Nachrichtenlänge 

EÜbertragung = n ∗ 

Datenrate 

Aufgabenverwaltung 

∗ (PSendeleistung + PGrundleistung) 

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


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


Source Prev Target Next Length Seq. Nr DR SL Bat. Flags Errors Rating Path 

a) 1 1 2 255 32 1234 NONE NONE 255 0x01 0 0/0 1 

b) 1 0 3 3 1 8214 MAX MIN 92 0x10 1 9/1 1,3 

c) 1 0 100 3 4 4382 MED LOW 50 0x02 0 0/0 1,3.. 

d) 4 3 55 255 30 8215 NONE NONE 255 0x01 0 0/0 4,3,1 

e) 255 255 255 255 0 0 0 0 0 0x00 0 0/0 0 

Routenwahl 

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 Energieeffizienz 6 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, 

5Zusätzlichen Einfluss hatten The Pulse Protocol“[38] und das Directed Diffusion“ Protokoll[39] 

” ” 

für kabellose Sensornetze. 

6Die Energieeffizienz bedeutet hierbei auch, dass vorzugsweise Knoten gewählt werden, welche über 

einen vollen Akku verfügen. 

39


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 konnte 8 – 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 gekennzeichnet 9 . 

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

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“) wechseln, 

aus dem sie sehr schnell wieder aufwachen kann. Zusätzlich kann die Taktfrequenz 

der jeweils aktuellen Aufgabe angepasst werden 10 . Der Funkchip verfügt ebenfalls über 

einen Power-Down- und einen Idle-Modus. Als weitere Möglichkeit kann ein Wake-on- 

Radio 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, 

1 ist jedoch ausgeschlossen. 

10 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


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 Eintrag 11 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

a) b) 

4.2. Software Deployment 

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


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 FPGAbasierten 

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 GUI 12 , 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 ” newlib“ 

mit den typischen Funktionen wie memcpy() oder printf(). 

12 Graphical User Interface, englisch für grafische Benutzeroberfläche 

44

Hardware Abstraktion 

ADC 

Power 

WD 

Flash 

RTC 

IRQ 

Timer 

LCD 

Audio STDIO 

„Callbacks“ 


RF Komponente 

Paket Empfangen 

Paket Senden 

Konfigurieren 

Wake on Radio 

Firmware.elf 

Header Files 

#!/usr/bin/perl 

@WISHLIST=(„puts“, 

...) 

Konvertier-Skript 

h 

c 

Generierter Code 

4.2. Software Deployment 

App. Code 

Sensornetz- und Knotenlogik 

Laufzeitprotokoll Energieverwaltung Ereignisverarbeitung 

Schnittste lle zur Firmware (Pointertabelle) 

App.elf 

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 besteht 13 . 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


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 Skript 14 , 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 Compiler 15 

ü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] 

14In der Variable @WISHLIST des Perl-Skripts make fptrs.pl werden die zu exportierenden Funktionen 

gelistet. 

15Die 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 

16bit Länge 

Preamble Sync Länge Ziel Quelle Typ 

Nutzdaten 

crc-16 

(optional) 

n*8 Bit 32 Bit 8 Bit 8 Bit 8 Bit 8 Bit 16 Bit Länge * 8 Bit 

16 Bit 

Hardware Software 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


Wake-On-Radio Paket 

Wake-On-Radio ACK-Paket 

Generisches ACK-Paket 

0x06 Weckgrund 

0x05 Weckgrund 

0x05 

8 Bit 

8 Bit 

Signalst. 

8 Bit 

P S 1/3/4 Z Q Typ Nutzdaten 

crc 

Prüfsumme 

32 Bit 

Zielkanal 

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 

8 Bit


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 Weckgrundes, 

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 verschickt 16 . Zusätzlich kommen negative Bestätigungen ( ” NACK 17 “) 

zum Einsatz, die dem Sender anzeigen, dass bei mindestens einem Empfänger Feh- 

ler 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 Update- 

Routinen 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 In der aktuellen Implementierung wird jedes Paket 10 mal verschickt. 

17 NACK ist die Abkürzung für not acknowledged (= Ablehnung) 

49


a) Broadcast 

b) Unicast 

Knoten A Knoten B Knoten C 

Nachricht 

Nachricht 

Nachricht 

Nachricht 

c) Unicast 

Nachricht 

bestätigt ACK (Nachricht) 

d) Wake-on- 

Radio 

Broadcast 

Unicast 

WoR (C) 

WoR (C) 

Empfangsbereit 

Sender aktiv 

ACK (WoR) 

inaktiv („Idle“) 

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

Finish 

Nack 

Data 

Setup 

Prepare 

FINISH ID 

0x05 0x05 0xFF 

NACK ID 

0x04 0x04 0xFF 

DATA ID Daten Position 

0x03 0x03 0xFF 

SETUP ID 

0x02 0x02 0xFF 

PREP ID 

0x01 0x01 0xFF 

Flags 

8 Bit 

Flags 

8 Bit 

Timesync (µS) 

24 Bit 32 Bit 


crc32 Anw. 

32 Bit 

NACK-Position 

32 Bit 

P S L 0xFF Q 0x04 L16 Nutzdaten crc 

Daten 

32 Bit 1..512 Byte 

Gesamtlänge crc32 Anw. crc32 Firmware 

32 Bit 32 Bit 32 Bit 

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


Zeit Sender Empfänger A Empfänger B 

-10 

-5 

0 

10 

15 

20 

25 

30 

35 

100 

105 

110 

115 

120 

125 

210 

215 

220 

E 

Wake 

Prepare 

Setup 

Data (0..2) 

Data (3..5) 

ACK 

Data (4..6) 

Data (13..15) 

G 

Finish 

NACK (0) 

Data (0..2) 

Finish 

NACK (3) 

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 

D 

F 

A 

B 

C


werden die mehrfach übertragenen Pakete nur als eine ” logische“ Übertragung dargestellt. 

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 ” Wakeon-Radio“ 

Mechanismus zum Einsatz. Als Weckgrund wird ” Softwareupdate“ angegeben, 

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 Position 

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


Nachbarschafts Information 

0x0E 

Bake 0x0F 

DR 

8 Bit 

SL 

8 Bit 

Seq. Nr. 

16 Bit 

res. Bat. Seq. Nr. Systemzeit 

8 Bit 8 Bit 

16 Bit 32 Bit 

P S 5/8 Z Q Typ Nutzdaten 

crc 

Bat. 

8 Bit 

DR: max. Datenrate 

SL: min. Sendeleistung 

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 = TWake + TSync + TInit + 

DDelay = (100ms ∗ Datenrate) ∗ DUpdate 

T Übertragung ≈ 5s + 7s + 5s + 

 

DUpdate ∗ n + DDelay 

∗ TIntervall + TFinish 

Datenrate ∗ 4s 

DNachricht 

 

 

DUpdate ∗ (10 + 6) 

250000 Bit 

s 

∗ 4s 

≈ 6 ∗ DUpdate 

∗ 10s + 10s 

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


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 neuen 

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 sichergestellt, 

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


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 Distance- 

Vector 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


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 TTL 20 -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 nahezu 

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


Route Error Paket 

(RERR) 

Route Reply Paket 

(RREP) 

Route Request Paket 

(RREQ) 

0x12 

0x11 

0x10 

Knotenliste 

Ziel 

Ziel 

8 Bit 

n*8 Bit 

Hops Seq. Start Seq. Flags 

8 Bit 16 Bit 8 Bit 16 Bit 32 Bit 

DR SL (minimal) 

Bat. 

(local) 

Bat. 

TTL Seq. Start Flags (local) 

Bat. 

P S L Z Q Typ Nutzdaten 

crc 

DR: max. mögliche Datenrate 

SL: min. nötige Sendeleistung 

(local) 

Zeit 

(local) 

Seq. 

(local) 

Seq. 

4 Bit 4 Bit 8 Bit 8 Bit 32 Bit 16 Bit 

(local) 

Zeit 

8 Bit 16 Bit 8 Bit 32 Bit 8 Bit 16 Bit 32 Bit 

kompl. Pfad 

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 Datenrate 21 , die hierzu minimal benötigte Sendeleistung 22 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 Also die Datenrate des niedrigsten Teilstücks 

22 Das Teilstück, welches die höchste Sendeleistung benötigt, bestimmt diesen Wert 

58 

n*8 Bit

Behandlung eines eingehenden ” Route-Request“-Paketes 


Empfängt ein Knoten ein ” Route-Request“-Paket von einem anderen Knoten, so überprü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 Route- 

Request 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


Abbildung 4.16: Behandlung eines eingehenden ” Route-Request“-Paketes 

Bin ich das Ziel? 

Liegt genau dieses Route-Request bereits vor? 

(Ziel, seq. Nr) 

nein 

Habe ich eine Route zum Ziel oder bereits 

ein anderes Route-Request zum Ziel? 

nein 

nein 

Route-Request an alle anderen 

Nachbarn weiterleiten! 

ja 

ja 

Paket verwerfen 

Route-Reply verschicken 

Ist das Ziel mein Nachbar 

oder habe ich eine bestehende Route zum Ziel? 

nein 

Handelt es sich um einen 

anderen Ursprungsknoten? 

nein ja 

ja 

Ausführen für alle Einträge in der 

Routingtabelle zum Ziel 

ja 

Route-Reply verschicken 

Eintrag in Routingtabelle aktualisieren. Neuen Request-Eintrag in Routingtabelle. 

Request TTL größer als bisher? 

ja 

Route-Request an alle anderen 

Nachbarn weiterleiten! 

60


Abbildung 4.17: Behandlung eines eingehenden ” Route-Reply“-Paketes 

Bin ich das Ziel dieses Route-Replys? 

nein 

Enthält der Pfad eine Schleife? 

Wurde genau dieses Route-Reply bereits 

verarbeitet? 

nein 

nein 

Neue Route in Routingtabelle übernehmen 

Hatten wir überhaupt (mind.) ein aktives 

Route-Request zu diesem Ziel? 

nein 

keine weitere Aktion 

ja 

ja 

ja 

ja 



Ausführen für alle offenen 

Route-Requests zum Ziel 

Route-Reply weiterleiten 


Timeout des Request-Eintrag in Routingtabelle 

auf MULTI_ROUTE_TIMEOUT setzen 

61


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“ Nachrichtenweiterleitung 

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


Abbildung 4.18: Behandlung eines von Knoten ” A“ eingehenden ” Route-Error“- 

Paketes. 

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 

Fehlerflag auf true setzen 

keine weitere Aktion 

nein 

Ausführen für alle nicht mehr über 

Knoten X erreichbaren Knoten Y 

Fehlerflag gesetzt? 

ja 

ja 

weiter... 

Route-Error Paket mit einer Liste aller nicht mehr 

über mich erreichbaren Knoten an alle meine 

Nachbarn verschicken 

63


G, [DFG], A 

Ziel, Pfad, Ursprung 

A) 

B: B 

C: C 

D: D 

G: -?- 

Routingtabelle 

Ursprung, Ziel 

[XYZ] 

A B 

A, G 

C D E 

F G 

Nicht mehr erreichbare Knoten 

X 

Nachbarschaft 

Route Request 

Route Reply 

Route Error 

Knoten mit ID X 

Hindernis 

..... Inhalt der Nachricht 

Abbildung 4.19: Legende der Signalisierung und Routenmanagement Grafik 

a) 

A, G 

b) 

A, G 

A) 

B: B 

C: C 

D: D 

G: -?- 

A B 

C D E 

A B 

A, G 

F G 

c) d) 

G, [EG], A 

A) 

B: B 

C: C 

D: D 

G: -?- 

G: DG 

C D E 

G, [FG], A 

F G 

A) 

B: B 

C: C 

D: D 

G: -?- 

G: DG 

A, G 

A) 

B: B 

C: C 

D: D 

G: -?- 

G: DG 

G: BEG 

G: CFG 

G, [DG], A 

A B 

A, G 

C D E 

G, [BEG], A 

A B 

A, G 

F G 

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

Daten 

Data Finish 

Data Setup 

0x15 

0x16 

0x14 

Länge 

n/a 

n/a 

0 Bit 

n/a 

0 Bit 0 Bit 


Prio RS Länge Typ Flags Quelle Ziel Seq. Nr. TTL Pfad 

4 Bit 4 Bit 16 Bit 4 Bit 9 Bit 8 Bit 8 Bit 16 Bit 8 Bit 

0..32 Byte 

Nachrichtenkopf 

DR SL Systemzeit 

8 Bit 8 Bit 

32 Bit 

P S L Z Q Typ L16 Nutzdaten crc 

Nachricht 

0 / 16 Bit 0..512 Byte 

DR: Datenrate 

SL: Sendeleistung 

RS: Routen Style 

Abbildung 4.21: Aufbau der zum Nachrichtenaustausch verwendeten Pakete. (DATA- 

SETUP, 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“-Mechanismus 

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


Phase 1: 

Partner wecken 

Phase 2: 

Übertragungskanal wechseln 

und Übertragungsparameter 

aushandeln 

Phase 3a: 

Übertragung „Hinrichtung“ 

*) es sind hier nur zwei Nachrichten 

dargestellt. Es könnten jedoch 

dutzende sein! 

Phase 3b: 

Abschluss „Hinrichtung“ 

Phase 4a: 

Übertragung „Rückrichtung“ 

*) nur, wenn überhaupt Nachrichten 

zur Übertragung auf dem Rückweg 

ausstehen! 

Phase 4b: 

Abschluss „Rückrichtung“ 

Knoten A Knoten B 

WoR 

ACK 

DATA SETUP 

ACK 

DATA SETUP 

ACK 

DATA 

ACK 

DATA* 

ACK 

DATA FINISH 

ACK 

DATA* 

ACK 

DATA* 

ACK 

DATA FINISH 

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. 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 Multihop- 

Nachrichtenweiterleitung in einem kleinen Netz beispielhaft dargestellt. 

67


a) b) c) 

C F 

C F 

A B 

D E 

G A B 

A B 

D E 

d) e) f) 

C 

C 

A B 

A B 

D E 

g) h) i) 

C 

C 

A B 

D E 

Fehlermeldung 

Nachricht 

D E 

G 

D E 

möglicher Pfad 

verwendeter Pfad 

A Datenquelle G Datensenke 

G 

G 

G A B 

G 

A B 

A B 

F 

C 

D E 

C 

F 

D E 

C 

D E 

erfolgloser Pfad 

G 

G 

G 

ausfallender Knoten 

G „normaler“ Knoten 

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 Implementierung 

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 

/ 

jars 

gnu 

ces 

firmware 

io 

getopt 

terminal 

watchdog 

lowpower 

cc1100 

sensornode 

interrupt 

flash 

display 

audio 

adc 

serial 

rtc 

Java-GUI 

aus „boop“-Firmware übernommen bzw. angepasst 

app 

simple 

monitor 

scanner 

rf_test 

power_test 

logtool 

entladekurve 

dauerbake 

Hauptanwendung 

syslog.c 

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 werden 1 . 

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 kabellosen 

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


” 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. sollte 2 

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 Ausgabefunktionen 

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 verwenden 

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 aufaddiert 3 , 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

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-Dateien 4 umwandeln. 

4 Comma-Separated Values. Diese Dateien können dann z.B. zur Erzeugung von Diagrammen ver- 

wendet werden. 

73


Zeilen Programmcode 

11000 

10000 

9000 

8000 

7000 

6000 

5000 

4000 

3000 

2000 

1000 

0 


Ansteuerung Funkchip 

Hardwareabstraktion, ... 

Nachrichtenübermittlung 

Routing 

Verwaltung, ... 

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 Hauptanwendung 

die Teilkomponenten Routing“ und Nachrichtenübermittlung“. 

” ” 

Es folgt nun eine detaillierte Vorstellung einiger ausgewählter Punkte der Implementierung. 

74


Abbildung 5.3: Verschiedene Zugriffsarten auf die Register des Funkchips[36] 

5.1.2 Ansteuerung des Funkchips 

Der Funkchip wird über SPI 5 an den Microcontroller angebunden. Auf der Seite des 

Microcontrollers wird das SPI durch den SSP 6 -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 FIFO 7 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 

6 Synchronous Serial Port 

7 First In First Out: Elemente werden in genau der Reihenfolge abgerufen, in der sie zuvor abgelegt 

wurden. 

75


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 hierbei 

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. 

8 

7 @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


@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 Signatur 9 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 Textsegment 

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


123 @map = split("\n",‘nm ELF_FILE‘); 

124 for (i=@map; i>0; i--) { 

125 

126 if (map[i] =~ /^(.*) T (.*)/) { # Symbol ist Funktion im Textsegment 

127 adr=1; name=2; 

128 

129 if (grep (/^name/, @WISHLIST)) { # Funktion soll exportiert werden 

130 

131 # Funktionssignatur suchen 

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 while (x 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

ten Funktionspointer zu erstellen: 

142 foreach(@fundstellen) { 

143 # cleanup.. libc 


144 _ =~ s/(.*?)(\s*)(\*)?_EXFUN$(.*?)(\s*?),(\s*?)(.*?)$/13 47/g; 

145 _ =~ s/_PTR/void*/g; 

146 _ =~ s/extern(\s*)//g; 

147 _ =~ s/$_VOID$/$void$/g; 

148 

149 # typ name (sig) 

150 _ =~ /(unsigned |)(.*?)(\s+)(.*?)(\s*)$(.*?)$/; 

151 f_typ=1.2; 

152 f_name=4; 

153 f_sig=6; 

154 

155 if (f_name eq name) { 

156 sig=f_sig; 

157 typ=f_typ; 

158 found="true"; 

159 last; # foreach-Schleife beenden 

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 genid++; 

173 print H_DATEI "typedef typ(*_AUTOGEN_fptr_genid)(sig);\n"; 

174 print H_DATEI "extern _AUTOGEN_fptr_genid const name;\n\n"; 

175 print C_DATEI 

176 "_AUTOGEN_fptr_genid const name=(_AUTOGEN_fptr_genid)0xadr;\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


233 if (array) { # bei der Variable handelt es sich bereits um einen Pointer 

234 print H_DATEI "#define name (((typ*) 0xadr))\n"; 

235 } else { 

236 print H_DATEI "#define name (*((typ*) 0xadr))\n"; 

237 } 

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 typedef int(*_AUTOGEN_fptr_29)(void); 

113 extern _AUTOGEN_fptr_29 const rand; 

114 

115 typedef int(*_AUTOGEN_fptr_30)(const char *); 

116 extern _AUTOGEN_fptr_30 const puts; 

117 

118 typedef int(*_AUTOGEN_fptr_31)(const char *, ...); 

119 extern _AUTOGEN_fptr_31 const printf; 

Listing 5.1: Automatisch erzeugte Funktionspointer in der Datei fptrs.h 

270 #define packet_stat (*((packet_stat_t *) 0x40002144)) 

271 #define TxBuffer (((unsigned char *) 0x40001d44)) 

272 #define SysTime (*((unsigned int *) 0x40001610)) 

Listing 5.2: Globale Variablen in der Datei fptrs.h 

76 _AUTOGEN_fptr_29 const rand=(_AUTOGEN_fptr_29)0x80009d2c; 

77 _AUTOGEN_fptr_30 const puts=(_AUTOGEN_fptr_30)0x80009cfc; 

78 _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 sprintf(TxBuffer,"String!"); 

4 printf("Hallo Welt. Zufallszahl: %d. String: %s\n",rand(), TxBuffer); 

Listing 5.4: Beispielcode einer Anwendung 

80

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 TxBuffer[6]=(SyncIn&0xFF000000)>>24; // den 32 Bit Wert auf 

10 TxBuffer[7]=(SyncIn&0x00FF0000)>>16; // vier Bytes aufteilen 

81


11 TxBuffer[8]=(SyncIn&0x0000FF00)>>8; 

12 TxBuffer[9]=(SyncIn&0x000000FF); 

13 

14 SendPacket(ALL_NODES, TYP_UPDATE , 10, TxBuffer); 

15 

16 feedWatchdog(); /* Verhindern, dass der Watchdog den Knoten neu startet */ 

17 } 

18 while(T0TC


a) b) c) d) e) f) 

Abbildung 5.4: Bildschirmfotos während eines erfolgreichen Softwareupdate- 

Durchlaufs 

Sender Empfänger 

(Zeit mod 10) < 4 ? 

nein ja 

Empfange NACK 

Pakete 

ggf. NACK 

verarbeiten 

Daten Senden 

Paket verarbeiten 

(Zeit mod 10) < 6 ? 

nein 

ggf. NACK 

versenden 

ja 

Paket empfangen 

nein 

Abbildung 5.5: Hauptschleifen der Implementierung des Protokolls für den Sender und 

die Empfänger 

83 

ja


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

CRC okay 

Erfolg 

Prepare 

Prepare 

Start Erwarte Setup 

CRC Check 

Finish 

CRC Fehler 

Fehlschlag 

Daten 

Setup 

Data, Setup 


Zustand 

eingehende 

Nachricht 

Finalzustand 

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


1842 unsigned short rid=0; 

1843 int best_rating=0; 

1844 unsigned short best_rating_route=NO_ROUTE; 

1845 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 if(routes[rid].target == Zielknoten && 

1850 routes[rid].nexthop != 0 && // Unused Slot 

1851 routes[rid].nexthop != 255 && // Route-Request 

1852 !(routes[rid].flags & ROUTE_ERROR) && // nur funktionsfähige Routen 

1853 (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 unsigned char rokay=true; 

1855 if(Path_Blacklist != NULL) { // kompletten Pfad überprüfen 

1856 unsigned char i; 

1857 for (i=0; i


Sendeleistung. Für die Bewertung werden diese Parameter so normalisiert, dass sie jeweils 

im Bereich zwischen 0 und 200 liegen 10 . 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. 

1865 // Die Bewertung basiert auf: 

1866 // Bandbreite routes[rid].min_datarate // 3 ... 10 

1867 // Akkupegel routes[rid].bat_level // 1 ... 200 

1868 // Hopcount routes[rid].hopcount // 1 ... 31 

1869 // Sendeleistung routes[rid].min_power // 1 ... 10 

1870 rating=1000000; 

1871 // Bewerte Route.. 

1872 switch(route_style) { 

1873 case LOW_LATENCY_ROUTE: 

1874 rating -= 300 * ((int)routes[rid].hopcount *7); 

1875 rating -= 1 * (200-(int)routes[rid].bat_level); 

1876 rating -= 1 * ((int)routes[rid].min_power*20); 

1877 rating -= 20 * ((10-(int)routes[rid].min_datarate)*20); 

1878 break; 

1879 

1880 case HIGH_BANDWIDTH_ROUTE: 





1885 break; 

1886 

1887 default: 

1888 case BEST_NETWORK_POWER_ROUTE: 





1893 break; 

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


1896 if (rating > best_rating) { 

1897 best_rating=rating; 

1898 best_rating_route=rid; 

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. 

1900 } // Route ohne Schleife 

1901 } // Route verwendbar 

1902 

1903 rid++; 

1904 } // Hauptschleife 

1905 

1906 return best_rating_route; 

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 get- 

NextNexthopMessage erreicht, die nun beide vorgestellt werden. Die Funktion Send- 

88


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 unsigned char NextHop=routes[nrid].target; 

980 unsigned char retVal=false; 

981 

982 unsigned short iterator=0xFFFF; 

983 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 // Paket zusammenbauen.. 

986 if ( !memcpy(TxBuffer, 

987 &data_route_index[iterator], 

988 sizeof(data_route_index_t))) { 

989 

990 puts(" Fehler beim Koperen (Struct)"); 

991 

992 return false; 

993 } 

89


994 if(data_route_index[iterator].length >= DRQ_MSG_SIZE) { 

995 

996 printf(" Nachricht ist größer als erlaubt (%d)!!\n", 

data_route_index[iterator].length); 

997 


999 } 

1000 

1001 unsigned char hdr_length=getHeaderLength(&data_route_index[iterator]); 

1002 

1003 TxBuffer[hdr_length]=0xFF; // Schutzbyte... 

1004 if((hdr_length+1)%2) { 

1005 // um die Nachricht später bequem ins Flash kopieren zu können, muss 

sie an einer graden "Wortgrenze" beginnen.. 

1006 hdr_length++; 

1007 TxBuffer[hdr_length]=0xFF; // weiteres Schutzbyte... 

1008 } 

1009 

1010 if ( !memcpy(&TxBuffer[hdr_length+1], 

1011 ((unsigned char*)(DRQ_BASE+DRQ_MSG_SIZE*iterator)), 

1012 data_route_index[iterator].length )) { 

1013 

1014 puts(" Fehler beim Kopieren (data)"); 

1015 


1017 } 

1018 

1019 sleep(100000); // warten, bis der andere Knoten bereit ist 

1020 

1021 count=50; 

1022 while(--count) { 

1023 if(SendPacket(NextHop, TYP_DATA | BESTAETIGT, 

1024 data_route_index[iterator].length+hdr_length+1, TxBuffer)) { 

1025 

1026 markSlotSent(iterator); // Nachricht als gesendet markieren 

1027 updateNachbarGood(nrid); // Verbindung zum Nachbarn ist gut 

1028 if(msg_rid != NO_ROUTE) { 

1029 updateRouteUsed(msg_rid); // Timeout der Route zurücksetzen 

1030 } 

1031 break; // Übertragung dieser Nachricht abgeschlossen 

1032 

1033 } else { // Paket konnte nicht verschickt werden 

1034 updateNachbarBad(nrid); // Verbindung zum Nachbarn ist schlecht 

1035 } 

1036 sleep(50000); // Zeit lassen, um Daten ins Flash zu schreiben 

1037 } 

90

1038 if(!count) { 


1039 puts(" Senden fehlgeschlagen !!!!!!"); 

1040 break; // Nach 50 Versuchen konnte eine Nachricht nicht zugestellt 

werden. Es macht keinen Sinn, weitere Nachrichten zu verschicken! 

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. 

1044 sleep(100000); 

1045 

1046 puts(" Sende DATAFINISH"); 

1047 count=50; 

1048 while(--count) { 

1049 if(SendPacket(NextHop, TYP_DATAFINISH | BESTAETIGT , 1, TxBuffer)) { 

1050 retVal=true; 

1051 break; 

1052 } 

1053 sleep((rand()%19000)+10000); 

1054 } 

1055 

1056 return retVal; 

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 unsigned short getNextNexthopMessage(unsigned char nexthop, unsigned short 

iterator_start) { 

532 unsigned irqstat=disableIRQ(); 

533 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

536 


537 unsigned char max_prio=0; 

538 unsigned short max_prio_msg=NO_MSG; 

539 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 if(// Slot ist überhaupt in Verwendung 

549 slotUsed(slot) && 

550 // und noch nicht abgeschlossen 

551 slotWaiting(slot) && 

552 // und noch nicht gesendet 

553 (!checkBit(SlotSentBitmap,slot)) && 

554 // und es gibt eine Route zum Ziel.. 

555 ((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))) && 

556 // und der nächste Schritt auf der gefundenen Route ist der Gesuchte? 

557 (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 if(iterator_start == 0) { 

559 if (data_route_index[slot].priority > max_prio) { 

560 max_prio=data_route_index[slot].priority; 

561 max_prio_msg=slot; 

92

562 msg_rid=rid; 

563 } 

564 } else { 

565 msg_rid=rid; 

566 max_prio_msg=slot; 

567 break; 

568 } 

569 } 

570 slot++; 

571 } 

572 

573 // Durchsuchen des Nachrichtenspeichers abgeschlossen 

574 

575 restoreIRQ(irqstat); 

5.2. Testdurchführung 

576 // 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 

577 return max_prio_msg; 

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 2 

3 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 = 7140m 2 = 0, 007km 2 

93


Abbildung 5.7: Testnetz aus 30 Knoten 

Abbildung 5.8: Knoten bei einem realen Test 

94

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 Echtzeituhr 12 

auf einen GPIO-Pin gelegt. An diesem Pin (von zwei verschiedenen Knoten) wurde ein 

hochwertiges Oszilloskop 13 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 

40s 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 Dieses wird immer genau dann ausgelöst, nachdem die Uhr um eine Sekunde fortgeschritten ist 

13 Agilent MSO6054A Mixed Signal Oscilloscope 

95


a) b) 

Q S Q S 

c) d) 

Q S Q S 

e) f) 

Q S Q S 

Q 

S 

Datenquelle 

Datensenke 

nicht verwendeter 

Knoten 

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


Abbildung 5.10: Gemessenes Interrupt-Signal der Echtzeituhr von zwei Knoten unmittelbar 

nach einer Synchronisierung. Die Genauigkeit von 40s entspricht 

etwas über einer Periode des 32768Hz Quarzes der Uhr. 

97


Listing 5.5 und 5.6 vorgestellte Code des Softwareupdates zur Synchronisierung verwendet. 


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

a) 

b) 

c) 


Bytes gesendet 

Bytes empfangen 

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 Knoten 15 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! 


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“ Kollisionen 

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


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 zeitgleich 

auf dem gleichen Übertragungskanal Daten, was zur Zerstörung beider Pakete 

führt. Aufgrund des eingesetzten Kanalzugriffsverfahrens 16 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 ” logischen“ 

Kollisionen wäre einiges an Aufwand – verbunden mit weiterem Overhead – zu 

treiben 17 . 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. 

geweckt worden von Knoten 20! Kanal: 2 

DATASETUP (speed 7, power 6) abgeschlossen. 

Beginne mit Datenaustausch! 

neue Nachricht von: 34 für: 29 




DATAFINISH Paket erhalten! 

Sende nun ausgehende Nachrichten 

Sende DATAFINISH 

Ü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

150 

140 

130 

120 

110 

100 

90 

80 

70 

60 

-8 -7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7 8 


Signalstärke / Abstand (indoor) Drehung um die eigene Achse 

150 

140 

130 

120 

110 

100 

90 

80 

70 

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


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 entwickeln 

1 , auf vielen Knoten gleichzeitig zur Ausführung zu bringen 2 und anschließend 

auszuwerten 3 , 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 

1Hardware-Abstraktion, Funktionen für den Versand bzw. Empfang von Datenpaketen, ... 

2Kabelloses Software Deployment 

3Laufzeitprotokollierung, Messung der Akkuspannung, ... 

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 realisieren 4 . 

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 

Netz 5 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 Ü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. . . . . . . . . . . 3 

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

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). . . . . . . . . . . . . . . . . . . . 10 

2.2 Szenario Kamerasensorknotennetzwerk (aus [16]) . . . . . . . . . . . . 11 

2.3 Einsatzszenario ” Positionsbestimmung“ (aus [24]) . . . . . . . . . . . . 12 

3.1 Übersicht Hardwareplattform Diagramm . . . . . . . . . . . . . . . . . 18 

3.2 Übersicht Hardwareplattform Foto . . . . . . . . . . . . . . . . . . . . 19 

3.3 Übersicht über die Messwerte der Leistungsaufnahme des Systems während 

verschiedener Betriebsmodi. . . . . . . . . . . . . . . . . . . . . . . . . 23 

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.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 

105


4.1 Grober Überblick über die zweigeteilte Softwarearchitektur. Gezeigt werden 

die wesentlichen Komponenten der Firmware und der Anwendung. 32 

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. . . . . . . . . . . . . . . 34 

4.3 Teilkomponenten der Hauptanwendung . . . . . . . . . . . . . . . . . . 35 

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. . . . . . . . . . . . . . . . . . . 36 

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. . . . . . . 38 

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. . . . . . . . . . . . 39 

4.7 Software Deployment Varianten: a) an einzelne Knoten über die serielle 

Schnittstelle und b) Übertragung an viele Knoten gleichzeitig per Funk. 43 

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. 45 

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. . . . . . . . . . . . . . . . . . . . . . . . . . 47 

4.10 Aufbau der direkt von der Firmware verwendeten Pakete. . . . . . . . . 48 

106


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“. . . . . . . . . . . . . . . . . . . . . . . . 

” 

4.12 Aufbau der für das kabellose Softwareupdate verwendeten Pakete. . . . 

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 Fehlersitua- 

50 

51 

tionen, mit denen das Protokoll umgehen kann, gezeigt. . . . . . . . . . 

4.14 Aufbau der Pakete, die zum Erstellen der Nachbarschaftsbeziehungen 

52 

verwendet werden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

4.15 Aufbau der für das Verwalten von Routen verwendeten Pakete ( RREQ“, 

” 

” RREP“ und RERR“). . . . . . . . . . . . . . . . . . . . . . . . . . . 

” 

4.16 Behandlung eines eingehenden Route-Request“-Paketes . . . . . . . . 

” 

4.17 Behandlung eines eingehenden Route-Reply“-Paketes . . . . . . . . . . 

” 

4.18 Behandlung eines von Knoten A“ eingehenden Route-Error“-Paketes. 

” ” 

4.19 Legende der Signalisierung und Routenmanagement Grafik . . . . . . . 

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 

58 

60 

61 

63 

64 

Routingtabelle von Knoten A im jeweiligen Schritt gezeigt. . . . . . . . 

4.21 Aufbau der zum Nachrichtenaustausch verwendeten Pakete. (DATASE- 

64 

TUP, 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! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

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 

66 

über D wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

5.1 Übersicht über das Verzeichnis der implementierten Software. Mit Ausnahme 

der Hauptanwendung sind nur die Unterordner und nicht die 

Dateien gezeigt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

5.2 Verteilung der über 22000 Zeilen Programmcode auf Firmware, Hauptanwendung 

und die übrigen Anwendungen. . . . . . . . . . . . . . . . . 74 

107


5.3 Verschiedene Zugriffsarten auf die Register des Funkchips[36] . . . . . . 75 

5.4 Bildschirmfotos während eines erfolgreichen Softwareupdate-Durchlaufs 83 

5.5 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 40s 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


[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

[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). http://www. 

ronetix.at/software.html. 

[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


[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

Diplomarbeit ? Konzeption und Evaluierung eines ... - CES

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?